Puppet: Pruefung auf Syntaxfehler von .pp und .erb Dateien

In dem Blogeintrag Konfiguration in GIT Repository verwalten / push-to-deploy habe ich den update Hook verlinkt, der eine Syntaxpruefung von .pp Dateien macht. Diesen habe ich heute morgen noch erweitert, so das auch die Templates mit der Endung .erb ueberprueft werden.

Wer die beiden Kommandos manuell ausfuehren moechte, sie sind wie folgt:

  1. Pruefen der Syntax von .pp Dateien:
    puppet parser validate /path/to/file.pp

    Im Fehlerfall gibt es eine Ausgabe wie zum Beispiel:

    Error: Could not parse for environment production: Syntax error at 'jails' at /home/user/git/puppet/modules/fail2ban/manifests/init.pp:13
  2. Pruefen der Syntax von .erb Template Dateien:
    erb -x -T '-' /path/to/file.erb  | ruby -c

    Im Fehlerfall gibt es eine Ausgabe wie zum Beispuel:

    -:44: syntax error, unexpected ')', expecting $end
    ...:jails').include? "ssh" ).to_s); _erbout.concat "n"
    ...

Wie bereits frueher geschrieben, richtig praktisch ist das ganze als update Hook im Git Repository. Die Fehler werden zwar trotzdem nicht zu 100% korrekt abgefangen, dafuer muss man noch Tests ausfuehren (dazu spaeter mehr), aber fuers Erste fangen die beiden Pruefungen schon eine Menge ab.

Bildschirmfoto vom 2014-05-07 07:26:27

Puppet: Konfiguration in GIT Repository verwalten / push-to-deploy

Es ergibt Sinn die puppet Konfiguration in einem GIT Repository zu verwalten. So kann man immer auf alte Versionen zurueckgehen sowie automatische Pruefungen zwischenschalten bevor man Aenderungen Live schaltet. Sexy wird das ganze mit push-to-deploy. So wird es gemacht:

Vorbereitungen auf dem puppet server

mkdir -p /srv/git/puppet
cd /srv/git/puppet
git init --bare
addgroup puppet-push
chgrp -R puppet-push /srv/git/puppet
find /srv/git/puppet -type d -exec chmod 0775 {} ;
find /srv/git/puppet -type d -exec chmod +s {} ;
chgrp -R puppet-push /etc/puppet
chmod 775 /etc/puppet

Damit mein Benutzername auch in das GIT Repository schreiben darf muss dieser Mitglied in der Gruppe puppet-push sein:

adduser USERNAME puppet-push

Nun benoetigen wir zwei Hooks in dem Repository. Einen update Hook der die Syntax ueberprueft, und ein post-receive Hook, der bei Bedarf die gepushten Dateien gleich an die richtige Stelle kopiert:

cd /srv/git/puppet/hooks/
wget http://git.pregos.info/scripts.git/blob_plain/HEAD:/push-to-deploy/update
chmod +x update
http://git.pregos.info/scripts.git/blob_plain/HEAD:/push-to-deploy/post-receive
chmod +x post-receive

Anschliessend sind auf Server Seite keine weiteren Aenderungen mehr notwendig.

Vorbereitungen auf dem lokalen Rechner

Bei sich lokal auf dem Rechner muss man nun ein Verzeichnis erzeugen, die aktuellen Dateien vom puppetmaster.example.org:/etc/puppet dorthin kopieren, GIT Repository initialisieren und committen:

mkdir ~/puppet
cd ~/puppet
scp user@puppetmaster.example.org:/etc/puppet .
git init
git add .
git commit -m "initial commit"

Nun noch das remote Repository hinzufuegen und pushen:

git remote add live user@puppetmaster.example.org:/srv/git/puppet
git push live master

Wenn alles richtig ist, dann ist die Ausgabe in etwa wie folgt:

user@client:~/git/puppet$ git push live master
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (22/22), 4.91 KiB | 0 bytes/s, done.
Total 22 (delta 2), reused 0 (delta 0)
remote: fatal: bad object 0000000000000000000000000000000000000000
remote: 
remote: diff-tree:
remote: Already on 'master'
remote: DEPLOY: master(bd01768f198a2513ba82f5f8765b4b222908ce4b) copied to '/etc/puppet'
To user@puppetmaster.example.org:/srv/git/puppet
 * [new branch]      master -> master

Syntaxfehler fuehren dazu, dass die Aenderungen nicht uebernommen werden:

user@client:~/git/puppet$ git push live master
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 328 bytes | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: 
remote: diff-tree:
remote: :100644 100644 c31414e094fbbf3af3792965f2f706ede6a70d24 f47cd2be9c7b3a9d4e23b885b2252ac0579319d2 M	manifests/site.pp
remote: 
remote: err: Could not parse for environment production: Syntax error at end of file; expected '}' at manifests/site.pp:6
remote: err: Try 'puppet help parser validate' for usage
remote: For more details run this:  git diff c31414e094fbbf3af3792965f2f706ede6a70d24 f47cd2be9c7b3a9d4e23b885b2252ac0579319d2 
remote: 
remote: error: hook declined to update refs/heads/master
To user@puppetmaster.example.org:/srv/git/puppet
 ! [remote rejected] master -> master (hook declined)
error: Fehler beim Versenden einiger Referenzen nach 'user@puppetmaster.example.org:/srv/git/puppet'

Die Informationen sind zusammengetragen von:

HowTo: Bios Update on Dell XPS 13 9333 (Haswell, late 2013) with Ubuntu and FreeDos

  1. gparted installieren und eine leere Fat16 Partition auf dem USB-Stick erstellen.
  2. unetbootin installieren und FreeDos 1.0 installieren.
  3. Die .exe Datei fuer das Bios-Update (heute: 9333A04.exe) von der Dell-Homepage herunterladen (Link)
  4. Den USB-Stick mounten und die .exe Datei in das root-Verzeichnis kopieren (neben ubninit, ubnkern, ldlinux.sys usw.)
  5. Laptop neu starten, F12 druecken. In den Bootoptionen das USB-Geraet waehlen
  6. Den ersten Screen von Unetbootin (Default) bestaetigen.
  7. Auf dem zweiten Bootscreen NICHT DIE ERSTE VORAUSGEWAEHLTE OPTION booten, sondern eine Nachfolgende. Ansonsten wird FreeDos auf der Festplatte installiert und das vorhandene System ueberschrieben.
  8. Nachdem FreeDos gebootet ist mit c: in das Laufwerk C: wechseln
  9. Dort die Datei ausfuehren. Dabei ist wichtig, dass der Laptop an das Stromnetz angeschlossen ist und nicht auf Batterie laeuft.
  10. Das Bios-Update wird nun installiert. Dabei gibt es verschiedene Fortschrittsbalken, der Laptop piepst wild rum und startet mehrfach neu.

Ein Versuch #Heartbleed fuer nicht-Techniker verstaendlich zu machen

heartbleed

Eigentlich sollte ich keine Zeit haben zu schreiben, aber das ist die mit Abstand krasseste Sicherheitsluecke die es seit langem gegeben hat. Das Ausmass kann man nur erahnen, im Prinzip muessen alle persoenlichen Daten auf einem System das den Fehler hatte als unsicher erachtet werden. Es reicht nicht die gepatchte Version von OpenSSL einzuspielen und die betroffenen Prozesse wie Apache, Postfix, Dovecot oder OpenVPN neu zu starten. Es muessen private Schluessel und Zertifikate erneuert werden und wer den Konsequenzen der Luecke klar ins Gesicht schaut wird auch ueberall Passwoerter neu setzen muessen.

Heute beim Kaffee und Kuchen fragte unsere Nachbarin wie man sich das vorstellen koennte und ich habe versucht es wie folgt zu erklaeren:

Stell Dir vor auf dieser Welt gibt es einen Hersteller fuer Haustuerschloesser. Dieser Hersteller baut sehr sichere Schloesser und man kann sich darauf verlassen, dass wenn man seine Haustuer mit einem Schloss dieser Marke schuetzt, dass dort nicht eingebrochen werden kann. Das Schloss ist in diesen Fall OpenSSL, und das Haus der Server selbst.

Vor ein paar Jahren gab es dann den Trend zu sogenannter Perfect Forward Secrecy. Im uebertragenen Sinne kann man sich das so vorstellen, dass das Schloss kontinuierlich neue Schluessel generiert die jedes mal anders sind. Gelangt also mal ein Haustuerschluessel in die falschen Haende, dann kann man damit trotzdem nichts mehr anfangen, weil das Schloss sich geaendert hat.

Die Sicherheitsluecke in OpenSSL erlaubt es, das man von extern, ohne, dass man auf den Server einbrechen muss, an sehr sehr private Daten gelangen kann. Das koennen Zugangsdaten sein oder auch der private Key, mit dem man sich dann fuer den Server ausgeben kann ohne eben dieser zu sein.

Wenn man das wieder auf den Schlosshersteller und das Haus zurueckbringt, dann stelle man sich vor, das man zu jedem Haus mit einem Schloss von diesem Schlosshersteller hingehen kann, und ohne einzubrechen bekommt man die Information wie das Schloss jetzt Schluessel generiert. Man muss nichts stehlen, man muss nichts kaputt machen, man geht einfach hin und fragt und das Schloss sagt es einem.

Auch wenn in dem Beispiel viele Dinge vielleicht als Vergleich hinken, es zeigt ziemlich einfach welche Tragweite die Sicherheitsluecke hat. Man kann ja von aussen nicht sehen „ob jemand vorbeigekommen ist und gefragt hat wie sich das Schloss aendert oder nicht“. Aus diesem Grund muss man alle Server auf denen OpenSSL in der betroffenen Version eingesetzt wurde als unsicher betrachten. Der Fehler existiert seit dem 14. Maerz 2012 und man muss also davon ausgehen, dass es Menschen / Organisationen gibt, die seit zwei Jahren in alles rein gucken konnten was man irgendwie sichern wollte.

Fuer Sysadmins ist das der Supergau…

Eine ganz gute Zusammenfassung zu dem Thema gibt es bei Golem:

Weitere Infos:

Wer seine eigene Infrastruktur testen moechte (Router, NAS, Drucket etc) kann mit dem heartbleeder lokale IP Adressen probieren und findet dann auf einschlaegigen Seiten wie Packetstormsecurity die entsprechenden Exploits…