The practical result of OpenBSD's support policy

January 29, 2015

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.

Comments on this page:

By Ewen McNeill at 2015-01-29 04:41:56:

I'd tend to agree with your assessment that there are quite a few OpenBSD installs -- especially in "appliance" style roles -- which are "as installed, basically until a forklift upgrade happens". Because the only practical way to safely upgrade them as a critical production role is a forklift upgrade -- build a new one and swap it in -- even if it's not brand new hardware per se. I certainly know of at least as many in-production/formerly-in-production OpenBSD installs that stayed as-is for years after formal end of support as I do ones that got upgraded every year.

For a project that does not get revenue from support -- and thus supporting N releases for Y years is probably just more-than-linear additional work for (much?) less than linear reward -- the "only support two release, releases are every 6 months" may well be the right tradeoff. (The other obvious model is the "enterprise distro" model, of longer support for a fee.) And maybe 12 months is too long if your aim is to encourage users to upgrade every 6 months or stop bothering you (so eg, 7-9 months might be "better" by those criteria).

But extrapolating the "we only support it for N months" to "therefore users will upgrade at least every N months" seems to show a wilful ignorance of how the real world works. "Continuous upgrade" might be the future, through automated upgrades. But for people to trust that you need to be really careful not to break things through those upgrades. Software engineering does not seem to have reached the point of doing that reliably yet.


By -dsr- at 2015-01-29 07:45:08:

Once upon a time, we had OpenBSD for our SSH bastion hosts.

The job of a bastion host doesn't change much over the years, but other things change. People find bugs in software that was presumed to work well. Sometimes remotely exploitable bugs. "No remotely exploitable bugs by default, at shipping time" is not useful three years later.

We also moved to a policy of not allowing servers to have SPOF disks. Turns out that OpenBSD did not (at least at that time) have good support for cheap disk mirroring.

Now those bastion hosts run Debian Stable. They get regular security updates from a team that has a good track record. We can generally upgrade between major versions in-place. (Still worried about Jessie.)

Written on 29 January 2015.
« A thought about social obligations to report bugs
I've come to believe Django's way of defining database tables is wrong »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 29 01:07:27 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.