On Sat, Apr 21, 2001 at 01:16:08PM -0400, Jaldhar H. Vyas wrote: > What exactly would be the point of that? Are the needed files likely to > change that often? And wouldn't this require keeping a copy of the > standard bind package around as well? yes, bind has security updates about once a week ;-) seriously though, it makes alot more sense for your chroot package to build a chroot jail, maybe do something about the config files, and then just divert the /etc/init.d/bind script elsewhere and replace it with one that installs the bind binaries into the chroot and then starts bind from there. this way you need not include any bind binaries in your package so your package won't need to be updated every time bind gets a security update. instead the mainline bind package would be updated by the security team, it would upgrade /usr/sbin/named* and run /etc/init.d/bind restart in its postinst, when that happens your initscript would copy the new updated binaries into the chroot and restart them. if your package is a complete fork of the mainline package the security team now has two bind packages to fix instead of one. given how busy they tend to be i think its prudent to avoid creating more work for them unecessarily. also your initscript should update certain things in the chroot at every start anyway, things like /etc/localtime so the logs have correct timestamps and the admin doesn't have to remember to update two /etc/localtimes if the default timezone should need to be changed. libc is another that needs to be updated in the chroot jail. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpcmdYJ70aS3.pgp
Description: PGP signature