I’ve had a “backup” puppet server for some time now, but the fail-over was completely manual. Meaning if the main puppet server failed, I’d actually need to change DNS to point to the other server. This if fine for environments where a bit of downtime does not hurt, but in a production environment it’s less than ideal. When I had a bit of spare time recently I decided to implement an automatic fail over for our environment. To do this I decided to use HAProxy for the load balancing and keepalived to manage a virtual IP.
Read more…
Mike Zupan’s blog has a nice how to on installing puppet’s dashboard on CentOS 5, following it I was able to get the dashboard up and running with ease. Since I have two puppet master’s that I’d like to report to the dashboard I found you can easily accomplish this without a full dashboard install on each master.
You just need to:
- Copy over ‘puppet_dashboard.rb’ with a modified HOST line to the other host.
- Modify /etc/sysconfig/puppetmaster.
- Turn on reporting on the clients.
- Restart puppetmaster.
Since the puppet_dashboard.rb is just making an HTTP post to the dashboard server, it can be coming from anywhere.
Since I failed to find a good description of how to do this on the web, I thought I’d share my recipe for using puppet to manage tripwire. This method will take care of running the initialization on the first puppetd run on a new machine, and update the policy file if its changed. It also has puppet managing your site.key, twcfg.txt, twpol.txt, and the daily cron to run the checks. Its an extremely simple setup, but gets the job done.
I’ll start with the tripwire.pp file for puppet, in this file you’ll define your tripwire class and associated files and packages:
Read more…
