A while back, I had written a quick and dirty shell script to take a simple tarball of the /etc directory of my linux machines and copy it to an FTP server. Then, to make sure that the FTP directory didn’t get out of hand, I had written the following in my puppet config for that server that would clean everything up with the use of the tidy resource type. The code looked like this:
Have you ever had one of those days where you see on your dashboard one of your long lost boxen is no longer successfully reporting into your beloved puppet master? I’ve had a problem child as of late and I’m not sure if it was a security patch for openssl or if it was when the box moved from one virtual environment into a vCloud environment. But whatever the reason, I was suddenly seeing red when I would manually run my puppet agent command on the box. Here is the error I was seeing:
I’m very fortunate to have a nice lab at work where I have a UCS chassis, fabrics, a few blades and a VNX to play with. Recently I’ve been working on getting our Razor implementation hammered out so messing around with all the good automation bits.
Now, because its a lab, it doesn’t tend to fall into the same patching cycles as our production servers do. My Razor server in particular is an example of this only getting updated when I have the chance to turn a wrench.
For those that are interested in learning a little bit more about Puppet, join me at the KC VMUG Meeting on August 15th from 1:30 – 4. I’ll be giving a talk on how we use Puppet at LightEdge and a few cool things you can do to automate your server deployments.
Should be a good (and informative) time.
Recently while patching some CentOS boxes in my lab, I noticed the following error.
This was a bit odd as one of the things that I will typically do when I see puppet or facter updates in my update list is to run the agent manually with a