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: Reports per Mail mit tagmail

Puppet bietet die Moeglichkeit bei Aenderungen Reports per Email zu versenden. Dafuer gibt es den Tagmail Report Processor. Folgendes muss man tun um ihn zu verwenden:

Zuerst muss tagmail fuer die Reports aktiviert werden. Dafuer tagmail in der /etc/puppet/puppet.conf in den reports unter master hinzufuegen. Falls die Zeile bereits vorhanden ist den Wert ergaenzen. Der Standardwert ist uebrigens store. Beispiel:

[master]
reports = store, tagmail

Danach kann man die Reports in der Datei /etc/puppet/tagmail.conf konfigurieren. Die Datei ist immer gleich aufgebaut. Werte: Emailadressen. Die Werte und Emailadressen koennen einzelne oder kommaseparierte Eintraege sein. Pro Zeile eine neue Definition. Folgende Werte sind moeglich:

  • all
  • Klassennamen
  • Loglevel
  • Tags

Beispiele:

  1. Alle Reports sollen an die Emailadresse puppetreports@example.org gesendet werden:
     all: puppetreports@example.org
  2. Reports der Klassen sudoers und fail2ban soll an admins@example.org geschickt werden
    sudoers, fail2ban: admins@example.org
  3. Events mit dem Logleven emerg und crit sollen an John Doe und operators@example.org verschickt werden:
    emerg, crit: john.doe@example.org, operators@examplr.org

Es kann auch mit NOT gearbeitet werden, weitere Informationen dazu gibt es in der Dokumentation unter Docs: Config Files: tagmail.conf.

Ausserdem koennen Tags als Grundlage fuer Reports dienen. Tags werden zum Beispiel in Klassen definiert. Die Syntax dafuer ist anders als das was bisher hier auf dem Blog zu lesen war:

tag 'foo', 'bar'

Es koennen ein oder mehrere Tags vergeben werden, wichtig ist, dass sie nicht => zugewiesen werden und auch am Ende kein Komma steht. Weitere Informationen ueber Tags gibt es in der Puppet Dokumentation unter Docs: Language: Tags

Diese Tags kann man danach ebenfalls als Wert in der /etc/puppet/tagmail.conf definieren:

foo: foo@example.org

Gibt es keine Aenderungen werden keine Mails verschickt:

May 11 11:04:38 host puppet-master[18075]: Compiled catalog for node01.example.org in environment production in 0.05 seconds
May 11 11:04:40 host puppet-master[18075]: Not sending tagmail report; no changes

Gibt es Aenderungen einfach den Posteingang pruefen.