I want to quiet, full blown PC, without fans nor a harddisk in my living room. See my other blog about this subject

Currently I’m thinking about the following setup:

  • NFS4 root
  • some sort of configuration management

I wanted to use puppet, but after seeing it use more than 30% of my main memory – This is on a AMD64 Ubuntu server – I was ready to ditch it.

I’ve also have experience with cfengine, so I’m going to use that. In conjunction with svn. I’m going to store all my configs + cfengine files in one repository. The modus operandi will become:

  1. edit a file
  2. check it into subversion
  3. periodically check out the subversion to a directory where cfengine will look for updates - this will probably happen every 5 minutes
  4. let cfegine distribute the changes to other machine
  5. let the cfagent on the different machine figure out what to do.

So this blog is now becomming a post on how to configure cfengine :)


The shortest none trivial snippet I could think of is

actionsequence = ( shellcommands )

    "/bin/echo Danger Robinson!" define=motd

    "/bin/echo Ha ha after the first echo!"

Note: no spaces are allowed in define=motd. With this you can get extra ordering.

From here we can do wilder stuff, like for instance getting a copy from the motd file and running a post processing which is needed in Debian:

uname -snrvm > /var/run/motd
[ -f /etc/motd.tail ] && cat /etc/motd.tail >> /var/run/motd

/etc/motd is a symlink pointing to /var/run/motd. All commands in the shellcommands section should begin with a /, hence the weird looking: /usr/bin/[.

Going about this, I’m getting to the following snippet:

actionsequence = ( copy shellcommands )


    "/bin/uname -snrvm > /var/run/motd"
    "/usr/bin/[ -f /etc/motd.tail ] && /bin/cat /etc/motd.tail >> /var/run/motd"

Which will update /etc/motd if there is a change.


I’ve created a subversion repository where I’m going to put these files in. A cronjob will periodically check this out into /etc/cfengine so that cfengine will pick up any new changes automatically.


I’ve found that sudo cfagent -Hnvf cfagent.conf is a very neat way to test out any given cfagent.conf, before deploying it for real.

Later on I will blog some more about the precise setup I’m going to use.