Da meine Bedürfnisse an einen Webserver eher minimal sind, habe ich mich gegen den Apache und für lighttpd entschieden. Hinzu kommt der reduzierte Ressourcenbedarf von lighttpd, was ihn wesentlich attraktiver macht.

lighttpd installieren

Die Installation ist unter Debian gewohnt einfach

sudo aptitude install lighttpd

was folgende Pakete mitinstalliert

libfam0 libterm-readkey-perl libterm-readline-perl-perl

lighttpd konfigurieren

Um später die Weiterleitung nutzen zu können, aktivieren wir die Module rewrite und redirect in /etc/lighttpd/lighttpd.conf durch entfernen der Rautezeichen. Das ganze sieht dann wie folgt aus:

server.modules              = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_compress",
            "mod_rewrite",
            "mod_redirect",
#           "mod_evhost",
#           "mod_usertrack",
#           "mod_rrdtool",
#           "mod_webdav",
#           "mod_expire",
#           "mod_flv_streaming",
#           "mod_evasive"
)

virtuellen Host einrichten

Lighttpd unterstützt mehrere (Sub-)Domains. Das ist besonders dann von Interesse, wenn man mehrere Webseiten auf einem Server betreiben will. Uns interessiert erst einmal nur der einfache Fall mit einer Domain. Dazu legen wir zunächst ein Verzeichnis an, welches später die Website beherbergen soll.

sudo mkdir -p /var/www/example/www
sudo chown www-data:www-data /var/www/example/www/

Danach hängen wir folgende Zeilen an /etc/lighttpd/lighttpd.conf an:

$HTTP["host"] =~ "^(www\.)?example\.com$" {
        server.document-root = "/var/www/example/www"
}

Der reguläre Ausdruck sorgt dafür, dass unsere Webseite sowohl mit als auch ohne Prefix www erreichbar ist. Anschließend starten wir lighttpd neu.

sudo invoke-rc.d lighttpd restart

SSL

Um später auch Passwörter vernünftig übertragen zu können bietet sich eine verschlüsselte Kommunikation mit SSL an. Dazu benötigt der Server ein signiertes Zertifikat. Die Erzeugung eines solchen ist leider etwas aufwändiger. Doch bevor wir loslegen, muss, falls nicht vorhanden, openssl installiert werden

sudo aptitude install openssl

und ein Schlüsselpaar erstellt werden.

openssl genrsa -out example.com.key 2048

Um ein Certificate Signing Request (CSR) zu erstellen, nutzen wir den (soeben) erstellten (öffentlichen) Schlüssel

openssl req -new -key example.com.key -out example.com.csr

Als Common Name (CN) geben wir die Adresse des Servers an für den das Zertifikat ausgestellt werden soll, für unser Beipiel also www.example.com.

Da selbstsignierte Zertifikate immer zu Fehler- /Warnmeldungen im Browser führen, bietet sich StartSSL an. Deren Wurzelzertifikat ist in den gängigen Browsern bereits installiert und für unsere Zwecke (Zertifikat für einen Webserver ohne Subdomains) ist der Dienst kostenlos. Beginnend mit dem Punkt "Express Lane" erzeugen wir zunächst ein SSL-Clientzertifikat für die Authentifizierung bei StartSSL und anschließend das SSL-Serverzertifikat. Als Domain geben wir nur example.com an, der Prefix wwww wird automatisch ergänzt. Die Generierung des Schlüsselpaares für das Serverzertifikat sollte man überspringen und das eigene zuvor erstellte verwenden. Das fertige Serverzertifikat wird uns als Base64-codierter Text präsentiert, den wir unter example.com.crt abspeichern.

Da lighttpd nur Zertifikate im PEM-Format unterstützt, müssen wir das CRT-Zertifikat vorher konvertieren. Dies geschieht einfach durch Hinzunahme unseres Schlüssels mittels

cat example.com.crt example.com.key > example.com.pem

Jetzt kopieren wir das Zertifikat noch an die richtige Stelle, bspw. /etc/lighttpd/ssl

