Mailserver auf Open Relay testen

Wer einen eigenen Mailserver betreibt und testen möchte ob er sich nicht ein Open Relay (ein Mailserver den jeder zum Senden von Mails benutzen kann) erstellt hat, kann das ganze testen.

mailradar.com/openrelay/

mailradar.com/openrelay/

Ein solcher Test ist auf http://www.mailradar.com/openrelay/ zu finden. Er probiert verschiedene Methoden aus, um mit dem angegebenen Mailserver eine Mail zu versenden. Wenn dies in allen Fällen fehl schlägt, ist der Server sauber konfiguriert.

Selbstsigniertes Zertifikat erstellen und bei Nginx einbinden

Für verschlüsselte HTTP Verbindungen benötigt man ein Zertifikat. Dieses kann man sich von einer Zertifizierungsstelle (Certificate Authority, CA) ausstellen lassen. Der Haken an der Sache ist das dies Geld kostet (CACert und StartCom mal außen vor gelassen). Eine Alternative hierzu wäre es das Zertifikat selbst zu erstellen. Bei Diensten die man nur für einen kleinen Nutzerkreis z.B. für die Familie hostet, ist es auch vertretbar die Zertifikatswarnung im Browser über sich ergehen zu lassen. Für die Zertifikate wird ein Ordner erstellt und in diesen gewechselt:

mkdir /etc/nginx/ssl
cd /etc/nginx/ssl

Nun werden das Zertifikat und der Certificate Signing Request erstellt:

openssl genrsa -out example.key 2048
openssl req -new -key example.key -out example.csr

Bei der Erstellung des Certificate Signing Request müssen einige Daten angegeben werden:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Mecklenburg-Vorpommern
Locality Name (eg, city) []:Neubrandenburg 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Skunk works
Common Name (e.g. server FQDN or YOUR name) []:example.org
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Nun muss das Zertifikat noch signiert werden, bevor wir es verwenden können:

openssl x509 -req -days 730 -in example.csr -signkey example.key -out example.crt

In diesem Fall ist das Zertifikat 730 Tage, also zwei Jahre gültig. Da die Signierung nun abgeschlossen ist, kann das Zertifikat in Nginx eingebunden werden. Dazu öffnen wir die Datei „/etc/nginx/sites-available/example“, wobei „example“ hier natürlich für die entsprechende Konfigurationsdatei steht. Dort sollte die SSL Konfiguration vorgenommen werden:

server {
        listen 443 ssl;

        root /var/www/example/root;
        index index.html index.htm;
 
        server_name .example.org;

        ssl_certificate /etc/nginx/ssl/example.crt;
        ssl_certificate_key /etc/nginx/ssl/example.key;
}

Nach dem Aktualisieren der Konfiguration mittels:

service nginx restart

ist die verschlüsselte Verbindung für die eingerichtete Seite aktiv und kann genutzt werden.

Weitere Informationen gibt es unter:
http://nginx.org/en/docs/http/configuring_https_servers.html

Dovecot und Punkte im IMAP

Wenn man bei einen normal konfigurierten Dovecot einen IMAP-Ordner mit dem Namen „“ anlegt, wird man im Mailprogramm folgende Ordnerstruktur zu sehen bekommen:

test@example
    org

Der Grund ist darin zu finden, das der Punkt im Falle einer Maildir-Konfiguration standardmäßig als Trennzeichen eingerichtet ist. Möchte man trotzdem IMAP Ordner mit einem Punkt anlegen, so hilft das Dovecot-Plugin „Listescape“. Die Handhabung ist dabei denkbar einfach. In der „conf.d/20-imap.conf“ wird dazu die auskommentierte Zeile:

#mail_plugins =

durch

mail_plugins = listescape

ersetzt. Nun muss in der Datei „10-mail.conf“ im vordefinierten Namespace „inbox“ der Seperator neu definiert werden:

namespace inbox {
  # Namespace type: private, shared or public
  #type = private

  separator = /

  ...
}

Er darf hier nicht auf einen Punkt gesetzt werden, da das ganze sonst nicht funktioniert. Nach einem anschließenden:

service dovecot restart

können dann auch neue Ordner mit einem Punkt im Namen angelegt werden. Auf bestehende Ordner wirkt sich das ganze allerdings nicht aus. Diese müssen bei Bedarf neu angelegt werden.

WordPress mit Lastproblemen

In den letzten Tagen hatte ich mit einer WordPress Installation einige Probleme. Diese äußerten sich darin, das die Webseite bei jedem Aufruf hohe Last erzeugte. Im Laufe der Zeit wurde die Laste dabei immer größer. Irgendwann gab der Server nur noch einen HTTP 500 Error von sich. Im Backend äußerte sich das ganze mit einer weißen Seite, was im Normalfall auf zu wenig Speicher für PHP hinweist.

In diesem Fall lag das Problem an anderer Stelle. Beim Überprüfen der Datenbank stellte sich heraus das die Tabelle „wp_options“ enorm groß war. Im Normalfall ist diese Tabelle ein paar MiB groß. In meinem Fall war sie knapp 600 MiB groß und bestand aus über 500.000 Einträgen. Bei diesen Dimensionen wird klar, wohin die Performance verschwunden ist. Im konkreten Fall gab es viele „transient“ und „displayed_galleries“ Einträge. Letzte Einträge werden vom Plugin „NextGEN Gallery“ erzeugt. Die „transient“-Einträge enstehen durch Caches (unter anderem für den RSS-Feed). Möchte man die Datenbank bereinigen helfen folgende SQL Befehle:

DELETE FROM wp_options WHERE option_name LIKE ('_transient_%')
DELETE FROM wp_options WHERE option_name LIKE ('displayed_galleries%')

Anschließend sollte die Tabelle optimiert werden, damit der von den gelöschten Einträgen belegte Speicherplatz wieder freigegeben wird.

Update:
Mittlerweile gibt es auch einen entsprechenden Artikel im WordPress Forum.

Weitere Informationen gibt es unter:
http://www.staze.org/wordpress-_transient-buildup/

Nginx Server mit PHP und MySQL unter Ubuntu aufsetzen

Mittels Nginx ist ein Webserver mit PHP und MySQL in ein paar Minuten eingerichtet. Dazu installiert man unter Ubuntu folgende Pakete:

sudo apt-get install mysql-server nginx php5-fpm php5-curl php5-gd php5-imap php5-mysql

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:

server {
        listen   80;
        listen [::]:80;

        root /var/www/example.org/root;
        index index.php index.html index.htm;
 
        server_name .example.org;

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

server {
        listen   80;
        listen [::]:80;

        root /var/www/example.org/test;
        index index.php index.html index.htm index.php; 

        server_name test.example.org;

        location / {
            auth_basic "Access denied";
            auth_basic_user_file /var/www/example.org/root/.htpasswd;

            autoindex on;
        }

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

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:

ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example

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.