Re: Internal "mirror" for fou4s

/ 2004-01-29 10:20:07 +0100
\ Markus Gaugusch:
> On Jan 29, Bernd Felsche <[email protected]> wrote:
> 
> > I've finally bitten the bullet and "done it right".
> >
> > The FAQ page mentions a couple of methods of keeping several hosts
> > updated from a common archive.
> >
> > One option not mentioned is to set up a "mirror" using an httpd.
> >
> Your apache setup seems to be ok.

You noticed the small change I made to your fou4s, to enable it to
have access to the local package repository via rsync -e ssh ?

> >
> > On each client, run
> > 	fou4s --export client.fou
> > and transfer the file to the master server.
> Uhhhmm ... no. The import/export feature was thought for completely
> offline hosts. You should rather run "fou4s --host client1", which imports
> the RPM db of that host via SSH.

BTW, I should get my act together and update fou4s-lge, merge
again with Markus, or just remove it from the page.
The version available on the download page is not working properly
with suse 9.0, is no longer config file compatible with Markus
fou4s, and the fact that it parses descriptions faster will only
be noticed on Pentium 120 and lower ;)

> > Proceed with updating the master server
> > 	fou4s --auto --checkfou4s
> No, you must run the --auto together with the --host parameter of the
> client. If several clients have nearly the same files, they are only
> downloaded once. I'd probably also don't use --auto but fou4s -ued (update
> patch descriptions, examine, download) and redirect to /dev/null. The
> clients should run fou4s a bit later and will just find the new packages,
> send notification mail, etc.

> I have yet to think of a mechanism for "publishing" updates, e.g. the
> admin tries an update on his test machine and says "ok, I want this on all
> others".
> I must admit, that I don't use such a setup anywhere, because I've never
> had a farm of SuSE machines to handle :(
> Only a couple of machines here and there - still handled manually.

Mechanism could be:
have <arch>/updates/<suseversion>/patches/*,
and  <arch>/updates/<suseversion>/patches.confirmed/*
Only copy "confirmed" patch descriptions to the confirmed directory,
and voila, all clients in "--only-confirmed" mode have them available.

Or, do it the other way round, do not make available the real
"patches/", have them in "patches.unconfirmed/", have the test machine
running with --even-unconfirmed, and copy them over into the
exported "patches/" when you confirm it.


	Lars Ellenberg
--