Gerade habe ich ein PHP-Update auf meinem OwnCloud-Server durchgeführt. Nach dem Update wollte die Cloud nicht mehr und hat mir nur eine leere Seite angezeigt. Die Logs waren mir auch keine Hilfe, denn die wurden nicht beschrieben. Keine Fehlermeldungen – einfach nur eine leere Seite.
Nachdem ich die OwnCloud-Konfiguration verschoben habe wurden mir im Installer eine Menge fehlender PHP-Module angezeigt, die bei dem Update wohl irgendwie zerstört oder deinstalliert wurden. Nachdem ich dann ein paar Module installiert hatte, war auf einmal sogar php-fpm spontan verschwunden. Ich weiß bis jetzt nicht, was da mysteriöses vor sich gegangen ist, jedenfalls habe ich PHP dann komplett neu installiert. Jetzt funktioniert wieder alles.
Das nur als Tipp, falls jemandem ähnlich merkwürdiges zustößt.
Das Blog „Digitales Echo“ hat soeben den aktuellen XMPP Servercheck veröffentlicht und präsentiert in einem Blogbeitrag die 15 besten XMPP-Server im deutschsprachigen Raum. „Die besten“ heißt hier: Besonders sicher und Datenschutz-freundlich. Voraussetzung für die Aufnahme in die Liste ist ein Doppel-A-Ranking auf xmpp.net – dazu kommen weitere Bewertungskriterien, die im verlinkten Beitrag erklärt sind. Auch mein trashserver.net ist in der Liste vertreten und schneidet mit einem „exzellent“ ab, was mich natürlich besonders freut. Seht euch die Liste einmal an – vielleicht wollt ihr ja zu einem anderen XMPP Server wechseln?
Vor einigen Wochen habe ich hier im Blog die langsame Reaktionszeit und sogar Nicht-Erreichbarkeit von GitLab, einer GitHub-Alternative, beklagt. Die offizielle, kostenlose GitLab-Instanz habe ich für private Repositories genutzt, weil GitHub solche Repos nicht kostenlos anbietet. Ich habe damals überlegt, mir eine eigene GitLab-Instanz zu hosten (schließlich ist die Community Edition von GitLab freie Software) – allerdings hat mich der hohe Ressourcenverbrauch von der Installation abgehalten.
In den Kommentaren wurde mir eine schlankere Alternative zu GitLab vorgeschlagen: Gogs.
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.
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.
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.
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:
Kürzlich habe ich euch gefragt, welchen Hoster ihr mir empfehlen könnt. Meine Anforderungen waren:
KVM-Virtualisierung
100% Ökostrom
Kompetenter und schneller Support
Gute Verfügbarkeit
Mindestens 100 MBit/s Upstream
Gutes Preis- / Leitungsverhältnis
Flexible, individuelle Anpassung der Serverressourcen
Eigene Images nutzbar
Unternehmens- und Serverstandort Deutschland
In den Kommentaren zu dem Beitrag wurde mir unter anderem Servercow.de vorgeschlagen. Ich habe mich ein wenig auf der Webpräsenz des Unternehmens umgesehen und war ziemlich schnell interessiert. Alle meine Anforderungen waren erfüllt und ich habe mir zunächst einen Testserver bereitstellen lassen, den ich nun auch fest gebucht habe. Hier will ich euch von meinen ersten Eindrücken und Erfahrungen mit Servercow.de erzählen.
