have you looked at fai (as in apt-cache show fai-client). you dont need a fai-server (any vcs will do), you dont need to install with fai, you can use cfengine with fai, you can script anything with fai. sure, you need to write some simple scripts and hack it to fit the way you want, but I think thats better then yet another in-house system very similar to fai :-) fai is written in perl and bash, but fai scripts can be written in any language. its gpl2+. cheers!

If you want to dig deeper in cfengine and stick with the one in debian lenny, then get yourself a copy of 'Automating Linux and Unix System Administration, second edition' by Campi and Bauer. Brilliant book. They teach you how to combine FAI, kikstart and jumpstart with cfengine 2.

At work I manage about 20 servers like this and provided I am the only unix admin, I'm glad I do it so.

Cfengine 3 is apparently much better than 2, but I still have not found anything I cannot do with 2, so ...

I know I will have to upgrade sometime in the future, but I am in no rush. Maybe those same authors will make a 3rd edition for cfengine 3 ...

Thanks for the feedback - FAI looks interesting but I'd always had it down as a more complex and capable solution.

(We already have in-house tools for reimaging machines so the idea of using FAI didn't really occur to me, I assumed it would want to be used for everything.)

CFEngine3 does look interesting, I did experiment with it briefly, but it doesn't yet appear to be recommended - nor is it included in the *BSD port trees (unless I missed it, or things have changed over the past few months).

FAI's problem, in my experience, is that it's too focused on initial deployment, and not enough on on-going maintenance. Unless you reinstall all your machines to effect a config change, FAI isn't particularly useful.

Out of interest, Steve, why is option 4: "Extend Puppet to do what I need" not on the list? Puppet's primitives only do what someone has sat down and made them do, so when there's differences between platforms it's usually because whoever wrote the support for a particular platform didn't need that part of the type for their case.

Of course your users can use sudo...wait, you make them enter a password? :)

I don't consider NOPASSWD a security problem. On the contrary, I consider PASSWD a security problem. It means users actually have a password, rather than key-only access. It also means that a keylogger or trojan horse of some kind can obtain their password, providing instant access to many other systems they have accounts on, as well as sudo on those machines. Unless you seriously think most users have multiple remote-system passwords. NOPASSWD and key-only SSH access, on the other hand, means that a compromise only affects one system.

I am no freebsd user, but cfengine 3 is ported: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/cfengine3/

FAI is obviously for hands-off installations, the name says it ;) the nice thing about it is that it works beautifully with cfengine's classes, so you can rollout new machines and have them inmediately set up to your needs.

Option "4. Fixing the broken bits" could have been listed but the bits that were broken weren't fully known, and it seemed like the potential gain from dong that wasn't too hard.

i.e. The task of creating puppet repository with all the rules/actions/steps and fixing puppet is harder work than dropping the CFEngine rules and rewriting those from scratch.

sudo PASSWD vs NOPASSWD is interesting.

Given that I disable remote-root by default to do something really bad a remote attacker needs to steal both a key and a password to compromise a machine fully - in the absence of security holes.

That to me seems saner than having to just steal a key and get root on my machine...

> FAI's problem, in my experience, is that it's too focused
> on initial deployment, and not enough on on-going
> maintenance. Unless you reinstall all your machines to
> effect a config change, FAI isn't particularly useful.

This is wrong, FAI's softupdate feature does not require that anything be reinstalled for a config change.

A key alone proves sufficient either way; just trojan-horse the user's account. For instance, add a fake sudo somewhere in their path, which fakes the password dialog, forwards to the real sudo to avoid suspicion, and deletes itself. Or, if you want a more active approach, prompt them for a password when they log in, and most users will just assume a configuration issue and enter their password. Or for a highly passive approach, just wait for them to use sudo and take advantage of the timestamp to run whatever you like as root.

How do you think about using debian packages for configuration management? You're limited to debian based systems, but there's nothing you can't do with debian packages and there's already a very powerful toolchain.

Using Debian packages would fail upon non-Debian systems - which would spoil their use.

Also I expect many of the packages would want to mess with the configuration files belonging to other packages - e.g. replacing /etc/sudoers, or modifying files beneath /etc/pam.d - so the packages I did install would be non-policy-compliant and liable to break upon future upgrades...

I just found http://packages.debian.org/sid/dpsyco which may help with the problems you described. Will have a look at it now.

so your only point against puppet is that some options are on some systems not available? Why do you think that something like chef would have solved that problem? Chef has so far much less platform support than puppet. So why do you think chef is the better option if you complain about platform support?

The only problem is that somebody didn't yet implement the os-/distro-specific parts for this option in puppet. Why not implement it yourself? If nobody is going to do it, require it or even just paying for it it will never be there...