[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Considering Debian (currently using Red Hat)



Boy, are u gonna get answers....

El mié, 14-01-2004 a las 08:56, Fred Whipple escribió: 
> Hi Everyone,
> 
> I'd like to get some of your thoughts on a few things relating to the 
> possibility of our company switching distributions from Red Hat to 
> Debian.  As most folks already know, Red Hat has drastically changed 
> their strategy, and we ultimately must make *some* relatively drastic 
> changes no matter what.  And, we intend not to switch to RHEL (though 
> not for financial reasons).  This gives us the opportunity, welcome or 
> not, to consider other distributions.  And even other OS's -- we're 
> frankly not closed to the idea of ultimately switching platforms 
> entirely to BSD or Solaris.  So with this in mind,
> 
> 1.)  One of the biggest reasons we went with Red Hat many years ago was 
> RPM.  Of course I know that Debian has a package system, and there're 
> constant arguments about which is better, if either.  What I wonder, 
> though, is how they compare for the purposes of security checking.  On a 
> Red Hat system, practically any file or directory outside of /home can 
> be found within the RPM database.  We can check each and every file, its 
> MD5 hash, etc.  It's like having a built-in Tripwire installation so 
> long as you trust the RPM database.  We've modified the RPM installation 
> such that we can trust it more than we trust Tripwire.  Do Debian 
> packages have similar security built-in?
Yes.... although it wouldnt be safe to say ALL files in every package as
some of the files (as config files) are generated from pre or
postinstall proceses and thus are likely to say.
Anyhow. Debian comes with a debsums command that takes the deb database
and does an md5 comparission of everything. Its quite effective.
Ive used aide, tiger and integrit as local IDS systems and they do their
job quite well. Ive never fiddled with tripwire though. Those will do
the debsums check for you plus, depending on package, will conduct other
similar testing procedures to detect filesystem changes.

> 2.)  A related reason we used Red Hat was that practically anything you 
> could want to use was pre-packaged in a simple to install RPM.  And they 
> were typically pretty high quality RPM's, and very often well 
> maintained.  Do admins typically find that they're able to find Debian 
> packages for most software they're typically interested in using?  I 
> realise this varries greatly between markets, but I guess what I'm 
> asking is do you usually find 70% of the packages you're interested in 
> in Debian package format, and well maintained?  80%?  Just a general idea.
> 
Well. Its a tradeoff there. Third party (non distro) software is almost
allways distributed in rpm's. This makes it much easyer for admins to
integrate that packages into your stuff. Debian is another taco there,
we have an authoritative source of packages (the debian project) and
most packages youll ever need are there. Third party debian packaged
software is generally complex to safely integrate into debian because
non-stable debian moves a lot (thus many prefer the testing and unstable
distribution, depending on usage) so most projects find it a PITA to
manage debs as third party.
On the other hand, debian makes it very easy for you to take a tarball
and turn it into a safely installable (for whatever debian version you
use) packacge through the dpkg-buildpackage command. If the third party
package is GNU-style compatible (has a configure, make, make install
style of distribution), dpkg-buildpackage will build you your deb and
you can then install it with the equivalent of the redhat rpm command
for debian, called dpkg.
Finally, debian supports you tracking packages from different versions
of it. Say, you want a stable (read OLD) setup for all email related
services, but you need a younger version of apache. You can quite
troublessly install the apache for debian/testing (which is younger)
into your debian/stable setup, and it will only install whatever testing
versions of the apache dependencies you need, thus leaving your email
services safely in their old versions (unless they depend on the same
libraries as the younger apache). 
> 3.)  I read quite a bit of the Web site, and see that in general, 
> releases seem to be very far and few between.  This is advantageous to 
> ISP's, of course, because we want things to just "work".  Is my 
> perception correct in that releases are far apart?  When is the next 
> release expected?  How significant is the difference from, say, 3.0 and 
Yes. Very very far appart. Between stable releases what differs is just
package versions, installation software upgrades and a whole lot of new
packages. Naturally, they also change in administration software (see
all the debian update-* commands, which make it easy to manage a lot of
things) 
> 3.1.  Can you just install a bunch of packages and call it an upgrade, 
> or do you have to go through a whole ordeal as you do between Red Hat .X 
> versions?
> 
You can just install a bunch of packages. Hey, we even have a command to
tell it to do it all by itself. Dependencies and all will be automagic
allly handled.

> 4.)  How long are previous versions maintainaned with patches and such?  
> Or to restate this, how long after a new version is released are you 
> FORCED to upgrade in order to maintain security?  How drastic are the 
> changes in between minor version increments (say, 3.0 to 3.1)?  For 
> example, Red Hat has tended to make significant kernel upgrades and 
> glibc upgrades in minor version changes, and has caused significant 
> incompatibilities that have caught us by surprise.
Its easyer to think about debian versions by 'stable releases'. For
example, whatever the current number is, the current stable release is
called woody (google for Toy Story Character +debian) the older one was
called potato. In my experience, the tradeoff is security. Old stable
releases are NOT actively mantained. This is necesary for the project to
move forward. However, there is a safe period of time (when the new
stable version release candidates come out) that allow you to perform
testing and everything so you can determine how are you going to
upgrade.

Now, in my experience, debian upgrades are not as painful as redhat ones
(particularly as redhat's .0 versions tend to be somehow lacking of
quality). In the debian case, every step is taken to ensure that the
system can be upgraded without ever rebooting. Of course, errors can and
DO, OFTEN happen, still, i single handedly manage arround 20 debian
servers and ive upgraded them through two stable releases without any
major problem.

> 5.)  Of course we'll be testing it extensively ourselves, but what would 
> you say the most significant differences, both from a user and an admin 
> perspective, are between Debian and <Brand X> Linux?  Or, maybe better 
> stated, why Debian?  I know that's a religeously charged question, but 
> at the moment our only position is "not RHL."  We're open to being 
> converted ;-)
> 
Debian is a unix for unix administrators. It has no truely usefull
visual administration tools (save for webmin which works on any unix).
One thing though which makes it a very unstressfull distro, is that it
has very toughly enforced standards for configuration. No package is
configured ever outside the /etc directory, no package ever lacks a
directory in /usr/share/doc, all logs are allways in /var/log, every
database file can be found in /var/lib ... all email servers spools can
be found in /var/spool....that kind of thing. So its ideal to standarize
complex administration proceses with relative ease. 
> 6.)  And finally, if you care to toss in any ideas or info, I'm very 
> glad and excited to hear it.  For instance, if you were going to switch 
> all your systems within the next year, would you choose something else?  
> A BSD port?  Go back to Solaris?  Novell?  SCO?  Just kidding.
> 
a) Keep on the free side, noone in their right mind runs proprietary
software based internet services.

b) Think about administration streamlining. This distro will make it
possible for you to standarize all common admin  processes with some
scripting.

c) This is pretty much built by large isp's to meet their needs you will
find a wealth of packages and options to operate on that.

d) Once you go debian though, youll never ever ever want anything else.
So beware, it is adictive.

> Thanks very much!
> 
>     -Fred Whipple
> 



Reply to: