Re: Administration (+apt-get dist-upgrade) of 100s of machines
Peter Valdemar Morch wrote:
Hi there,
We have 100s of almost identical machines that need to be kept up-to-date with apt-get dist-upgrade .
Having to run apt-get dist-upgrade manually on all of them is just not working (taking too much man-power) due to having to answer the same Y/N debconf(?) questions over and over again especially about config files.
Is there a smarter way? How does one manage many, many debian installations
without having to give each one special manual treatment? Ideally I'd like
this to be a fully automated operation and only be
notified of any failures in a reliable way.
Rather than trying to write our own scripts, I've searched the admin::configuring
and use::configuring tags and come up with dpsyco, ugrade-system and fai, but
they all seem inappropriate to our needs.
We can't possibly be the first to need this...
As a related question, the main interface to these boxes is through apache2
(and http). Is there an apt-get frontend that runs under apache2 and that can
handle debconf questions? (And what happens to that if apache2 itself needs
upgrading?)
Hope you guys have some pointers/experience to share...
Sincerely,
Peter
You have gotten many good replies in this thread, given the problem as you posed
it, but it seems to me that even the optimimum solution now may not be scalable
if your number of installed machines grows substantially. The following comment
is not a direct reply to your questions, but offered as something to consider in
the future.
Large installations are often administered centrally by keeping the root
partition images on a server, maintaining and upgrading the images, rather than
the machines themselves. If the master root partition images are hardlinked,
they should not take much more disk space than a single image, and if rsync is
used for ryncing the images, then a distribution upgrade should should only take
minutes per machine. To make the upgrade fail-safe, you could have two root
partitions on each machine with the option of falling back to the old root
partition, during a trial period.
Under control of a server, on each client a maintenance boot partition syncs its
copy of the boot partition image to the server master image before booting into
the root partition. This method is widely used for both GNU-linux and windows
clients. It is not only useful for upgrades, but also for application rollouts
as well, and it also has advantages with respect to disaster recovery.
I've never done it myself, but I'm sure other readers could offer pointers.
Reply to: