FAI 3.3 released

[Michael Tautschnig]

> Hello,
> 
> just my 2c:
> 
> > >      The reason is quite simple: It is a server with a complete
> > >      different layout of the filesystem, using xfs and some other
> > >      special settings. But it would be much easier if we can use
> > >      fai to keep the system up-to-date...
> > 
> > That works perfectly fine, just install the fai-client package on the target
> > system and set the proper values in fai.conf. I'm using it on one of my servers
> > and I believe several others are doing so too.
> 
> I never found fai-softupdate the right way to keep the system under control.
> To make small changes to config files, just install a package and stuff like
> that, perhaps the layout of my FAI configuration was not the best. But
> serveral steps in the scripts should/could not be run more than once. So I
> ended up using FAI for installation an then run some sort on on-all script
> to do the day to day management. (Perhaps my initial FAI did not even had
> softupdates)
> 
> One problem I had where packages that got requested by users after the
> initial installation. They got added to the fai configuration, but some
> times the next installation was broken, due to dependencies or that what
> ever, or I forgot the according config file change.
> 

That's a matter of proper processes. I'm managing my entire system configuration
using a central (subversion) repository hosting the FAI config space. Any kind
of configuration change is only done in this repository. Afterwards, I run
softupdates to enable those changes (or add new packages) on the target host. In
fact, I have measures in place that ensure that other admins will get notified
if anyone ever changes something on a host other than via a softupdate.

This may seem like overkill for changing a single line in a config file or
something. But it allows, for example, migrating an entire setup from A to
totally new (and different) servers and client hosts at location B without the
slightest fear that some change might have been forgotten over the years. By the
way, A == TU München, B == TU Darmstadt.

> Currently I am evaluating bfcg2 and puppet, both the next generation
> cfengine to be. The Idea is to install a base system with preseeding and let
> bcfg2/puppet do the rest. The outcome should be a simple (quick) rollout, a
> consistent configuration based on rules. And changes of the clients are
> mangened through the central config space.
> 

Of course, these tools also do their job in some or the other way. I just never
found that much of a difference, they just seemed much more complicated. But
that's a matter of taste I guess.

Best,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20091103/de82b382/attachment-0001.bin