SSH Konfiguration: Privat, Arbeit, teilen mit Kollegen?!

Ich habe meine .ssh/config Datei mit den Einträgen die ich benötige. In dieser Datei habe ich Einträge für dienstliche Systeme aber auch private. Aus diesem Grund kann die Datei nicht einfach mit anderen Kollegen geteilt werden. Wie das dennoch erreicht werden kann, kurz und pragmatisch hier beschrieben:

Als allererstes muss ich die Konfigurationsdatei aufsplitten können in mehrere Teile. Also ein ~/.ssh/config.d/ Verzeichnis anstatt einer einzelnen Datei. SSH unterstützt das von Haus aus nicht, man kann sich aber an dieser Stelle eines Tricks bedienen: ein Alias für das Kommando „ssh“, das bei jedem Aufruf die .ssh/config einfach neu schreibt. Dafür die folgende Zeile in die .bash_aliases  eintragen:

alias ssh="cat ~/.ssh/config.d/* > ~/.ssh/config; ssh"

Als zweites gilt es nun die Dateien aufzuspalten. Ich persönlich pflege drei Dateien:

  1. general
  2. privat
  3. work

In der ersten Datei habe ich Optionen, die für alle Hosts gelten:

Host *
Compression             yes
CompressionLevel        9
ServerAliveInterval     30
#VisualHostKey          yes

In den anderen Dateien sind die Definitionen für die privaten und die Arbeitsrechner.

Der dritte Punkt ist der einfachste: Die Dateien einfach in ein Repository legen, symbolische Links aus dem Repository in das config.d Verzeichnis erzeugen und mit den Kollegen teilen.

Natürlich Backups zwischendrin etc. nicht vergessen ;-)

Snippets: git, aptitude, who, mysql, tcpdump, lftp

Ein Sammelsurium von diversen Kommandos die sich angesammelt haben und die ich mir eben aufschreiben musste:

  • GIT – Die Aenderungen von Commit XYZ anzeigen:
    git show COMMITHASH
  • GIT – In den git commit messages suchen:
    git log --all --grep "foo"
  • GIT – Was hab ich noch mal in dieser Datei seit dem letzten pullen geaendert?
    git diff HEAD /path/to/file
  • APTITUDE – Was ist die Abhaengigkeitskette warum dieses Paket installiert ist:
    aptitude why PACKAGENAME
  • WHO – Wann wurde das System das letzte mal neu gestartet?
    who -b
  • MYSQL – Wie erzeuge ich die Tabelle neu:
    SHOW CREATE TABLE tabellenname;
  • TYPDUMP – Mit tcpdump den Traffic mitschneiden und in einer Datei speichern um diese später mit wireshark zu analysieren:
    tcpdump -i eth0 host 192.168.1.30 -X -s0 -w /tmp/foo
  • LFTP: Verzeichnislisting rekursiv erzeugen und Ausgabe in einer Textdatei speichern:
    lftp -u user,pass -e 'find /;bye' host > file_list

Puppet: Style pruefen mit puppet-lint als pre-commit hook

Ich hatte bereits puppet-lint in einem eigenen Blogeintrag vorgestellt. Noch schoener als das manuelle Aufrufen ist natuerlich das ganze als pre-commit Hook zu haben und gar nichts ins Repository rein zu lassen, was nicht den eigenen Regeln entspricht.

Folgendes ist mein pre-commit Hook:

#!/bin/bash
 
echo "Checking syntax with puppet-lint"
 
for i in $(git diff --name-only --cached | grep -E '.(pp)'); do
        if [ -f "${i}" ]; then
                # --no-80chars-check because of sshkey.pub and
                # https://github.com/rodjek/puppet-lint/issues/70
 
                puppet-lint --no-80chars-check --no-single_quote_string_with_variables-check --with-filename ${i}
 
                if [ $? -ne 0 ]; then
                        echo "ERROR: Bad syntax, see errors above. Aborting!"
                        exit 1
                else
                        echo "Nice work in: ${i} :-)"
                fi
        fi
done

Puppet: Manifest Dokumentation mit puppet doc / post-commit Hook

Wie ueberall im Leben bietet es sich auch an puppet Manifest Dateien zu dokumentieren. Die Dokumentation dort basiert auf rdoc. Die Syntax wird in der Puppet Manifest Documentation Wiki Seite unten ganz gut beschrieben. Hier ein paar Beispiele:

  1. Eine Testklasse mit Dokumentation davor. Wichtig ist, dass zwischen Ende der Dokumentation und Definition der Klasse KEINE Leerzeile ist, sondern die Kommentare bis direkt an die class test() {} Zeile gehen:
    Bildschirmfoto vom 2014-05-18 20:02:08
  2. Die einfachste Art- und Weise die Dokumentation zu lesen ist, diese auf der Kommandozeile auszugeben. Das tut man mit dem folgenden Befehl:
    puppet doc /path/to/manifest.pp

    Bildschirmfoto vom 2014-05-18 20:01:17

  3. Schoener zu lesen ist das ganze als HTML Seite. Ich persoenlich habe in dem GIT Repository in dem ich die Puppet Konfiguration verwalte einen post-commit Hook, der mir die Dokumentation erzeugt und in einem Verzeichnis ablegt, das mit Apache freigegeben ist. Der Aufruf dafuer ist in der post-commit Datei:
    puppet doc --all --mode rdoc --outputdir /var/www/example.org/puppetdocs/

    Und es sieht dann am Ende wie folgt aus:
    Bildschirmfoto vom 2014-05-18 20:02:44

    Wenn im Modul root Verzeichnis eine Datei README liegt, wird diese als Gesamtdokumentation fuer das Modul mit hinzugenommen.