Nach Ablauf der Weihnachtspause machen wir unsere Drohung wahr und beginnen mit dem Bau des eigenen Aquariums. In diesem Teil beschäftigen wir uns mit dem Einrichten der virtuellen Maschine, Ubuntu Server und der Grundinstallation von Barracuda und einer Octopus Instanz.

Alle Schritte wurden unter Mac OS 10.8 durchgeführt und getestet. Der Einfluss des Host-Systems ist allerdings relativ gering, das Tutorial sollte mit leichten Adaptionen auch in anderen Betriebssystemen anwendbar sein.

Virtuelle Maschine

Zuerst brauchen wir eine virtuelle Maschine mit Ubuntu Precise Server als Betriebsystem. Dazu laden wir als erstes das Image Ubuntu Server 12.04.1 LTS und eine Virtualisierungssoftware. Ich benutze Parallels Desktop für Mac, im Prinzip müsste aber alles auch mit VirtualBox oder VMWare funktionieren.

Dann erstellt man eine virtuelle Maschine und installiert das Betriebssystem. Die meisten, die dieses Tutorial in Angriff nehmen, haben so etwas höchstwahrscheinlich schon gemacht, deswegen werden wir nicht jeden Schritt einzeln durchexerzieren. Im Zweifelsfall finden sich auch genug Anleitungen dazu im Netz. Man sollte nur ein paar wichtige Eckpunkte beachten:

• Das Betriebssystem sollte auf Englisch installiert werden. Sonst kann es zu einigen interessanten Fehlern kommen, da das Barracuda Skript sich teilweise darauf verlässt.
• Die Netzwerkeinstellungen sollten so gewählt werden, dass unsere Maschine eine fixe IP Adresse bekommt. Das kann je nach Virtualisierungssoftware auf verschiedenen Wegen erreicht werden. In Parallels reichen dafür die Standardeinstellungen. Zwar arbeiten die auch über DHCP, Parallels verteilt an eine Maschine aber immer dieselbe Adresse.
• Wir brauchen keinerlei Zusatzpakete, das System sollte völlig nackt sein. Einzig OpenSSH ist zu Beginn praktisch, wenn man die ersten Schritte nicht in der wenig handlichen Default-Shell durchführen will.
• Sämtliche GUI-Pakete können auch eingespart werden. Zwar funktioniert Barracuda auch mit ihnen, sie kosten im Betrieb aber Arbeitsspeicher und sind nicht wirklich notwendig.
• Parallels bietet für Ubuntu eine „Express-Installation“ an. Wir lassen uns nicht darauf ein, sondern machen lieber alles selbst. Damit die bisher genannten Punkte auch sicher eingehalten werden.

Nach durchführen des Installationsprozesses sollte man im Idealfall den Login-Prompt vor sich haben, den man mit den zuvor gewählten Daten füttert. Ubuntu erlaubt standardmäßig keinen root-Login. Stattdessen hat unser, bei der Installation erstellter, Account sudo Rechte. Wir geben also einfach sudo su in die Kommandozeile ein, antworten mit dem selben Passwort wie beim Login, und schon sind wir in der root-Shell, in der wir ab nun weiterarbeiten.

DNS Setup

Aegir kennt keine Unterverzeichnisse mehr. Jede Site braucht eine eigene Domain. Im Prinzip könnten wir jedes mal einen Eintrag in /etc/hosts vornehmen, bei vielen Seiten wird das aber umständlich, also brauchen wir eine bessere Lösung.

Option 1: xip.io

xip.io ist ein kostenloser Service der klugen Köpfe hinter 37 Signals. Das Prinzip ist einfach. Ein spezieller DNS-Server fängt alle Anfragen auf xip.io, und löst sie auf eine IP-Adresse in der Subdomain auf. Zum Beispiel:

• 192.168.1.10.xip.io zeigt auf 192.168.1.10
• mydevsite.192.168.1.10.xip.io zeigt ebenso auf 192.168.1.10

