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.
Git ist das beliebteste verteilte Versionsverwaltungssystem und in der Software-Welt allgegenwärtig. Spätestens bei komplexeren Softwareprojekten, der Arbeit in einem Team oder der Beteiligung an einem bereits bestehenden Softwareprojekt z.B. auf GitHub, sind gewisse Git-Kenntnisse Voraussetzung. In diesem Beitrag will ich auf die wichtigsten Kommandos eingehen und eine Einführung in Git geben, sodass sich auch Neulinge schnell zurechtfinden. Dabei nehme ich Bezug auf die Plattform GitHub. Selbstverständlich funktioniert die Anleitung in ganz ähnlicher Form auch mit anderen Git-Anbietern wie z.B. GitLab – einzig die URLs zu den Repositories unterscheiden sich.
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:
Nachdem gestern Abend durch einen Bug in Prosody 0.10 Nightly keine Web-Registrierung mehr für meinen Server möglich war, habe ich den Bug bei den Entwicklern gemeldet. Weniger Stunden später wurde der Fehler behoben und seit heute morgen gibt es die gefixte Version auch im Debian Repo. Die Web-Registrierung ist damit wieder möglich.
Ich bin überrascht, wie schnell auf den Bug reagiert wurde. Das Dev-Team macht einen guten Eindruck :)
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
