Just moozing

Before you can check your notes, you must make them…

A Puppet primer

with 3 comments

This blog post is a quick introduction and survival guide for basic puppet usage.

Client and server relation

PuppetMasterDiagramThe basic idea of puppet is to have a centralized server, called puppetmaster, and serve configurations to client machines, both windows, Linux and maybe other OS’es.

There are some nice advantages to this approach

  • Centralized configuration allows for sharing passwords, domain names and other things between client machines.
  • Version controlling using git is much simpler. It is as simple as version controlling the /etc/puppet/manifests folder

This is really powerful with something like vagrant, but that is off topic. You could start with a google search.

The client identifies itself using its host name. In order to have security, the first access to the server will trigger a signing request, which must be signed on the server before any configuration is sent.

Basic commands to look at (server side)

puppet cert list
puppet cert sign <client.somesite.com>

 

Configuration on the server

Puppet works with modules and manifests. Modules are what you expect – some configuration, customized or from puppetforge, that ensures some configuration on the client based on some parameters. Do note that modules are simple to work with, so whenever you want to make a configuration grouping, just create a module and version control it.

Some basic module commands


puppet module list
puppet module generate <someone-somemodule>
puppet module install <some_module_from_puppetforge>

The configuration for the different client are located in manifests. I use a tree like the following


# tree manifests/
manifests/
├── nodes
│   ├── filetest.pp
│   ├── ldap.pp
│   └── puppetmaster.pp
└── site.pp

With

  • site.pp: site specific variable definitions
  • nodes/puppetmaster.pp: configuration for the puppetmaster itself
  • nodes/ldap.pp and other nodes/*.pp: configuration for (an example) ldap server, test stuff and any other servers or desktops that I configure using puppet

An extract from filetest.pp

node /^filetest\d+$/ {
  site_base_server { 'base server stuff': }

# yes, we install swat on test servers
package {'swat': ensure => 'installed' }

class { 'samba':
  workgroup     => 'WORKGROUP',
  netbios_name  =>  $hostname,
  server_string => 'Awesome Test FileServer',
  motd => false,
  firewall => false,
}

file { "/srv/samba":
  ensure => "directory",
}

samba::share { 'homes':
  options => {
    'comment'        => 'Home Directories' ,
    'browseable'     => 'no' ,
    'read only'      => 'no',
    'create mask'    => '0700',
    'directory mask' => '0700',
    'valid users'    => '%S',
  },
}

...

Highlight from the example

  • Line 1: “node /^filetest\d+$/”: The definition is for all clients identifying themselves as filetest01, fileserver05, and so on. They will all get the same configuration. Note the use of “$hostname” in line 9
  • Line 2: “site_base_server { ‘base server stuff’: }”: In site.pp, I have a definition of site_base_server, which is based on a module called base_server. It enables me to easily have a base line server configuration with default setting for proxies, firewalls, users, puppet itself and so on.

 

Client side

When installing a new server, the key used is the host name.

 

Minimal command


puppet agent --test --noop

puppet agent --test --server puppetmastertest.somesite.com

The “–noop” flag is no-operation, and will just show what would be done, should you decide on applying it. The “–server” flag is useful is the puppetmaster server is something else than “puppetmaster.

These flags can also be set in the /etc/puppet/puppet.conf configuration file.

 

Final words

Puppet is a good tool to handle configuration across multiple machines. One of my favorite spin-off is the amount of build-in knowledge in such a system. It also allows for incremental improvement of functionality and security across a domain. There are also ways of doing TDD with puppet.

 

Advertisements

Written by moozing

May 5, 2014 at 15:00

Posted in Tech

Tagged with , ,

3 Responses

Subscribe to comments with RSS.

  1. […] have mentioned vagrant before. A show stopper for me has been issues with getting it to work with libvirt. Now there is a […]

  2. […] Ansible for provisioning resembles using puppet, as I have described before. Ansible uses playbooks, and using tasks, variables, roles and so on, the system gets rolled out […]

  3. […] is a provisioning tool like puppet (I wrote a puppet primer some time ago). They are similar, and like other provisioning tools, they are designed to roll out […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: