Nach der Installation der nötigen Pakete geht es an die grundlegende Konfiguration des Webserver:
mkdir -p /var/www/example.org/root
mkdir -p /var/www/example.org/test
cd /var/www
chown -R www-data:www-data .
usermod -a -G www-data nutzername
In diesem Beispiel soll die Domain „example.org“ sowie die Subdomain „test.example.org“ eingerichtet werden. Deshalb legen wir zwei Ordner an. Anschließend teilen wir Nginx mit, welche Domains und Subdomains der Webserver verwalten soll. Dazu legen wir die Datei „/etc/nginx/sites-available/example“ an und füllen diese mit folgendem Inhalt:
Im ersten Block wird die Domain „example.org“ definiert und konfiguriert. Durch die Notation „.example.org“ wird Nginx angewiesen, jede Subdomain welche nicht definiert ist, auf die Hauptseite umzuleiten. Für die Domain „test.example.org“ wurde außerdem ein Passwortschutz angelegt und die Verzeichnisansicht aktiviert. Damit die Konfiguration auch aktiv werden kann, muss eine symbolische Verknüpfung in das Verzeichnis „/etc/nginx/sites-enabled“ angelegt werden:
Die bestehende „default“-Datei im „sites-enabled“ Ordner enthält eine Beispielkonfiguration. Diese kann entwerder entfernt werden oder konfiguriert werden:
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /var/www/default/root;
index index.php index.html index.htm;
server_name _;
}
Mit dieser Konfiguration wird jede Seite auf Default umgeleitet, welche nicht in anderen Konfigurationen auftaucht. Nun muss nur noch der Webserver (und des PHPs Moduls) neugestartet werden:
service nginx restart
service php5-fpm restart
Ist der Server bereits online, reicht es auch die Konfiguration neuzuladen:
service nginx reload
Sollten während der Konfiguration Fehler auftreten, so hilft ein Blick in das entsprechende Log:
cat /var/log/nginx/error.log
Benötigt man eine Datenbank für die gewünschte Webanwendung, so muss diese in die SQL Datenbank eingespielt werden. Ist alles richtig konfiguriert worden, läuft der Webserver auf Port 80 und wartet auf erste Anfragen.
Möchte man einen Mailserver auf seinem eigenen Server aufsetzen, so kann man sich durch hunderte Seiten Dokumentationen wühlen. Allerdings geht das ganze auch einfacher. Für einen Mailserver benötigen wir dabei einen MTA (Mail Transfer Agent) und einen IMAP/POP3 Server. Als MTA wird in diesem Fall Postfix und als IMAP/POP3 Server Dovecot genutzt werden. Dankenswerterweise liefert Ubuntu bereits das Paket „dovecot-postfix mit, welchen nur installiert werden muss:
apt-get install dovecot-postfix
Bei der anschließenden Installation werden einige Fragen gestellt. So sollte man bei einem dezidierten Server die Konfigurationsart „Internet-Site“ wählen. In der abschliesenden Frage sollte der Domainname des Servers eingetragen werden. Dieser muss dabei nicht mit dem Domainnamen der späteren Mailadressen übereinstimmen. So könnte der Domainname „mail.example.com“ sein, während die spätere Mailadresse „“ lautet.
Mailserver schauen nach ob der Name der IP Adresse (Reverse DNS) auch zum Mailserver passt. Nutzt man zum Beispiel die IP-Adresse 192.168.10.1 und deren Reverse DNS Name lautet „mail.example.com“ so muss auch der Hostname „mail.example.com“ lauten. Den Hostnamen kann man in der „/etc/hosts“ Datei konfigurieren. Auch ein Blick in die „/etc/postfix/main.cf“-Datei lohnt sich. Der Hostname (myhostname) sollte hier der gleiche sein. Auch das Überprüfen der Option „mydestination“ ist empfohlen.
Der Mailserver soll für verschiedene Domains zuständig sein. Außerdem sollen bei diesem Setup keine Unix Accounts für die Nutzer angelegt werden, die Verwaltung der Nutzer erfolgt virtuell. Auch auf Datenbanken zur Speicherung der Nutzer wird verzichtet, da sich dies erst ab zirka 100 Domains lohnt. Im ersten Schritt wird die Datei „/etc/postfix/main.cf“ um folgende Einträge erweitert:
Postfix wird bei der Gelegenheit in Zeile 3 auch der Gruppe „vmail“ hinzugefügt. In den letzten beiden Zeilen wird der Ordner für die lokalen Mailboxen erzeugt und dem Nutzer „vmail“ zugewiesen. Danach geht es an die Konfiguration der virtuellen Mailboxen:
nano /etc/postfix/virtual_domains
In der Datei „virtual_domains“ werden die Domains festgelegt für welche das System zuständig ist. Dabei wird jede Domain zeilenweise eingetragen:
example.com
example.org
Das Mapping der jeweiligen Mailadressen zu den Mailboxen findet in der Datei „/etc/postfix/vmailbox“ statt:
nano /etc/postfix/vmailbox
Dort werden auch wieder zeilenweise die jeweilige Mailadresse zu der Mailbox zugeordnet.
example.com/webmaster
example.com/seeseekey
Die jeweiligen Pfade der Mailbox sind dabei nicht absolut, sondern setzen sich aus dem in „virtual_mailbox_base“ definierten Pfad und dem jeweiligen Mailboxpfad zusammen. Der Slash am Ende der Mailboxdefinition führt dazu das Postfix als Speicherverfahren „maildir“ anstatt „mbox“ benutzt, wobei „maildir“ vorgezogen werden sollte. Weiterleitungen von einer Mailadresse an eine andere, werden in der Datei „/etc/postfix/virtual_alias“ definiert:
Postfix benötigt einige binäre Lookuptabellen, welche nach jeder Änderung mittels:
erzeugt werden müssen. Nun muss der LDA (Local Delivery Agent) in der „/etc/postfix/master.cf“-Datei konfiguriert werden. Dieser nimmt die Mail vom MTA entgegen und speichert sie in den lokalen Mailboxen. Dazu fügen wir am Ende der Datei die Zeilen:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
hinzu. Nachdem die Mailboxen über Postfix fertig konfiguriert worden sind, geht es an die Detailkonfiguration von Dovecot. In der Datei „/etc/dovecot/conf.d/10-auth.conf“ wird die Option „#disable_plaintext_auth = yes“ auskommentiert, damit keine Klartextauthentifikation möglich ist. Am Ende der Datei kommentieren wir die Zeile:
!include auth-system.conf.ext
aus und stattdessen die Zeile:
!include auth-passwdfile.conf.ext
ein. Anschließend wird die Datei „auth-passwdfile.conf.ext“ bearbeitet. Die Datei sollte nach der Bearbeitung in etwa so aussehen:
Im nächsten Schritt wird der LDA in Dovecot konfiguriert. In der Datei „/etc/dovecot/conf.d/15-lda.conf“ ergänzen wir dem „lda“-Block so das er anschließend wie folgt aussieht:
protocol lda {
# Space separated list of plugins to load (default is global mail_plugins).
#mail_plugins = $mail_plugins
hostname = mail.example.com
postmaster_address =
auth_socket_path = /var/run/dovecot/auth-master
mail_plugins = cmusieve
}
Nun muss noch der Speicherort der Mailboxen bekanntgegeben werden. Dazu wird in der Datei „/etc/dovecot/conf.d/10-mail.conf“ die „mail_location“ von:
mail_location = mbox:~/mail:INBOX=/var/mail/%u
in
mail_location = maildir:/var/mail/vhosts/%d/%n
geändert. Um Probleme mit der Authentifikation von Postfix zu vermeiden muss die Datei „/etc/dovecot/conf.d//10-master.conf“ angepasst werden. Hier wird der Block:
unix_listener auth-master {
mode = 0666
user =
group =
}
geändert. Nach einem Neustart der Dienste:
sudo service dovecot restart
sudo service postfix restart
sollte das Mailsystem funktionieren. Ist das wider Erwarten nicht der Fall, so empfiehlt sich ein Blick in die Logdateien „/var/log/mail.err“ und „/var/log/mail.log“. Wenn die Informationen in diesen Dateien zu ungenau sind, hilft es in der Konfigurationsdatei „/etc/dovecot/conf.d/10-auth.conf“ die Optionen:
auth_verbose = yes
auth_debug = yes
zu setzen. Dadurch ist die Ausgabe wesentlich ausführlicher. Möchte man einen neuen Nutzer anlegen so erzeugt man zuerst die passende Zeile für die „passwd“-Datei im „vhosts“-Verzeichnis:
Nun muss der entsprechende Eintrag in der „/etc/postfix/vmailbox“ angelegt werden und einige Befehle ausgeführt werden:
postmap /etc/postfix/vmailbox
mkdir -p /var/mail/vhosts/example.com/info
chown -R vmail:vmail /var/mail/vhosts
sudo service dovecot restart
sudo service postfix restart
Natürlich kann man sich für das anlegen neuer Nutzer auch ein entsprechendes Skript schreiben. Nach dem Neustart der Services ist das neue Postfach eingerichtet und kann genutzt werden.
Auch im Webserver Nginx lässt sich „Basic Authentification“ einrichten. Dazu fügt man in der entsprechenden Konfigurationsdatei im Server folgenden Block hinzu:
In dem definierten Ordner wird nun eine Datei mit dem Namen „.htpasswd“ angelegt“. Dieser Datei funktioniert dabei nach dem Schema „Nutzername:Passwort“. Mittels:
openssl passwd
kann dar Passworthash für die Datei erzeugt werden. Alternativ kann das ganze auch über das „htpasswd“ Tool, welches im „apache2-utils“-Paket enthalten ist, erstellt werden:
htpasswd .htpasswd seeseekey
Die „.htpasswd“-Datei könnte dann so aussehen:
seeseekey:ppWAv1Wkrq/jg
Nach dem Neustart des Servers mittels:
sudo service nginx restart
sollte die „Basic Authentification“ funktionieren.
Seit einigen Tagen läuft diese Webseite auf einer Nginx Instanz mit einer entsprechenden PHP Konfiguration. Bei der minimalen Installation fehlen dabei einige Bibliotheken, welche von entsprechenden PHP Anwendungen benötigt werden. Konkret handelt es sich dabei um „curl“ und „gd“. Um diese auf einem Ubuntusystem nachzurüsten genügt es die Pakete „php5-curl“ und „php5-gd“ zu installieren:
sudo apt-get install php5-curl php5-gd
Im Falle von Nginx müssen dabei keine Änderungen an der Konfiguration vorgenommen werden. Nginx wird bei der Paketinstallation automatisch neugestartet.
Wie man Git auf einem Ubuntuserver aufsetzt hatte ich vor einiger Zeit in einem Artikel beschrieben. Nachteil der vorgestellten Methode ist, das sie sich nur für einen Nutzer eignet. Natürlich kann man mit dieser Methode auch mehrere Nutzer zu dem Repositories verbinden, hat damit aber keine Möglichkeit mehr Zugriffsberechtigungen für die Repositories zu setzen.
Als Lösung für das Problem wird Gitolite für die Nutzer und Rechteverwaltung genutzt. Im ersten Schritt werden auf dem Server die notwendigen Pakete installiert:
sudo apt-get install git openssh-server perl
Als nächster Schritt wird der Nutzer angelegt, in welchem Gitolite läuft und in diesen gewechselt:
sudo useradd -m git
sudo su git
Danach geht es auch schon an die Installation von Gitolite:
cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln
Anschließend muss der öffentliche SSH Schlüssel von dem Rechner mit welchem auf das System zugriffen werden soll in den Home Ordner des „git“ Nutzers kopiert werden. Anschließend kann das Setup abgeschlossen werden:
cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub
Damit ist das Setup abgeschlossen und es kann an die Konfiguration gehen. Dazu wird vom Rechner dessen Public Key beim Setup benutzt wurde das entsprechende administrative Repository geklont:
git clone git@192.168.1.128:gitolite-admin
Die Dateistruktur des Repositories sieht dabei wie folgt aus:
conf
gitolite.conf
keydir
seeseekey.pub
In dem Verzeichnis „keydir“ sind die SSH Schlüssel enthalten. Um einen Nutzer hinzuzufügen reicht es einfach einen neuen öffentlichen Schlüssel in das Verzeichnis zu legen und das ganze ins Git Repository einzubringen. Die eigentliche Konfiguration der Repositories erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeugung so aus:
Das bedeutet das es zwei Repositores gibt, eines trägt den Namen „gitolite-admin“ und dient der Verwaltung. Das zweite Repository ist „testing“ auf das alle Nutzer zugreifen dürfen. Benötigt man nun ein neues Repository, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den entsprechenden Rechten hinzu. Sobald das ganze commitet und gepusht wurde, legt Gitolite das neue Repository an. Wenn man bei den Schlüsseln mehrere SSH Schlüssel pro Nutzer wünscht, so legt man dafür am besten eine Verzeichnisstruktur an:
Möchte man ein Repository löschen so entfernt man es aus der „gitolite.conf“ und löscht es anschließend auch vom Server. Damit hat man eine Lösung für Git Server mit mehren Nutzern und und entsprechender Verwaltung.