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…
I find myself compressing files for archival purposes constantly – today I was sitting, waiting on one such compression on a SMP box and thought it seems silly that bzip2 does not use more than one CPU. After a quick flip through the man page for bzip2 I found no way to force it to use more than one core. A quick web search yielded pbzip2 (http://compression.ca/pbzip2/) – another project that does indeed allow you to use more than one CPU for compress and decompression of bzip2 files. A quick test showed a huge reduction in compression time: 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.
Being in a large corporate environment has positives and negatives, one of those negatives is that many companies use HTTP proxies to control and track internet usage from your work machines. While in most cases this is very important from the HR and workplace productivity side, it can become a headache if you actually need something outside your companies firewalls that is blocked. In my case I wanted to backup some configurations and code to my home machine. To do this I’d generally just rsync over ssh or scp the files over to an off site machine. Sadly with a full firewall up and all traffic required to go through HTTP proxies, I had to find a different solution. In my case, I decided to use ‘corkscrew’.
Read more…