Puppet: Testen in einer Testumgebung – Hallo Vagrant

Wenn ich mit Puppet arbeite passiert dieses leider viel zu häufig direkt auf dem Livesystem. Das ist natürlich Mist und darf so nicht sein. Eine Lösung ist Vagrant. Damit können sehr einfach „Wegwerf-VMs“ erzeugt werden um die Puppetkonfiguration zu testen. Wie das geht möchte ich in diesem Blogeintrag kurz festhalten.

Als Vorbereitung ist auf meinem PC das Paket virtualbox aus den Standardrepositories und Vagrant von deren Webseite installiert.

Um nun eine VirtualBox mit Ubuntu 12.04 LTS 64bit über Vagrant zu starten sind nur wenige Schritte notwendig:

mkdir ~/vagrant
cd ~/vagrant
touch HELLO_I_WAS_HERE
vagrant init puppetlabs/debian-7.4-64-puppet
vagrant up

Die Ausgabe sollte ungefähr so aussehen:

user@host:~/vagrant$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'hashicorp/precise64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'hashicorp/precise64'
    default: URL: https://vagrantcloud.com/hashicorp/precise64
==> default: Adding box 'hashicorp/precise64' (v1.1.0) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/hashicorp/precise64/version/2/provider/virtualbox.box
==> default: Successfully added box 'hashicorp/precise64' (v1.1.0) for 'virtualbox'!
==> default: Importing base box 'hashicorp/precise64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1408706120277_30417
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default: 
    default: Guest Additions Version: 4.2.0
    default: VirtualBox Version: 4.1
==> default: Mounting shared folders...
    default: /vagrant => /home/user/vagrant
user@host:~/vagrant$

Mit dem Befehl vagrant ssh kann nun eine SSH-Verbindung zu der VM hergestellt werden. Der Ordner ~/vagrant in dem wir uns befinden ist in der VM unter /vagrant/ verfügbar:

user@host:~/vagrant$ vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)
 
 * Documentation:  https://help.ubuntu.com/
New release '14.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
 
Welcome to your Vagrant-built virtual machine.
Last login: Fri Sep 14 06:23:18 2012 from 10.0.2.2
vagrant@precise64:~$ ls -l /vagrant
total 20
-rw-r--r-- 1 vagrant vagrant    0 Aug 22 11:30 HELLO_I_WAS_HERE
-rw-r--r-- 1 vagrant vagrant 4826 Aug 22 11:11 Vagrantfile
vagrant@precise64:~$

Die VM kann mit vagrant destroy wieder gelöscht werden.

In der Datei Vagrantfile wird die VM konfiguriert. Das praktische ist, dass dort Puppet eingebunden werden kann, so dass beim Hochfahren der VM dieses gleich ausgeführt wird. Um nun meine Konfiguration zu testen kopiere ich das puppet Verzeichnis in den Ordner vagrant. Kopieren ist wichtig, ich habe zuerst einen symbolischen Link erzeugt, aber die VM kann dem ja nicht folgen 8-)

scp -r puppetmaster:/etc/puppet ~/vagrant/

Anschließend sind in der Vagrantfile zwei Optionen zu konfigurieren. Erstens den Hostnamen der VM, damit wenn Puppet ausgeführt wird dieser korrekt ist und die richtigen Einstellungen übernommen werden. Zweitens den Pfad zu dem von puppet benötigten Manifest und den Modulen:

  config.vm.hostname = "mynode.example.org"
 
  config.vm.provision "puppet" do |puppet|
    puppet.manifests_path = "puppet/manifests"
    puppet.manifest_file  = "site.pp"
    puppet.module_path = "puppet/modules"
    #puppet.options = "--verbose --debug"
  end

Beim Starten der VM wird Puppet dann automatisch ausgeführt. Läuft die VM bereits kann das mit dem Befehl vagrant provision erneut angestoßen werden.

Auf diese Art- und Weise kann die Puppetkonfiguration in einer VM getestet werden bis alles so ist wie ich es haben möchte.

Zum Schluss:

  • Die Virtualbox wird standardmäßig im headless Mode gestartet. Wer über die Applikation eine GUI möchte muss dafür den folgenden Codeschnippsel in seine Vagrantfile hinzufügen:

      config.vm.provider "virtualbox" do |v|
             v.gui = true
      end
  • Damit beim ersten hochfahren der VM als erstes die Paketquellen aktualisiert werden die Datei bootstrap.sh mit dem folgenden Inhalt in dem Verzeichnis ~/vagrant/ ablegen:

    #!/bin/bash
    apt-get update

    und danach in der Vagrantfile VOR den puppet Block die folgende Zeile einfügen:

      config.vm.provision :shell, path: "bootstrap.sh"
  • Webseite des Projektes: www.vagrantup.com
  • Viele fertige Vagrant Boxes gibt es in der Vagrant Cloud: vagrantcloud.com
  • Für die vielen Einstellmöglichkeiten in der Vagrantfile gibt es eine Dokumentation unter: docs.vagrantup.com

