dropdown menu


Puppet is a configuration management tool, which automates the configuration of servers. Puppet follows client-server model (Puppet Agents are connected to a Puppet Master), and agents are checking (by default every 30 mins) the status of the server, and if needed they download (pull) from master the necessary configuration (packages, files etc.)  Master can be run only on Linux and using port 8140. 

Declarative language: it describes the desired state of a server (instead of saying “run this command that starts a service,” it says  "ensure this service is running".)
Idempotency: if we implement it many times (eg. running a command many times) the state of the server will remain the same (adding a line to a file is not idempotent as the file will grow during runs)
Fact: Facts are details related to a node (fact can be a hostname, ip address, filenames etc.)
Catalog: Facts are compiled to catalogs. The agent uses catalogs to apply what is needed (install packages, create files..)
Manifest: a file with pp (puppet program) extension, which contains puppet code
Resource: anything which can be configured on a system, like a user, a specific file, a directory, a running service etc.
Resource type: similar resources can be grouped into types (like all existing users on a system belong to the user resource type)
Classes: a puppet code which contain multiple small operations working toward a single large goal can be organized into a class (like all ssh related things, would be called together the ssh class)
Modules:  collection of files or directories (such as manifests, class definitions), reusable and shareable units of puppet


Puppet agent/master:

Puppet master contains all the puppet code and definitions which are applied on every server where puppet agent is running. Puppet agent (on the client servers) runs as a service, and triggers a Puppet run at the configured time (usually every half an hour). Puppet agent does not have access to any manifests; instead, it requests a pre-compiled catalog from puppet master.

The Puppet master collects details (facts) of the target machine, then these are compared with the originally defined configuration details. After that Puppet master creates a catalog (a list which needs to be applied on the client) and sends it to the targeted Puppet agents. The Puppet agent then applies those configurations to get the system into a desired state. Finally, once one has the target node in a desired state, it sends a report back to the Puppet master.



When the Puppet agent starts running at the first time, it generates a SSL certificate and sends it to the Puppet master which is going to manage it for signing and approval. Once the Puppet master approves the agent’s certificate signature request, it will be able to communicate and manage the agent node.

Signing a certificate:
1. puppet cert list          <--see all unsigned certificate requests  (does not sontain a + sign, so cert is not signed yet)
2. puppet cert sign <host>   <--will sign the certificate request from given host (host can be checked from the above output)
3. puppet cert sign --all    <--lists all certificates (signed and not signed, + means it is signed))

puppet cert clean <host>     <--removing a host from puppet

Master is the certificate authority for all agents. When agent tries to communicate with the master it checks if it has a signed certificate from the master, if not it generates a certificate request, sends it to the master, the master signs the certificate request and sends it back to the agent. The agent stores it and uses it for all future communications. Until master approves the certificate request, no communiaction will start between master and agent.

auto sign:
1. create file on master:
maintenance@puppet:/$ cat /etc/puppet/autosign.conf

2. restart services on master



Puppet code is contained in files which are called manifests, and they have .pp extension. These files contain what we want to achieve (a service is running, a directory exists,  a user is not on the system anymore.)

