modul – Seite 2 – pregos blog

Puppet: Ein Modul mit mehreren Klassen

5. Mai 20145. Mai 2014 prego 2 Kommentare

Bisher hab ich immer nur pro Modul eine Klasse definiert. Es existiert an dieser Stelle aber keine Beschraenkung. In der init.pp wird eine Klasse definiert die den Modulnamen tragen muss. Daneben koennen aber weitere .pp Dateien liegen die ebenfalls Klassen implementieren.

Ich persoenlich habe auf verschiedenen Servern verschiedene Dateien unter /etc/cron.d/ abgelegt die ich auch in puppet ueberfuehrt habe. Da ich nicht alle Cronjobs auf allen Nodes deployen (und auch ausfuehren) moechte, gleichzeitig aber nicht fuer jedes Datei ein eigenes Modul definieren will, habe ich ein Modul „cronjobs“ erzeugt mit verschiedenen Klassen. Hier eine beispielhafte Struktur:

├── files
│   └── etc
│       └── cron.d
│           └── foo
└── manifests
    ├── foo.pp
    └── init.pp

Die init.pp hat fast keinen Inhalt:

# class that contains several cronjobs on different hosts
 
class cronjobs () {
 
}

Die Datei foo.pp sieht wie folgt aus:

# place cron.d file for foo job
 
class cronjobs::foo {
 
  file { '/etc/cron.d/foo':
    ensure => 'file',
    owner  => 'root',
    group  => 'root',
    mode   => '0644',
    source => 'puppet:///modules/cronjobs/etc/cron.d/foo'
  }
}

Wichtig ist hier, dass die Klasse MODULNAME::KLASSE heisst. Genauso wird diese Klasse dann auch in einem Node definiert:

node 'client1.example.org' inherits default {
 
  class { 'cronjobs::foo': }
}

Haette man in dem gleichen Modul noch eine Klasse cronjobs::bar koennte man diese in einem anderen Node definieren. So kann ich in einem Modul verschiedene Cronjob Dateien haben die auf unterschiedlichen Hosts deployt werden.

Puppet: ein NTP-Modul mit zwei Neuerungen

3. Mai 20143. Mai 2014 prego Schreib einen Kommentar

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:

Sicherstellen, dass der Service auch laeuft
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
├── 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' ], } }
node 'node1.example.org' inherits default { class { 'ntp': servers => [ 'ntp1.example.org', 'ntp2.example.org', 'ntp3.example.org' ], } }

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

30. April 20142. Mai 2014 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: Das erste eigene Modul mit einer MOTD

27. April 201427. April 2014 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:

Auf allen Systemen muss /etc/motd ein Symlink nach /var/run/motd sein
Auf allen Systemen muss das Verzeichnis /etc/update-motd.d/ existieren
Auf allen Systemen muessen die Skripte von Nick Charlton im /etc/update-motd.d/ Verzeichnis existieren
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: