Monthly Archives: August 2008

Zurück aus London

Alle die noch auf Antwort wegen des Treffens warten: Ich bin gerade eben aus London zurück, aber werde versuchen, morgen allen eine E-Mail zukommen zu lassen. Es ist leider alles etwas kurzfristig, aber wie ich dieses Wochenende erfahren habe, bringt gerade das Unerwartete und Improvisierte oft die besten Ergebnisse :)

Xen auf Debian. Teil 5

Mit Backups ist es wie mit dem Sport: Jeder weiß, wie wichtig Backups sind, aber kaum jemand macht’s. Und wenn doch, dann meist nicht regelmäßig. Entsprechend haben viele auch ein schlechtes Gewissen, wenn man auf das Thema kommt. Allerdings gibt es einen Unterschied: Backups lassen sich automatisieren, Sport leider nicht. Und das ist zumindest für Backups eine gute Nachricht. Außerdem sind heute Programme wie rdiff-Backup so einfach zu bedienen, dass es kaum einen Grund gibt, kein Backup zu haben.

In diesem vorerst letzten Teil werden wir sämtliche virtuellen Xen-Domains erst täglich (oder nächtlich) auf dem Wirt sichern und diese Daten dann als differenzielles Backup auf einen anderen Server ziehen. Schematisch also:

Domain1, Domain2, Domain3 –> Wirt –> Backup-Server.

Wir haben also immer ein komplettes aktuelles Backup auf dem Wirt und beliebig lange in die Vergangenheit reichende differenzielle Backups auf dem Backupserver. So können jederzeit Verzeichnisse oder Dateien wiederherstellen, so wie sie zu einem beliebigen Zeitpunkt waren.

Für den ersten Schritt, also das Backup der Domains auf den Wirt, bedienen wir uns eines fertigen Skripts von John Quinn.

http://www.johnandcailin.com/blog/john/backing-your-xen-domains

Das Skript speichern wir unter /usr/bin/xenBackup, setzen owner und group auf root und chmod auf 700.

Jetzt erstellen wir das Verzeichnis /backups und /mnt/xen auf dem Wirt. Dann bearbeiten wir das Skript von John in einem Punkt: Wir ändern den Wert von xenDiskArea und wählen unsere LVM Volume Group, in meinem Fall wäre das vg0.

Nun müssen wir noch rsync und rdiff-backup installieren
# apt-get install rsync rdiff-backup

Wir probieren einmal, ob auch alles funktioniert, wie gedacht:

# xenBackup -a -t /backups -e rsync -s

Mit -a werden alle Domains gesichern, mit -d können einzelne Domains gewählt werden. Mit dem Schalter -s werden die Domains erst runtergefahren, bevor ein Backup durchgeführt wird. So sparen wir uns die zusätzlichen Datenbank-Backups, die eigentlich nötig wären, wenn wir die Domains im laufenden Betrieb sichern würden. Natürlich muss man abwägen, ob es das Wert ist. Wenn der Server stets ausgelastet ist und man auf die eine Minute Downtime pro Tag verzichten möchte, muss man eben noch die Datenbank-Backups separat durchführen.

Wenn das Skript problemlos durchgelaufen ist, können wir noch einen Versuch starten, um zu schauen, ob das Backup auch geklappt hat. Wir fahren eine Domain runter und starten eine neue mit Xen:
# xen-create-image --copy=/backups/sicherungsordner --ip=192.168.1.10 --hostname=mymachine

Auf diese Weise kreiert Xen aus den Backup einen Server, der identisch sein sollte mit dem Backup und auch voll funktionsfähig sein müsste.

Wenn also die Integrität des Backups geklärt ist, können wir das Skript in die Crontab eintragen:

5 4 * * * root /usr/bin/xenBackup -q -a -t /backups -e rsync -s

Damit wird jede Nacht um 5 nach 4 ein Backups aller Domains durchgeführt. Und der erste Schritt des Backups ist eingerichtet. Natürlich haben wir noch nicht viel gewonnen. Das Backup wird auf dem selben Server durchgeführt, auf dem die Daten liegen und es wird immer nur der aktuelle Zustand festgehalten. Wenn man feststellt, dass man vorgestern eine wichtige Datei gelöscht hat, hat man keine Chance, die Datei wieder zu bekommen. Um beide Schwachstellen auszuschalten, werden wir ein differenzielles Backup auf einem separaten Server durchführen.

