Schlagwort: puppetmaster

Puppet: SSL Zertifikate neu erzeugen für Master, Agent und PuppetDB

prego Schreib einen Kommentar

Wenn man „ausversehen“ mal auf dem Puppetmaster Server ein

puppet cert clean --all

ausgeführt hat und dann versucht das ganze Schlamassel wieder auszubaden sind folgende Informationen gut zu wissen:

  • Neue Zertifikate auf den Nodes erzeugt man, in dem man das Verzeichnis /var/lib/puppet/ssl einfach umbenennt und den Agent neu laufen lässt: 
    $ mv /var/lib/puppet/ssl /var/lib/puppet/ssl_old
$ puppet agent --test --server puppet.example.org
  • Wenn man auf dem Puppetmaster ebenfalls ein neues Zertifikat erzeugt und es dann Fehlermeldungen auf den Nodes gibt nach dem Motto „hostname was not match with the server certificate“ helfen folgende Schritte:
    1. Auf dem Puppetmaster Server den Certificate Hostname anzeigen: 
      $ puppet master --configprint certname
    2. Puppetmaster ausstellen und altes Zertifikat löschen: 
      $ service puppetmaster stop
$ find $(puppet master --configprint ssldir) -name "$(puppet master --configprint certname).pem" -delete
    3. Den Zertifikatsnamen und die Alternativen DNS-Namen in der /etc/puppet/puppet.conf eintragen mit den folgenden Optionen: 
      [master]
certname=puppet.example.org
certdnsname=puppet.example.org
dns_alt_names=puppetmaster.example.org
    4. Puppetmaster Server im Vordergrund starten und zusehen wie die neuen Zertifikate generiert werden, wenn die Meldung „notice: Starting Puppet master version…“ dort steht mit Strg+c beenden: 
      $ puppet master --no-daemonize --verbose
Strg+c
$ service puppetmaster start
  • Wenn es dann von PuppetDB eine Fehlermeldung gibt nach dem Motto „‚replace facts‘ to PuppetDB: certificate verify failed“ hilft folgendes: 
    $ service puppetdb stop
$ mv /etc/puppetdb/ssl /etc/puppetdb/ssl_old
$ /usr/sbin/puppetdb-ssl-setup -f
$ service puppetdb start

Infos von hier und da.

Puppet: Update Debian Wheezy auf puppetlabs Pakete

prego 2 Kommentare

Ich habe auf allen meinen Servern puppet auf die Version von puppetlabs aktualisiert. Dafür habe ich folgende Schritte durchgeführt:

  1. Herunterladen der puppetlabs-release-wheezy.deb von apt.puppetlabs.com und Installation auf dem Node: 
    cd /tmp
wget http://apt.puppetlabs.com/puppetlabs-release-wheezy.deb
dpkg -i puppetlabs-release-wheezy.deb
aptitude update && aptitude safe-upgrade
  2. Auf dem puppetmaster musste ich noch ein aptitude dist-upgrade durchfühhren
  3. Ich hatte das Paket libaugeas-ruby1.8 installiert was zu Problemen führte. Deswegen: 
    aptitude install libaugeas-ruby && aptitude purge libaugeas-ruby1.8
  4. Die Einstellung templatedir in der puppet.conf ist deprecated und führt zu entsprechenden Warnungen wenn der agent läuft. Mit dem folgenden Snippet in meinem basics Modul habe ich es entfernt: 
      augeas { 'puppet.conf':
    context => '/files/etc/puppet/puppet.conf',
    changes => [
      'rm main/templatedir',
    ],
    notify  => Service['puppet'],
  }
  5. Das Monitoring des Puppetmasters wie in dem verlinkten Blogeintrag beschrieben schlug mit einem HTTP 403 fehl. Die Ursache lag in einer Änderung der Syntax in der auth.conf. Dort muss nun anstatt allow 1.2.3.4 ein allow_ip 1.2.3.4 stehen.

Puppet: Hiera und Puppet – Installation, Einrichten, Moduleinbindung

prego Ein Kommentar

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:

  • —: Definiert den Beginn der Datei
  • :backends: Gibt das Format an in dem die die Daten vorliegen. In diesem Fall ist YAML definiert.
  • :hierarchy: Definiert die Hierarchie der Datenquellen. In diesem Fall gibt es nur eine moegliche Datenquelle ‚common‘
  • :yaml::datadir:Definiert fuer das YAML Backend das Verzeichnis in dem die Daten gespeichert sind. In diesem Fall das Verzeichnis /etc/puppet/hieradata

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‘.