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 XXXXX") 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.
