Puppet: ein NTP-Modul mit zwei Neuerungen

Nach und nach alle Dienste mit puppet abzudecken und dabei in der Komplexitaet immer weiter steigern. Das mache ich gerade. Heute ein Modul mit zwei Neuerungen:

  1. Sicherstellen, dass der Service auch laeuft
  2. Im Template ein Array durchlaufen

Man kann mit puppet sehr einfach sicherstellen, dass Dienste auch laufen. Dafuer reichen die drei Zeilen:

  service { 'ntp':
    ensure => running,
  }

Weiter gibt es Sinn mehrere NTP Server in der ntp.conf zu definieren. Aus diesem Grund konnte ich nicht mit der gleichen Syntax arbeiten wie bei dem apt Modul. Der entscheidende neue Abschnitt im Template ist:

<% @servers.each do |server| -%>
server <%= server %>
<% end -%>

Siehe dazu auch die Sektion Iteration in der Using Puppet Templates Dokumentation. Komplett sieht das ganze so aus:

  • Ordnerstruktur:
    ├── manifests
    │   └── init.pp
    └── templates
        └── ntp.conf.erb
  • init.pp:
    # make sure ntp package is installed and service
    # is running
     
    class ntp ( $servers = [
      '0.debian.pool.ntp.org',
      '1.debian.pool.ntp.org',
      '2.debian.pool.ntp.org',
      '3.debian.pool.ntp.org',
      ] ) {
     
      package { 'ntp':
        ensure => installed
      }
     
      service { 'ntp':
        ensure => running,
      }
     
      file { '/etc/ntp.conf':
        ensure  => 'present',
        owner   => 'root',
        group   => 'root',
        mode    => '0644',
        content => template('ntp/ntp.conf.erb'),
        }
    }
  • ntp.conf.erb:
    #############################################################################
    #                                                                           #
    # !!! This file is managed by puppet, all manual changes will be lost !!!   #
    #                                                                           #
    #############################################################################
     
     
    # Keep ntpd from panicking in the event of a large clock skew
    # when a VM guest is suspended and resumed.
    tinker panic 0
     
    # Local users may interrogate the ntp server more closely.
    restrict 127.0.0.1
    restrict ::1
     
    # You do need to talk to an NTP server or two (or three).
    <% @servers.each do |server| -%>
    server <%= server %>
    <% end -%>
     
    # Undisciplined Local Clock. This is a fake driver intended for backup
    # and when no outside source of synchronized time is available. 
    server  127.127.1.0
    fudge   127.127.1.0 stratum 10
    restrict 127.127.1.0
     
    # By default, exchange time with everybody, but don't allow configuration.
    restrict -4 default kod notrap nomodify nopeer noquery
    restrict -6 default kod notrap nomodify nopeer noquery
     
    # Driftfile.
    driftfile /var/lib/ntp/drift
  • Definition des nodes:
    node 'node1.example.org' inherits default {
      class { 'ntp':
        servers => [ 'ntp1.example.org', 'ntp2.example.org', 'ntp3.example.org' ],
      }
    }

HowTo: move running process to screen

Schonmal das Problem gehabt, dass man einen Prozess startet und sich danach denkt: Mist, haette ich den mal im screen ausgefuehrt? Passiert klassisch am Freitag Nachmittag wenn man SIGWOCHENENDE empfangen moechte. Fuer genau das Problem habe ich aber gerade eine Loesung gefunden: reptyr

Das Programm kann bei Debian oder Ubuntu einfach aus den Repositories installiert werden:

apt-get install reptyr

Anschliessend funktioniert das folgende Szenario:

  • Ein Terminal Fenster starten (T1) und folgenden Befehl eingeben:
    T1 - root@foo:~# tail -f /var/log/syslog
  • Ein zweites Terminal Fenster starten (T2) und als root einen screen starten:
    T2 - root@foo:~# screen
  • Im screen die PID fuer den Prozess raussuchen und anschliessend mit repryr holen:
    T2 - root@foo:~# pidof tail
    28802
    root@foo:~# reptyr 28802
  • Im T1 sieht man nun etwas wie folgt
    T1 - [1]+  Angehalten              tail -f /var/log/syslog
  • Im T1 nun mit dem folgenden Befehl sicher gehen dass alles sauber ist:
    T1 - root@foo:~# bg; disown
  • Im T1 nun etwas in die Logdatei schreiben und im screen anschauen, wie es geloggt wird:
    T1 - root@foo:~# logger foo

Man finde ich das praktisch! :-)