Die folgende Anleitung ist eine schamlose Kopie von Dean Gaudet: http://arctic.org/~dean/rdiff-backup/unattended.html

Auf dem Backup-Server kreieren wir einen neuen Nutzer Namens backups. Der Nutzer sollte keine Shell und kein Passwort haben und /backups als Heimatverzeichnis:
# useradd -m -d /backups -s /bin/false backups

Dann übergeben wir das Verzeichnis dem neuen User:
# chown backups:backups /backups/

Als nächstes installieren wir rdiff-backup auf dem Backup-Server:
# apt-get install rdiff-backup

jetzt erstellen wir einen Passphrase-freien SSH-Key für diesen User:

# su
# su -m backups
% ssh-keygen -t rsa

Bei der Frage nach dem Dateinamen und Speicherort wählen wir /backups/.ssh/id_rsa_backup
Wir vergeben wie erwähnt keine Passphrase.

Jetzt erstellen wir die Datei /backups/.ssh/config mit folgendem Inhalt

host Name-des-Wirts
hostname Name-des-Wirts
user root
identityfile /backups/.ssh/id_rsa_backup
compression yes
protocol 2

Damit geben wir an, wie der Wirt von diesem Backup-Server aus kontaktiert werden soll. Jetzt müssen wir noch den SSH-Ordner absichern:

% chmod -R go-rwx /backups/.ssh

Der nächste Schritt ist, dass wir auf dem Wirt den Zugang vom Backupserver aus erlauben.

Erst geben wir auf dem Backupserver den öffentlichen Key aus und speichern ihn in der Zwischenablage:

# cat /backups/.ssh/id_rsa_backup.pub

Jetzt wechseln wir auf den Wirt und erstellen die Datei /root/.ssh/authorized_keys2
Die Datei bekommt folgenden Inhalt (vorsicht, alles muss in einer Zeile stehen):

command="rdiff-backup --server --restrict-read-only /backups",from="Backupservername",no-port-forwarding,no-X11-forwarding,no-pty [öffentlicher Schlüssel]

Der öffentliche Schlüssel wird direkt hinter “no-pty” mit einem Leerzeichen Abstand eingefügt. Auf diese Weise kann sich ein User zwar als zwar als Root auf dem Wirt anmelden, allerdings nur mit Leserechten für /backups und nur vom Backupserver aus und nur, wenn er den passenden privaten Schlüssel zum angegebenen öffentlichen Schlüssel hat.

jetzt müssen wir auch hier den SSH-Ordner absichern:
# chmod -R go-rwx /root/.ssh

Außerdem muss auch auf dem Wirt rdiff-backup installiert sein. Zwar darf der User mit diesem root-Zugang nur das Verzeichnis /backups lesen, aber es ist trotzdem nicht schön, den Root-Zugriff von überall aus zu erlauben, wir sollten daher den Zugriff auf den Backups-Server einschränken. Dazu öffnen wir auf dem Wirt die Datei /etc/ssh/sshd_config und fügen noch eine Zeile hinzu:
AllowUsers root@name-oder-ip-des-backup-server [weitere user]

Ganz wichtig: jeder weitere User muss explizit genannt werden, ansonsten wird er nicht mehr auf den Server gelassen. Man kann sich auf diese Weise sehr schnell selbst ausschließen.

Dann müssen wir den ssh-Daemon neustarten:
/etc/init.d/ssh restart

Wir probieren das einmal aus, indem wir angemeldet als User backups auf dem Backup-Server rdiff laufen lassen:

% rdiff-backup Name-des-Wirts::/backups /backups/name-des-wirts

Hier müsste SSH einmal anfragen, ob der Wirt akzeptiert werden soll. Wenn nach einem Passwort gefragt wird, ist etwas schief gelaufen. Falls das Backup in Ordnung ist, können wir auch hier einen Croneintrag vornehmen, diesmal allerdings nicht für Root, sondern für den User backup:

# crontab -e -u backups

Der Inhalt lautet:
30 4 * * * rdiff-backup name-des-wirts::/backups /backups/name-des-wirts

Damit hätte der Wirt etwa 25 Minuten, um ein Backup der Domains vorzunehmen, bevor sich der Backupserver anmeldet, um die Sicherung auf die eigene Festplatte zu ziehen. Wenn man nicht gerade einen Fileserver betreibt, sollte die Zeit recht großzügig bemessen sein. Bei inkrementellen Backups und wenigen Veränderungen auf den Domains sollte das Backup etwa 2-3 Minuten maximal betragen.

