"clone" an example client?

Brian Kroth bpkroth at gmail.com
Thu Dec 8 16:26:39 CET 2011


SYSTEMS Oliver Osburg <osburg at osburg.org> 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 FAI
>>
>> at least to have the package selection transfered to the FAI config 
>> would save a lot of work, I think
> Hi,
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20111208/482af1e6/attachment.bin>


More information about the linux-fai mailing list