Finally, the time has come… CFEngine

The amount of work that has not been automated bores me to death.

Imagine changing your own user password every month (!) on x-hundredth hosts manually for different reasons.

Of course, you can script it with an expect script and ssh-keys, but its still not ideal. What if your account is locked on one of them or the password changed manually at one time for a reason. then the expect script fails and the host in question is not completed.

First up, to determine policies and to add Gentoo’s portage so Cfengine recognises it in package management. Nothing too elaborate, just a simple setup that works.

package_changes               => "individual";
package_list_command          => "/usr/bin/python -c 'import os; os.system("/bin/ls -d /var/db/pkg/*/* | cut -c 13-")'";
package_list_name_regex       => ".*/([^s]+)-d.*";
package_list_version_regex    => ".*/[^s]+-(d.*)";
package_installed_regex       => ".*";                  # all reported are installed
package_name_convention       => "$(name)";
#package_list_update_command    => "/bin/echo --sync";           
package_list_update_command    => "/usr/bin/eix-sync";           
package_list_update_ifelapsed     => "14400";                 


package_add_command        => "/usr/bin/emerge -q --quiet-build";
#package_add_command         => "/bin/echo Installing";
package_delete_command      => "/usr/bin/emerge --depclean";
package_update_command      =>  "/usr/bin/emerge --update";
package_verify_command      => "/usr/bin/emerge -s";
package_noverify_regex      => ".*(Not Installed|Applications found : 0).*";

This causes portage to synchronise every 10 days and we use eix to speedup certain things.

Next up, we will save this file but not yet activate it. First I used the default update_script that came with cfengine as a failsafe mechanism. Editted to suit my needs, I don’t need a

/home/mark(etc)

with access to localhost ;-). Although these are mark’s unix pages of course. still, as a humourous sidenote maybe. Nope, editted out this one. Next up, I changed the place where cfengine keeps its masterfiles, for security-through-obscurity reasons. Although not real security, if it throws off even 10% of scriptkiddies it means it was successful.

When the client’s intranet is ready, I will move the cfengine off the public interface despite the fact the traffic never sees the full unprotected internet. Hackers can be even within one’s own ISP after all 🙂

Finally, I will configure cfengine to run shell-scripts on every host when present in a directory on its master and move the shell-script to an archive-directory along with the output logfiles.

My basic setup is now finished and onward to a more difficult setup.

Â