Mein ELK-Stack läuft in einer kleinen VM mit nur 1,4 GB RAM. Leider war das für Logstash und Elasticsearch schnell zu wenig, sodass vor allem Logstash vom System regelmäßig „gekillt“ wurde, weil kein RAM mehr verfügbar war. Logstash hat alleine schon mit über 800 MB Verbrauch zu Buche geschlagen – Elasticsearch auch nochmal mit ca. 250 – 300 MB. Zusammen mit den anderen Diensten in der VM war das zu viel. Mit wenigen Handgriffen kann man den Speicherkonsum von beiden Komponenten allerdings schnell zügeln.

Weiterlesen ›

Prosody ist ein inzwischen weit verbreiteter, moderner und meinen Erfahrungen nach zuverlässiger XMPP-Server, der durch zahlreiche Module erweitert werden kann. Geschrieben ist Prosody in der Skriptsprache Lua. Zur Installation habe ich vor 3 Jahren schon einmal eine Anleitung geschrieben. Dieser Beitrag soll die etwas veraltete Version ersetzen.

Weiterlesen ›

Bis gestern habe ich meinen trashserver.net XMPP Server unter Prosody Version 0.10 (Nightly) laufen lassen, um einige neue Module nutzen zu können, die zu früheren Zeitpunkten nur für die Nightly-Version verfügbar waren. Alle von mir verwendeten Module gibt es mittlerweile auch für die stabile Prosody Version 0.9.10, sodass ich ein Downgrade durchführen wollte, um von der stabileren Version (und weniger Updates!) profitieren zu können. Letzte Woche hatte ich bereits einen Versuch gewagt, auf die stabile Version umzusteigen. Dabei kam es jedoch zu Problemen mit der UTF-8 Codierung der Datenbank.

Weiterlesen ›

Meine Server-Backups mache ich seit vorgestern über das Tool rdiff-backup, das bereits in den Repositories größerer Linux-Distributionen liegt. Rdiff-backup kann inkrementelle Backups von lokalen oder entfernten Quellen anlegen und verfügt über eine Delta-Synchronisierung, d.h. nur geänderte Bereiche einer Datei werden tatsächlich übertragen. Das macht rdiff-backup besonders effizient und damit zum idealen Werkzeug für Server-Backups.

Weiterlesen ›

Mit einem sogenannten ELK-Stack können Server-Logfiles zentral gesammelt, analysiert und die Analyseergebnisse graphisch repräsentiert werden. Die Analyse kann z.B. Antworten auf folgende Fragen liefern:

• Wie viele Zugriffsversuche auf meine Server wurden unternommen?
• Wie viele HTTP-Requests pro Minute verarbeitet mein Webserver?
• Wirken die Anti-Spam-Maßnahmen?

Da die Logfiles zentral gespeichert werden, ist die Analyse über viele Server hinweg sehr angenehm und einfach machbar. In diesem Beitrag soll es um die Einrichtung eines solchen ELK-Stacks gehen. Verwendet werden die Elasticsearch-Produkte Filebeat, Logstash, Elasticsearch und Kibana.

Weiterlesen ›

Standardmäßig ist das Prosody Modul „mod_register_web“ (ermöglichst die Registrierung von XMPP Accounts über ein Webinterface) nicht besonders hübsch. Statt der default-Templates kann man aber auch ohne Eingriff in den Modul-Sourcecode eigene HTML-Dateien zur Gestaltung verwenden. Möglich macht das die undokumentierte Konfigurationsvariable „register_web_template“, die man in der /etc/prosody/prosody.cfg.lua nur zu definieren braucht.

Malte Kiefer hat bereits ein kleines, Bootstrap-basiertes Template geschrieben und unter einer freien Lizenz veröffentlicht: https://github.com/beli3ver/Prosody-Web-Registration-Theme
Ich habe mir ein neues Verzeichnis /etc/prosody/register-templates/ erstellt und das Template von Malte dort hineinkopiert:

mkdir /etc/prosody/register-templates/
cd /etc/prosody/register-templates
git clone https://github.com/beli3ver/Prosody-Web-Registration-Theme

In der /etc/prosody/prosody.cfg.lua wird dann einfach der Pfad zum Template angegeben:

-- Register Web Template files
register_web_template = "/etc/prosody/register-templates/Prosody-Web-Registration-Theme";

… dann noch ein Prosody Neustart:

prosodyctl restart

… und das neue Webinterface zur Registrierung sollte erscheinen.

Die trashserver.net Registrierung in einer angepassten Version

Meine Server verfügen seit ein paar Wochen über lokale, nur vom DNS Root abhängige DNS-Resolver, die auch DNSSEC beherrschen. Der Vorteil: DNS-Ergebnisse lassen sich lokal cachen und man muss weniger auf externe Infrastruktur vertrauen. Das verbessert Datenschutz und Sicherheit. Die DNS-Anfragen werden direkt an einen der DNS-Rootserver gestellt und von dort aus aufgelöst. Der kleine DNS-Resolver „Unbound“ ist perfekt als lokaler Resolver geeignet und mit wenigen Kommandos einsatzbereit:

apt install unbound

Eigentlich könnte die Anleitung an dieser Stelle schon fast zu Ende sein, denn nach der Installation horcht der Resolver lokal bereits auf Port 53 und beherrscht auch schon DNSSEC. Trotzdem sind wir noch nicht fertig, denn der Resolver bekommt jetzt noch eine aktualisierte Version des DNSSEC Root Trust Anchors:

Weiterlesen ›

Obwohl ich das WordPress Plugin „Cachify“ schon seit langem auf meinem Blog einsetze, habe ich mich bisher noch nicht besonders damit beschäftigt. Bis vor einer halben Stunde war das Plugin auf die „Datenbank“-Caching-Methode gestellt. Zusätzlich war die HTML-Komprimierung aktiv. Jetzt läuft Cachify mit Memcached und bringt eine beachtenswerte Performancesteigerung mit sich (verarbeitete Seitenaufrufe pro Sekunde):

• Ohne Cachify:         19 trans/sec
• Datenbank:             38 trans/sec
• Festplatte:               13 trans/sec (?)
• Memcached:           177 trans/sec

Etwas merkwürdig hat sich der Festplatten-Cache verhalten. Damit war der Blog sogar langsamer als ohne Cache. Da für mich ohnehin memcached als klarer Sieger feststand und eine Festplatte niemals gegen den RAM ankommt, wollte ich auch nicht lange nach der Ursache forschen. Die Memcached-Methode steht nur für Nginx-Webserver bereit. Der Grund ist u.A. hier erklärt: Cachify Caching-Methoden

Weiterlesen ›