auto-softupdate

[Henning Glawe]

On Fri, Mar 17, 2006 at 01:43:12PM +0100, Cedric BRINER wrote:
> I'm thinking to put /usr/sbin/fai softupdate in the cron of every client.
> is there a best practice for doing this.

well, _in principle_ you could do this; however, you should also add an init
script updating the machine, in case it was switched off when the update
should happen.

> let's say that this softupdate will happen every night. What happen If I'm working
> on a the configuration space, and that this configuration is not yet working well.
> 
> To avoid such situation, I was thinking to give a version to the configuration
> space, and to do a script on any client which will do a softupdate only if the
> version of the configuration space is higher than the last softupdate done.

I am doing it a bit differently: our configuration is kept in a CVS
repository, where we mark the 'production' versions of the files with a
sticky tag 'STABLE'.
the clients check out this tag (setting FAI_CVSTAG variable in fai.conf).

> Does some one of you has already think of this; is this a good idea ?

depends; as we are administrating 150 machines using fai-update-system (which
has been merged as "fai softupdate" in the official fai), we _don't_ use a
cronjob for starting the updates (however, we planned to do so earlier).

The problems are: 
1) not only the configuration space, but also an archive of 
   locally created packages is worked on by a group of people. sometimes
   mistakes happen, such as uploads of broken packages to the archive or
   configuration files tagged STABLE while they actually aren't ;). If a cron
   job would do the updates, and something is badly broken, you have to run
   around the whole not-too-small building to fix the machines.

2) network bandwidth: though we have 100Mbit in-house network and the package
   mirror is connected to the switch even with 1Gbit lan, letting 150
   machines download a new, bugfixed version of, say, openoffice, really
   saturates the in-house network (this could be worked around using a
   random-delay in the cron jobs).

we have chosen another strategy:
 - I have written a small utility in perl, which logs in as root via ssh to
   the clients and starts the updates there, tracks their status using a 
   parser on the stdout of fai, and displays it in a not-so-well-designed ;)
   curses UI. the tool keeps N machines updating at the same time, going 
   through a list of all to-be-updated machines (the tool is called
   fai-updater, and due to time limitations not yet published).
   
 - in regular intervals, someone starts an update on a group of
   representative test machines, using fai-updater and can easily see if
   something has gone wrong. if everything went well, fai-updater is set lose
   on all the machines in the department.

-- 
c u
henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20060317/c5f4869b/attachment.bin