An example manifest file which removes a user (/home/user-absent.pp):
user {'dave':
 ensure => absent,

To run it:
# puppet apply /home/user-absent.pp
Notice: Compiled catalog for aix_test.mydomain.org in environment production in 0.27 seconds
Notice: /Stage[main]/Main/User[dave]/ensure: removed
Notice: Finished catalog run in 0.48 seconds

We can have multiple manifest files which we can use at the same time, so they are not used directly when Puppet syncs resources:

Before being applied, manifests get compiled into a document called a “catalog,” which only contains resources and hints about the ordering to apply them. (In a master/agent Puppet environment agents can only see the catalog (and not the manifests)). By using this logic, manifests can be flexible and describe many systems at once. A catalog describes desired states for one system. (Agent nodes can only retrieve their own catalog)

site.pp is the main entry point (manifest) for the entire puppet network, this file is the main starting point for the catalog compilation (referred as site manifest)



puppet help
puppet help resource

/etc/puppet/puppet.conf                   main configuration file
puppet config print                       lists puppet config parameters (config files, module path, users …)

facter                                    lists environment variables
facter <variable>                         lists only one variable
facter -p                                 see any facts that have been defined locally

puppet cert list                          shows you any pending requests generated by the agents
puppet cert list --all                    shows all the approved and pending certificate requests
puppet cert sign <FQDN>                   sign and approve the authentication request
puppet cert clean                         remove the existing certificate from the master
puppet cert generate                      generate certificate (by default it is not needed only in specific situations)

puppet resource --types                   list all default resource types that are available to Puppet
puppet resource user                      list all user resources on the server with attributes
puppet resource user <user>               lists attributes of given user
puppet resource user katie ensure=present shell="/bin/bash"   setting a new desired state for a resource
puppet resource user katie --edit         change a resource in text editor, after it is saved Puppet will modify that resource

puppet describe                           lists all of the associated attributes for Puppet resource types
puppet describe --list                    lists resources with some description (puppet resource --types, will lists only the names)
puppet describe -s <TYPE>                 print short information about a type

puppet parser validate demouser.pp        verify the code is error free (shows if there are syntax errors)
puppet apply demouser.pp --noop           it shows what it would be done (it will not change anything, called smoke test)

Puppet agent -t is --test:
The --test option runs the Puppet client in the foreground, outputs to standard out, and exits after the run is complete. 
most common options used for testing. These are 'onetime', 'verbose', 'ignorecache', 'no-daemonize', 'no-usecacheonfailure', 'detailed-exitcodes', 'no-splay', and 'show_diff'.

puppet agent -tv --noop                  no operation mode (does not change anything on the client, it will show what Puppet would do, as a dry run)
puppet agent -tv                          apply configurations with verbose mode
Puppet agent -td                          apply configurations with debug mode

puppet apply -e 'notify {"Hello World": }'
puppet apply -e 'if "Puppet" == "puppet" { notify { "true!?": } }'

puppet apply <path to manifests file>     applying puppet code in the given manifest file
puppet apply --modulepath=/mnt/test /mnt/test/site.pp

puppet master --no-daemonize --verbose --debug     on Puppet master (we can see the results of the run, it is logged as well)

puppet module install puppetlabs-msql     install a specific module
puppet module list                        lists installed modules


Installing Puppet

Below method shows how to install puppet by using ruby and gems.
(It is good for opensource puppet, for enterprise may other method is needed.)

1. install ruby
(AIX is already configured to use yum, so ruby install is pretty simple.) 
# yum install ruby

2. install gems needed for puppet
# mkdir -p /etc/puppet /var/lib/puppet

# /opt/freeware/bin/gem install --no-rdoc --no-ri --version 2.5.1 facter
# /opt/freeware/bin/gem install --no-rdoc --no-ri --version 2.1.0 json_pure
# /opt/freeware/bin/gem install --no-rdoc --no-ri --version 1.3.4 hiera
# /opt/freeware/bin/gem install --no-rdoc --no-ri --version 3.8.7 puppet

3. create links for puppet commands
# ln -s /opt/freeware/lib64/ruby/gems/2.4.0/gems/puppet-3.8.7/bin/puppet /usr/bin/puppet
# ln -s /opt/freeware/lib64/ruby/gems/2.4.0/gems/facter-2.5.1/bin/facter /usr/bin/facter

4. fix some bugs/errors
Changing syck thing in YAML related ruby file:

for AIX 7.1 TL5 and 7.2 TL1 (and above) puppet chpasswd has a bug:
# sed '/(:chpasswd)/ s/, user//' $RUBY_CHPASSWD >RUBY_CHPASSWD.new

5. after that puppet commands should work: 
# puppet --version


Visualizing resources into graphs (GraphViz):

1. generate dot files with puppet:
    - puppet apply --modulepath=/mnt/test /mnt/test/site.pp --noop --graph
    - 3 dot files will be under: /var/lib/puppet/state/graphs (expanded…, relationsh., resources)

2. copy dot files to mobaxterm:
    - first I copied to /mnt: cp /var/lib/puppet/state/graphs/*.dot /mnt
    - scp labuser@*.dot .

3. convert dot files to graphs (png)
   /drives/c/_WORK/Tools/graphviz/bin/dot.exe -Tpng resources.dot -o resources.png
   /drives/c/_WORK/Tools/graphviz/bin/dot.exe -Tpng relationships.dot -o relationships.png
   /drives/c/_WORK/Tools/graphviz/bin/dot.exe -Tpng expanded_relationships.dot -o expanded_relationships.png



Puppet also has a linter to enforce the style guide. It is called puppet-lint and can be installed from gems.
root@pro-puppet4:~# puppet-lint parent-scope.pp
ERROR: ssh::params not in autoload module layout on line 2
ERROR: ssh not in autoload module layout on line 10
WARNING: top-scope variable being used without an explicit namespace on line 12


No comments:

Post a Comment