Michael W Lucas - Absolute OpenBSD

2003, No Starch Press | 1-886411-99-9

This time (especially since this book is a big one) I’m going to take notes here as I go rather than write them up when I’m done reading. (I’ve just started though so not much to see here yet!)

Opening rant

I had a rant here about the silly noob-shaming tone in this book. It’s annoying, but I’ve since chilled out about it. Ok! Now that that’s out of my system, I’ll focus on the good things in this book from here on out – there are lots. My humorless attitude toward the tone aside, Lucas is a great writer and each section of the book I’ve read so far is packed with practical information, historical context, and a pretty inspiring thoroughness.

Paritioning for installation

The book goes into enough detail about the why of the OpenBSD partitioning philosophy that I feel better equipped to make a decision about the partitioning scheme I’ll use on my laptop. There is some interesting reasoning behind the partitioning that extends beyond security considerations. From the security standpoint, it makes sense that you might not want to allow files (which could be malicious programs) to have setuid or setgid capabilities allowing them to run as other users, like root. It’s a kind of sandboxing for a partition which might store untrusted files like ones downloaded from the internet. I’m not really a security nut despite my interest in OpenBSD (which is driven primarily by UNIX-curiosity and a desire for simple human-audited tools wherever possible) but keeping a sandboxed partition for untrusted files actually makes a lot of sense.

Another reason behind the default partition scheme is to put certain parts of the system on faster parts of the disk – something I never even think about anymore since all of my machines boot from an SSD, but if you’re installing OpenBSD onto a disk with a spinning platter in the 90s, I guess the speed variance between different physical sections of the disk could be enough to make it worthwhile to put your root and swap partitions first on the disk. I’m not totally sure, but I think that must mean those disks were putting their initial sectors at the outer edge and working inward, and the speed gain would be from the advantage of having more bits per track on the outer rings, so you might not need to do as much track switching when reading from the disk? (Oh well yes, Lucas actually addresses this directly in the discussion of swap: outer rings are faster, I guess because of the latency of switching tracks but that isn’t explicitly mentioned.)

Anyway! It’s not a concern (for me) anymore, and neither is having to worry about supporting machines with a BIOS that can only read the first ~512MB of the disk.

Another rationale for partitioning that’s mentioned is to keep your partition with /var or wherever you put logs at some reasonable size to give it a hard cap preventing it from filling up the entire disk and making it difficult to then actually use the system to recover the system. I’ve actually seen this happen a few times on work systems unfortunately, but even on my personal laptop I like the idea of having a log partition with a hard cap to prevent runaway log bloat taking down the system.

I’m sort of leaning toward having on big combined root + everything partition, plus capped partitions for untrusted files and another for logs and another for swap. So maybe just four partitions on my laptop? For the VPS proxy, I’ve already got the default partition scheme in place because the hosting provider set the image up like that, and I don’t see any reason to want to change it. On that (virtual) machine all the non-system files (like my website and all the luvsound releases etc) are already mounted on a (virtual) external drive.

Treating /home and /tmp as basically the same would be interesting too. If /usr/local is used mostly for scripts and local programs then /home could just be file storage (as maybe it should be) and lumping it with /tmp on the largest partition would let me keep putting files in haphazard places as I tend to do. The only major change for me would be getting into the habit of always compiling builds into /usr/local and keeping other programs in /usr too.