Stephan A. Rickauer wrote: > Currently, our Institute investigates alternative operating systems > compared to Linux. Apart from technical issues we are also concerned > about lifecycle management as well. We simply don't want to > reinstall/upgrade an entire OS all half year, which is the main reason, > why we will no longer use half-commercial system like SuSE (= 2 year > lifecycle for 'free' version).
When I was working as an independant consultant, I would occassionally get calls from people who were only interested in one thing: how much I charge per hour. That's it. Wouldn't tell me about the job, or ask me how many hours I felt a job might take. They apparently believed all people could accomplish the same job in the same number of hours, or that they would all do the same job. Be careful when you pick measures for a project. There is often a lot more to it than one simple measure. :) > The question is how you OpenBSD guys handle the upgrade issue. From the > website I learned that -STABLE is maintained for only one year (= two > releases). Given that upgrading by skipping one release is not > recommended, does that mean one needs to upgrade the entire OS every > half year? I couldn't get that from the website. First of all, you get lots of points for worrying about "lifecycle". Too many people measure the success of a project by "does it work NOW?", not "how long can I keep it working? How do I upgrade it? How do other people maintain it? How do I fix it when it breaks?", etc. There are a lot of measures to how the upgrade process works out. Here are SOME: 1) Frequency (i.e., how often do you need to do upgrades) 2) Difficulty (how much human work is involved) 3) Ugency (when an upgrade is needed, how important is it that it is done *NOW*) 4) Downtime (when you do the upgrade, do you need to do it at 3:00am, or can you do it during production hours?) 5) Flexibility (what cute tricks can you do to make the process simpler, safer, easier, etc.) Yes, OpenBSD had new releases every six months, and only supports a previous release with patches for one past release, so your frequency is going to be higher. So, at the outside, you are looking at an upgrade every year, and I'd recommend staying with the active release, rather than jumping two releases every upgrade cycle. So that looks bad (kinda like my hourly rate. :) HOWEVER...the rest starts looking pretty good. :) How difficult is it to upgrade? Usually, "Not Very". Granted, we don't have an automatic tool that does all the work (and thinking) for you, but all things considered, I'd rather that *you* be closely involved in the upgrade of your machines, rather than having some magic happen in the background. It certainly makes it easier to deal with "issues" if something goes wrong, as you have a much better idea what happened. How "urgent" are upgrades? Usually, not very urgent at all. That's why you run OpenBSD, right? Look at the errata pages...not a lot of them are security issues for many of the applications that OpenBSD is put to. That isn't to say they aren't important or shouldn't be fixed...but usually it is not a "ok, we gotta shut down the main firewall or router NOW to implement a fix, as it is critical and exploits are running around NOW!" 4) How much downtime do you experience when you do the upgrade? Well, for certain applications, you could configure your systems for ZERO downtime (CARP'd firewalls -- upgrade one, reboot, upgrade the other, reboot). Other apps, the upgrades will usually involve minimal downtime. Beware of systems that make upgrades too painless -- friend of mine recently had his Debian system rooted, he suspects a hole in the kernel. While he had been using the "wonderful" Debian update process, he had skipped that little detail about updating the kernel and rebooting, "too inconvienent". When you are sitting on the Internet, I think "convience" has to be secondary to security. 5) Flexibility: wow. I love OpenBSD. :) Granted, learning a lot of this will come from time and usage, and looking at YOUR particular applications. The ability to test your installs on "not identical" hardware is very nice. The siteXX.tgz stuff is great. The simplicity of the installer is just magical. Anyway...look at the whole picture, not just how often you have to do upgrades. Remember: there are reasons we don't support old releases very long -- in addition to the work required, there is the fundemental "moving forward" philosophy of OpenBSD. With every release, they try to make the OS more secure and more correct. Not only does pushing stuff back to old releases take time and effort, but some stuff just won't go easily. The malloc(3) upgrades were a huge improvement to security, but pushing them back to 3.6 or before isn't going to happen. We don't want you to think that because you run 3.5-stable, that you are as safe or as reliable as you are if you are running -current. Lifecycle has to be part of your planning -- if you can push off a "problem" for two years, you may just hope it isn't your problem then and never deal with it. If you know that every six months to a year you should upgrade, and put that into your planning now, overall your life will be easier. Nick.