Auf diese Weise haben wir ein recht ordentliches Backup-System. Zwar ist es bei weitem nicht perfekt. Schöner wären rotierende Backups, mit vollen Backups einmal in der Woche und täglichen differenziellen Backups, aber in diesem Bereich sind der Paranoia ohnehin keine Grenzen gesetzt. Ich begnüge mich mit diesem Setup und sichere die Daten auf dem Backup-Server gelegentlich noch auf eine externe Festplatte zu Hause.

Damit ist der vorerst letzte Teil dieser Anleitung abgeschlossen. Im ersten Teil hatten wir einen einfachen Server aufgesetzt, im zweiten den Mailserver eingerichtet, im dritten Teil den Webserver und im vierten Teil das CMS Drupal.

Eigentlich habe ich die Anleitung mehr für mich selbst geschrieben. Denn in ein paar Wochen werd ich die meisten Schritte hier wieder vergessen haben und müsste sie mir sonst wieder mühsam zusammensuchen, aber vielleicht geht es ja dem ein oder anderen genauso und ich kann helfen, ein bisschen Zeit zu sparen. Deswegen steht die Anleitung im Blog und nicht bei mir auf der Festplatte. Natürlich kann ich keine Garantie dafür übernehmen, dass bei der Anwendung der Anleitung nicht alles kaputt geht, die Daten gelöscht werden und der Server explodiert, aber zumindest kann ich versichern, dass ich alle Schritte genauso selbst durchgeführt habe :)

PS: Ich hab inzwischen noch ein Addendum zum Monitoring und Statistiken verfasst.

XEN auf Debian. Teil 4

Nachdem wir im dritten Teil den Webserver aufgesetzt haben, geht es diesmal um die Installation eines CMS. Ich habe mich für Drupal entschieden, aber ein Weblog oder Wiki tut es genauso. Zunächst erstellen wir eine neue Gruppe www und fügen unseren User und www-data zu dieser Gruppe hinzu. Danach müssen wir die Gruppe des Verzeichnisses /var/www/ auf diese neue Gruppe www umstellen. Außerdem ändern wir die Berechtigung des Ordners auf 775. Damit wir auch Dateien im Ordner ablegen können. Auch für weitere Dateien, die wir anlegen, gilt, dass sie auch von der Gruppe gelesen werden können sollten. Dass die Dateien also der Gruppe gehören sollten. Jetzt können wir Drupal von drupalcenter.de auf Deutsch herunterladen und das Verzeichnis auf den Server übertragen. Während die Daten hochgeladen werden, können wir per phpMyAdmin einen neuen User und eine neue Datenbank für die Drupalinstallation erstellen. Außerdem brauchen wir noch mod_rewrite, um saubere URLs in unserem CMS zu bekommen. Dazu wechseln wir ins Vezeichnis /etc/apache2/mods-enabled und legen einen neuen Softlink an. # ln -s /etc/apache2/mods-available/rewrite.load Jetzt müssen wir das Überschreiben der URLs auch erlauben. Dazu öffnen wir die Datei /etc/apache2/sites-available/default und ändern den Wert für AllowOverride im Ordner /var/www/ auf All Und Drupal hätte ganz gerne auch die Imagelibrary GD. Glücklicherweise geht das unter Debian recht einfach: # apt-get install php5-gd Jetzt muss noch der Apache neu gestartet werden: # /etc/init.d/apache2 restart Wenn die Dateien schon auf dem Server sind, müssen wir noch eine Datei umbenennen. Die Datei /var/www/drupal/sites/default/default.settings.php wird umbenannt in settings.php Hier muss darauf geachtet werden, dass der Webserver Zugriff auf die Dateien und Verzeichnisse hat. Wenn wir jetzt im Browser die Adresse der Drupal-Installation angeben, kann die Installation beginnen. Der Rest ist dann selbsterklärend. Zum Abschluss legen wir noch einen Cron-Dienst an, den Drupal benötigt. Wir öffnen die Datei /etc/crontab und fügen folgende Zeile hinzu: 45 * * * * root /usr/bin/wget -O – -q http://beispielseite.com/cron.php Damit wird der Dienst einmal pro Stunde gestartet. Jetzt haben wir ein komplettes und recht mächtiges CMS auf dem Server. Der nächste Teil beschäftigt sich dann mit Backups.

XEN auf Debian. Teil 3

