Re: Lifecycle question [Not again!]
Ladies, some of you may remember the life cycle questions I had asked to this list a few months ago. In that time people partly felt offended by my questions related to OpenBSD's six month cycle compared to long life cycles supported by vendors like Novell and Redhat (for linux, at least). But, a few of you took the time and tried to explain to me how easy, smooth and consistent an OS upgrade with OpenBSD would be (instead of flaming) and why security is always related to progress etc. I am very grateful for that. Since pure theory is never convincing for me, I now took the chance and upgrade 3.7 to 3.8 on my carp firewall setup. And all I wanted to tell you here is that you all were right: It is not just smooth, consistent and easy - it's really fun! The entire upgrade took me less than an hour without one microsecond of down time. Cool. Thanks again, -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question [Not again!]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephan A. Rickauer Sent: Monday, November 14, 2005 9:57 AM Cc: misc@openbsd.org Subject: Re: Lifecycle question [Not again!] Ladies, some of you may remember the life cycle questions I had asked to this list a few months ago. In that time people partly felt offended by my questions related to OpenBSD's six month cycle compared to long life cycles supported by vendors like Novell and Redhat (for linux, at least). But, a few of you took the time and tried to explain to me how easy, smooth and consistent an OS upgrade with OpenBSD would be (instead of flaming) and why security is always related to progress etc. I am very grateful for that. Since pure theory is never convincing for me, I now took the chance and upgrade 3.7 to 3.8 on my carp firewall setup. And all I wanted to tell you here is that you all were right: It is not just smooth, consistent and easy - it's really fun! The entire upgrade took me less than an hour without one microsecond of down time. Cool. Thanks again, -- Stephan A. Rickauer Any details? Binary upgrade using install discs? Any trouble merging files? I assume you didn't have any packages installed?
Re: Lifecycle question [Not again!]
Will H. Backman wrote: Any details? Binary upgrade using install discs? yes. Any trouble merging files? no. I diffed them all and merged the rare manual changes manually. I assume you didn't have any packages installed? three of which all I could upgrade using 'pkg_add -r'. The only one thing producing trouble was to recompile ftp-proxy from Camiel Dobbelaar which I use since I find it more useful than the system one. Well, actually it wasn't trouble - I just had to do it manually, of course ;) -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question [Not again!]
How's this? http://www.xs4all.nl/~hanb/software/OpenBSD-binary-upgrade/ Or do you like to have the feeling you did it yourself? # Han
Re: Lifecycle question
Theo de Raadt schrieb: The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. I don't understand this whole conversation. Oh, I didn't know my English was so bad ;) Instead, what those vendors give people is a 5 year patch-every-month cycle. It is actually a 'patch-every-week' cycle, speaking of SuSE. And there you don't have this clear distinction between OS and 'programs' since they distribute patches for everything. When one buys a SuSE Linux Enterprise Server, you get binary patches for kernel+modules and applications like MySQL, Apache etc. for five years. Don't ask me *how* they do it - but they do quite well. That is completely unsustainable. The pieces we build upon are advancing too fast. I couldn't tell Linux is advancing slower. I don't buy into that method of operating system componentizatio at all, that you can just keep patching and patching. It was not true 15 years ago, 10 years ago, 5 years ago, and I see no proof that it will be true ever in the future. Well, you may be right when asking for the technically 'better' system - what I didn't do (*please* no flames now ;) ). -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question
On 2005-09-07 10:43, Stephan A. Rickauer wrote: Theo de Raadt schrieb: That is completely unsustainable. The pieces we build upon are advancing too fast. I couldn't tell Linux is advancing slower. I think he was speaking about software in general. I don't buy into that method of operating system componentizatio at all, that you can just keep patching and patching. It was not true 15 years ago, 10 years ago, 5 years ago, and I see no proof that it will be true ever in the future. Well, you may be right when asking for the technically 'better' system - what I didn't do (*please* no flames now ;) ). I believe that what he's trying to say is that both kernel and userland will in 5 years time be much different from today, both for OBSD and Linux. From that perspective it might be questionable to patch a system for 5 years since either you'll end up with pretty much everything changed from the original installation or you'll end up with a 5 years old system with a ton of patches. In the first case it would probably be much quicker to make a large up- grade every 6th month than applying many small patches every week. In the second case it will be harder to create good patches since the systems the bugs are found in will be very different to the ones the patches have to be made for. -- Erik Wikstrvm
Re: Lifecycle question
Theo de Raadt wrote: If this is what your real agenda is -- baiting -- then you should consider staying off our project's mailing lists. It is not about baiting, but about learning. Learning involves asking questions. Questions may offend people. It is not my intention to upset people as stated often enough in previous mails I have written to that very list. If you feel attacked already then I recommend founding a religion where popes and masters are sacrosanct. I am totally serious. If you came to pick fights, stay away. I am serious as well. I came to learn and I will stay to learn, if you like it or not. Stephan -- The philosopher Alexis de Tocqueville observed that people may be hesitant to speak freely not because of fear of government retribution but because of social pressures. When an individual announces an unpopular opinion, he or she may face the disdain of their community or even be subjected to violent reactions. from Wikipedia
Re: Lifecycle question
On 9/5/05, Giedrius Rekaius [EMAIL PROTECTED] wrote: On Mon, 05 Sep 2005 15:52:50 +0300, Stephan A. Rickauer [EMAIL PROTECTED] wrote: I am already in love with it, since I plan to use it as a HA-firewall using carp and pfsync. Problem here is just that it looks as if I had to reinstall it all year ... Hi Stephan, If it's just a firewall, and you won't need any new features (wich will come with some new release), then why should you upgrade? Just configure it, put the server somewhere in the dark corner and it will handle it's job very nicely :) If it is a firewall it is a very dangerous thing to do. I would recommend that you not only upgrade for every release but also apply all security patches as soon as they are released. Otherwise your *OpenBSD firewall* can go for a toss :-) kind regards Siju
Re: Lifecycle question
On 9/5/05, Stephan A. Rickauer [EMAIL PROTECTED] wrote: Ramiro Aceves schrieb: I like and use both systems. But If you are concerned about easy upgrading, I would recommend Debian GNU/Linux (no flamewars please ;-) ). It is a very stable system that it is upgraded slowly, about 2 years (they whant to speed it in the future to 18 month cicle). You will not We have FreeBSD, Debian Sarge and SuSE 9.0 9.1 9.3 as productive systems running. Technically, we're kind of aware of the differences. system. If you want a desktop with hundreds of packages installed, I find Debian more practical to upgrade. Both systems allow you to tweak the internals as you want. Both come with the base system and the remaining applications. We use SuSE on ~50 desktops in our Institute and are quite happy (well, we had to tune it a bit to make it use apt-get). Debian is my first choice for non-BSD servers, but I would not use it for dekstop purposes still. Well, don't wan't flame wars here either ;) Anyway, I am getting in love with OpenBSD because of its securyty, simplicity, stability, clarity, superb documentation and coherency. If I would have to build a server conected to the dangerous Internet, I will undoubtlely use OpenBSD. I am already in love with it, since I plan to use it as a HA-firewall using carp and pfsync. Problem here is just that it looks as if I had to reinstall it all year ... If that's the case, then you just take one down, upgrade it, bring it back online, take the other down, upgrade it, bring it back online. I fail to see the issue here. 'nuff said. Thanks, -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch -- Abe Al-Saleh And then came the Apocolypse. It actually wasn't that bad, everyone got the day off and there were barbeques all around.
Re: Lifecycle question
Abraham Al-Saleh schrieb: I am already in love with it, since I plan to use it as a HA-firewall using carp and pfsync. Problem here is just that it looks as if I had to reinstall it all year ... If that's the case, then you just take one down, upgrade it, bring it back online, take the other down, upgrade it, bring it back online. I fail to see the issue here. 'nuff said. The issue is that I don't have only two firewalls but also many, many others plus even more ;) I am asking 'generally' and not because I don't have the time to update *two* machines twice a year. Not to mention that upgrades with other OS's are even painful _with_ HA setup ... As an Insitute we have limited resources in terms of personal AND money. Therefore, I am forced to rethink any strategy twice. Thanks to all comments - had been very helpful so far. Stephan
Re: Lifecycle question
On 9/6/05, Stephan A. Rickauer [EMAIL PROTECTED] wrote: Not to mention that upgrades with other OS's are even painful _with_ HA setup ... As an Insitute we have limited resources in terms of personal AND money. Therefore, I am forced to rethink any strategy twice. Thanks to all comments - had been very helpful so far. I'm responsible for 4 different OpenBSD-based firewalls and 4 different customers. One locations is carp+pfsync based one with two machines. Last week I upgraded one of the customers to a new release and it took me a total of 30 minutes on-site work. 15 of those were trying to access the firewall in the cramped server room ;-). With planning and an extra set of backups it took me about 1 hour of worktime. This should be able to fit within most limited budgets :-). Once you learn the OpenBSD mindset it is easier to install, upgrade and maintain than most other package based systems. I would say that is it faster to upgrade an OpenBSD box from one release to another compared to Debian (with their wonderful apt-get/dpkg system). The reason is that OpenBSD installations are usually much smaller and leaner and you don't have to download 500MB+ to get a working system. cheers, Nickus
Re: Lifecycle question
Nick Holland schrieb: 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.) I agree. Furthermore, one has to distinguish between upgrades of an entire OS release level and patching a running system. The latter is not an issue here since any OS needs patching all the time. Well, they may differ in frequency etc. again, but the differences are negligible. 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 Ok, that is the key issue here. Upgrading a firewall which has not much software installed at all, which even runs in a HA environemnt etc. is really not a big thing. But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). 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. For those application server beasts mentioned earlier one is not necessarily interested in getting 'new features', even if they made the system more secure. I would not even expect backporting - just deliver patches for security relevant issues, so that one can keep the system running for 2-3 years. 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. Hm. In my case it will be definitely *my* problem and I can now choose how often I would like to have it ;) One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That keeps TCO pretty low compared to a (technically much better) system that I need to reinstall/upgrade 10 times during that period, don't you think? There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ... Well, I am not a programmer, therefore I may not see the effort. Thanks for your comments! -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question
Tobias Weingartner schrieb: This is a systems management issue. It all depends on how you manage your systems. Compartementalizing change, change management, etc. I Exactly. can recommend talking to Fritz Zaucker (tell him I sent ya). He's at ETHZ as well (in EE I think). His team, along with Tobias Oetiker and the guys/gals over there have some experience in this sort of management. Yes, I know those guys. They base their infrastructure on Debian mostly. And they've had the man power to build great system management tools, like SEPP or the ISG Toolchest. The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. Thanks, -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question
On 9/6/05, Stephan A. Rickauer [EMAIL PROTECTED] wrote: The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. I (as many others) use some OpenBSD servers in a business environment. I recently upgraded a server from 3.5 to 3.7 (I chose to skip a release). upgrading the system lasted for about 60 mins, including downloading the new release. about 45 mins of these I spent checking things in /etc (I could have been quicker, but I wanted to use those new pf features ;) application upgrades did cost about 8 hours, with about 6.5 hours for one sngle application which configuration had changed. I think, a firewall could upgrade in about 20 mins. the first one. if you more than one, and they are similiar, its more like 5-10 mins for each following. --knitti
Re: Lifecycle question
--On 06 September 2005 10:16 +0200, Stephan A. Rickauer wrote: There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ... Some problems could be addressed quite simply in an older system, but having that as the stated policy means that all problems fixed in newer code would have to go through a procedure something like: Decide on the severity of the problem as to whether it needs fixing in older code, Check which released versions are affected, Produce and test patches for all of these, Distribute patches, Notify users where security-critical, etc. In areas of code which have undergone major change, just backporting the fix can be quite a task. This may be ok for a vendor, who can dedicate staff to the process of maintaining what, 6 or 7 trees (though some vendors don't seem to do particularly well at the 'test patches' stage), but doesn't seem to fit well with how OpenBSD is developed - fixing problems seems at least equally important as adding new features, so that's a lot of time spent analysing (e.g. as to whether a particular problem fixed might affect security). The people who are capable of that type of analysis usually can find more productive ways to spend their time. But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). There doesn't have to be so much difference, actually. With OpenBSD an upgrade is usually pretty straightforward. The main part of the process (boot from bsd.rd, run the 'upgrade' process) can equally be used for patches and upgrades. With an upgrade the initial step is to read updateXX.html, with a patch you can first create distribution *.tgz files using 'make build' and 'make release' and host them on local ftp (a bit of overkill for one or two machines, but invaluable on a larger network). Obviously there have been major transitions (a.out to ELF, for example) where greater care has to be taken, but these are unusual and well-publicised. Perhaps they can be taken as a cue to carry out a more involved rebuild rather than a simpler upgrade (which often gives a chance to refactor and simplify a complex organically-grown system). With an application server, you often have to pay so much attention to keeping the parts other than the OS up-to-date (which of course are the parts with the most custom configuration), that the time spent on the OS is pretty low in comparison anyway.
Re: Lifecycle question
On Tue, Sep 06, 2005 at 11:00:34AM +0100, Stuart Henderson wrote:
There doesn't have to be so much difference, actually. With OpenBSD an
upgrade is usually pretty straightforward. The main part of the process
(boot from bsd.rd, run the 'upgrade' process) can equally be used for
patches and upgrades. With an upgrade the initial step is to read
updateXX.html, with a patch you can first create distribution *.tgz
files using 'make build' and 'make release' and host them on local ftp
(a bit of overkill for one or two machines, but invaluable on a larger
network).
I usually do it the other way. dirty, but works most of the time.
minimal downtime for sure.
pkg_info | awk '{print $1}' packages-2keep
vi packages-2keep ; leave the bare minimum which will bring the rest
; as dependencies
mkdir /old
mv /bsd /bsd.old
mv bsd /bsd
cp -R /bin /sbin /old/
export PATH=/old/sbin:/old/bin:$PATH
for file in man* comp* base*; do tar -zvxpf $file -C/; done
reboot
then - or pkg_add according to packages-2keep, or ports rebuild
for non-kernel issues tar -zvxpf ... -C/ works like a charm. :-)
--
Igor CacoDem0n Grabin, http://violent.death.kiev.ua/
Re: Lifecycle question
--On 06 September 2005 10:16 +0200, Stephan A. Rickauer wrote: There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ... Development does not stand still. There are *huge* differences in some areas of OpenBSD over two years of time. In many cases, some are designed to block new areas of attack, and to clean-up code in a major way. Forcing you to update at least once every two releases is a good way to make sure you benefit from all these changes. And evaluating those changes, and porting back whatever may have some security relevance is too hard. If you prefer: some developer rewrites some code to clean it up at time T. Then a new attack comes up at time T2 that targets that specific area. We discover that OpenBSD is not affected... well, if the gap between T and T2 is greater than two releases, we do not even check that the old code was affected. This happens more often than you would think.
Re: Lifecycle question
Stephan A. Rickauer wrote: Nick Holland schrieb: ... 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 Ok, that is the key issue here. Upgrading a firewall which has not much software installed at all, which even runs in a HA environemnt etc. is really not a big thing. But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). well...they often are a very similar process. The good news is upgrading OpenBSD is pretty well documented in one place. However, the application servers you mention often will need *application* upgrades, probably more often than OpenBSD does. You will end up doing your upgrades one way or another. Sometimes the applications will just be patched, in other cases, you will have to upgrade to new versions. ... One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That keeps TCO pretty low compared to a (technically much better) system that I need to reinstall/upgrade 10 times during that period, don't you think? not at all. If that Redhat system gets rooted once in five years, you will lose far more than you ever lost in time doing planned upgrades/updates. Your reputation, your client/customer data is worth far more than planned upgrades. There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ... Well, I am not a programmer, therefore I may not see the effort. First of all, you are trivializing the process of making patches. In some cases, yes, it is just a matter of applying the exact same patch in the earlier tree. But that is certainly not always the case. Sometimes the patch needs significant reworking to work on previous versions, and of course, each patch has to be tested on each release that is supported. Let's say a bug is found. It is fixed. A quick look is taken to see what the significance of the bug is. IF there is obviously an implication to the bug (reliability, security), it is published as an errata patch. If not, we just move on. The developers don't spend a huge amount of time looking at the implications of a bug -- it's a bug, fix it. This attitude causes the often-seen fixed six months ago in OpenBSD message on security bulletins. Sometimes people critisize the OpenBSD project because we don't wave our hands and warn people of every bug we find...well, watch the source-changes list, you will see thousands of bugs fixed every year. IF there is clearly a security implication, sure, we let people know, but if it isn't obvious, fix and move on. Here's the gotcha: Most bugs are *potential* security holes. We treat 'em as such. Most other projects are only interested in proof that a bug has security implications. We don't care, it's a bug, fix it. Anyone remember the OpenSSH bug where some people who should have known better were running around encouraging people to *ignore* our warnings and NOT upgrade until we showed the actual bug? And that was one that was CLEARLY a security bug. Any of those fixed and moved on bugs could later be found to be exploitable. OpenBSD 3.5 is not as secure as OpenBSD 3.6 was, patches or no patches. OpenBSD 3.7 is more secure than 3.6. And so on. OpenBSD is about security. Supporting old releases, even if practical, would be defeating the purpose people use OpenBSD for. I can not believe that SuSE or any other Linux vendor can provide good support for five-year-old platforms, regardless of claims. Linux thrashes too much (This week's packet filtering system is X) for this to be practical. Since they clearly don't proactively audit code anyway, how will they even find bugs in obsoleted code from three or four years ago until AFTER they are exploited? Nick.
Re: Lifecycle question
Stephan A. Rickauer wrote: Nick Holland schrieb: 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.) I agree. Furthermore, one has to distinguish between upgrades of an entire OS release level and patching a running system. The latter is not This is somewhat related to what I wrote earlier -- the severity of upgrading an entire OS release level is (with some subjectivity) insignificant compared to what I have seen on other OSes. This is a clear benefit of the short release cycle, and it would be a waste not to use it, e.g. by upgrading only once a year. Consider upgrading an intrusive patch, i.e. something you might already be used to on other OSes, except that it doesn't happen every month but every six months. I say that, because if you'd choose to do the patching as I do (see Nick's point #5), upgrading is pretty much the same work as patching, with only a few extra steps. The largest part of the procedure is explained in the release(8) man page. To recapitulate, the steps required for upgrading OpenBSD manually are 0. Get the install media: Buy a CD, or download, or make your own release(8) at the appropriate time on a local build box tracking -current 1. Install and boot new kernel 2. Untar install sets 3. Update /etc and /dev 4. Reboot This is quite similar to patching the way I do it, except that it's ok to take a shortcut and /etc and /dev may be left alone: 0. Make a new -stable release(8) 1. Install new kernel (shortcut: it's ok not to reboot here) 2. Untar install sets for x in list of sets; do tar xpfz $x -C /; done 3. Reboot This release(8) stuff is the reason why I highly suggest to have some support infrastructure -- a build machine in addition to test boxes. I am using a few self-written scripts for making releases; bloaty sh stuff from 1.5 years ago -- they work nicely, but aren't fit for wide public release and probably in desperate need of a rewrite. Interested parties may request them, though, and I will give them to anyone who can convince me that (s)he doesn't actually need them (wrt release(8) knowledge.) Anyways, with these scripts, that anyone could just as well write for him- or herself, I start a screen and come back later -- two hours later, give or take, I have nice -stable install sets that I can deploy and a bootable install .iso image if I need it. This is lots of work for the computer, and very little to do for me. I estimate some 10 minutes of actual human work, and during the course of following -stable, even more things could be automated than what I currently do. *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). They *are* really similar, see above. :-) One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That As Henning@ is quoted from somewhere in another mail, he has some boxes that were upgraded since OpenBSD 2.7. Those are from more than 5 years ago, and since he even made it through the a.out-ELF change, I can't think of anything that would prevent this from going on another 10 years ... well, except for utter and complete hardware destruction or those boxes becoming too slow for their future purpose(s). Moritz
Re: Lifecycle question
The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. I don't understand this whole conversation. Instead, what those vendors give people is a 5 year patch-every-month cycle. That is completely unsustainable. The pieces we build upon are advancing too fast. I don't buy into that method of operating system componentizatio at all, that you can just keep patching and patching. It was not true 15 years ago, 10 years ago, 5 years ago, and I see no proof that it will be true ever in the future.
Re: Lifecycle question
Stephan A. Rickauer wrote: Tobias Weingartner schrieb: This is a systems management issue. It all depends on how you manage your systems. Compartementalizing change, change management, etc. I Exactly. can recommend talking to Fritz Zaucker (tell him I sent ya). He's at ETHZ as well (in EE I think). His team, along with Tobias Oetiker and the guys/gals over there have some experience in this sort of management. Yes, I know those guys. They base their infrastructure on Debian mostly. And they've had the man power to build great system management tools, like SEPP or the ISG Toolchest. The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. Thanks, Hi, My input on living with a 6 month release cycle... Security is always a compromise. I can accept a 6 month release cycle in the interests of keeping a system exposed to the Internet as proactively secure as possible. I find little comfort in other operating systems where security is more of a management by crisis environment. OMG, an active exploit, we need to patch NOW! That is MUCH more disruptive than a planned upgrade that realistically takes little time. As someone else pointed out, an actual intrusion takes a much larger amount of time (forensics trying to figure out how far the damage goes... try that on 250+ PC's!!). With tools such as expect, serial consoles, the rather simple upgrade cycle, central storage of configuration files (ssh backups nightly of /etc), it can be pretty simple to press a button and have an upgrade happen. I haven't taken it that far myself, because I only maintain 6 OpenBSD firewalls, but I have to say they are on the east cost, central, and western Canada, and I have YET to make an onsite visit (well, that wouldn't happen, but the server would be shipped to me.. darn, I'd love to get to Halifax! :-) ). Anyway, of course you have to make your own decision, and as you have stated, you are not a programmer, so yes, that puts you in a difficult position from an automation point of view. Much kudos to you for having the foresight to be considering this issue. One more point.. from a programmer's point of view... Some patches are trivial to backport. Othere patches can be EXTREMETLY difficult, if not impossible under certain circumstances. There can be a cascading effect of dependencies, and the chances of this increase as you go back in time. If the OpenBSD team promised to support (pick a number) 4 releases back, there is a huge chance that at some point in time, they will just technically NOT be able to back port a security issue to a (pick a number) 2 year old system. In this case, they have to break their promise and say sorry, but we cannot do it and maintain the integrity of the system. To get this patch, you will have to upgrade your system. WHAM out of the blue you need to in a panic plan to upgrade your 100,200, etc systems. With some of the changes in OpenBSD, I would imagine it is difficult to support 1 release back, but they have made that committment, and to my knowledge have never failed. I cannot imagine any software vendor promising a secure system for 5 years! there is absolutely NO WAY to predict the state that computers will be in 5 years from now. Maybe someone will bring a Quantum computer online and our whole concept of security will have to change (and yes, I know I am talking out of my ass here)...but 5 hears is a HUGE amount of time. That would be 10 releases of OpenBSD, and that would date back to OpenBSD 2.7, which is about where I started using OpenBSD. The state of the world has changed significantly since then. Who would have thought that we would have to dedicate so much human time/computer resources to fighting SPAM?? I first set up spamdb on OpenBSD 3.6. There were feature enhancements that made it better for 3.7enough that it justified (in my mind) upgrading. As for application servers, I have a different perspective. Protect them with other servers that you plan on keeping secure. Get the app server working, make sure you have good hardware, and forget about them. I have a few OpenBSD systems internal on networks protected by other hardware that are running probably 3.2. They are not exposed to the Internet, have basic protection for themselves, and I have no intentions on upgrading them until my client wants to upgrade the software...In this case, I have an attitude of if it's not broken, don't fix it. I know that it's a risky policy, but as I said in my first sentence, security is a tradeoff. Best of luck on your decision!
Re: Lifecycle question
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theo de Raadt Sent: Tuesday, September 06, 2005 11:43 AM To: Stephan A. Rickauer Cc: misc@openbsd.org Subject: Re: Lifecycle question The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. I don't understand this whole conversation. Instead, what those vendors give people is a 5 year patch-every-month cycle. That is completely unsustainable. The pieces we build upon are advancing too fast. I don't buy into that method of operating system componentizatio at all, that you can just keep patching and patching. It was not true 15 years ago, 10 years ago, 5 years ago, and I see no proof that it will be true ever in the future. Familiarity breeds content I'm scared to death just patching OpenBSD, but I just did another successful one recently and my stress levels go down every time. While I have been personally using OpenBSD for years, it was only with version 3.6 that I started using it in production. I'm sure that over time, I'll be less scared. I'm nervous when I update Linux, Windows, Novell, OSX, or OpenBSD. I think what scares me about OpenBSD is that _I_ will make a mistake due to the additional manual steps. Most other systems automate more, and I can falsely assume that people smarter than me have worked through the issues. It is hard to get a feel for the true level of risk without statistics. People can give anecdotal evidence about how a Windows security update blew out their accounting server and required a rebuild. You can get those stories for any OS. I think the lifecycle question will seem less disruptive as I become more familiar. Perhaps we should call the current OpenBSD Version 3, Service Pack 7. In the Windows world, there are all kinds of software packages that require a recent service pack. Windows 2000 is supported for many years, but not at the original service pack level if you intend to do anything useful with it. Same thing with OSX.
Re: Lifecycle question
Will H. Backman wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theo de Raadt Sent: Tuesday, September 06, 2005 11:43 AM To: Stephan A. Rickauer Cc: misc@openbsd.org Subject: Re: Lifecycle question The reason why I bother this list is that I am impressed of OpenBSD from the technical point of view. I like its consistency and purity. But in business environments or comparable organizations where money is an issue, one needs to think about system management very carefully, since it has a direct impact on money as well. That's why I can't understand people can really live with the 6 months lifecycle. I don't understand this whole conversation. Instead, what those vendors give people is a 5 year patch-every-month cycle. That is completely unsustainable. The pieces we build upon are advancing too fast. I don't buy into that method of operating system componentizatio at all, that you can just keep patching and patching. It was not true 15 years ago, 10 years ago, 5 years ago, and I see no proof that it will be true ever in the future. Familiarity breeds content I'm scared to death just patching OpenBSD, but I just did another successful one recently and my stress levels go down every time. While I have been personally using OpenBSD for years, it was only with version 3.6 that I started using it in production. I'm sure that over time, I'll be less scared. I'm nervous when I update Linux, Windows, Novell, OSX, or OpenBSD. I think what scares me about OpenBSD is that _I_ will make a mistake due to the additional manual steps. Most other systems automate more, and I can falsely assume that people smarter than me have worked through the issues. It is hard to get a feel for the true level of risk without statistics. People can give anecdotal evidence about how a Windows security update blew out their accounting server and required a rebuild. You can get those stories for any OS. Yeah. But the thing about other OS's doing that is that they have significant data loss, complete dead systems and software that cannot run on that machine until it gets updated. This is not very likely with OpenBSD as the whole system is patched and built as a whole. That's one of the great things about OpenBSD as opposed to some *other* OS's... it's not simply a kernel, or userland, or windows it's the complete package all in one. Brandon
Re: Lifecycle question
On Mon, 05 Sep 2005 15:35:19 +0200, Stephan A. Rickauer wrote: Well, I am thinking of using OpenBSD for our firewalls. Those I do want to upgrade regularly. Not because of features, but because of patches. You will be rewarded by this choice; I am sure ! And still, I cannot understand the writers of arguments 'compared to'. Having something out there that is worse, does not make you automatically the invincible market leader. The OpenBSD boxes that I run need the least intervention. But still, there could be even less. Patches are a good example. When I download a patch for the first box, I rather read and study and understand what is going on and apply the steps described in the header one by one, manually. For all the other boxes, I simply have no real time to sit next to them and wait for some 'make' to have finished. Also, here, the most obvious solution is a script doing this automatically on demand: checking some URL for new patches, download, and run the header as script. Including recompiling the kernel (if required). Me passing by that box, check the success and reboot (if needed) manually should be quite enough. I don't see a need to sit next to the boxes again and again, issuing and waiting for the always same commands for always the same patch. I am too lousy as coder; and I can imagine that someone else has written a perfect script for this; so why not include this as utility for everyone to use ?
Re: Lifecycle question
Stephan A. Rickauer wrote: 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. Well, I'm no expert, but you could also upgrade once a year without skipping any release. At the end of the n release support, you could just upgrade to n+1 then n+2 right after... and you're back for a year of support. Of course, you could also maintain you own security patches for older unsupported releases, but this is another story... Antoine
Re: Lifecycle question
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). 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. Thanks for helping, Stephan, I am a 3 year Debian Linux user and recently started using OpenBSD. I like and use both systems. But If you are concerned about easy upgrading, I would recommend Debian GNU/Linux (no flamewars please ;-) ). It is a very stable system that it is upgraded slowly, about 2 years (they whant to speed it in the future to 18 month cicle). You will not need to learn new things. OpenBSD is another different flavour of Unix (true Unix) and presents many differences with Linux. You will have to learn new things. Debian has got more ready to use packages than OpenBSD has. I found more applications for my engineering work and amateur radio hobby. Upgrades are a simple aptitude dist-upgrade command. On OpenBSD, you usually have to reinstall everything when you upgrade (or compile). Debian upgrade is an easier and automated task. This is not a problem if you are going to build a server, a firewall, a database server or something related, that is based on a few packages added to the base system. If you want a desktop with hundreds of packages installed, I find Debian more practical to upgrade. Both systems allow you to tweak the internals as you want. Both come with the base system and the remaining applications. Anyway, I am getting in love with OpenBSD because of its securyty, simplicity, stability, clarity, superb documentation and coherency. If I would have to build a server conected to the dangerous Internet, I will undoubtlely use OpenBSD. Just my 2 cents. Ramiro.
Re: Lifecycle question
Howdy Debian has got more ready to use packages than OpenBSD has. I found more applications for my engineering work and amateur radio hobby. Upgrades are a simple aptitude dist-upgrade command. On OpenBSD, you usually have to reinstall everything when you upgrade (or compile). Espie has done a lot of work in this area in -current recently. It will get easier. (Not that its difficult now) Regards Edd
Re: Lifecycle question
Ramiro Aceves schrieb: I like and use both systems. But If you are concerned about easy upgrading, I would recommend Debian GNU/Linux (no flamewars please ;-) ). It is a very stable system that it is upgraded slowly, about 2 years (they whant to speed it in the future to 18 month cicle). You will not We have FreeBSD, Debian Sarge and SuSE 9.0 9.1 9.3 as productive systems running. Technically, we're kind of aware of the differences. system. If you want a desktop with hundreds of packages installed, I find Debian more practical to upgrade. Both systems allow you to tweak the internals as you want. Both come with the base system and the remaining applications. We use SuSE on ~50 desktops in our Institute and are quite happy (well, we had to tune it a bit to make it use apt-get). Debian is my first choice for non-BSD servers, but I would not use it for dekstop purposes still. Well, don't wan't flame wars here either ;) Anyway, I am getting in love with OpenBSD because of its securyty, simplicity, stability, clarity, superb documentation and coherency. If I would have to build a server conected to the dangerous Internet, I will undoubtlely use OpenBSD. I am already in love with it, since I plan to use it as a HA-firewall using carp and pfsync. Problem here is just that it looks as if I had to reinstall it all year ... Thanks, -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question
On Mon, 05 Sep 2005 15:52:50 +0300, Stephan A. Rickauer [EMAIL PROTECTED] wrote: I am already in love with it, since I plan to use it as a HA-firewall using carp and pfsync. Problem here is just that it looks as if I had to reinstall it all year ... Hi Stephan, If it's just a firewall, and you won't need any new features (wich will come with some new release), then why should you upgrade? Just configure it, put the server somewhere in the dark corner and it will handle it's job very nicely :) Giedrius -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Lifecycle question
Stephan A. Rickauer wrote: 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. From my experience, I can say that upgrading is not actually an issue with OpenBSD. This can be best explained with one of the catch-phrases that describe it, OpenBSD constantly evolves, it does not revolutionize all the time. Version numbers are mostly that, numbers, and an indication that several weeks of disciplined quality assurance went into it after another development cycle. The result is really painless upgrades -- maybe not in a sense of (attempted) automation like on some other OSes, but in terms of breakages. The time saved by the fact that everything typically Just Works makes up for the few additional manual steps during upgrades, and Nick Holland is so kind to supply very thorough upgradeXY.html documents for every release, outlining any possible gotchas. There are also several ways to speed up upgrades when dealing with lots of similar boxes, slightly customized `release(8)'s via siteXY.tgz and so on. All in all, it helps to have some support infrastructure to manage an OpenBSD deployment -- e.g. a build box and maybe one or two representative test boxes (although that's good to have with any other OS as well.) As I am writing this, your second mail just came in. With your HA setup, there won't even be any downtime during upgrades, and they will *really* be painless as you probably don't have to deal with any package upgrades. Reboot new kernel, untar sets, apply a prepared patch for /etc, MAKEDEV and mtree, reboot and you're good to go after some 5 minutes, give or take, per box. Of course, simply swapping out harddrives with an upgraded installation is another possibility. Moritz
Re: Lifecycle question
Giedrius RekaE!ius schrieb: If it's just a firewall, and you won't need any new features (wich will come with some new release), then why should you upgrade? Just configure it, put the because patch-xy has been made for release zz where I have release bb after 'it has been in the dark corner' for some years? Stephan
Re: Lifecycle question
Moritz Grimm schrieb: The result is really painless upgrades -- maybe not in a sense of (attempted) automation like on some other OSes, but in terms of breakages. The time saved by the fact that everything typically Just Works makes up for the few additional manual steps during upgrades, and Nick Holland is so kind to supply very thorough upgradeXY.html documents for every release, outlining any possible gotchas. That is an important information, thanks. I can't recall how often SuSE messed up an upgrade procedure because they compiled kernel modul xy and shipped them with conflicting userland version yz ... nightmares. I guess I'll risk it with OpenBSD ;) -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Lifecycle question
Henning Brauer schrieb: you don't have to reinstall at all. hogwash by some people here. I have about a hundred servers in production, some are upgraded ever since 2.7 times or so. upgrade typically takes us 5 minutes and one reboot a box. Well, I am thinking of using OpenBSD for our firewalls. Those I do want to upgrade regularly. Not because of features, but because of patches. Stephan
Re: Lifecycle question
I recently did my first upgrade from 3.6 to 3.7 without the cd's and it was surprisingly simple... I would say the upgrade was less complicated than my last linux upgrade (kernel and userland is in sync here). Love this OS On Mon, 05 Sep 2005 15:21:29 +0200 Moritz Grimm [EMAIL PROTECTED] wrote: From my experience, I can say that upgrading is not actually an issue with OpenBSD. This can be best explained with one of the catch-phrases that describe it, OpenBSD constantly evolves, it does not revolutionize all the time. Version numbers are mostly that, numbers, and an indication that several weeks of disciplined quality assurance went into it after another development cycle. The result is really painless upgrades -- maybe not in a sense of (attempted) automation like on some other OSes, but in terms of breakages. The time saved by the fact that everything typically Just Works makes up for the few additional manual steps during upgrades, and Nick Holland is so kind to supply very thorough upgradeXY.html documents for every release, outlining any possible gotchas. Moritz -- Bill Chmura
Re: Lifecycle question
Moritz Grimm wrote: Stephan A. Rickauer wrote: 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. Of course, simply swapping out harddrives with an upgraded installation is another possibility. Moritz I second that motion. GENERIC allows for you to build and test on *whatever* hardware and then with minimal changes plug the hdd into the new machine and you're off running. Disk arrays cause a bit of a cluster in this theory, but still a workable solution and a lot better than downtime. -JR
Re: Lifecycle question
...on Mon, Sep 05, 2005 at 03:35:19PM +0200, Stephan A. Rickauer wrote: Henning Brauer schrieb: you don't have to reinstall at all. hogwash by some people here. I have about a hundred servers in production, some are upgraded ever since 2.7 times or so. upgrade typically takes us 5 minutes and one reboot a box. Well, I am thinking of using OpenBSD for our firewalls. Those I do want to upgrade regularly. Not because of features, but because of patches. For a simple filtering firewall, you won't need to do much for an upgrade. Perhaps touching a few files in /etc according to the upgrade document, and if you use any ports or local binaries, getting them up to the current version. The basic layout of things hasn't been changed for a long time, it's not as if suddenly config files will have to be in a different directory because someone wants to be compatible with some standards document or so. On the other hand, there's little incentive to upgrade such a setup at all (except for the exercise) - there are rarely catastrophic bugs that will be able to compromise your system, and throwing in a new version of things like openssh or zlib will usually work a couple of versions back from the current release, even if there's no formal patch. (In reality, if there's a case where you really, really need to upgrade such a system after a few years, it will probably hurt - currently have that with a 3.3 box with so many local changes that it barely looks like OpenBSD anymore...). Alex.
Re: Lifecycle question
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