Mehr Sicherheit fuer die eigenen Daten: Groupware ohne Google

Dieses ist der zehnte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten neun Artikeln befinden sich am Ende des Blogposts. Im zehnten Teil moechte ich meine Loesung zum Thema Groupware ohne vorstellen.

Wir leben in der Cloud. 24 Stunden vom Tag ist der Router mit dem Internet verbunden. Das Smartphone ist nur noch bei schlechter Netzabdeckung offline und die wird auch immer seltener. Es ist bequem auf dem Smartphone eine Telefonnummer ins Adressbuch hinzuzufuegen, und der Eintrag auf dem DECT Telefon Zuhause aktualisiert sich auch automatisch. Es ist bequem auf dem stationaeren Arbeitsplatz PC eine Emailadresse ins Adressbuch zu uebernehmen und spaeter ist sie auch auf dem Adressbuch des Laptops. Koennen wir uns eine Welt in der die Mails NICHT auf einem Server liegen und gleichermassen von Arbeitsplatz PC, Laptop, Smartphone, Tablet oder Webinterface bei Bekannten abgerufen werden koennen vorstellen? Ich nicht.

Google macht es einem da sehr einfach. Mit Diensten wie GMail, dessen Adressbuch, Google Calendar oder auch Google Drive gibt es fuer alles Loesungen. Sie sind kostenlos und das Erstellen eines Google Kontos dauert gerade mal zwei Minuten. Auf fast allen Geraeten kann man es sehr einfach einbinden. Wenn man ein Android Smartphone oder Tablet besitzt, ist die Integration perfekt!

Ich war auch in der Google Abhaengigkeit und mich davon zu loesen war schwerer als gedacht. Ich werde hier in diesen Blogpost keine Anleitungen schreiben wie alles eingerichtet ist, das ist definitiv zu kompliziert. Wenn jemand das Setup nachbauen moechte kann er mich gerne kontaktieren und ich helfe dabei oder gebe Tipps. Deswegen hier meine Loesung nur grob umrissen.

Grunsaetzlich liegt alles auf einem eigenen Server. Dieser ist voll verschluesselt. Fuer Emailempfang und Versand sowie den Zugriff via IMAP ist Postfix als MTA und Dovecot als MDA installiert. Bei beiden Diensten ist Perfect Forward Secrecy eingerichtet. Bei Dovecot wurde weiter das managesieve Plugin aktiviert. Postfix akzeptiert Verbindungen mit STARTTLS auf Port 25 und 465; letzterer damit man auch aus restriktiven Netzen bei denen Port 25 gesperrt ist wie z.B. be vielen WLANs in Hotels oder Gastnetzen von Universitaeten Emails versenden kann. Dovecot wurde so konfiguriert, dass nur Verbindungen ueber IMAPS auf Port 993 akzeptiert werden.

Als Groupware kommt bei mir Tine20.org zum Einsatz. Installiert habe ich es aus den bereitgestellten Debian Repositories. Apache ist so konfiguriert, dass der vhost auf Port 80 automatisch auf den vhost auf Port 443 weiterleitet. Tine20 wurde mit Postfix und Dovecot Backend eingerichtet. So kann ich die komplette Konfiguration der User und der Virtual Mailboxes aus dem Tine20 Adminmodul machen.

Als MUA auf dem Desktop verwende ich Thunderbird. Fuer Email ist alles mit den Standard Boardmitteln konfiguriert. Kalender, Adressbuch und Aufgaben werden mit Hilfe der Kombination aus Lightning Plugin und SOGo Connector synchronisiert.

Als Mailclient auf dem Smartphone verwende ich Kaiten Mail. Zur Synchronisation von Kalender, Adressbuch und Aufgaben nutze ich die Apps CalDAV-Sync, CardDAV-Sync und Tasks. Die Android eigene Kalenderapplikation habe ich gegen aCalendar getauscht.

Dieses Setup ermoeglicht es mir die Synchronisation meines Google Kontos in den Android Einstellungen komplett zu deaktivieren.

