> I would skim the documentation for the command to run, or the configuration to enter, only to get error messages in response. Then a period of frantic searching and trial and error would follow. Until I finally got it right. Once it worked, I reread the original documentation and saw that the answers were right there all along. Crystal clear. And yet somehow it did not register the first time. This happened on multiple occasions.
Not that I disagree, but in this case that is really not the point of what I quoted.
The point is that often, before you reach some level of understanding, you can read the docs 5 times and not find the answers you are looking for, even though they are there! As soon as you reach the right level of understanding, then the docs are perfect!
haha thanks this seems so oddly familiar. setting up openbsd on a vps slowly. each problem as you write, stumped, searching frustratedly. only to find the answer staring me in the face in the docs i definitely tried to read the first time round :')... getting slowly more into the 'read it slowly and take notes'. litterally every issue :D. they say these man pages / docs are the best. they really are. maybe there is some learning curve to transition from bad documentation to good documentation...
either way, thanks for writeup, definitely going to reread it better and maybe it will save me some fallingonmyface soon!
If you forget about the security focus that only started when Theo de Raadt got pwned by N3tBSD h4xx0rz, it is one of the best OS experiences the interwebs has to offer.
It has gotten a lot friendlier than it used to be too. It used to be that you had to build your own -CURRENT every week if you wanted to have something akin to an update.
Nowadays, you can run a binary update every six months and you even get binary patches for the errata in the interim. And if you need to patch your kernel you can grab it from GitHub.
I had a small board from 10 years ago I wanted to turn into a VPN and I just had to boot it, connect the serial adapter, download a new bsd.rd, and it was fresh and ready to go again.
It's sad that they had to let VAX and other legacy platforms go with the switch to clang, but, if some hardware has ever worked in OpenBSD, it is likely to keep working decades from now.
I used Amsterdam BSD two years back to scratch my itch. It was a no nonsense, perhaps perfect way to try out OpenBSD.
The thing keeping me from using OpenBSD/FreeBSD on my new production app is I don't know what kinds of issues I may run into compared to Debian stable on a fairly beefy dedicated server.
My new app has dependancies:
a) http reverse proxy. No problem
b) Java 21 / Clojure 1.12. JDK 21 virtual threads is a must. Unclear what level of support/quality can be expected on OpenBSD or FreeBSD.
Beautiful, thoughtful writing. In an era where taking time to understand something thoroughly seem to fall to the wayside over skimming, this warmed my heart: "Originally I planned to make this post a simple recipe. Just follow these steps, and you have your website running in no time. But now I know it won't work like that. At least not for everyone. Instead, I'll just give you the list of resources I used and the first version of the configuration files that worked. The ingredient you need to add is some time and effort".
As a somewhat more senior OpenBSD user (daily driver on my work laptop, work desktop, maintaining two servers, and reading misc@ and tech@), I think you can drop your reliance on relayd(8) and make your configuration much simpler. Yes, you lose caching granularity, but I doubt you see the amount of traffic needed to justify monthly and annual cache limits. Here is a sketch which I have typed out without any testing.
/etc/acme-client.conf
domain ewintr.nl {
domain key "/etc/ssl/private/ewintr.nl.key"
domain full chain certificate "/etc/ssl/ewintr.nl.fullchain.pem"
sign with letsencrypt
}
domain vrijkorteverhalen.nl {
domain key "/etc/ssl/private/vrijkorteverhalen.nl.key"
domain full chain certificate "/etc/ssl/vrijkorteverhalen.nl.fullchain.pem"
sign with letsencrypt
}
/etc/httpd.conf:
types {
include "/usr/share/misc/mime.types"
}
server http {
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 301 "https://$HTTP_HOST$REQUEST_URI"
}
}
server "ewintr.nl" {
listen on * port 80
listen on * tls port 443
root "/htdocs/ewintr.nl"
tls {
certificate "/etc/ssl/ewintr.nl.fullchain.pem"
key "/etc/ssl/private/ewintr.nl.key"
}
location match "/linklog/%d*/links%-([%d%-]*)" {
block return 302 "$REQUEST_SCHEME://$HTTP_HOST/linklog/#links-%1"
}
location "/feed/" {
block return 302 "$REQUEST_SCHEME://$HTTP_HOST/atom.xml"
}
location "/quick-go-test-clycle-with-reflex" {
block return 301 "$REQUEST_SCHEME://$HTTP_HOST/posts/2020/quick-go-test-cycle-with-reflex/"
}
# ---&<---
}
server "vrijkorteverhalen.nl" {
listen on * port 80
listen on * tls port 443
root "/htdocs/vrijkorteverhalen.nl"
tls {
certificate "/etc/ssl/vrijkorteverhalen.nl.fullchain.pem"
key "/etc/ssl/private/vrijkorteverhalen.nl.key"
}
}
Do not forget to add your acme-client calls to crontab(1) (as is of course noted on the manpage).
My philosophy so far is that the shorter my configuration files, the easier it is to read/comprehend, the more defaults I rely on, and the happier I am as a user. Learning to live with defaults and resisting nearly all urges to deviate from them is a virtue that OpenBSD teaches very well.
Now if only I could figure out why streaming 1440p60 x11grab to 1080p60 always leads to massive frame drops if anything else is running on the system (Is it the kernel not being preemptive? Xenocara?) I would have all my own use cases covered.
i didnt understand it until i stumbled on the bsd supp docs that openbsd couldnt be ****** to include. i dont have the sources, but v7 vol2 is close enough:
vol2 contains fuller book like manuals and tutorials for complicated things like ed, C, filesystem, UNIX, etc. and should be your first introduction to UNIX/BSD, while the man(1) program (vol1) serves as a complementary quick reference for experienced users and for short programs that dont need much explanation. sadly V7 wont tell you about the internet because that was started by the "net" releases of 4.3-4.4BSD (see kirk mckusicks history https://www.youtube.com/watch?v=DEEr6dT-4uQ )
for vi, get the PostScript.ps files for the OTHER manual from keith bostics sources (openbsd src only has troff source and no troff):
wouldnt it be nice if installation did this and syspatch patched it and sysupgrade merged it?
openbsd is also not very good at pointing you to the right manual. making them grepable was a small improvement for me.
mkdir man && cd man &&
for n in 1 2 3 4 5 6 7 8 9
do for m in /usr/share/man/man$n{/,/"`machine`"/}*
do test -f "$m" && man $n "`basename $m .$n`" | col -b > "`basename $m`"
done
done
grep relink * | grep kernel
maybe use it to train an LLM, idk.
the 15 min long boot is due to relinking done by /etc/rc
you can try pressing ^T to see whats going on at boot and ^C to skip anything
Very nice read!
This really resonated with me:
> I would skim the documentation for the command to run, or the configuration to enter, only to get error messages in response. Then a period of frantic searching and trial and error would follow. Until I finally got it right. Once it worked, I reread the original documentation and saw that the answers were right there all along. Crystal clear. And yet somehow it did not register the first time. This happened on multiple occasions.
Everyone is so used to garbage documentation, that they go googling instead, but OpenBSD docs are in fact very good.
Not that I disagree, but in this case that is really not the point of what I quoted.
The point is that often, before you reach some level of understanding, you can read the docs 5 times and not find the answers you are looking for, even though they are there! As soon as you reach the right level of understanding, then the docs are perfect!
haha thanks this seems so oddly familiar. setting up openbsd on a vps slowly. each problem as you write, stumped, searching frustratedly. only to find the answer staring me in the face in the docs i definitely tried to read the first time round :')... getting slowly more into the 'read it slowly and take notes'. litterally every issue :D. they say these man pages / docs are the best. they really are. maybe there is some learning curve to transition from bad documentation to good documentation...
either way, thanks for writeup, definitely going to reread it better and maybe it will save me some fallingonmyface soon!
If you forget about the security focus that only started when Theo de Raadt got pwned by N3tBSD h4xx0rz, it is one of the best OS experiences the interwebs has to offer.
It has gotten a lot friendlier than it used to be too. It used to be that you had to build your own -CURRENT every week if you wanted to have something akin to an update.
Nowadays, you can run a binary update every six months and you even get binary patches for the errata in the interim. And if you need to patch your kernel you can grab it from GitHub.
I had a small board from 10 years ago I wanted to turn into a VPN and I just had to boot it, connect the serial adapter, download a new bsd.rd, and it was fresh and ready to go again.
It's sad that they had to let VAX and other legacy platforms go with the switch to clang, but, if some hardware has ever worked in OpenBSD, it is likely to keep working decades from now.
Sent from my OpenBSD M2 MacBook.
Very good read, made me want to try OpenBSD again after a story similar to yours.
thanks for the good read.
I used Amsterdam BSD two years back to scratch my itch. It was a no nonsense, perhaps perfect way to try out OpenBSD.
The thing keeping me from using OpenBSD/FreeBSD on my new production app is I don't know what kinds of issues I may run into compared to Debian stable on a fairly beefy dedicated server.
My new app has dependancies:
a) http reverse proxy. No problem
b) Java 21 / Clojure 1.12. JDK 21 virtual threads is a must. Unclear what level of support/quality can be expected on OpenBSD or FreeBSD.
c) Postgres 17 (TimeScale)
I thought ast (Andrew Tanenbaum) would cycle past and kick you in the water and say "This is Minix territory".
Beautiful, thoughtful writing. In an era where taking time to understand something thoroughly seem to fall to the wayside over skimming, this warmed my heart: "Originally I planned to make this post a simple recipe. Just follow these steps, and you have your website running in no time. But now I know it won't work like that. At least not for everyone. Instead, I'll just give you the list of resources I used and the first version of the configuration files that worked. The ingredient you need to add is some time and effort".
As a somewhat more senior OpenBSD user (daily driver on my work laptop, work desktop, maintaining two servers, and reading misc@ and tech@), I think you can drop your reliance on relayd(8) and make your configuration much simpler. Yes, you lose caching granularity, but I doubt you see the amount of traffic needed to justify monthly and annual cache limits. Here is a sketch which I have typed out without any testing.
/etc/acme-client.conf
/etc/httpd.conf: Do not forget to add your acme-client calls to crontab(1) (as is of course noted on the manpage).My philosophy so far is that the shorter my configuration files, the easier it is to read/comprehend, the more defaults I rely on, and the happier I am as a user. Learning to live with defaults and resisting nearly all urges to deviate from them is a virtue that OpenBSD teaches very well.
Now if only I could figure out why streaming 1440p60 x11grab to 1080p60 always leads to massive frame drops if anything else is running on the system (Is it the kernel not being preemptive? Xenocara?) I would have all my own use cases covered.
i didnt understand it until i stumbled on the bsd supp docs that openbsd couldnt be ****** to include. i dont have the sources, but v7 vol2 is close enough:
https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/bswv7.html
vol2 contains fuller book like manuals and tutorials for complicated things like ed, C, filesystem, UNIX, etc. and should be your first introduction to UNIX/BSD, while the man(1) program (vol1) serves as a complementary quick reference for experienced users and for short programs that dont need much explanation. sadly V7 wont tell you about the internet because that was started by the "net" releases of 4.3-4.4BSD (see kirk mckusicks history https://www.youtube.com/watch?v=DEEr6dT-4uQ )
for vi, get the PostScript.ps files for the OTHER manual from keith bostics sources (openbsd src only has troff source and no troff):
https://sites.google.com/a/bostic.com/keithbostic/the-berkel...
the interactive vi tutorial is also great: assuming you installed the relevant src tar: wouldnt it be nice if installation did this and syspatch patched it and sysupgrade merged it?openbsd is also not very good at pointing you to the right manual. making them grepable was a small improvement for me.
maybe use it to train an LLM, idk.the 15 min long boot is due to relinking done by /etc/rc
you can try pressing ^T to see whats going on at boot and ^C to skip anything
or just delete it from /etc/rc
you are now on the beginning of the long, tedious, futile and soul crushing journey of dealing with documentation and source code on openbsd.typo
should beJust ask a LLM what are the commands to perform what you need to do.
We are indeed living in new times.
But don’t let that get in the way of the Amsterdam socializing :)