Das wäre eine Lösung ohne jeglichen Aufwand. Nachteile sind aber vor allem die etwas unhandlich langen Domains, und die Tatsache, dass man Internetzugang braucht, um die Virtuelle Maschine zu erreichen. Das kann nervig sein, wenn man von unterwegs arbeitet.

Option 2: dnsmasq

Viel praktischer wäre es doch, wenn wir eine Top Level Domain hätten, die immer auf unseren Testserver zeigt. Und damit alles schön in einem Paket ist, sollte dieser auch gleich als DNS-Server agieren. Barracuda liefert eigentlich eine Integration für bind9 mit, das ist für unseren Anwendungsfall aber zu komplex. Stattdessen installieren wir dnsmasq:

apt-get install dnsmasq

Und editieren die mit dem Editor unserer Wahl – also vi – die folgenden Dateien

/ETC/DHCP/DHCLIENT.CONF:

Hier suchen wir die Zeile prepend domain-name-servers 127.0.0.1; und stellen sicher dass sie nicht auskommentiert ist, beziehungsweise fügen sie bei Zeile 20, nach supersede domain-name "fugue.com home.vix.com"; ein. Damit befehlen wir der Netzwerkkonfiguration unseren internen DNS-Server standardmäßig mit abzufragen.

/ETC/DNSMASQ.CONF

Hier konfigurieren wir dnsmasq selbst. Und zwar machen wir einen fixen Adresseintrag. In Zeile 62 sollten wir ein Beispiel dazu finden:

#address=/double-click.net/127.0.0.1

Diese kopieren wir und ändern sie, sodass die Top-Level Domain .bcd (kurz für „Barracuda“) auf unsere statische Adresse (in meinem Fall 10.211.55.12) zeigt.

address=/bcd/10.211.55.12

Achtung: Statt bcd kann man natürlich jede andere erfundene Top-Level Domain verwenden. Beliebte Kandidaten wie .local oder .private werden jedoch von OSX für interne Services wie zum Beispiel Bonjour schon verwendet. Das kann da zu interessanten Problemen führen und sollte deshalb vermieden werden.

Nach einem Neustart von dnsmasq …

/etc/init.d/dnsmasq restart

… sollte das ausführen von dig irgendwas.bcd unter anderem folgende Answer Section zurückliefen:

;; ANSWER SECTION:
irgendwas.bcd.      0   IN  A   10.211.55.12

Das bedeutet der DNS-Server läuft und ist zumindest innerhalb der Virtuellen Maschine erreichbar. Wir brauchen ihn aber auch noch von aussen. Dazu gehen wir in eine Shell im Hostsystem und suchen wiederum:

dig irgendwas.bcd @10.211.55.12

Das sollte wieder in derselben Answer Section resultieren. Wir wissen also, dass der DNS Server auch von aussen erreichbar ist, jetzt müssen wir nur mehr sicherstellen, dass das System unseren neuen DNS Server auch verwendet. Unter OSX geschieht das in den Einstellungen zum gerade aktiven Netzwerkadapter im Reiter DNS.

Die Lösung ist leider nicht optimal, da man die Default-Einstellungen überschreiben, und das ganze – sollte man mehrere verschiedene Adapter und Umgebungen verwenden – auch noch mehrfach eintragen muss. Problematisch wird es bei Netzwerken mit eigenen DNS Servern, die dann plötzlich nicht mehr funktionieren. Sollte jemand eine elegantere Variante kennen, würde ich mich über Hinweise freuen!

Manchmal werden die neuen DNS Einträge nicht sofort berücksichtigt, beziehungsweise nach Fehlern nicht aktualisiert. Unter OSX leert man den DNS-Cache mit folgendem Kommando:

sudo dscacheutil -flushcache

Oft reicht das nicht aus, da DNS-Abfragen durch mDNSResponder – ein Teil von Bonjour – laufen, und der cached sie auch noch zusätzlich. In diesem Fall liefert dig zwar das richtige Ergebnis, ping behauptet aber trotzdem den Host nicht zu kennen. Um das Problem zu lösen schießt man den verantwortlichen Prozess ab, damit er beim nächsten Aufruf neu gestartet wird. Nicht schön, aber wer so viel Verwirrung stiftet hat es verdient.

