> On Fri, 15 Oct 1999, Tony Nugent wrote:
>> I happen to like redhat... it's a brilliant distribution. The new
>> RH61 is very, very nice to use. So is its rpm package manager (as it
>> has always been). I need to manage dozens, potentially hundreds, of
>> linux boxes, and rpm allows me to do some aspects of this very easily.
>> Mandrake and SuSe (and others, eg, TurboLinux) also use rpm for their
>> package management. It's nothing short of brilliant (ahhh... that is
>> once you get to know and understand how it works).
> Not to start a distro flamewar, but dpkg is brilliant. rpm is OK if
> you've never seen dpkg.
We should definitely take this off-line. It's not fair
for us to discuss this on Tom's list, given that he doesn't
like these new-fangled package managers.
I think rpm has some features that beat out dpkg.
dpkg doesn't have the -V/--verify option to perform and
integrity test. debsums isn't as mature or informative
--- testing only MD5 checksums and failing to store
permissions/ownership etc. Also the output formats of
the dpkg command is not script friendly, I can use it
with xargs and while-read loops as I can with rpm.
That said I must say that apt-get and console-apt (formerly
apt-find) is WAY ahead of rpm (and rpmfind) for automatic
package fetching, and installation as well as dependency
resolution. The structure of the /var/lib/dpkg is MUCH more
robust and manageable than the huge dbm files under
/var/lib/rpm/. If you get something "broken" in the package
management "database" you can usually figure it out and fix
it with a text editor and some stock UNIX commands.
Debian packages are of generally better then those from Red
Hat (with fewer integration issues, and usually more
proactive bugfixing and patching done to them). Debian has
many more maintainers than Red Hat has in its development
group. The Debian packages are of a finer granularity
(allowing us more control over what gets installed and what
we don't need), and their use of "virtual packages" and
"alternatives" handling makes the whole system integrate
better.
The Debian concept of "system policy" is also much better
than that of the RPM based systems that I have used. They
have much more reasonable default filesystem permissions,
fewer SUID programs, better default configuration files,
with more useful comments in them, and no-frills,
no-nonsense post-installation configuration scripts that
make a subsystem useable with less fuss than the RPM
"hunt done the configs to edit them" default.
Also the debian file format ('ar' archives containing tar.gz
files) is easy to work with and offers great potential for
future development and enhancement.
For all the things I like about Debian I still have
my complaints. dselect is evil! The lack of a
"Kickstart" like package for automating new installations
is sad (though you can work around it with Tom's Rt/Bt
and some scripting). As I said before, the output
formats of dpkg aren't script-friendly (though some
patches to dlocate might fix that).
By far the things I'd most like to see for Debian is
a really top-notch system integrity auditing tool and
the publication of GPG detached digital signatures for
all packages. (They already have a debian developer's
keyring as a package, and GnuPG is at production-level
now. So much of the infrastructure is in place).
Here's how that would work:
It would be booted from a write protected floppy. It would
contain copies of sh, ar, tar, gzip, and GnuPG and an
authenticated keyring file. You might have a base system
CD. You might have a directory full of updated/downloaded
packages (/var/cache/apt/archives). You might point this
tool at a URL. You might do all three.
Once started this package would iterate through your list of
installed packages (possibly testing signatures on some of
your /var/lib/dpkg control files). It would then find the
appropriate .deb file (searching the CD, the local cache
archives, any optional mounted directories and the archives
on any URLs that you've specified). Having found a copy of
the .deb SOMEWHERE it would check find the digital sigs on
it, extract (ar -x) the main tar.gz and run tar dzf on that.
This would generate a list of differences between the
packages and the installed files.
Voila! A full system audit!
(Of course I have to actually work on this and resolve
some minor issues. For example, if the list of packages
was tampered with, so that our auditor didn't know to
look for them ... so we'd need a list of "check files"
--- key files in various *system* directories that
indicate that a package control (/var/lib/dpk/info)
file has been removed or that some system binaries have
been installed by bypassing the package management system.
That list would have to be available dynamically, and would
have to be digitally signed by a Debian maintainer or
a few! Also you'd want to have a way to vette your
modified configuration files, and to over-ride some
checks -- particularly permissions/ownership changes,
to match your site's policies)
So far no OS that I know of ships with a comprehensive
system auditing tool such as I've described. One beauty
of this method would that that you could restore compromised
and/or corrupted files as you went (optionally capturing the
bad ones for later forensics purposes). Rather than relying
on checksumming, you're actually use tar.gz images from
which you can restore the entire system! (This sort of
package might even be extended for cloning and restoring
systems, since the "installed packages" list and some
configuration data would constitute a system profile).
Uh-oh! Now I've done it. I've rambled on about the very
thing that I didn't want to bother Tom with.
Sorry, Tom! I hope you just skipped past this if you
didn't want to read it. At least I changed the Subject:
--
Jim Dennis [EMAIL PROTECTED]
Linuxcare: Linux Corporate Support Team: http://www.linuxcare.com
