Featured Post

Directory environments in Puppet

Environments are individual groups of Puppet agents each environment have there own completely different manifests and module-paths. This basically is useful for testing changes to our Puppet code before implementing them on production machines. There are two types of implementation of environments structure in Puppet one if directory based and another is config file based here we will see bit of an insight about directory based. As usual for more information about this you can visit puppetlabs official website. On the master node: Append following details in puppet.conf which is placed under /etc/puppet or /etc/puppetlabs/puppet:     Under [main] section add a variable called confdir with value as /etc/puppet or /etc/puppetlabs/puppet     confdir=/etc/puppet Then add information regarding environments/manifests and modulepath in it.      #environments     environmentpath = $confdir/environments     default_manfiest = $confdir/manifests     basemodulepath =
Post a Comment

Puppet installation on agent/server

Puppet can be used as a standalone model or as agent/server model.

There are basically 2 types of puppet version available in market.
  • Free version of puppet.
  • Enterprise version of puppet which is also know as puppet-enterprise.
Here we will be installing the free version of puppet.

0. Enable EPEL repo, you can find the latest version of EPEL on below URL:
1. Install prerequisites before installing puppet
  • [root@rhel6 ~]# yum install ruby-shadow ruby ruby-libs
2. Resolve the dependencies like ruby(selinux).

3. Install puppetmaster and facter on the server node.
  • [root@rhel6 ~]# yum install puppet-server facter
4. Install puppet and facter on the agent node.
  • [root@rhel6 ~]# yum install puppet facter
Once these packages are installed on both the machines.

Make sure that your agent node can ping the server node with the name as puppet.

[root@rhel6 ~]# ping puppet
PING puppet (192.168.122.14) 56(84) bytes of data.
64 bytes from puppet (192.168.122.14): icmp_seq=1 ttl=64 time=0.356 ms
64 bytes from puppet (192.168.122.14): icmp_seq=2 ttl=64 time=0.831 ms
^C
--- puppet ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1887ms
rtt min/avg/max/mdev = 0.356/0.593/0.831/0.238 ms
[root@rhel6 ~]#

Now on agent node fire the command as puppet agent --test as this is the first time you are firing this command what this command will do?

It will create a certificate on the agent node which needs to be signed by the puppet master so that both the machines can communicate between each other.

[root@rhel6 ssl]# puppet agent --test
info: Creating a new SSL key for rhel6.sunny.com
info: Caching certificate for ca
info: Creating a new SSL certificate request for rhel6.sunny.com
info: Certificate Request fingerprint (md5): 60:B9:2F:99:5C:A7:5E:81:8C:3A:65:F6:02:5A:69:92
Exiting; no certificate found and waitforcert is disabled
[root@rhel6 ssl]#

Now go on the puppet master node and fire the command puppet cert --list what this command will do is display all the certificate requests pending on masters side.

[root@puppet requests]# puppet cert list
  "rhel6.sunny.com" (60:B9:2F:99:5C:A7:5E:81:8C:3A:65:F6:02:5A:69:92)
[root@puppet requests]#

Now just the signing of certificate is required.

[root@puppet requests]# puppet cert --sign rhel6.sunny.com
notice: Signed certificate request for rhel6.sunny.com
notice: Removing file Puppet::SSL::CertificateRequest rhel6.sunny.com at '/var/lib/puppet/ssl/ca/requests/rhel6.sunny.com.pem'
[root@puppet requests]# 

 Now the certificate is signed, lets now try to run the puppet agent --test command on the agent side and check if the agent node now can communicate with the puppet master.

[root@rhel6 ssl]# puppet agent --test
info: Caching certificate for rhel6.sunny.com
info: Caching certificate_revocation_list for ca
info: Caching catalog for rhel6.sunny.com
info: Applying configuration version '1410275402'
notice: Finished catalog run in 0.35 seconds
[root@rhel6 ssl]#

Related Docs:

Comments

  1. Sunil KamatJune 22, 2016 at 11:10 PM

    Good Going man (Y) . keep up the good work and keep writing.
    I see that puppet stuff u write is of puppet 2.x , how about moving to puppet 3/4 ?

    ReplyDelete

Post a Comment

Popular posts from this blog

Exec in Puppet

Exec is a very useful resource type present in Puppet which is used to executes external commands. Puppet basically runs as a daemon in which it executes every 30 mins. So while writing an exec resource type make sure that the exec resource must be able to run multiple times without causing any harm to the machine i.e. it must be idempotent. Suppose you just want to run a command like reload a service for that what you can do is? exec { "reload httpd": command => "service httpd reload", path => "/usr/local/bin/:/bin/:/sbin/", } Lets break this line by line: exec { "reload httpd": This specifies that the resource type is exec type and has a human readable name as "reload httpd". command => "service httpd reload", This specified which command to execute when puppet is executed. path => "/usr/local/bin/:/bin/:/sbin/", This specifies where the binary service can be found in your mac
Read more

Un-revoke the revoked certificate in Puppet

If you revoked or deleted the puppet agent’s certificate accidentally. Basically it is nearly impossible un-revoke a certificate. The solution is to recover all revoked certificates then revoke other certificates which don’t need to be recovered. But if in-case you have thousands of revoked certificates then its a bit lengthy process. Second one is to generate a new certificate for the client/agent and get that signed by the puppet master.  List of all the certificates which are signed at the moment:  [root@puppet requests]# puppet cert list --all + "fedora20"            (AE:57:40:F6:FC:E1:CD:DD:ED:EE:1E:8C:A7:81:0D:76) + "kubuntu14.sunny.com" (20:6B:A1:E2:A3:DE:B1:95:C8:80:4C:B4:27:2B:C0:A2) + "puppet.sunny.com"    (68:12:76:3C:D0:F8:0D:2D:8B:2B:40:E7:49:2D:55:5B) (alt names: "DNS:puppet", "DNS:puppet.sunny.com") + "rhel6.sunny.com"     (DC:6E:B1:FC:27:1D:7A:2A:85:E7:3E:3A:24:8B:64:D3) [root@puppet requests]# N
Read more

Dry run in Puppet --noop

 Dry run in puppet is a powerful feature given by puppet. This basically is used to test your Puppet manifests on any of the environment without actually making any changes to the machine. To dry-run Puppet, --noop flag needs to be used. Puppet’s ‘noop’ (no-operation) mode shows you what would happen, but actually doesn’t do anything :) This basically helps us for debugging stuff. For instance: [root@puppet manifests]# puppet apply site.pp --noop notice: /Stage[main]/Sudo/File[/etc/sudoers]/content: current_value {md5}e81452ad78198a79772447b1f2b3b614, should be {md5}e2d690ebe349d93efa84146eb854c987 (noop) notice: Class[Sudo]: Would have triggered 'refresh' from 1 events notice: /Stage[main]/Ssh::Service/Service[sshd]/ensure: current_value stopped, should be running (noop) notice: Class[Ssh::Service]: Would have triggered 'refresh' from 1 events notice: Stage[main]: Would have triggered 'refresh' from 2 events notice: Finished catalog run in 2.75 seco
Read more