Re: ISP asking about switching to Debian from OpenBSD
On Wed, Nov 21, 2001 at 11:04:32PM -0800, Karsten M. Self wrote:
> on Tue, Nov 20, 2001 at 01:38:11PM -0800, Mark Ferlatte
> (ferlatte@cryptio.net) wrote:
> > On Tue, Nov 20, 2001 at 01:28:36PM -0600, David Batey wrote:
> > > STABILITY: is Debian a good choice for heavy lifting?
> > There are some legit concerns regarding the Linux kernel as opposed to
> > the *BSD kernels as far as heavy lifting goes, but if you're
> > considering Debian, then you probably feel that those concerns are
> > addressed to your satisfaction. As far as distributions go, Debian's
> > packaging quality is very high, and if you go with stable that's
> > exactly what you get: serious stability.
> My own experience running GNU/Linux and OpenBSD (2.7) side-by-side is
> that I get the odd freeze and restart on oBSD, but not GNU/Linux (unless
> it's something I've done myself, usually involving crashing X). Typical
> uptimes on both systems run months. UPS on the GNU/Linux box, I've
> watched the oBSD walk straight through power flux that flickers the
> lights, with nothing more than a surge protector.
Not to slam oBSD, as it's really good at what it aims to be, but
it's a niche product aimed at a specific target, and it's really
good at that. "Heavy Lifting" isn't that target.
Oh, and walking through that flicker? That was your power supply,
not the OS. If the CPU doesn't get enough juice, it doesn't get
enough juice and all the clever, proper code in the world won't
help.
> > > I know about apt-get for easy installation of bug/security patches;
> > > does the ease-of-install ever compromise security or functionality?
> > Not in my experience.
> I'll hit this point more specifically.
> I'm going to swap out my OpenBSD system for a very light stable Debian
> install.
I replaced mine with a webramp 700. Mostly to get rid of the
noise (fans and disk drives).
But all it was doing was firewalling and DNS. The DNS got moved to a
MacOS X box (no, I'm not an open source zealot) and my wife sleeps
better.
> OpenBSD offers a very tight, very secure, by default, system. What you
> lose in the process are:
> - Flexibility of configuration and modification. I like SysV init.
> Theo rants how it sucks and is more complex. The Debian
> implementation is damned good for GNU/Linux, is worlds better than
> Red Hat's "gee, we could use another three levels of indirection,
> let's put them in" crap, and makes starting, stopping, and
> restarting services completely straightforward.
Uh, not to be an argumentative drunk, but what about
/etc/alternatives?
While I have *lots* of problems with RedHat, their init stuff isn't
all that bad.
> - Choice. You can choose the software you want to install. Much of
> it is packaged for Debian. That which isn't you can install from
> RPM (via alien) or compile from sources (use equivs to satisfy
> deps). You can run the oBSD mods if they'll build, though there may
> be compiler tweaks they've effected, I haven't dug into the system
> that deeply. The *BSDs offer ports (and from what I've heard,
> they're cool), but this puts you outside the envelope of security
> audits provided by the oBSD core. apt-get source puts you near the
> equivalent functionality of ports.
Having used the ports system, and the .deb package system, I like
the .deb system much better for large installations.
I no longer put a compiler on each machine, I have an internal
debian mirror with a tracking section (tracking unstable and such)
a snap-shotted section (basically a snapshot of unstable at a
certain point in time) and a "misc-packages" section. When I want
a new package (for instance the upgraded lvm stuff) I moved it
from the tracking directory to the misc-packages directory, and
the next time I run dselect on a machine, it gets installed--if I
want.
Any custom software gets .debianized and shoved in there.
It's nifty, and works much better than having to make; make
install on 100 machines.
> oBSD is pretty clear that it's a full *system*, not merely an
> assembly of packages as is the case for many GNU/Linux distros
> (Debian included). However, the collection of packages approach
> means that Debian can offer many things to many people. oBSD is
> pretty much "secure Unix clone, primary network services
> orientation". Not a bad thing. But limited choice.
Every network, every sub-net, every cluster has different
requirements. Debian/Linux offers a much wider variety than BSD. Not
that this is always a good thing, but it allows you to customize for
your own needs.
> Bruce Schneier identifies four periods of concern for security
> issues:
> 1. Introduction of vulnerability. It exists, but is unknown.
> 2. Awareness. It is known, but not necessarially patched.
> 3. Introduction of fix. A software patch is available.
> 4. Application of fix. Software patch is widely applied.
Number 4 is wishful thinking.
> What oBSD does is try to minimize factor 1. What Debian does is
> address 3 & 4. They're somewhat orthogonal approaches (Debian also
> addresses 1 a bit), but both have significant impacts on the
> security of *your* system. I find the Debian approach to be more
> compelling.
Quite frankly, proper design and coding is the only way to prevent
most vulnerabilities.
Everything else is locking the barn door when you're not sure the
horse is still inside or not. Yes, you still have to lock the door,
but it's occasionally too late.
> > > OpenBSD is pretty secure; how does Debian compare? Is Woody ready
> > > for prime-time yet? (If not, would an upgrade from potato to
> > > woody likely cause hiccups?)
> Woody's pretty adequate for a desktop. I'd stick with Potato for
> production, 'Net-facing, servers.
It depends on your needs. With the appropriate appliances in front
of a box (IPNat, and port blocking routers), you reduce your risk to
the specifc application, which gets back to the list above. You are
almost as likely to find a vulnerability in stable as unstable,
modulo the fact that the longer a specific package is out, the
longer the "bad guys" have to find a vulnerablity in it. And the
good guys have to patch it.
> > > FUNCTIONALITY: We need DNS server packages, ssh (with ssh
> > > tunneling available for other services), smtp/pop, web-based
> > > scheduling/claendaring/email facilities, HTTP (apache/mod_perl)
> > > servers, and so on...
> Deb's down wi'dat. Cold.
The web-based scheduling/calendaring pretty much sucks unless you're
willing to spend money on it. But this is going to be true for any
platform.
--
Share and Enjoy.
Reply to: