I'm continuing to explore the use of puppet for managing systems. I'm convinced that it's the best system for managing large groups of interacting servers and keeping them all in sync. For example, today I was trying to figure out why a cronjob that processes log files wasn't working. Turns out that it was a system issue and there was also a problem with mail aliases, so we weren't even finding out.

I create a simple puppet recipe for all our machines that simply ensures crond is running. That's basic and now it's ensured on all our machines. This was simple:

class cron {
      service { crond:
\t      ensure => running,
\t      enable => true
      }\t\t
}

Next I created a manifest to installed the correct crontab entry on the right machines to process the logs along with setting the right environment variables for the processing daemon. There's a cron "type" in puppet so it's pretty easy:

class kobj_log_daemon {

      cron { kobj_log_daemon:
           command => "bin/kobj_log_daemon -v",
\t   user => www,
\t   hour => 0,
\t   minute => 5,
\t   environment => ["WEBROOT=/www", "MAILTO=root"],
      }
}

Finally, I took care of mail aliases by putting /etc/aliases under the control of puppet. Here's the class definition that does that:

class aliases {
 file { "/etc/aliases":
   mode  => 640,
   source => 
     "puppet://puppet.kobj.net/dist/apps/sendmail/aliases",
   owner => "root",
   group => "root",
   before  => Exec["create aliases db"]
 }

 exec { "new_aliases":
   command => "/usr/bin/newaliases",
   alias => "create aliases db",
   subscribe => File["/etc/aliases"],
   refreshonly => true,
 }
}

Now there's one place--under version control--where all of this is controlled for every machine we own. Managing this any other way would be a recipe for disaster.


Please leave comments using the Hypothes.is sidebar.

Last modified: Thu Oct 10 12:47:18 2019.