Seit dem neusten Release von Tine20.org – Collin – kann Tine auch als Server fuer OwnCloud Clients fungieren. Das funktioniert prinzipiell auch schon ganz gut, aber gerade auf dem Smartphone gibt es immer nochmal wieder Synchronisierungsprobleme. Ob das nun an der App, Tine20, Android 4.4 oder an meiner Serverkonfiguration liegt habe ich noch nicht herausgefunden.

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.
  • Der neunten Teil stellt meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vor.

Mehr Sicherheit fuer die eigenen Daten – vollverschluesselte Festplatten auf Servern

Dieses ist der neunte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten acht Artikeln befinden sich am Ende des Blogposts. Im neunten Teil moechte ich meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vorstellen.

Wenn ich eine verschluesselte Verbindung zu einem anderen Rechner / Dienst im Internet aufbaue kann ich das ungewollte Mitlesen der Kommunikation erschweren bis verhindern. Speichere ich nun die Daten auf eigenen Servern und vertraue sie nicht Firmen wie Google (Mail, Drive), Microsoft (Outlook.com, Skydrive) oder Amazon Cloud (Dropbox) an, dann erschwere ich auch erst einmal das ungewollte Lesen meiner Daten. Ich bin ja schliesslich kein Administrator auf dem anderen Server und weiss nicht wann sich wo auf deren Seite jemand potentiell dazwischen schaltet.

Meine Daten liegen also auf einem selbstgehosteten Server und ich baue eine verschluesselte Verbindung dahin auf. Die Daten auf dem Server selbst sind aber immer noch unverschluesselt gespeichert. Es kann also potentiell jemand ins Rechenzentrum gehen, sich den Server schnappen, analysieren und die Daten dort herunter ziehen. Was liegt da naeher als die Festplatten zu verschluesseln.

Mit LUKS (klick) steht dafuer unter Linux auch eine gute Loesung zur Verfuegung. Auf meinem Laptop oder meinem Arbeitsplatzrechner setze ich sie bereits ein. Ist ja auch kein Problem beim Booten das Passwort einzugeben. Das bei einem Server zu tun ist es schon sehr viel umstaendlicher, denn man sitzt ja eigentlich nie direkt davor…

Ich werde hier nun keine Anleitung schreiben wie man die Schritte 1:1 geht um seine Festplatte mit LUKS zu verschluesseln. Davon gibt es bereits genuegend im Netz. Einige Distributionen wie Debian bieten es sogar im Installer gleich an die Festplatte mit LVM zu erzeugen und dann mit LUKS zu verschluesseln. Die Stichworte beim Suchen nach entsprechenden Dokumentationen sind Distributionsname + „LUKS“ oder „cryptsetup“ oder „encrypted filesystem“. Nicht zu vergessen auch unter /usr/share/doc/cryptsetup/ nach zuschauen!

Der Clou an der Geschichte ist nun, das man einen dropbear SSH Server in die initramfs seines Servers hinzufuegen kann. So ist es moeglich waerend des Bootvorgangs eine SSH Verbindung in die initramfs aufzubauen und dort das Passwort zum entschluesseln der Festplatte einzugeben. Damit das ganze komfortabel wird, nutze ich dafuer SSH-Keys ohne Passwort in Verbindung mit einem Miniskript pro Maschine.

Boese boese mag sich nun mancher denken, aber alles halb so wild. Ich habe eine Maschine die ist unverschluesselt. Einfach, weil Sie es nicht benoetigt und dort nichts wichtiges abgespeichert ist. Auf dieser Maschine habe ich einen Ordner mit ecryptfs verschluesselt (klick fuer Anleitung). In diesem Ordner bewahre ich folgendes auf:

  1. private Keys fuer die Verbindung zu dem Dropbear Servern im initramfs der virtuellen Maschinen
  2. eigene known_hosts Datei dafuer
  3. Ein Skript pro VM das mir die Eingabe des Passworts erleichtert.

Das Skript sieht schematisch wie folgt aus:

#!/bin/bash
 
ssh -o "UserKnownHostsFile=known_hosts/known_hosts.initramfs" -i "keys/servername" root@1.2.3.4 "echo -ne "**TOPSECRET**" >/lib/cryptsetup/passfifo"

Wenn ich nun einen Server neu starte bei dem die Festplatte verschluesselt ist, dann melde ich mich auf der unverschluesselten Maschine an, mounte den ecryptfs verschluesselten Ordner und muss dann nur noch das entsprechende Skript starten, z.B. ./unlock_servername und schon bootet die Maschine durch.

In diesem Kontext sicherlich noch einmal spannend ist auf einen drei Jahre alten Blogeintrag „Howto: virsh console“ zu verweisen um sich das ganze auch vom physikalischen Server aus anzuschauen ;-)

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.