Re: ISP asking about switching to Debian from OpenBSD
On Thu, Nov 22, 2001 at 09:40:37PM -0800, Karsten M. Self wrote:
> on Thu, Nov 22, 2001 at 02:12:17AM -0800, Petro (petro@auctionwatch.com)
> wrote:
> > 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:
> > > 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.
>
> Depends on the heavy lifting involved. For a wide range of
> public-facing network services, it's perfectly acceptable.
Heavy lifting is of course a relative thing, but the site I help run
pushes an average of 40Mbits a second.
Of course, this is an average over the whole site, but we've only
got about 25-40 machines facing the public.
That's what I think of when I think of heavy lifting.
> > Oh, and walking through that flicker? That was your power supply,
>
> Actually, I checked -- it's a power strip, not a surge protector. I
> think it's the heavy electrons, they take longer to slow down ;-)
No, not the strip, THE SUPPLY, you know that little tin box in the
back of your machine that the long black cable sticks into? The one
that leads from the powerstrip to the the machine? Most modern
powersupplies can handle flickers fairly well.
(and yes, that was a little more smartass than needed. I know from
another list that Karsten isn't an idiot).
> > > 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?
>
> I don't think that's terribly complex. It's not much more than is
> already done in /lib and /usr/lib to point to the proper libraries.
> Symlinks.
No, but it's a little hard to follow the first time.
Were you refering to Redhat's habit of writing init-scripts that are
somewhat arcane and source other scripts for functions?
>
> My contact with RH boxen is pretty limited these days, but I know
> there's a bunch of cruft under /etc/sysconfig for networking that's
> sourced in multiple places. I've had headaches trying to work out what
> goes where with RH's MySQL startup scripts. I find that the /etc/init.d
> (or /etc/rc.d/init.d) script frequently invokes at least one level, and
> sometimes two or more, of other scripts. Tracing execution through this
> path is tortured. Debian does far better at localizing everything to
> the /etc/init.d script itself, or, where it doesn't, to localizing the
> additional cruft to a minimal number of locations
> (/etc/network/interfaces).
Ah. yes, you are refering to that.
In some places that's refered to as "code reuse" and greatly
recommended.
And yeah, it's driven me bugfuck more than once.
> > > 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.
>
> Agreed.
>
> > > 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.
>
> It's a numbers game. Debian makes accomplishing # 4 far easier than any
> other system I'm familiar with.
The problem is the space between 3 and 4. Mr. Schneier left out a
step:
3.5 Broadcasting of fix availablility.
> > > 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.
> Making sure the barn door's made of wood (or steel) rather than paper
> helps.
> OpenBSD's audit focusses very heavily on eliminating buffer overflows
> and looking at use of UID 0. Between the two of these, you're attacking
> the foundations of a large number of possible exploits. The other
> attack angle is sane configuration defaults. Since the majority of
> users never touch the defaults, and a large number of exploits are based
> on buffer attacks, this actually cuts the vulnerability profile
> significantly. Debian could learn from this, and is, with the various
> hardened packages / tasks which can be applied.
I hope I wasn't taken to be attacking either Debian/Linux or oBSD.
Both are good systems and both have their place.
> > 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.
>
> Yeah, I guess the word with calendaring that it all sucks, and mostly
> doesn't exist.
>
> Incidentally, there was an item about HP's OpenMail package, an Exchange
> replacement, IIRC. This is a product HP's indicated it's going to
> shelve, I'm not sure if the announcement is saying that the product will
> be continued, or just that there's some near-term development happening:
>
> http://eltoday.com/article.php3?ltsn=2001-11-16-001-14-PS
>
> ...reads as if it's the latter. Pity.
Last time I looked at it, it was completely unavailable.
>
> OpenMail's one of HP's worse failings. The company really ought to
> pick up the product and run with it, free software if at all possible,
> and put the squeeze on MSFT.
The current best bet is the OpenOffice team. They seem to be working
with the PHPGroupware guys, which is a decent enough project that
just isn't good enough yet, and with the 90/10 rule, I don't know if
it will be.
--
Share and Enjoy.
Reply to: