Unmanaged files

[mcgroarty]

So far I've found that the kernel, webmin, and sbadmin are installed directly, rather than as packages. I was really surprised to find this on a Debian server.

The problems I anticipate are -

It's easy to miss an upgrade should security issues be discovered

There's no checking for conflicts when installing/updating other packages

There are no md5 sums for debsums

Tiger, logcheck, and other security tools' configurations aren't automatically updated for these packages via normal Debian package updates.

And the one that bit me already -

Standard Debian make-kpkg kernel packages don't know how to properly update grub's boot.lst on installing newer/custom kernels.

I didn't catch this straight off -- dpkg ate grub's menu.lst, and I saw a $30 restore fee before I'd uploaded a byte of data. Ouch.

Where would be the right place to suggest turning these into traditional .deb packages in the future?

[knightfoo]

The kernel was done seperately because the default Debian kernels don't play nice with our install environment. They should be packaged (custom kernel .deb) but it just hasn't been done yet. GRUB was chosen because it makes troubleshooting a lot easier for the datacenter technicians, even though it is not a Debian default. It is really frustrating when you know there is another kernel on the drive but you can't modify LILO to boot it. :)

Webmin was installed outside of the packaging system for a couple of reasons. The first is that Debian packages all of the modules seperately, and they package an older version of Webmin. A lot of Webmin users were thrown off by this becuase they couldn't install the modules they needed due to incompatibility with the older version of Webmin. Also, the Webmin self-update feature (which a lot of people like) places newer versions outside of the packaging system anyway, so it didn't make much sense to package it.

The sbadm is just a couple of configuration files (init script and config) that doesn't warrant a package. It has no dependencies aside from ssh, and it isn't even version dependent.

-knightfoo

[mcgroarty]

Originally posted by knightfoo
The kernel was done seperately because the default Debian kernels don't play nice with our install environment. They should be packaged (custom kernel .deb) but it just hasn't been done yet. GRUB was chosen because it makes troubleshooting a lot easier for the datacenter technicians, even though it is not a Debian default. It is really frustrating when you know there is another kernel on the drive but you can't modify LILO to boot it. :)


By not playing nice with the SB install environment, do you mean something specific about the kernel, or just the way the kernel's installed?

I'm going to need to customize my kernel, and would definitely appreciate a heads up on anything that'll break the system.

[knightfoo]

Originally posted by mcgroarty
By not playing nice with the SB install environment, do you mean something specific about the kernel, or just the way the kernel's installed?

I'm going to need to customize my kernel, and would definitely appreciate a heads up on anything that'll break the system.

All of the Debian kernel packages use an initrd, but the mkinitrd does not like being run in a chroot'ed environment. It never selects the properly root partition, if it runs at all. The kernel that we install is a stock kernel from kernel.org with no modifications. The only thing you should watch out for is the network card drivers and the ext3 filesystem drivers. I would recommend compiling the 8139too and eepro100 drivers into the kernel. Also make sure you update the grub menu.lst file.

-knightfoo