Wandering Thoughts archives

The practical result of OpenBSD's support policy

Recently I read Ted Unangst's long term support considered harmful (via), where he mentions OpenBSD's relatively short term support policy (it's one year at most and less in practice) and then says:

Now on the one hand, this forces users to upgrade at least once per year. On the other hand, this forces users to upgrade at least once per year. [...]

Oh, how this makes me laugh. Sadly.

We have a not insignificant number of OpenBSD firewalls. I don't believe that any of them are running a currently supported OpenBSD release and if they are it's not because we upgraded them, it's because they were set up recently. Other than that we leave the firewalls strictly alone until we have to change them for some reason.

(One of the reasons we never attempt to upgrade firewalls is that OpenBSD more or less explicitly doesn't have backwards compatibility between releases in things like PF; OpenBSD can and has changed PF syntax, rules, and rule handling around from release to release. When the core of your firewall may have changed, upgrades are not a 'cvs up; recompile', they are a full exercise of 'install a spare machine then retest and requalify everything from scratch' (which in our small environment is done by hand on scrounged hardware). Deployment of the result has its own pains.)

I don't think we're alone here; I suspect that there are lots of people running OpenBSD releases that are out of support. OpenBSD's short support period certainly accomplishes the goal of less (valid) bug reports to OpenBSD and less work for OpenBSD to do, but it doesn't necessarily either get users to upgrade or reduce the actual bugs that they may encounter. Instead the effect of this short support period and lack of long term support is to maroon more OpenBSD users without any support at all.

I doubt that OpenBSD cares about such marooned users, but as usual I feel like mentioning the practical results of a policy, not just the theoretical ones.

All of this leads me to laugh very hollowly at Ted Unangst's conclusion that:

A one year support window isn't too short; it's too long.

I'm pretty certain that the major goal this would achieve would be to allow OpenBSD to reject even more bug reports.

(There is a general lesson here but I'm going to leave it to another entry.)

Sidebar: OpenBSD and practical support

To put it very simply, we aren't worried much by the lack of support we have with our current firewalls because we don't expect any support and I don't think we'll ever file any bug reports with OpenBSD even if we find issues (which we do from time to time). Our attitude on the state of OpenBSD is 'we get what we get and it's nice if it works'. If it doesn't work, we find something that does.

(This is why we ran Fedora L2TP VPN servers for a while.)

Some people might consider this lack of bug reports to be antisocial, but I have some opinions for them.

What /etc/shells is and isn't

In traditional Unix, /etc/shells has only one true purpose: it lists programs that chsh will let you change your shell to (if it lets you do anything). Before people are tempted to make other programs use this file for something else, it is important to understand the limits of /etc/shells. These include but are not limited to:

• Logins may have /etc/passwd entries that list other shells. For example, back when restricted shells were popular it was extremely common to not list them in /etc/shells so you couldn't accidentally chsh yourself into a restricted shell and then get stuck.

  Some but not all programs have used the absence of a shell from /etc/shells as a sign that it is a restricted shell (or not a real shell at all) and they should restrict a user with that shell in some way. Other programs have used different tests, such as matching against specific shell names or name prefixes.

  (It's traditional for the FTP daemon to refuse access for accounts that do not have a shell that's in /etc/shells and so this is broadly accepted. Other programs are on much thinner ice.)

• On the other hand, sometimes you can find restricted shells in /etc/shells; a number of systems (Ubuntu and several FreeBSD versions) include rbash, the restricted version of Bash, if it's installed.

• Not all normal shells used in /etc/passwd or simply installed on the system necessarily appear in /etc/shells for various reasons. In practice there are all sorts of ways for installed shells to fall through the cracks. Of course this makes them hard to use as your login shell (since you can't chsh to them), but this can be worked around in various ways.

  For example, our Ubuntu systems have /bin/csh and /bin/ksh (and some people use them as their login shells) but neither are in /etc/shells.

• The (normal and unrestricted) shell someone's actually using isn't necessarily in either /etc/shells or their /etc/passwd entry. Unix is flexible and easily lets you use $SHELL and some dotfile hacking to switch basically everything over to running your own personal choice of shell, per my entry on using an alternate shell.

  (Essentially everything on Unix that spawns what is supposed to be your interactive shell has been clubbed into using $SHELL, partly because the code to use $SHELL is easier to write than the code to look up someone's /etc/passwd entry to find their official login shell. This feature probably came into Unix with BSD Unix, which was basically the first Unix to have two shells.)

• Entries in /etc/shells don't necessarily exist.
• Entries in /etc/shells are not necessarily shells. Ubuntu 14.04 lists screen.

• Not all systems even have an /etc/shells. Solaris and derivatives such as Illumos and OmniOS don't.

In the face of all of this, most programs should simply use $SHELL and assume that it is what the user wants and/or what the sysadmin wants the user to get. It's essentially safe to assume that $SHELL always exists, because it is part of the long-standing standard Unix login environment. As a corollary, a program should not change $SHELL unless it has an excellent reason to do so.

Note particularly that a user's $SHELL not being listed in /etc/shells means essentially nothing. As outlined above, there are any number of non-theoretical ways that this can and does happen on real systems that are out there in the field. As a corollary your program should not do anything special in this case unless it has a really strong reason to do so, generally a security-related reason. Really, you don't even want to look at /etc/shells unless you're chsh or ftpd or sudo or the like.

(This entry is sadly brought to you by a program getting this wrong.)

ZFS should be your choice today if you need an advanced filesystem on Unix

The other day I ran down why ZFS is your only real choice on Linux if you need an advanced filesystem. Well, it's not just Linux. I don't know enough about the landscape of filesystems on other Unixes to confidently say it's your only choice on non-Linux Unixes, but I do think it is by far your best choice for this job.

Let's start with the first and biggest reason: ZFS works and has for years. At this point ZFS has been running in production environments (some of them very big and/or demanding) for more than half a decade. Yes, development is still happening and people are still finding issues (just as they are with essentially any filesystem), but the bulk of ZFS (in code and features) is extensively battle tested and is highly unlikely to blow up on you. Using ZFS puts you nowhere near the bleeding edge, and I don't think there's any other advanced Unix filesystem that can really make that claim.

The second reason is that ZFS is cross-platform, and in fact with care and advanced planning you can move ZFS pools between Unixes (instead of just shifting from one Unix to another for your next storage server build or the like). Chosing ZFS does not lock you into Solaris the way it once did; these days you can run ZFS reasonably sensibly on your choice of Oracle Solaris, anything Illumos based (eg OmniOS or SmartOS), FreeBSD, and Linux. People are running ZFS in production on all of these. This covers almost all of the gamut of major remaining Unixes and gives you plenty of choices as far as style, administration, user level tools, and so on. And if your first choice of Unix for ZFS turns out to have problems, well, no big deal; you can move your basic architecture to another Unix. In a way you can treat ZFS much the way you treat applications like Apache or Exim and basically host it on the Unix substrate of your choice.

(Yes, yes, the OpenBSD and NetBSD and DragonflyBSD and OS X Server crowds are now annoyed at my over-generalization. Sorry, you're all relatively marginal in this space at this time.)

Finally, and it's high time I said this explicitly, ZFS not merely works but it's decently good and has generally made the right design decisions. I can quibble with some of its architectural choices and it's (still) missing a few features that people continually yearn for, but on the whole it is not merely a filesystem that is there but a filesystem that is actually nice, with choices that are sensible and usable.

This last reason is actually kind of important. If there are no other production ready advanced filesystems on Unixes (Linux or otherwise) then ZFS would win today by default. But if it kind of sucked, you might want to stick with current filesystems and wait unless data integrity was really, really important to you. As it is ZFS is decent and deciding to use ZFS doesn't constrain your Unix choices much, so I think you should seriously consider using ZFS for its data integrity advantages.

(There are any number of situations where using ZFS is still not worth the hassles or the risks. Or to be direct, ZFS is certainly not to the point on Linux and maybe FreeBSD where I think using it is a slam dunk obvious choice. Of course on Solaris or Illumos you basically have no option, so go with the flow.)