Im ersten Teil dieser Anleitung hatten wir den Server grundlegend konfiguriert, im zweiten Teil dann einen Mailserver installiert. Im dritten Teil richten wir den Webserver ein. Im Gegensatz zum Mailserver ist das relativ simpel und in wenigen Schritten erledigt.

Wir beginnen mit der Installation von Apache:
# apt-get install apache2

Fertig! Fast. Wenn man jetzt den Domainnamen in einen Browser eingibt, erscheint der Text “it works”. Wir können jetzt damit beginnen, HTML-Dateien unter /var/www/ abzulegen. Wer nun versucht, die Daten aufzurufen, wird allerdings eine Überraschung erleben. Es wird immer nur der Inhalt von /var/www/apache2-default angezeigt. Um das abzustellen, müssen wir die Serverkonfiguration ändern. Dazu öffnen wir die Datei /etc/apache2/sites-enabled/000-default und kommentieren folgende Zeile mit # aus: RedirectMatch ^/$ /apache2-default/

Jetzt noch ein beherzter Neustart des Webservers und die Daten unter /var/www/ sollten angezeigt werden.
# /etc/init.d/apache2 restart

Ja, damit haben wir einen voll funktionsfähigen Webserver. Allerdings kann momentan nur eine Domain auf dem Server existieren. Da Server in der Regel aber stark genug sind, um mehrere Websites zu hosten, schauen wir nochmal, wie das genau funktioniert.

Wir wechseln ins Verzeichnis /etc/apache2/sites-available und legen eine neue Datei mit folgendem Inhalt an

<virtualhost *>
DocumentRoot “/var/www/”
ServerName www.beispieldomainname.de
ServerAlias beispieldomainname
<directory /var/www/>
Options Indexes FollowSymLinks Multiviews
AllowOverride All
Order allow,deny
allow from all

</Directory>
</virtualHost>

Jetzt wechseln wir ins Verzeichnis /etc/apache2/sites-enabled und legen einen Softlink auf die soeben erstellte Datei.
# ln -s /etc/apache2/sites-available/beispielname

Und ein Neustart.
# /etc/init.d/apache2 restart

Auf diese Weise können wir pro Verzeichnis eine Domain hosten.

Jetzt noch ein paar Kleinigkeiten installieren. Zum Beispiel php:
# apt-get install libapache2-mod-php5

Damit ist php voll funktionsfähig.

Jetzt den Datenbankserver mySQL:
# apt-get install mysql-server

hierfür noch ein Passwort vergeben:
# mysqladmin -u root password [passwort]

Damit ist Mysql eingerichtet. Wir können aber zur leichteren Konfiguration noch phpmyadmin installieren
# apt-get install phpmyadmin

Schon ist phpMyAdmin unter domainname/phpmyadmin verfügbar.

Mit Debian geht das wirklich alles extrem leicht von der Hand. In wenigen Minuten haben wir so einen vollständigen Server, inklusive php und mySQL. Jetzt können die eigentlichen Applikationen kommen. In den nächsten Teilen wird es um die Installation des CMS Drupal gehen und dann um das Backup all dieser Einzelteile.

Xen auf Debian. Teil 2

Nachem wir im ersten Teil den Server aufgesetzt und grundlegend abgesichert haben, folgt jetzt der Mailserver.

Einer der grundlegendsten Dienste auf einem Server ist der Maildienst. Wir haben in der Grundkonfiguration des Servers festgelegt, dass wir über Angriffe auf den Server benachrichtigt werden wollen, aber ohne einen MTA kommt nichts bei uns an. Der Mail-Server besteht aus zwei Teilen, Postfix als MTA und Courier für den Pop3- oder IMAP-Zugriff.

Obwohl Mail so grundlegend ist, geht die Konfiguration nicht ganz so leicht von der Hand. Will man gar auf lokale User verzichten und virtuelle User einrichten und die User von mySQL verwalten lassen, dann sollte man besser auf automatische Tools wie ispconfig wechseln. Bei händischer Konfiguration lauern hier einfach zu viele Fallen.

Wir wollen hier allerdings erst einmal Mail nur für lokale Benutzer einrichten und solange man den Überblick über die Anwender behalten kann (sprich: solange man nicht dutzende von Anwendern hat), ist das der unkomplizierteste Weg.

Wir beginnen mit der Installation des MTA postfix

# apt-get install postfix

In der Abfrage, die darauf folgt, geben wir den Domainnamen ein und wählen Internetserver als den korrekten Modus aus.

Da wir Courier für IMAP verwenden wollen, müssen wir das Mailbox-Format auf maildir festlegen. Dazu öffnen wir /etc/postfix/main.cf und fügen ganz am Ende ein:

home_mailbox = Maildir/

das Abschließende Slash ist unbedingt notwendig.

Nun können wir User und Adressen festlegen.

neue User fügen wir hinzu mit
# useradd -m [username]
# passwd [username]

Das Adressenmapping wird über /etc/postfix/virtual_alias geregelt. So können beliebige Mail-Adressen auf beliebige User gemappt werden. Ich bekomme meine Mail also unter a.topal@abc.de oder atopal@abc.de oder abdulkadir.topal@abc.de
Wobei ich hier auch unterschiedliche Domainnamen eintragen könnte.

Die Syntax der Datei sieht wie folgt aus:

a.topal@abc.de atopal@localhost
atopal@abc.de atopal@localhost
abdulkadir.topal@abc.de atopal@localhost

Also beliebige Adresse links real existierender User rechs.

Es bietet sich hier an, einige Adressen, wie zum Beispiel root oder postmaster, auf einen unprivilegierten User zu mappen.

Nach dem Abspeichern muss die Datei noch in ein Binärformat gebracht werden mit:

# postmap /etc/postfix/virtual_alias

Jetzt müssen wir die Konfiguration noch etwas umstricken. Dazu öffnen wir /etc/postfix/main.cf

Hier entfernen wir unseren Domainnamen aus der Liste “mydestination ” und fügen nach home_Mailbox noch zwei Einträge hinzu:

virtual_alias_domains = abc.de
virtual_alias_maps = hash:/etc/postfix/virtual_alias

Außerdem können wir hier auch festlegen, wie groß die Postfächer und die einzelnen Mails werden dürfen. Ich hab kein Platzproblem und wähle:

mailbox_size_limit = 10240000000
message_size_limit = 204800000

Das ist ein Limit von 10 GB per Postfach und 200 MB pro Mail.

Jetzt abspeichern und den MTA neu starten mit
# /etc/init.d/postfix restart

Um nicht nur lokal, sondern auch per POP3/IMAP auf die Mails zugreifen zu können, installieren wir jetzt noch Courier:

#apt-get install courier-pop courier-imap

Wir verneinen die Frage nach dem Webfrontend und haben einen vollwertigen POP3-/IMAP-Server zur Verfügung.

Leider sind aber POP 3 und auch IMAP recht alte Standards und sehen vor, dass das Passwort im Klartext übertragen wird. Dem kann dadurch abgeholfen werden, dass vorher eine verschlüsselte Sitzung aufgebaut wird. Glücklicherweise ist das mit Debian extrem einfach einzurichten.

Wir intallieren erst courier-imap-ssl
# apt-get install courier-imap-ssl

Jetzt müssen wir die Datei /etc/courier/imapd.cnf anpassen, indem wir die korrekte Server-Adresse unter CN=localhost eintragen.

Dann löschen wir das alte Zertifikat /etc/courier/imapd.pem und erstellen ein neues:
# mkimapdcert

Außerdem wollen wir verhindern, dass sich Clients versehentlich ohne Verschlüsselung anmelden können. Dazu öffnen wir die Datei /etc/courier/imapd-ssl und ändern den Wert für IMAP_TLS_REQUIRED auf 1

Das war’s schon. Die Anleitung gibt es in Ausführlich auch nochmal hier. Man sollte sich allerdings bewusst sein, dass damit nur eine Verschlüsselung hergestellt wird, ohne dass die Authenzität der Gegenseite geklärt wäre. Man in the middle Attacken wären hier also nicht zu verhindern. Dazu müsste man sich ein gültiges Zertifikat von einer autorisierten CA beschaffen. Meines Wissens nach gibt es die aber noch nicht kostenlos.

Wenn es nur darum ging, Mails zu empfangen und vom Server lokal zu verschicken, dann sind wir jetzt fertig. Allerdings werden die meisten wohl lieber einen eigenen Mailclient auf ihrem eigenen Rechner benutzen. Dazu müssen wir uns authentifizieren, wenn wir über SMTP Mails versenden wollen. Hier muss man besonders vorsichtig sein. Bei einem Fehler kann man leicht zum offenen Relay werden und der Server soll ja nur unsere Mails abschicken, nicht aber fremde weiterleiten.

Bevor wir mit der Integration von Cyrus-SASL (simple authentication and security layer) beginnen können, müssen wir sicherstellen, dass einige Pakete installiert sind:

# apt-get install libsasl2 libsasl2-modules sasl2-bin

Nach der Installation müssen wir 2 Parameter einstellen in der Datei /etc/default/saslauthd

Der erste Parameter wird auf yes gesetzt, also START=yes. Außerdem verwenden wir lokale Benutzer und können auch die lokale Authentifizierung benutzen, indem wir MECHANISMS=”shadow” setzen.

Jetzt müssen wir smtpd aus dem chroot lassen. Dazu öffnen wir /etc/postfix/master.cf
Die Zeile:
smtp inet n – – – – smtpd
wird geändert in
smtp inet n – n – – smtpd

In der Spalte chroot wird also ein n gesetzt.

Damit SASL auch mit Postfix zusammenarbeitet, müssen wir die Datei /etc/postfix/sasl/smtpd.conf erstellen und ihr folgenden Inhalt geben:

pwcheckmethod: saslauthd
mech_list: PLAIN LOGIN
log_level: 3

Jetzt müssen wir noch den Benutzer postfix zur Gruppe sasl hinzufügen. Dazu einfach die Datei /etc/group öffnen und postfix hinzufügen (die ID wird sich wahrscheinlich unterscheiden):
sasl:x:45:postfix

Als letzten Schritt müssen wir noch die Postfix-Konfiguration abändern, um SASL zu berücksichtigen. Dazu öffnen wir /etc/postfix/main.cf und fügen am Ende der Datei folgendes hinzu:

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destina$
smtpd_sasl_security_options = noanonymous

Beim Einrichten der Verbindung muss man nur darauf achten dass SSL aktiviert ist.

Solange man nur lokale User verwendet, ist das Einrichten eines Mailsservers gar nicht so schwierig. Wobei ich zugeben muss, dass ich hier Spam- und Virenabwehr nicht eingebunden habe. Einerseits ist das schon recht aufwendig, andererseits bin ich nicht so der Freund von Filtern auf dem Server. Bei False negatives hab ich lokal noch eine Chance die Mails zu retten, auf dem Server ist das ausgeschlossen.

Falls man den Server aus einem Image lädt, muss man ein paar Dinge anpassen, bevor man den Mailserver nutzen kann. Zunächst sollte man den Domainnamen anpassen mit

# dpkg-reconfigure postfix

Außerdem muss in der Datei /etc/postfix/main.cf unter virtual_alias_domains die Domain eingetragen werden, für die Mails angenommen werden sollen. Dnach die Konfguration neu laden:
# /etc/init.d/postfix reload

Schließlich sollte man auch die Mappings der Mailadressen korrigieren unter /etc/postfix/virtual_alias und danach aktualisieren mit
# postmap /etc/postfix/virtual_alias

Für TLS muss zudem ein neues Zertifikat für die neue Serveradresser erzeugt werden. Dazu wechseln wir ins Verzeichenis /etc/ssl und löschen die vorhandenen Dateien in /certs und /private und legen mit folgendem Befehl die neuen Dateien an:

# openssl req -new -x509 -extensions v3_ca -keyout private/ssl-cert-snakeoil.key  -out certs/ssl-cert-snakeoil.pem -days 3650

Die Datei private/ssl-cert-snakeoil.key  muss dann noch der Gruppe ssl-cert zugeordner werden mit:

# chown :ssl-cert ssl-cert-snakeoil.key

Das war der zweite Teil. Im dritten Teil folgt das Aufsetzen eines Webservers. Verglichen mit dem Mailserver ist das aber ein Kinderspiel.

Grüße aus Whistler, Kanada

Heute ist der 4. Tag den wir hier in Whistler sind. Die Organisation war hervorragend und ich hab so viele Leute getroffen, die ich schon seit Jahren als Name kenne, aber noch nie gesehen hatte.

Es gab aber auch ein paar Überraschungen. Am zweiten Tag wurden die ersten Bären hier direkt am Hotel gesichtet. Am 3. Tag wurde der Weg nach Vancouver von einem Erdrutsch komplett zugeschüttet, sodass wir nicht mehr den kurzen Weg nehmen können, sondern einmal komplett um das Gebirge herumfahren müssen. Statt 2 Stunden Fahrt haben wir am Freitag also 8 Stunden vor uns. Heute ist der 4. Tag und heute morgen ist ein Truck in den Transformater des Hotels gefahren und hat dadurch die komplette Stromversorung des Hotels runtergezogen. Glücklicherweise hat das Hotel eine Notstromversorgung, die aber leider nicht die Badezimmer umfasst.