sudo killall -HUP mDNSResponder

Edit: Die Hinweise sind eingelangt. Es gibt eine (relativ) einfache und elegante Lösung unter OSX. Und zwar legt man im Ordner /etc eine Unterordner resolver an, und erstellt dort eine Datei namens bcd (ohne Endung) mit folgendem Inhalt:

nameserver 10.211.55.12

Dadurch wird ein neuer DNS Resolver registriert und für alle Domains die auf bcd enden verwendet, ohne in die normale Netzwerkkonfiguration einzugreifen.

Barracuda und Octopus

An diesem Punkt haben wir eine Virtuelle Maschine die auf die Domains mit der Endung .bcd horcht. Wir sind also bereit Barracuda selbst einzurichten.

Die offizielle Anleitung rät den das Meta-Kommando boa zu verwenden, welches fertige Konfigurationen für local und public Server bereitstellt. Beide funktionieren in unserem Setup jedoch nicht so richtig, deswegen gehen wir den etwas längeren Weg und konfigurieren selbst.

Als erstes laden wir in unserer virtuellen Maschine als root User die beiden Installationsskripte:

wget -q -U iCab http://files.aegir.cc/BARRACUDA.sh.txt
wget -q -U iCab http://files.aegir.cc/OCTOPUS.sh.txt

Installation von Barracuda

Dann installieren wir die benötigte Software und die Master-Instanz. Dazu editieren wir die gerade geladene Datei BARRACUDA.sh.txt. Dort finden sich eine Menge Optionen und alle sind sehr ausführlich dokumentiert. Man sollte sie zumindest kurz überfliegen, dann erklärt sich vieles von selbst. Folgende Punkte sind zu beachten:

• _MY_EMAIL: Den richtigen Wert hierfür zu finden überlasse ich dem Hausverstand.
• _EASY_LOCALHOST und _EASY_PUBLIC müssen auf NO gesetzt werden.
• Sollte man nicht vorhaben Drupal 5 zu unterstützen, ist für _PHP_FPM_VERSION und _PHP_CLI_VERSION der Wert 5.3 im Hinblick auf Drupal 8 Support empfehlenswert.
• _XTRAS_LIST: Für unsere Setup sind CSF (Firewall) und PDS (DNS-Cache) nicht notwendig, und stellen nur potentielle Fehlerquellen dar – also raus damit. Dafür nehmen wir CSS (Compass Tools) und SLR (Tomcat + Solr) mit auf.
• Im Idealfall erkennt das Skript die Domain und IP-Adresse automatisch. Sollte man Fehlermeldungen bezüglich FQDN und Adressauflösungen bekommen, so kann man _MY_OWNIP, _MY_HOSTN und _MY_FRONT mit den entsprechenden Werten befüllen und eventuell _DNS_SETUP_TEST auf NO setzen.

Nachdem man die Datei bearbeitet und mehrfach kontrolliert hat, führt man das Script mit bash BARRACUDA.sh.txt aus und holt sich einen Kaffee oder ein alternatives Heißgetränk mit dem man die nächsten Minuten überbrücken kann.
Sofern der Prozess nicht aufgrund irgendwelcher Fehler abgebrochen wurde, wirft das System einen einmalig verwendbaren Login-Link aus. Diesen findet man jederzeit auch in der Datei /var/aegir/install.log. Wir benutzen den Link, und setzen auch ein Admin-Passwort, weiter werden wir die Master Instanz aber gar nicht verwenden.

Die Octopus Instanz

Im zweiten Schritt der Installation erstellen wir eine Octopus Instanz für unser Development-System in der wir dann arbeiten. Theoretisch wäre es möglich auch mehrere zu generieren, das macht in unserem Fall allerdings nur begrenzt Sinn.

