> 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
pgprt7EjGygj8.pgp
Description: PGP signature
