puppet master --compile nodename |
hiera -c /etc/puppet/hiera.yaml apt::sources ::fqdn="puppetnode.example.net" |
Weitere Variablen kann man einfach so wie den fqdn auch übergeben:
hiera -c /etc/puppet/hiera.yaml apt::sources ::fqdn="puppetnode.example.net" ::provider="foobar" |
Hiera ist eine key-/value Datenbank von Konfigurationsdaten fuer Puppet. Als ersten Schritt moechte ich aufzeigen wie man es installiert, minimal einrichtet und testweise in ein Modul einbindet.
Zuerst muss auf dem Puppetmaster Server (ich arbeite unter Debian Wheezy) das folgende Paket inklusive seiner Abhaengigkeiten installiert werden:
aptitude install ruby-hiera-puppet |
Nach der Installation muss eine Konfigurationsdatei fuer Hiera unter Puppet erzeugt werden. Die Datei ist per Definition die /etc/puppet/hiera..yaml. Sie hat folgenden Inhalt:
--- :backends: - yaml :hierarchy: - common :yaml: :datadir: '/etc/puppet/hieradata' |
Erklaerung der hier gemachten Einstellungen:
Sicherstellen das das gerade angesprochene Verzeichnis existiert:
mkdir -p /etc/puppet/hieradata |
Anschliessend die folgende Datei common.yaml in dem Verzeichnis anlegen:
--- testmessage: hallo welt |
Testen ob alles funktioniert kann man das ganze danach mit dem folgenden Aufruf:
hiera -c /etc/puppet/hiera.yaml testmessage |
Zum Schluss noch ein Beispiel wie man den Wert nun in Puppet in einer Klasse ausliesst und in einer Datei speichert:
class hieratest {
$testmessage = hiera("testmessage")
file { '/tmp/hieratest.txt':
content => inline_template("<%= testmessage %>n"),
}
} |
Wenn man daraus zum Beispiel ein Modul ‚hieratest‘ macht, auf einem Node einbindet und Puppet laufen laesst, dann findet man dort die Datei /tmp/hieratest.txt mit dem definierten Inhalt ‚hallo welt‘.
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.
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:
Durch die Arbeit inspiriert, habe ich nun auch fuer mich Privat einen puppet Server zur Verwaltung meiner virtuellen Maschinen aufgesetzt.
Puppet ist ein Tool zum Konfigurationsmanagement von Computern mit Betriebssystemen wie Unix, Linux und FreeBSD. Ein IT-Administrator kann damit an zentraler Stelle die Konfiguration von Rechnern in seinem Netzwerk verwalten. Puppet eignet sich sowohl für einzelne Rechner als auch für große Rechnerverbünde |
Als erstes wurde die generelle Infrastruktur aufsetzen. Das bedeutet fuer mich:
Alles hier beschriebene passiert auf der Basis von Debian wheezy. Auf dem Server der als puppet master dienen soll habe ich zuerst das entsprechende Paket mit seinen Abhaengigkeiten installiert:
sudo aptitude install puppetmaster |
Anschliessend habe ich in der /etc/default/puppetmaster den Parameter START=yes gesetzt. Wichtig ist nun noch sicherzustellen, dass der Port 8140 von den Clients aus erreichbar ist.
Danach habe ich auf den Clients den puppet agent installiert:
sudo aptitude install puppet |
Auch hier habe ich in der /etc/default/puppet wieder den Parameter START=yes gesetzt. Weiter habe ich in den DAEMON_OPTS den Parameter zu dem Server angegeben. Beispiel:
--server puppetmaster.example.org |
Dann habe ich probiert mich mit dem puppet agent an den puppet master Server zu verbinden:
puppet agent --server puppetmaster.example.org --test |
Auf dem puppet master konnte ich danach das unsignierte Zertifikat des Clients mit dem folgenden Befehl sehen:
puppet cert list |
Danach musste es mit dem folgenden Befehl signiert werden, wobei puppetclient.example.org der FQHN des puppet clients ist:
puppet cert sign puppetclient.example.org |
Alle signierten Zertifikate kann man sich uebrigens mit dem folgenden Befehl anzeigen lassen:
puppet cert list --all |
Danach konnte ich den puppet agent auf dem Client erneut laufen lassen und die Verbindung war erfolgreich. Zum Ende das neu starten des puppet agents auf den Clients nicht vergessen, damit der Prozess mit den neuen DAEMON_OPTS laeuft.
Notizen:
root@host:~# puppet agent --test --server puppetmaster.example.org err: Could not retrieve catalog from remote server: Connection refused - connect(2) warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run err: Could not send report: Connection refused - connect(2) root@host:~#
root@host:~# puppet agent --test --server 192.168.1.100 err: Could not retrieve catalog from remote server: Server hostname '192.168.1.100' did not match server certificate; expected one of puppetmaster.example.org, DNS:puppet, DNS:puppet.example.org, DNS:puppetmaster.example.org warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run err: Could not send report: Server hostname '192.168.1.100' did not match server certificate; expected one of puppetmaster.example.org, DNS:puppet, DNS:puppet.example.org, DNS:puppetmaster.example.org root@host:~#