Die Datei OCTOPUS.sh.txt ist im BARRACUDA.sh.txt im großen und ganzen recht ähnlich:

• Wir setzen _USER auf einen handlichen Benutzernamen wie dev, development oder masterofdesaster. Der Einfachheit halber gehen wir in den weiteren Schritten von dev aus.
• _MY_EMAIL und _CLIENT_EMAIL können dieselbe, wieder vom Hausverstand diktierte, Adresse enthalten.
• PHP-Versionen und DNS-Setup konfiguriert man am besten analog zu BARRACUDA.sh.txt.
• _PLATFORMS_LIST enthält eine Liste von Drupal-Distributionen die für diese Octopus-Instanz automatisch installiert und aktualisiert werden. Wer herumprobieren will und eine längere Installation in Kauf nimmt kann sich hier austoben. Man kann Distributionen aber natürlich auch später von Hand installieren.

Wir führen die Datei wieder mit bash OCTOPUS.sh.txt aus und trinken den zweiten Kaffe für heute. Wenn alles glatt geht bekommen wir wieder einen Login-Link, diesmal zu unserem richtigen Aegir-Interface. Dieser findet sich auch diesmal in einer Log-Datei: /data/disk/dev/log/install.log.

Die Installation versendet auch automatisch eine E-Mail mit weiteren Instruktionen an die in OCTOPUS.sh.txt notierten E-Mail Adressen. Sollte diese nicht ankommen findet man sie auch in /data/disk/dev/log/setupmail.txt. Für den nächsten Schritt wichtig sind vor allem die FTP-Zugangsdaten.

Die erste Plattform

Wenn bis zu diesem Punkt alles funktioniert hat stehen wir kurz davor endlich unsere erste Drupal Website zu installieren. Dazu melden wir uns anhand der FTP-Zugansdaten mithilfe eines beliebigen FTP-Clients an und navigieren ins Verzeichnis static. Dieses ist reserviert für eigene Plattformen, also Drupal-Distributionen, die Barracuda beim Update nicht anrührt. Dort erstellen wir ein Verzeichnis my-drupal und befüllen es mit der aktuellsten Drupal-Version.

Dann begeben wir uns wieder in das Aegir-Interface unserer Octopus-Instanz und erstellen mit Content Management » Create Content » Platform (oben in der Administrationsleiste) eine neue Plattform der wir den Namen My Drupal geben. Wichtig ist dass der angezeigte Pfad unter dem Plattform Namen auch dem im Dateisystem entspricht.

Nach dem Speichern dauert es ein wenig bis Aegir die Plattform verifiziert. Danach können wir mit dem Tab Add Site eine Neue Seite anlegen. Dieser geben wir eine beliebige Domain, die auf .bcd endet und wählen – verwirrender Weise – zuerst ein Installationsprofil und danach eine Plattform in der dieses verfügbar ist. In unserem Fall sollte das vorerst Standard und My Drupal sein. Hat man gleich mehrere Distributionen mit installiert sollten diese auch zur Auswahl stehen.

Nach dem Speichern braucht Aegir wiederum ein wenig um unsere neue Seite zu installieren, dann liefert uns das Admin Interface direkt den aktuellen Status der Seite und einen Link zum einmaligen Anmelden.

Die letzten Schritte können wir nun beliebig oft wiederholen, um weiter Plattformen, Distributionen und Seiten zu installieren. Innerhalb von my-drupal (und allen anderen Plattformen in static) können wir auch wie gewohnt Module und Themes hinzufügen.

Das war noch nicht alles!

Bisher haben wir eine tolle Übung in Sachen Server- und DNS Konfiguration absolviert, das Leben als Entwickler erleichtert es uns bisher aber noch nicht gewaltig. Im nächsten (und voraussichtlich letzten) Teil dieser Blogreihe gehe ich auf einige Tips, Tricks und Stolpersteine rund um den Entwicklungsprozess innerhalb von Barracuda und Aegir ein. Das Beste kommt also zum Schluss!