Puppet: Konfigurationsdateien manipulieren mit Augeas

Ich stand vor der Frage, wie ich auf allen puppet Nodes die /etc/puppet/puppet.conf editiere. Dabei sollten zwei Eintraege sichergestellt sein:

  1. In der [main] Sektion soll pluginsync=true stehen
  2. In der [agent] Sektion soll report=true stehen

Kurz habe ich ueberlegt ob ich die Datei selbst ueber puppet verteilen soll. Dann wurde ich aber auf Augeas gestossen. Augeas ist ein Tool, das ueber sogenannte Linsen (lenses) verschiedene Konfigurationsdateien in einer baum-Struktur darstellen und bearbeiten kann. Puppet hat Augeas ueber die Ruby Language Bindings bereits integriert. Es ist also problemlos moeglich damit die puppet.conf zu editieren. Hier meine Loesung aus der Klasse:

  augeas { 'puppet.conf':
    context => '/files/etc/puppet/puppet.conf',
    changes => [
      'set main/pluginsync true',
      'set agent/report true',
    ],
    notify  => Service['puppet'],
  }
 
  service { 'puppet':
    ensure  => 'running',
  }

und so sieht es aus wenn es denn durchlaeuft:

notice: Augeas[puppet.conf](provider=augeas): 
--- /etc/puppet/puppet.conf	2014-05-23 20:30:48.000000000 +0200
+++ /etc/puppet/puppet.conf.augnew	2014-05-23 20:30:54.000000000 +0200
@@ -8,9 +8,12 @@
 prerun_command=/etc/puppet/etckeeper-commit-pre
 postrun_command=/etc/puppet/etckeeper-commit-post
 
+pluginsync=true
 [master]
 # These are needed when the puppetmaster is run by passenger
 # and can safely be removed if webrick is used.
 ssl_client_header = SSL_CLIENT_S_DN 
 ssl_client_verify_header = SSL_CLIENT_VERIFY
 
+[agent]
+report=true
 
notice: /Stage[main]/Basics/Augeas[puppet.conf]/returns: executed successfully
info: /Stage[main]/Basics/Augeas[puppet.conf]: Scheduling refresh of Service[puppet]
notice: /Stage[main]/Basics/Service[puppet]: Triggered 'refresh' from 1 events

Weitere Moeglichkeiten wie immer in der entsprechenden Puppet Type Reference.

Puppet: Style pruefen mit puppet-lint als pre-commit hook

Ich hatte bereits puppet-lint in einem eigenen Blogeintrag vorgestellt. Noch schoener als das manuelle Aufrufen ist natuerlich das ganze als pre-commit Hook zu haben und gar nichts ins Repository rein zu lassen, was nicht den eigenen Regeln entspricht.

Folgendes ist mein pre-commit Hook:

#!/bin/bash
 
echo "Checking syntax with puppet-lint"
 
for i in $(git diff --name-only --cached | grep -E '.(pp)'); do
        if [ -f "${i}" ]; then
                # --no-80chars-check because of sshkey.pub and
                # https://github.com/rodjek/puppet-lint/issues/70
 
                puppet-lint --no-80chars-check --no-single_quote_string_with_variables-check --with-filename ${i}
 
                if [ $? -ne 0 ]; then
                        echo "ERROR: Bad syntax, see errors above. Aborting!"
                        exit 1
                else
                        echo "Nice work in: ${i} :-)"
                fi
        fi
done

Puppet: Virtuelle Ressourcen fuer Gruppen und ein Beispiel aus der Praxis

Ich habe gerade ueber virtuelle Ressourcen fuer Benutzer und public SSH-Keys geschrieben. Nach dem gleichen Schema kann man natuerlich auch virtuelle Ressourcen fuer Gruppen erzeugen. Wofuer man das ganze in der Praxis brauchen kann moechte ich an dem folgenden Beispiel erklaeren.

Das ganze basiert auf dem Beispielmodul users aus dem Beitrag Puppet: Virtuelle Ressourcen fuer Benutzer und SSH-Keys. Dort habe ich naemlich fuer den Benutzer mmuster die Gruppe wheel konfiguriert.

