view · edit · history · print


Don't tell the systems HOW to do stuff, tell WHAT to do.

It it a one size fits all?

No, you can use tools like: Puppet, Chef, Salt, Ansible but no single approach fits all situations (link).

But before you are looking further, you should learn: RAL/resource, Facter, exec, Augeas/Xpath, Marionette Collective, ...

data/process flow

get started

server> yum install puppet-server
client> yum install puppet

client> echo "   puppet" >> /etc/hosts # make sure the client finds the master

server> service puppetmaster start
client> service puppet start

server> puppet cert --list
server> puppet cert sign --all
server> puppet cert list --all

config: /etc/puppet/
logs: /var/log/messages /var/log/daemon.log
vardir (where Puppet stores dynamic and growing data) default: /var/lib/puppet/

server> facter
server> egrep "fqdn:|memorytotal:|lsbdistdescription:" /var/lib/puppet/yaml/node/*
server> ls -1 /var/lib/puppet/ssl/ca/signed/ | sed -e 's/.pem//' # list nodes with signed certificates from facter info

client> puppet agent --test # force-run the agent once (optional --server=`hostname`)


further config

using the special "site" manifest

[root@sapocvm1 manifests]# cat /etc/puppet/manifests/site.pp
file {'puppetisalive':
	path    => '/tmp/puppetlives',
	ensure  => present,
	mode => 444,
	content => "I'm a test file.",

[root@sapocvm2 ~]# puppet agent --test
info: Caching catalog for
info: Applying configuration version '1398242680'
notice: /Stage[main]//File[puppetlives]/ensure: created
notice: Finished catalog run in 0.08 seconds
[root@sapocvm2 ~]# ls -ld /tmp/puppetlives
-rw-r--r--. 1 root root 16 Apr 23 10:44 /tmp/puppetlives

[root@sapocvm2 log]# tail -f messages
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Caching catalog for
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Applying configuration version '1398242680'
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: (/Stage[main]//File[puppetlives]/ensure) created
Apr 23 10:44:39 sapocvm2 puppet-agent[23803]: Finished catalog run in 0.08 seconds

# on the server:
# changed the "description" puppetlives -> puppetisalive
# added mode => 444

[root@sapocvm2 ~]# puppet agent --test
info: Caching catalog for
info: Applying configuration version '1398242943'
notice: /Stage[main]//File[puppetisalive]/mode: mode changed '0644' to '0444'
notice: Finished catalog run in 0.05 seconds
[root@sapocvm2 ~]# ls -ld /tmp/puppetlives
-r--r--r--. 1 root root 16 Apr 23 10:44 /tmp/puppetlives

Random commands

$ puppet resource user <username>
$ puppet describe --list # describe info for resources
$ puppet apply /root/examples/test.pp 
$ puppet agent --test --debug --noop # --debug shows details and --noop simulates changes

Tree of /etc/puppet Files

 |           |-site.pp

my_module/ — This outermost directory’s name matches the name of the module.
    manifests/ — Contains all of the manifests in the module.
        init.pp — Contains one class named my_module. This class’s name must match the module’s name.
        other_class.pp — Contains one class named my_module::other_class.
        my_defined_type.pp — Contains one defined type named my_module::my_defined_type.
        implementation/ — This directory’s name affects the class names beneath it.
            foo.pp — Contains a class named my_module::implementation::foo.
            bar.pp — Contains a class named my_module::implementation::bar.
    files/ — Contains static files, which managed nodes can download.
        service.conf — This file’s URL would be puppet:///modules/my_module/service.conf.
    lib/ — Contains plugins, like custom facts and custom resource types.
    templates/ — Contains templates, which the module’s manifests can use.
        component.erb — A manifest can render this template with template('my_module/component.erb').
    tests/ — Contains examples showing how to declare the module’s classes and defined types.
        other_class.pp — Each class or type should have an example in the tests directory.
    spec/ — Contains spec tests for any plugins in the lib directory.



  • parameterise your class variables
  • share and use existing modules from repositories
  • small reusable modules
  • private modules should be wrappers containing the private data

Management of multiple environments

figure out howto multi-master (n-serv 1-client) / federated (n-teams 1-client) / multi-tenant (1-serv n-cust)


  • Team A - Linux O/S Config A
  • Team B - windows O/S Config B
  • Team C - Linux O/S Configs C & D

You probably have several difference choices that might have different drawbacks or benefits depending on exactly how you're managing things. One option that comes to mind is to use something like 'environments' to define a different site.pp file for each tenant. Each tenant could "claim" the machines under their control by setting a property on the console or in the agent's puppet.conf like so:

tenant = "teamA"

In your master's puppet.conf, something like this:

manifest = "/usr/local/etc/puppet/tenant/${tenant}/manifests/site.pp 

And so Team A's site.pp would be at:

You could arrange the directory/manifest structure there any way you want.  This would be equally as valid:
manifest = "/usr/local/etc/puppet/manifests/${tenant}-site.pp 

If you worry that 1 team will add node classification of another one, then the only way is via enviroments, each enviroment will have it's own site.pp.


complementary tools


admin · attr · attach · edit · history · print
Page last modified on May 11, 2014, at 02:04 AM