Rund um das Spiel Minecraft hat sich mittlerweile eine riesige Community gebildet. Das schlägt sich auch in den Werkzeugen und Anwendungen nieder, welche in irgendeiner Art mit Minecraft verbandelt sind. Eines dieser Werkzeuge ist der „JavaScript Redstone Simulator“ von Mordritch.
Der Redstone Simulator in Aktion
Dabei handelt es sich um eine Webapplikation mit welcher komplexe Redstoneschaltkreise simuliert werden können. Redstone ist dabei in etwa das Pedant zur Elektronik in der realen Welt. Die verschiedenen Elemente können auf einem Raster gesteckt werden und dann einer Simulation unterzogen werden. Auch ein Export des Ganzen ist möglich. Zu finden ist der Simulator unter http://mordritch.com/mc_rss/.
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/
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.
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:
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:
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.
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.
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.