Mit Puppet kann ich nun in einem eigenen Modul sehr simpel sicherstellen, dass diese Gruppe auch existiert. Mein Modul groups sieht wie folgt aus:

└── manifests
    ├── init.pp
    ├── virtual.pp
    └── wheel.pp

Und auch der Aufbau der drei Dateien sind genau wie die in dem users Modul, nur viel einfacher:

  • init.pp
    class groups () {
      include groups::virtual
    }
  • virtual.pp
    class groups::virtual {
      @group { 'wheel':
        ensure => 'present',
        }
    }
  • wheel.pp
    class groups::wheel inherits groups::virtual {
      realize(
        Group['wheel']
      )
    }

Um sicherzustellen, dass die Gruppe wheel auch wirklich existiert, erweitere ich nun die Klasse mmuster.pp aus dem Beispiel des anderen Beitrags um einen include fuer die Gruppe wheel. Das ganze sieht dann wie folgt aus:

class users::mmuster inherits users::virtual {
 
  include groups::wheel
 
  realize(
    User['mmuster'],
    Ssh_authorized_key['mmuster-privat']
  )
}

Ich mache das ganze natuerlich nicht einfach nur um den Benutzer in irgendeine Gruppe zu packen, sondern die Gruppe soll auch spezielle Berechtigungen erhalten: root Rechte erlangen ohne Passworteingabe. Dieses realisiere ich ueber sudo. Dafuer habe ich ebenfalls ein eigenes Modul „sudoers“ und darin wiederum die Klasse „wheel“. Diese sieht wie folgt aus:

class sudoers::wheel {
 
  include groups::wheel
 
  file { '/etc/sudoers.d/60_wheel':
    ensure => 'present',
    source => 'puppet:///modules/sudoers/etc/sudoers.d/60_wheel',
    owner  => 'root',
    group  => 'root',
    mode   => '0440'
  }
}

Der zweite Ort an dem die Gruppe wheel konfiguriert ist. Spaetestens jetzt wuerde es zu Problemen kommen, wenn die Klasse wheel aus dem sudoers Modul UND der Nutzer mmuster zusammen auf einem Node konfiguriert sind. Mit den virtuellen Ressourcen hingegen klappt es.

Ach so, die /etc/sudoers.d/60_wheel sieht uebrigens so aus:

#############################################################################
#                                                                           #
# !!! This file is managed by puppet, all manual changes will be lost !!!   #
#                                                                           #
#############################################################################
 
#
# Members of the wheel group may gain root privileges without password
#
 
%wheel          ALL = (ALL) NOPASSWD: ALL

Puppet: Virtuelle Ressourcen fuer Benutzer und SSH-Keys

Puppet kann Ressourcen nur einfach definieren. Hat man eine Klasse einmal eingebunden, kann man dieses an einer zweiten Stelle nicht erneut tun. Folgendes Beispiel:

Ich deploye eine selbst entwickelte Software und moechte sie unter einem bestimmten Nutzeraccount laufen lassen. Mit Puppet stelle ich sicher, dass der Nutzeraccount existiert. Spaeter moechte ich auf dem gleichen Server eine zweite Software deployen die ebenfalls unter diesem Benutzeraccount laeuft. Ich erzeuge dafuer ein weiteres Modul das die Abhaengigkeiten abbildet. Laesst sich wunderbar alles konfigurieren, aber spaetestens auf dem Server gibt es dann einen Fehler:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Class[FOO] is already declared; cannot redeclare at /etc/puppet/manifests/site.pp:20 on node node01.example.org

Die Loesung fuer das Problem sind virtuelle Ressourcen. Im folgenden Beispiel moechte ich aufzeigen, wie man Benutzeraccounts als virtuelle Ressourcen definiert und auf den Nodes einbindet. Die Loesung die ich hier aufzeige habe ich mir nicht selbst ausgedacht, sondern bei meinem Kollegen abgeguckt.

