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.7....enough 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!
Cheers,
Steve
