Posts

Showing posts with the label noop

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  ...
Post a Comment
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...
Post a Comment
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:2...
Post a Comment
Read more

puppet agent???

*Agent sub-command in Puppet "puppet agent"* The puppet agent subcommand is a powerful tool which fetches the configurations from a master server and get that applied to the agent node. It has basically two modes: 1. Daemonize and fetch configurations every half-hour (this is by default and can be changed). 2. Run once and quit It is the main puppet client. Basically its purpose is to retrieve the local machine's configuration from a remote server[the master] and apply it to the agent node. In order to successfully communicate with the remote server, the client must have a certificate signed by a certificate authority provided by the puppet master. The client will connect and request a signed certificate unless and until the puppet master sign's the certificate the agent node cannot communicate with the puppet master. Once the client has a signed certificate, it will retrieve its configuration from the puppet master and apply it on the agent node. Now sup...
Post a Comment
Read more