sudo mkdir /etc/lighttpd/ssl
sudo cp example.com.pem /etc/lighttpd/ssl/
sudo chmod 400 /etc/lighttpd/ssl/example.com.pem

Für einen reibungslosen betrieb muss der Webserver das Intermediate-Zertifikat (IM) von StartSSL ausliefern, mit dem unser SSL-Serverzertifikat unterschrieben wurde. Dazu laden wir zunächst die benötigten Zertifikate herunter, vereinen diese und speichern sie ebenfalls unter /etc/lighttpd/ssl ab.

wget -c https://www.startssl.com/certs/sub.class1.server.ca.pem
wget -c https://www.startssl.com/certs/ca.pem
cat ca.pem sub.class1.server.ca.pem > ca-certs.crt
sudo cp ca-certs.crt /etc/lighttpd/ssl/
sudo chmod 400 /etc/lighttpd/ssl/ca-certs.crt

Nun bleibt uns nur noch SSL in lighttpd zu aktivieren. Dazu editieren wir die Datei /etc/lighttpd/lighttpd.conf und ergänzen vor dem virtuellen Host folgende Zeilen:

## redirect all hosts to their secure equivalents
$SERVER["socket"] == ":80" {
        $HTTP["host"] =~ "(.*)" {
                url.redirect = ( "^/(.*)" => "https://%1/$1" )
        }
}

## enable ssl
$SERVER["socket"] == ":443" {
        ssl.engine = "enable"
        ssl.ca-file = "/etc/lighttpd/ssl/ca-certs.crt"
        ssl.pemfile = "/etc/lighttpd/ssl/example.com.pem"
}

Sobald mehrere Leute an einem Dokument arbeiten wollen oder man eine Dokumentenhistory braucht, ist eine Versionsverwaltung Gold wert. In der Vergangenheit war ich immer auf das Wohlwollen eines Freundes angewiesen um Zugriff auf einen SVN-Server zu bekommen. Da ich mittlerweile einen eigenen vServer habe, will ich die Gelegenheit nutzen und auf git umsteigen. Da git eigentlich auf eine verteilte Struktur aufsetzt, ist ein eigenständiger Server nicht unbedingt nötig, erleichtert aber den Datenaustausch bei mehreren Nutzern. Um nicht für jeden Git-Nutzer einen vollwertigen Systemaccount anlegen zu müssen, kommt zusätzlich gitosis zum Einsatz.

Server konfigurieren

Auf Serverseite benötigen wir zu git-core noch gitosis. Was wir durch

sudo aptitude install git-core gitosis

schnell erledigt haben. Dabei werden zusätzlich noch folgende Pakete mitinstalliert

libcurl3-gnutls libdigest-sha1-perl liberror-perl patch python-central
python-pkg-resources python-setuptools python-support rsync

Da eine Anmeldung mittels Passwort unerwünscht ist, brauchen wir zur Anmeldung ein öffentliches Zertifikat. Je nachdem unter welchem Account (Rechner) man später gitosis administrieren will, wählt man die id_rsa.pub aus. Diese findet man in ~/.ssh. Sollte dies nicht der Fall sein, kann einfach mittels

ssh-keygen -t rsa

ein Schlüsselpaar erzeugt werden. Die Initialisierung des Administrationsrepository erfolgt dann mittels

sudo -H -u gitosis gitosis-init < id_rsa.pub

, was uns auch bestätigt wird

Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

Das Administrationsrepository gitosis-admin lässt sich nun einfach klonen mittels

git clone gitosis@example.com:gitosis-admin.git

Sollte der Zugriff per ssh nur bestimmten Nutzern erlaubt sein (was sich z.B. durch eine Passwortabfrage bemerkbar macht), muss die /etc/ssh/sshd_config entsprechend um den Nutzer gitosis erweitert werden, also bspw.

AllowUsers user gitosis

Nach einem Neustart des SSH-Servers durch sudo invoke-rc.d ssh restart sollte der Zugriff auf gitosis-admin gelingen.

Repository anlegen

Um ein neues Repository anzulegen, editiert man die gitsois.conf im Administrationsrepository und erweitert sie um folgenden Block.

[group project-team]
members = user1 user2
writable = project

Damit hat man das Repository project für die Nutzer user1 und user2 angelegt. Damit diese auch tatsächlich Zugriff erhalten, müssen deren öffentliche Schlüssel im Ordner keydir liegen. In unserem Fall sind dies die Dateien user1.pub und user2.pub. Anschließend die Änderungen mittels

git commit -a -m "Repo project fuer user1 und user2 erstellt"
git push

auf den Server übertragen und der administrative Teil ist erledigt.

user1 oder user2 hat nun die Möglichkeit das Repository zu initialisieren und hochzuladen, was wie folgt aussehen kann:

mkdir project
cd project
git init
git remote add origin gitosis@example:project.git
git config branch.master.remote 'origin'
git config branch.master.merge 'refs/heads/master'
echo "Kurze Projektbeschreibung" > .git/description

# Dateien editieren, committen ...

git push origin master:refs/heads/master

Nutzer hinzufügen

Um einen Nutzer hinzuzufügen wird dessen öffentlicher Schlüssel benötigt. Für Benutzer hans auf Maschine host wird bspw. die id_rsa.pub in hans@host.pub umbenannt, nach <code>gitosis-admin/keydir kopiert und dem Repository hinzugefügt. In Kurzform

mv id_rsa.pub gitosis-admin/keydir/hans@host.pub
git add gitosis-admin/keydir/hans@host.pub

Nun muss noch die gitosis.conf entsprechend angepasst werden. Angenommen hans möchte am Projekt project mitarbeiten, sieht das dann in etwa so aus

[group project-team]
members = user hans@host
writable = project

Nach einer Übertragung mittels

git commit -a -m "Nutzer hans hinzugefuegt"
git push

kann hans das Repository mittels

git clone gitosis@example.com:project.git

auschecken.

Client konfigurieren

Auf Clientseite bleibt eigentlich nur die Installation von git-core. Damit beim Commit der korrekte Name und die Mailadresse angezeigt wird, sollt man

git config --global user.name 'Hans Mustermann'
git config --global user.email 'hans@example.com'

ausführen. Weiterhin empfiehlt sich noch das Ändern weiterer Variablen um sich die Arbeit etwas schöner zu machen:

git config --global color.diff auto
git config --global color.branch auto
git config --global color.interactive auto
git config --global color.status auto
git config --global core.editor vim
git config --global merge.tool vimdiff

Links

• Git Homepage
• Git Community Book
• Git Manual
• git ready
• Why Git is Better Than X

Irgendwann kommt das Bedürfnis nach einen eigenem Mailserver. Als MTA habe ich mich für exim4 entschieden und dovecot macht den MDA (auch wenn dieser eigentlich nicht benötigt wird).

Exim4 installieren

Die Installation ist unter Debian gewohnt einfach

sudo aptitude exim4

, wobei folgende Pakete installiert werden

bsd-mailx{a} exim4 exim4-base{a} exim4-config{a} exim4-daemon-light{a} libpcre3{a} mailx{a} psmisc{a}

Auch die anschließende Konfiguration mittels

sudo dpkg-reconfigure exim4-config

gestaltet sich nicht wesentlich komplizierter. Einfach dem Dialog folgen und die entsprechenden Werte einsetzen. Für meinen Server mit fester IP sieht das dann wie folgt aus:

type of mail configuration:

internet site

system mail name:

example.com Wenn man sich unsicher ist, kann man sich seinen Hostnamen auch mittels hostname -f anzeigen lassen. Dieser sollte in /etc/hosts definiert und in /etc/hostname gesetzt sein. Um den Hostnamen nur temporär zu setzen reicht ein sudo hostname example.com.

IP-addresses to listen:

(empty)

recipient domains:

example.com Bei Bedarf können auch mehrere durch Semikolon getrennt angegeben werden.

domains to relay:

(empty)

machines to relay:

(empty)

keep number of DNS-queries minimal:

NO

delivery method for local mail:

Maildir in home dir

split configuration in small files:

YES

root and postmaster mail recipient:

$USER

TLS aktivieren

Die benötigten Zertifikate sind schnell durch

sudo usr/share/doc/exim4-base/examples/exim-gencert

erzeugt. Das Aktivieren geschieht dann durch Anlegen einer Datei bspw. /etc/exim4/conf.d/main/00_exim4-config_localmacros mit folgenden Inhalt:

# Enable TLS support for Exim
MAIN_TLS_ENABLE = true

Nach einem Neustart von Exim mittels sudo invoke-rc.d exim4 restart sind wir auch schon fertig.

Konfiguration testen

Zunächst kann man sich mit telnet davon überzeugen, dass der MTA ordentlich läft.

telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 example.com ESMTP Exim 4.69 Fri, 02 Oct 2009 13:14:00 +0000
help
214-Commands supported:
214 AUTH STARTTLS HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
quit
221 example.com closing connection
Connection closed by foreign host.

Wenn wir uns auf Port 25 einloggen, sollte sich Exim ordentlich melden. Bei Eingabe von help sollte STARTTLS als unterstützes Kommando auftauchen. Ist dies nicht der Fall, ist bei der Aktivierung von TLS irgendetwas schief gegangen. Abschließend trennen wir die Verbindung mit quit.

Die erste Testmail an user mit "test" im Betreff schickt man sich einfach mittels

mail -s "test" user
bodytext
^D
Cc:

Spätestens jetzt sollte auch der Ordner Maildir im Homedirectory liegen und man kann auf die Mails bspw. mit mutt zugreifen.

Weiterleitung (Aliase) einrichten

Möchte man E-Mails nicht nur unter seinem Unix-Account empfangen, empfiehlt es sich Aliase in /etc/aliases anzulegen. Angenommen Hans Mustermann mit dem Account hmuster will auch unter seinem Realnamen Mails empfangen, müssen folgende Zeilen hinzugefügt werden:

hans: hmuster
mustermann: hmuster
hansmustermann: hmuster
hans.mustermann: hmuster

Dovecot installieren

Will man seine Mails auch per IMAP abrufen, muss man sich noch einen MDA installieren. Ich habe mich für Dovecot entschieden, was gewohnt einfach geht. Der Befehl

sudo aptitude install dovecot-imapd

installiert dabei folgende Pakete

dovecot-common{a} dovecot-imapd libldap-2.4-2{a} libmysqlclient15off{a} libpq5{a} mysql-common{a}

.
Die unterstützten Protokolle habe ich in /etc/dovecot/dovecot.conf durch

protocols = imaps

auf verschlüsseltes IMAP reduziert. Die dafür benötigten Zertifikate setzt man durch
Entkommentieren von

ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

Das Arbeiten auf entfernten Maschinen ist dank ssh auf unixartigen Systemen überhaupt kein Problem. Für die unartigen Betriebssysteme gibt es zur Not putty ;). Jedoch kann man sich das Leben mit der richtigen Konfiguration noch ein bisschen erleichtern.

Konfiguration

Auch wenn /etc/ssh/sshd_config standardmäßig gut aus sieht, sollte man noch ein paar Zeilen ergänzen. Zunächst sollte man verbieten, dass sich root einloggen darf

PermitRootLogin no

und auch sonst möchte man vielleicht nur bestimmten Nutzern Zugriff auf den ssh-Dienst geben

AllowUsers ich du er sie es

Da mir immer irgendwer (FritzBox?) die Leitung bei Inaktivität trennt, empfiehlt sich zusätzlich das Setzen von

ClientAliveInterval 20

Login ohne Passwort

Zunächst erstellt man sich auf Clientseite ein Schlüsselpaar mittels

ssh-keygen -t rsa

Die Nachfrage nach dem Passwort lässt man leer (Enter drücken). Der private Schlüssel befindet sich anschließend in ~/.ssh/id_rsa und der öffentliche Schlüssel ist in ~/.ssh/id_rsa.pub. Nun muss der öffentliche Schlüssel noch auf dem Host an die ~/.ssh/authorized_keys angehangen werden. Am einfachsten geht das mittels

ssh-copy-id -i ~/.ssh/id_rsa.pub $user@$host