Eigentlich kommt man bei mehreren Benutzeraccounts auf mehreren Servern nicht um einen LDAP Server herum. Bei kleineren Setups kann man es aber auch noch auf die klassische Art- und Weise mit lokalen Konten machen.

Viele Anleitungen die man im Internet liesst zeigen Wege, bei denen man die Benutzerinformationen als Parameter an die Klasse uebergibt. Ich habe mich bewusst dagegen entschieden und alle Infos in dem Modul. Spaeter werde ich mich wohl noch mal mit Hiera beschaeftigen, dann werde ich die Informationen dort ablegen.

Die Verzeichnisstruktur meines Moduls „users“ sieht wie folgt aus:

└── manifests
    ├── init.pp
    ├── mmuster.pp
    └── virtual.pp

Die init.pp ist sehr simpel:

class users () {
  include users::virtual
}

Spannender wird es dann, wenn man die virtual.pp anschaut:

class users::virtual {
 
  @user { 'mmuster':
    ensure      => 'present',
    comment     => 'Max Mustermann,,,',
    shell       => '/bin/bash',
    managehome  => true,
    groups      => ['sudo', 'wheel' ],
    }
 
  @ssh_authorized_key { 'mmuster-privat':
    ensure      => 'present',
    type        => 'ssh-rsa',
    user        => 'mmuster',
    key         => 'AAA [...] ZZZ='
  }
}

Virtuelle Ressourcen definiert man mit einem vorgestellten @. In dem Beispiel werden zwei virtuelle Ressourcen definiert:

  1. Den Nutzeraccount mmuster
  2. Den oeffentlichen SSH-Key mmuster-privat

Die Parameter fuer den Nutzeraccount mmuster bedeuten folgendes:

  • ensure => ‚present‘: Stellt sicher, dass der Benutzeraccount existiert. Wenn nicht wird er angelegt.
  • comment => ‚Max Mustermann,,,‘: Kommentar zum Benutzeraccountt in der /etc/passwd
  • shell => ‚/bin/bash‘: Die Shell die der Benutzeraccount haben soll.
  • managehome => true: Stellt sicher das das Homeverzeichnis existiert.
  • groups => [’sudo‘, ‚wheel‘ ]: Stellt sicher, dass der Benutzeraccount Mitglied in den Gruppen sudo und wheel ist. Die Gruppen muessen im System existieren. Sie werden nicht automatisch angelegt!

Die Einstellungen fuer den SSH-Key mmuster-privat bedeuten folgendes:

  • ensure => ‚present‘: Stellt sicher, dass der SSH-Key existiert
  • type => ’ssh-rsa‘: Definiert den Verschluesselungsalgorithmus
  • user => ‚mmuster‘: Der Benutzeraccount zu dem dieser oeffentliche SSH Schlussel gehoert
  • key => ‚AAA […] ZZZ=‘:Der eigentliche public key

Fertig ist die Definition der virtuellen Ressourcen. Damit diese spaeter auch auf dem Node ausgefuehrt werden, muessen sie mit der realize Funktion markiert werden. Das passiert in der dritten Datei: mmuster.pp

class users::mmuster inherits users::virtual {
 
  realize(
    User['mmuster'],
    Ssh_authorized_key['mmuster-privat']
  )
}

Das schoene an dieser Loesung ist, dass der Nutzer nun mit einer einzigen Zeile zu dem Node hinzugefuegt werden kann:

include users::mmuster

Zum Schluss: Das Passwort wird nicht gesetzt. Man kann den Hash bei dem Nutzer mit dem Parameter password => “ mitgeben. Das finde ich aber nicht gut, weil die Nutzer dann die Passwoerter nicht selbst aendern koennen. Man findet im Netz auch Infos zu Kruecken mit denen man das Passwort nur beim Nutzer anlegen setzen kann, sollte man an diesem Punkt angelangt sein ist definitiv wieder der Zeitpunkt erreicht sich erneut Gedanken ueber einen LDAP Server zur Benutzerverwaltung zu machen 8-)