Linux

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 ›

Der ein oder andere schüttelt jetzt vielleicht den Kopf: „SPF? Den Mist braucht doch keiner! Macht nur Ärger!“ – Richtig, SPF ist doof. Und trotzdem verwenden große E-Mail Privider SPF, um die Herkunft von E-Mails zu überprüfen und so festzustellen, ob es sich um Spam handelt oder nicht. Mehr Informationen dazu, wieso SPF doof ist, könnt ihr euch auf der Blog-Seite von Heinlein-Support einholen: https://www.heinlein-support.de/vortrag/spf-dkim-greylisting-der-neue-spamschutz (Empfehlung!)

Für jene unter euch, die ganz einfache, simple Mailserver verwenden, kann so ein SPF-Eintrag im DNS aber trotzdem sinnvoll sein: Nicht, weil ihr SPF selbst nutzen sollt, um Spammer zu identifizieren (dafür gibt es wesentlich bessere Technik), sondern um besonders schlechte Provider wie Microsoft (Hotmail, Outlook.com) oder GMX dazu zu bringen, eure E-Mails nicht als Spam zu klassifizieren ;) Fehlt ein SPF Record in der Absenderdomain, sind sich diese Provider nicht sicher, ob sie die Mail als harmlos einstufen sollen oder nicht. In einigen Fällen landen eure E-Mails dann schnell im Spam oder werden erst gar nicht akzeptiert. Habt ihr hingegen einen einen SPF Record in eurem Zonefile, kann derjenige Provider nachsehen und wird feststellen, dass der sendende Server tatsächlich legitimiert ist, die E-Mail zu verschicken. Alles ist gut und euch wird vertraut.

Einen sehr praktischen SPF-Record Generator gibt es hier: http://www.spf-record.de

Wie in den Vortragsfolien von Peer Heinlein schon steht: Ausgehend SPF zu nutzen, schadet nicht und hilft in einigen Fällen. Nur selbst danach filtern sollte man nicht.

Ich habe meinen Beitrag zum Sammeln von Let’s Encrypt-Domainbestätigungen um einen Abschnitt erweitert: Mit einer einfachen Weiterleitung auf eine spezielle Subdomain kann man nicht nur alle Subdomains zusammenfassen, sondern auch alle Hosts. Setzt man mehrere Subdomains auf mehreren Hosts ein, ist es ganz praktisch, seine Bestätigungsdateien immer nur noch in einem Verzeichnis auf einem Hosts zu erstellen. Das erspart einem zwar leider auch nicht das Erstellen dieser Dateien, aber immerhin muss man dazu nicht auch noch auf sämtlichen Hosts eingeloggt sein.