SYSTEMS Oliver Osburg <[email protected]> 2011-12-08 12:20:
On 07.12.2011 17:15, Frank Lienhard wrote:I have an i386 client, which I installed manually and I'm now wondering how to setup future clients "identical" to that with FAIat least to have the package selection transfered to the FAI config would save a lot of work, I thinkHi,I often reconfigure my clients, too. Config Files change, and I also would appreciate a way to "automatically" create FAI configs from a running Debian Machine. But in a way, this violates the FAI philosophy "Do all configurations on the server".After some thinking, one could conclude that this will never be possible to do 'perfectly' But I'm sure one could do nice things which could make a Sysadmin's life easier. Here, Machines constantly are updated. The following would be useful:a) check regularly if files deployed by FAI change on a Host in a certain class, so the file on the FAI server needs to be updated. b) check regularly if new packages are installed on the clients. If so add these packages to the package lists. c) check regularly if packages were removed on the clients. If so, remove these packages from the package lists on the FAI server. d) for all packages it needs to be checked if any configuration file is changed from the Debian default
I tend to think of fai as being useful for installs and use cfengine (or pick your variant) for config file maintenance (it also stores everything in a vcs). In my environment cfengine and fai work very closely together to bring a machine up and working in very little time - just add it to the right cfengine classes (eg: webserver or lab_host), which are dynamically turned into fai classes (eg: WEBSERVER or LAB_HOST) using a config/class/ script. Those FAI classes then make use of service specific disk_config and package_config files to install the machine's packages (eg: apache2 or rsync), then cfengine controls the configuration of those services. The usual mantra after that is to replace the machine (usually a vm) rather than upgrade it, so we just go through the same process again and transfer service ips/cnames around as necessary once the new one is up and running. That way if we replace or change packages on a service's config we just get the new version the next time we install rather than fighting with upgrading.
For lab hosts, I tend to let FAI get them partially working via netboot and then rsync the rest off of a golden image. That makes for a single point of management for most configs and customizations, then cfengine handles the rest.
Also, there's a tool called pkgsync I ran across a while ago that may help with some of the other points you outline above:
http://packages.debian.org/squeeze/pkgsync Brian
signature.asc
Description: Digital signature
