On Wed, 4 Oct 2000, Tony Lambiris wrote:
> > Why? I've been running RH systems on servers for more than 5 years now and
> > never had a problem with them. Sure, their distribution is buggy at times,
> > but it's usually restricted to a small subset of software, and is usually
> > fixed quite rapidly. At the least, don't install what's known to be buggy,
Except for the sort command... ;)
>
> I never said RH couldn't work in a server environment. Also, not everyone is
> running in the same environment as you. Were your servers multi-user
> environments? Did you have amd or ftpd running on them? There are a ton of
We use RedHat for everything. We run an entire production environment,
including a rack full of servers and about 60 desktops, on RedHat. It's
fast, easy, and so long as you watch out for the bug fixes, reliable.
That's not to say that it doesn't have issues, but every distribution I've
used does.
> factors that come into play. I am not impressed. I also don't know how you
> can continue to use Red Hat full well knowing that with every release,
> there are going to be multiple bugs in the software.
See above. All distros have bugs, even debian, though it has a lot less
of them. It's unavoidable. If you have ever worked in a professional
Unix shop, you typically will stay about a year behind the releases in
order to make sure all the important bugs get fixed.
RedHat is no different, except that the time period is generally much
shorter (3-6 months). For running a large-scale environment, this is
acceptable, since generally you wouldn't want to upgrade all that often,
as things need to be kept stable.
For the enterprise, there aren't any distros I'd chose over RedHat. For
personal use I'm beginning to prefer debian, but the install is S-L-O-W
and cumbersome, especially if you want to customize it, and dselect SUCKS.
This makes it tough to justify when I can install a redhat system in about
10 minutes, and I know what I get.
> Do you run Windows as well?
Nope... no comparison. Redhat has about 20 major bugs a distribution,
Windows has about 20,000 on average. RedHat is FAR, FAR more reliable.
> And in case you missed it, I said the admin did a default install. If
> he had deleted packages he did not need, who knows if the crack ever
> would've happened.
Probably true. But this has no bearing on what distribution was used.
>
> > >I just read on Slashdot that Red Hat 7.0 had over like 2,500 documented bugs,
> > >or something outrageous like that.
> >
> > Documented and Verified are completely different. If you look a litte more
> > closely, what counts as a "Documented" bug is more often than not "Stupid User
> > Error". For example, someone reported as a bug the fact that when one does
> > not have write permission on a directory/file, they can not edit those files.
> >
> > That's not exactly a bug!
> >
>
> Point taken, but I didn't feel the need to go into the multiple factors
> affecting people submitting bug reports. Almost every environment is different.
> This is a matter of common sense.
If you're going to quote a number of reported bugs as part of your
argument, then the nature of the reports is DEFINITELY important to your
argument. Your point didn't do anything to strengthen your argument at
all. A large percentage of the 2,500 reported bugs are bogus. Not to say
that there aren't a lot of them, and I'm sure as hell going to steer clear
of RH 7 for now... they're using a BETA glibc and gcc. The gcc doesn't
even produce a working kernel. DUH.
> > Locked down and buggy are again, two different concepts. Just because a
> > certain distribution may or may not be buggy has nothing to do with whether or
> > not it can be hardened. RH is just like every other distribution
> > or Unix system for that matter, when it comes to be locked down. You do
> > exactly the same things to harden all Unix systems.
> >
>
> Again, pointing out the obvious.
Perhaps, but you're not considering the obvious in your arguments. So it
needs to be done.
>
> Example: a new exploit comes out that writes a suid root shell to /tmp. First
> off, how many people create a seperate tmp partition (I do)? And how many
> people set the /tmp partition NOSUID in their fstab (I do)?
This isn't a good example, because the actions you've taken only give the
illusion of improved security. In order to create an SUID root script,
you need a process that has the permissions of root. So you can create
the file anywhere where you have the appropriate permissions.
Granted, this may foil some script kiddie, but it may not... if the script
is well-written enough to look for such things (or just sticks the SUID
program in /bin) then you've gained nothing.
> Of course, if Red Hat did not decided to include that service (or at
> least turned on by default), they would've spared a lot of headaches.
> Why spend a day or two locking down Red Hat, when you can install
> something like OpenBSD and have it secured in 2 minutes. It's
> inefficient.
If there weren't lots of other benefits to running redhat, then everyone
WOULD run *BSD. But I'm stating the obvious...
> I beg to differ, apt-get is by far the greatest and most powerful package
> installer.
apt-get is fine... but dselect sucks. And when you're doing the install,
that's how its done.
> Well let's just put it this way... I have a few friends that attend Keene
> State college, and if the cracker was in fact an attendee at KSC, I would've
> been told,
There's no reason to assume that that is true. Even if you yourself were
an active member of the cracking underground at your school, that doesn't
preclude the possibility that there were a number of lone rogues that
don't act as part of any community of hackers attending KSC, so it's
entirely possible that your dormmate might be the cracker and you wouldn't
know about it, if they were smart enough to keep their trap shut. Good
hackers generally don't get caught because they don't blab about their
exploits. They let their "work" speak for them... You're talking about
script kiddies.
--
Derek Martin
Senior System Administrator
Mission Critical Linux
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
