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:
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.
Der User piarm74eodkxs hat einen Chatroom für Diskussionen zu diesem Blog erstellt. Da er schon der zweite User ist, der mich auf einen „Blog-Chatroom“ angesprochen hat, gehe ich mal davon aus, dass es anscheinend Bedarf gibt ;) Jedenfalls findet ihr den von ihm moderierten Chatroom unter bloggeflüster@conference.trashserver.net. Schaut doch mal rein! Natürlich darf auch zu jedem anderen Blog / Blogpost oder Thema diskutiert werden.
