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

Re: Maintaining multiple Debian boxes



Dale Scheetz scripsit:
|Wow! Bet that keeps you busy ;-)

Less than you would think, honest, I am doing a PhD at the same time
;-)

|You might want to check out DoList in the upgrades directory. This script
|runs dpkg from a list of packages that have been properly ordered to
|resolve the dependency issues. Once you have a working list (check out the
|base.list file as an example) you can run DoList against it and your
|package archive to do repetative upgrades. If your 56 machines are
|networked together, then you only need to keep the archive on one machine
|and mount it nfs on the target machine, run DoList and you are done. 
|At the moment this is still not effortless, because of the various
|questions that packages ask during installation. But this problem is being
|worked on by others and should be resolved soon.

I have: it is almost there but not quite what I want. One of the
problems is the way upgrades need to be done. I understand that 99% of
the developers don't have more than 4-5 machines on which Debian is
running so the problem isn't felt but please try and go into
multi-machine mode as you read on.

dselect is out: interactive, hence useless. dpkg via rsh from a single
trusted host (or ssh) isn't bad, only needs the packages to be NFS
mountable and our local mirror allows NFS mounts for hosts within the
UK (the academic net is a 33Mb/s ring over the UK so we don't have
bandwidth problems as long as we don't leave our cosy
neighbourhood). The problem, as you mentioned, is the answering of
questions, a real pain, _and_ the fact that some configuration files
are modified without telling the user (cf. my mail on /etc/X11/Xservers).

Also, most packages, once upgraded need a reboot to be running clean,
e.g. sendmail which isn't stopped during upgrade (this is criminal BTW
since you then proceed to modify the .cf file...), this is not good
for multi-machines 'cos I have jobs running and people to take care
of...

Finally, what about the extras? For example, without /etc/environment
with LD_PRELOAD set to the GNU malloc I couldn't get xrdb to work in
the first incarnation of X 3.2 - changing it on all machines meant an
rdist, no problem...

Basically my real problem is that I cannot find a coherent upgrade
strategy, something which would be very nice is a dry run option to
dpkg and dselect, i.e. pretend and show me problems, then I can see it
before I mess up... Also a verbose mode where it shows me file
modifications, this would have helped me catch the /etc/X11/Xservers
problem before it hit me.

Once I have an "optimal dry run" I can then write a script which does
the nifty things by hand, like upgrading the libc first to save
dependencies or something along those lines.

Arrigo

P.S.	I added debian-users in the Cc: field 'cos I think it is of
	interest over there.

-- 
Arrigo Triulzi <arrigo@ic.ac.uk>, http://www.ma.ic.ac.uk/~agbt
Mathematics Dept. Imperial College of Science & Technology - London - UK


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: