Kategorie: Computer

Puppet: ein Modul mit Template, Variablen und Bedingung (/etc/apt/sources.list)

prego 2 Kommentare

Vor kurzem erst hatte ich darueber geschrieben, wie man in puppet ein eigenes Modul definiert.
Heute moechte ich zeigen, wie in einem Modul mit Templates, Variablen und if-Bedingung gearbeitet werden kann. Ich habe mir dafuer die Datei /etc/apt/sources.list ausgesucht in die ich – je nach Host – unterschiedliche Mirror eintragen moechte. Dafuer habe ich das Verzeichnis /etc/puppet/modules/apt/ mit der folgenden Ordnerstruktur angelegt:

├── manifests
│   └── init.pp
└── templates
    └── sources.list.erb

Mein Template fuer die sources.list sieht wie folgt aus:

#############################################################################
#                                                                           #
# !!! This file is managed by puppet, all manual changes will be lost !!!   #
#                                                                           #
#############################################################################
 
 
 
deb     <%= mirror %>  <%= release %>  main
<% if source -%>
deb-src <%= mirror %>  <%= release %>  main
<% end -%>
 
deb     http://security.debian.org/  <%= release %>/updates  main
<% if source  -%>
deb-src http://security.debian.org/  <%= release %>/updates  main
<% end -%>

In dem Template kann man zwei Variablen erkennen. Diese sollen bei Bedarf ueberschrieben werden koennen <%= mirror -%> und <%= release %>. Ausserdem gibt es eine Bedingung, wenn die Variable source Wahr ist, wird auch die deb-src Zeile eingefuegt.

Die apt/manifests/init.pp fuer das Modul sieht wie folgt aus:

class apt (
  $mirror = 'http://ftp.de.debian.org',
  $release = 'wheezy',
  $source = false ) {
 
  file { '/etc/apt/sources.list':
    ensure  => 'present',
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => template('apt/sources.list.erb'),
    }
}

Neu ist, dass in der Klassendefinition die Variablen mit entsprechenden Standardwerten definiert wurden. Das Bild wird komplett, wenn nun ein neuer Node in der sites.pp definiert wird:

node default {
  class { 'motd': }
}
 
node 'client02.example.org' inherits default {
  class { 'apt':
    mirror => 'http://debianmirror.example.org/pub/linux/debian/debian/',
    source => true
  }
}

Hier ist neu, dass der Node „client02.example.org“ explizit angegeben wurde. Er erbt die Einstellungen des default Node. Erweiternd ist die Klasse apt definiert, bei der die Variablen mirror und source einen anderen Wert annehmen als der Standartwert.

Ich bin mir dessen bewusst, dass es ein apt Modul auf puppetforge gibt, zum Lernen finde ich das hier gerade aber einfacher.

Informationen habe ich auch aus dem Blogeintrag „Puppet templates and default values for variables„.

Puppet: Ueberwachen von puppet agent und puppet master mit Nagios

prego Schreib einen Kommentar

puppet agent

Man kann mit Nagios gut pruefen ob der puppet agent sich regelmaessig mit dem puppet master abgeglichen hat. Das Plugin dafuer ist check_puppet_agent und ist auf NagiosExchange zu finden.

Eingebunden zum Beispiel per NSCA gibt es einem eine Warnung sobald etwas nicht mehr laeuft.

Bildschirmfoto vom 2014-04-26 14:15:13

puppet master

Auch kann man von extern pruefen ob der puppet master erreichbar ist. Das geht am besten ueber HTTP mit der REST API. Auf dem Nagios Server habe ich dafuer das folgende Kommando definiert:

define command{
command_name    check_puppetmaster
command_line    $USER1$/check_http -H $ARG1$ -S -p 8140 -u /production/status/puppetclient --header="Accept: yaml"
}

Den Check habe ich wie folgt eingerichtet:

define service{
use                             my-service
host_name                       server.example.org
service_description             puppet master
check_command                   check_puppetmaster!puppetmaster.example.org
}

Zu guter Letzt muss dem Nagios Server gestattet werden die Abfrage ueber die REST API auch durchzufuehren. Dafuer auf dem puppet master Server in der /etc/puppet/auth.conf die folgenden Zeilen hinzufuegen:

path /status/puppetclient
auth any
method find
allow 1.2.3.4

Und schon steht auch dem Monitoring des puppet masters nichts mehr im Wege:

Bildschirmfoto vom 2014-04-26 14:40:58

Puppet: Syntaxpruefung mit puppet-lint

prego Schreib einen Kommentar

Mit dem Tool puppet-lint kann man die Syntax seiner puppet manifest Dateien pruefen. Die Installation erfolgt aus den Repositories:

sudo aptitude install puppet-lint

Die Syntaxpruefung geht dann mit dem Aufruf:

puppet-lint --with-filename /etc/puppet/modules

Falls es Auffaelligkeiten gibt werden diese auf der Kommandozeile ausgegeben:

root@host:~# puppet-lint --with-filename /etc/puppet/modules/
foo/manifests/init.pp - WARNING: line has more than 80 characters on line 5
foo/manifests/init.pp - ERROR: tab character found on line 34
foo/manifests/init.pp - WARNING: => on line isn't properly aligned for resource on line 23
root@host:~#

Puppet: Das erste eigene Modul mit einer MOTD

prego Schreib einen Kommentar

Nachdem die puppet Infrastruktur steht moechte ich nun auf alle Server eine eigene, individuelle MOTD nach dem Ubuntu Vorbild verteilen. Damit alles funktioniert muessen verschiedene Bedingungen erfuellt sein:

  1. Auf allen Systemen muss /etc/motd ein Symlink nach /var/run/motd sein
  2. Auf allen Systemen muss das Verzeichnis /etc/update-motd.d/ existieren
  3. Auf allen Systemen muessen die Skripte von Nick Charlton im /etc/update-motd.d/ Verzeichnis existieren
  4. Auf allen Systemen muss das Paket ‚figlet‘ installiert sein.

Die perfekte Ausgangslage um ein eigenes Modul fuer puppet zu schreiben, dass automatisch alle Bedingungen sicherstellt. #

Ich habe unter /etc/puppet/modules/ die folgende Verzeichnisstruktur erzeugt:

└── motd
    ├── files
    │   └── etc
    │       └── update-motd.d
    │           ├── 00-header
    │           ├── 10-sysinfo
    │           └── 99-footer
    └── manifests
        └── init.pp

Die Skripte im Unterverzeichnis files habe ich von der Seite Debian/Ubuntu: Dynamic MOTD. Im Verzeichnis manifests ist eine init.pp abgelegt. Diese hat den folgenden Inhalt:

class motd {
 
  package { 'figlet':
    ensure => 'installed'
  }
 
 
 
  file { '/etc/motd':
    ensure => 'link',
    target => '/var/run/motd',
  }
 
 
 
  file { '/etc/update-motd.d/':
    ensure => 'directory',
    owner  => 'root',
    group  => 'root',
    mode   => '0755'
  }
 
 
 
  file { '/etc/update-motd.d/00-header':
    ensure => 'present',
    source => 'puppet:///modules/motd/etc/update-motd.d/00-header',
    owner  => 'root',
    group  => 'root',
    mode   => '0755'
  }
 
  file { '/etc/update-motd.d/10-sysinfo':
    ensure => 'present',
    source => 'puppet:///modules/motd/etc/update-motd.d/10-sysinfo',
    owner  => 'root',
    group  => 'root',
    mode   => '0755'
  }
 
  file { '/etc/update-motd.d/99-footer':
    ensure => 'present',
    source => 'puppet:///modules/motd/etc/update-motd.d/99-footer',
    owner  => 'root',
    group  => 'root',
    mode   => '0755'
  }
}

Ich denke sie ist relativ selbsterklaerend. Als erstes wird sichergestellt, dass das Paket figlet installiert ist. Danach wird der symbolische Link erzeugt falls er nicht existiert. Als drittes validiert, dass das Verzeichnis /etc/update-motd.d/ existiert und danach die Skripte an die richtige Stelle kopiert.

Damit dieses Modul auch an alle puppet nodes verteilt wird, habe ich einen default node definiert. Dieser greift immer dann, wenn ein node nicht explizit aufgelistet wurde. Dafuer wurde die Datei /etc/puppet/manifests/site.pp mit dem folgenden Inhalt angelegt:

node default {
  class { 'motd': }
}

Nach dem manuellen Aufruf des puppet agents auf dem node wird die Konfiguration uebernommen:

user@host:~# puppet agent --server puppetmaster.example.org --test
info: Caching catalog for host.example.org
info: Applying configuration version '1398539626'
info: FileBucket adding {md5}d41d8cd98f00b204e9800998ecf8427e
info: /Stage[main]/Motd/File[/etc/motd]: Filebucketed /etc/motd to puppet with sum d41d8cd98f00b204e9800998ecf8427e
notice: /Stage[main]/Motd/File[/etc/motd]/ensure: ensure changed 'file' to 'link'
notice: /Stage[main]/Motd/File[/etc/update-motd.d/]/ensure: created
notice: /Stage[main]/Motd/File[/etc/update-motd.d/10-sysinfo]/ensure: defined content as '{md5}684e660175b367c21bbf0bf5b4cb2475'
notice: /Stage[main]/Motd/File[/etc/update-motd.d/00-header]/ensure: defined content as '{md5}13ab41fc9d68d2e2b05c31185aecfab5'
notice: /Stage[main]/Motd/File[/etc/update-motd.d/99-footer]/ensure: defined content as '{md5}8609d989ae2538fbb15f9055c995d050'
notice: Finished catalog run in 1.16 seconds
user@host:~#

Anschliessend ist die MOTD zu sehen wenn ich mich mit dem Server verbinde:

Bildschirmfoto vom 2014-04-26 21:17:22