Found some parties interested in Puppet! What an easy sell! These people manage hundreds of Unix and Linux servers daily. The sales process was so easy it was almost a shoo-in! These are people doing security audits on their machines and in the past they were just limited to performing the security audits and reporting them. When I told them that they could now go one step beyond by ensuring that the files are always kept in their original condition (adhering to security check lists) they were very interested.
Probably the only thing that I have to look into a bit more is the web front end to puppet. There were a few projects that I found namely puppetshow and puppet-reporter but a lot of the links to these sites were dead. These projects are mostly based on ROR and seems promising. I especially like the puppet-reporter and am looking to get it working as this is being written.
Will report more once I get it up and running
Tuesday, May 18, 2010
Monday, May 10, 2010
Decreasing the default poll time for puppet client
I did this the last time but recently just found out I forgot how to do it. The default poll time for the client is about 30 mins. While this is just fine for some applications, but then how the heck to increase the frequency of the poll or decrease the poll time?! I looked around for what I did last time but could not find it (thanks to a hdd which is not active), after looking around more and feeling really frustrated almost giving in, I found the configuration parameter.
The configuration parameter to decrease the poll time is :
"runinterval=" this should be placed in the [puppet] section in the puppet.conf configuration file. This post is just to serve as a reminder to myself if I just happen to be old and forget this again :P.
The configuration parameter to decrease the poll time is :
"runinterval=
Thursday, May 6, 2010
Being a file server?
One thing that I like a lot about puppet is it's ability to act as the source of configuration hence being the head honcho is a configuration management setup. Setting this baby up though required much patience as the docs needed some maneuvering.
Okay here goes. Inside the default configuration, there is a file called fileserver.conf which describes the behavior of the puppet master server acting as a fileserver or source of configuration files. This file was not present in my opensuse package. So all I had to do was to create the file in /etc/puppet/. Okay say you wanted as most of the examples state be a source of the sudoers file. This means that any server connected to the network with the puppet client installed will pull the sudoers file from the main server.
site.pp has to be configured as so:
class sudo{
file { "/tmp/sudoersxxx":
owner => root,
group => root,
mode => 440,
source => "puppet://robot-ng/files/sudoersxxx"
}}
Here I purposely picked /tmp so that it will not effect the real sudoers file since we are just doing a quick test to see if our configuration works. Okay so far so good. Let's get to the good part where it had me typing furiously not to mention tearing out my hair follicles at the same time. Notice the part "source => 'puppet://robot-ng/files/sudoersxxx'". I will tell you my understanding of this as the docs and examples put in good olde' spinning confusion for hours and hours. To the server this part means that, expect to find the source file from a server called "robot-ng". The source file itself is called 'sudoersxxx', as for the path that the file is kept, this config is telling puppet master to peek into the fileserver.conf configuration file and look up the path under a section called 'files'. So, in the fileserver.conf file I put this:
[files]
path /etc/puppet/files/dist/apps/sudo/
allow *
When puppet master finds this, it will follow the path to fetch the configuration file. The next bit of the allow is to specify which host is allowed to get this file. I have covered what I think is the most confusing of the configuration management source file examples, so hopefully less of your fingernails will be embedded in your scalp trying to get this to work compared to me :).
Okay here goes. Inside the default configuration, there is a file called fileserver.conf which describes the behavior of the puppet master server acting as a fileserver or source of configuration files. This file was not present in my opensuse package. So all I had to do was to create the file in /etc/puppet/. Okay say you wanted as most of the examples state be a source of the sudoers file. This means that any server connected to the network with the puppet client installed will pull the sudoers file from the main server.
site.pp has to be configured as so:
class sudo{
file { "/tmp/sudoersxxx":
owner => root,
group => root,
mode => 440,
source => "puppet://robot-ng/files/sudoersxxx"
}}
Here I purposely picked /tmp so that it will not effect the real sudoers file since we are just doing a quick test to see if our configuration works. Okay so far so good. Let's get to the good part where it had me typing furiously not to mention tearing out my hair follicles at the same time. Notice the part "source => 'puppet://robot-ng/files/sudoersxxx'". I will tell you my understanding of this as the docs and examples put in good olde' spinning confusion for hours and hours. To the server this part means that, expect to find the source file from a server called "robot-ng". The source file itself is called 'sudoersxxx', as for the path that the file is kept, this config is telling puppet master to peek into the fileserver.conf configuration file and look up the path under a section called 'files'. So, in the fileserver.conf file I put this:
[files]
path /etc/puppet/files/dist/apps/sudo/
allow *
When puppet master finds this, it will follow the path to fetch the configuration file. The next bit of the allow is to specify which host is allowed to get this file. I have covered what I think is the most confusing of the configuration management source file examples, so hopefully less of your fingernails will be embedded in your scalp trying to get this to work compared to me :).
Wednesday, May 5, 2010
Blow by Blow to get puppet master working on Opensuse
Okay, let's be honest here. I really loath reading documentation. Once an app presents itself qualifying itself by saying I have to read a handbook first before using it, then I go looking for another app. So here I am going to record blow by blow (usually by trial and error with a method I coin "giving it everything it needs until it works") of getting puppetmasterd working on opensuse 11.2
- Firstly of course we have to get the package installed by running 'zypper -n in puppet-server'.
- Okay! Everything is done now let's start her up. Usually you will get an error like this "Starting puppetmaster services.Manifest does not exist: /etc/puppet/manifests/site.pp" and after spitting this error at you the service will fail to get going.
- Okay, following the principle above, let's feed it what it needs by doing 'mkdir /etc/puppet/manifests; touch /etc/puppet/manifests/site.pp'. This will create the manifests directory and put in a temporary site.pp for it to chew on. Let's try again.
- Okay better now, the service started up, after a while though something else cropped up "Could not find user puppet"
- Let's add the puppet user .. "useradd -m puppet" and see if it helps. Ah yes! No more errors!
Keep on pulling my strings!
When asked normally anybody who is new to ruby will say that they first got into ruby when they heard of Ruby On Rails the so-called killer app to emerge from the ruby camp. Newbies too normally will start to see the ruby world through the rose or otherwise colored glasses of RoR.
Well, I heard of Ruby before RoR and never did use it seriously for building any applications. Another project in the ruby camp has piqued my interest more and that is Puppet. I build and maintain a lot of architectural component daily and some tasks are not only repetitive they are just thankless and god forsaken! Well enter Puppet! Puppet has made performing or better yet automating these tasks fun again.
I have never had so much fun with systems side programming since the hey days of Nagios! To me, Puppet has succeeded in creating it's own contributing audience much how Nagios has. For those who took a trip to the sun to reboot it (great film from Boyle) and because of that have not heard of Puppet ... here is a little quote from the main Puppet Site to summarize what it does ... "is the leading open source tool for data center automation. Puppet helps you save time, gain visibility into your server environment, and ensure consistency across your IT infrastructure". Say you have installed about 30 servers and on each server you had to perform some system hardening such as tcpwrapper modifications or other such fun things ... imagine having to do this for each server or every time a new server is added into your environment. Let's just you will be a busy person will little left of something called a life!
Well our predecessors faced this same issue and left us with tools to help us out and Puppet happens to be one of them! By no means though is Puppet the only one. There are others like cfengine and others but for my money Puppet managed to make it the most fun with as least brain melting as possible. Some of the other things that I like about Puppet is the fact that the technology is mature and is available on most Unix platforms, so that makes deploying easy. I have tested most of the recipes and unlike some other Open Source projects out there that I know of the examples actually work and they work consistently well.
Puppet hails from a company called reductive labs and is also the commercial arm for Puppet. I have a good feeling that data center automation will be the next best thing and for now the easiest and quickest way to achieve some semblance of automation is through Puppet. Kudos for a well built app!
Well, I heard of Ruby before RoR and never did use it seriously for building any applications. Another project in the ruby camp has piqued my interest more and that is Puppet. I build and maintain a lot of architectural component daily and some tasks are not only repetitive they are just thankless and god forsaken! Well enter Puppet! Puppet has made performing or better yet automating these tasks fun again.
I have never had so much fun with systems side programming since the hey days of Nagios! To me, Puppet has succeeded in creating it's own contributing audience much how Nagios has. For those who took a trip to the sun to reboot it (great film from Boyle) and because of that have not heard of Puppet ... here is a little quote from the main Puppet Site to summarize what it does ... "is the leading open source tool for data center automation. Puppet helps you save time, gain visibility into your server environment, and ensure consistency across your IT infrastructure". Say you have installed about 30 servers and on each server you had to perform some system hardening such as tcpwrapper modifications or other such fun things ... imagine having to do this for each server or every time a new server is added into your environment. Let's just you will be a busy person will little left of something called a life!
Well our predecessors faced this same issue and left us with tools to help us out and Puppet happens to be one of them! By no means though is Puppet the only one. There are others like cfengine and others but for my money Puppet managed to make it the most fun with as least brain melting as possible. Some of the other things that I like about Puppet is the fact that the technology is mature and is available on most Unix platforms, so that makes deploying easy. I have tested most of the recipes and unlike some other Open Source projects out there that I know of the examples actually work and they work consistently well.
Puppet hails from a company called reductive labs and is also the commercial arm for Puppet. I have a good feeling that data center automation will be the next best thing and for now the easiest and quickest way to achieve some semblance of automation is through Puppet. Kudos for a well built app!
Subscribe to:
Posts (Atom)