Ich bin erst Anfang 2016 auf servercow.de aufmerksam geworden. Dein Unternehmen gibt es aber schon länger. Wann hast du entschlossen, selbst Hoster zu werden? Was waren Deine Beweggründe?
Durchstarten wollte ich im Bereich der IT-Beratung, denn da bin ich groß geworden. Hosting war ein Teil davon, dennoch kam der Anstoß zum Hoster erst durch einen ehemaligen Partner. Ich neige die Billig-Hoster Methoden grundsätzlich ab und bin auch kein Freund des Marketings und damit einhergehenden Floskeln. Ich bin sehr penibel in Bezug auf Sicherheit und Datenschutz. Das Genannte gepaart mit Verantwortungsbewusstsein ergab letztendlich Servercow. :-) Das Image der kleinen Hoster ist schlecht, oft gar nicht unberechtigt. Das Motto ist „Software XY kaufen, Server vermieten und Geld verdienen“. Es laufen kritische Dienste völlig unbeeindruckt offen im Internet, vielleicht sogar veraltet und angreifbar. Unsichere TLS-Cipher und Protokolle sind oft Standard.
Das sind nur die negativen Beispiele, versteht sich. Es gibt auch viel Positives! Aber das wären dann keine Beweggründe für Servercow mehr. :-) Mir ist es lieber, die Kunden finden durch Hörensagen zu Servercow. Mir ist der Ruf des kleinen unscheinbaren Betriebes lieber. Ich käme nicht auf die Idee einen Kunden zu binden, der nicht zufrieden ist. Da haben beide Parteien nichts von.
Seit Vorgestern setze ich für meine Serverbackups „Borg Backup“ ein. Zuvor habe ich Sicherungen über rdiff-backup erstellt; jetzt wollte ich einmal etwas neues ausprobieren. Mike Kuketz hat das Tool in seinem Blog kurz erwähnt, also habe ich es mir mal angesehen und eingerichtet. Besonders gut gefällt mir an Borg Backup, dass es schnell und effizient arbeitet. Indem die zu übermittelnden Daten zu „Chunks“ zusammengefasst werden und Dateien nicht einzeln übertragen werden, kann man einen Delta-Mechanismus anwenden, der bei Änderungen an Dateien nur die geänderten Bits überträgt. Die Einrichtung und Bedienung ist schlicht gehalten und lässt eigentlich keine Wünsche offen.
Es gibt wenig Software, von der ich sofort überzeugt bin. Netdata gehört aber definitiv dazu: Das 2013 gestartete Projekt hat sich auf die Fahnen geschrieben, eine möglichst einfache Lösung für Realtime-Monitoring von Linux-Servern anzubieten. Lösungen zur Echtzeitüberwachung von Servern gibt es zu genüge: Mal mit hübschem Webinterface, mal mit weniger benutzerfreundlicher Oberfläche. Zu Netdata kann ich sagen: Hier wurde aus meiner Sicht wirklich alles richtig gemacht. Warum? Darum:
Einfache, gut strukturierte Weboberfläche
Keine Konfiguration notwendig: Installieren und los geht’s!
Im Frühjahr 2014 habe ich meine erste ausführliche Anleitung zur Einrichtung eines einfachen Mailservers mit Postfix und Dovecot auf diesem Blog veröffentlicht. Viele Leser sind so erfolgreich zu ihrem privaten oder geschäftlichen Mailserver gekommen. Nachdem nun zwei Jahre vergangen sind und sich mittlerweile auch mein eigenes Setup geändert hat, will ich euch mit diesem Beitrag eine neue, aktualisierte Anleitung für einen Mailserver mit erweiterten Funktionen vorstellen.
Diese Anleitung wurde mehrmals im Ganzen auf einem neu installierten Ubuntu Server getestet und für funktionierend befunden. Solltest du dennoch einen Fehler finden oder einen Verbesserungsvorschlag haben, schreib‘ mir an: mailserver [ett] thomas-leister.de
Am Ende dieser Anleitung werdet ihr einen robusten Mailserver mit Spam-Abwehrmechanismen und weiteren Extras vor euch haben, den ihr so direkt verwenden und auf das Internet loslassen könnt. Außerdem liegt mir etwas daran, die grundlegende Funktionsweise des Mailsystems zu erklären, sodass ihr versteht, was Schritt für Schritt eingestellt wird. Ich betreibe selbst erst seit wenigen Jahren einen eigenen Mailserver und hätte mir zu Anfangszeiten gewünscht, zu verstehen, was ich da eigentlich konfiguriere. Wer einfach nur schnell zu einem Ergebnis kommen will, kann die Erklärungen natürlich überspringen und einfach nur Schritt für Schritt die Anweisungen befolgen. Ich rate aber trotzdem, sich mit dem Thema zumindest grundlegend auseinanderzusetzen: Wenn ein gewisses Verständnis vorhanden ist, können künftige Erweiterungen und Änderungen an der Software einfacher durchgeführt werden.
Tipp: Wer statt auf Handarbeit lieber auf eine fertige Lösung setzt, sollte sich einmal Mailcow ansehen.
Der ein oder andere überlegt sich vielleicht, auch seinen eigenen Mailserver zu betreiben. Wann ist das überhaupt sinnvoll? Was spricht dagegen? In diesem Beitrag will ich auf diese Fragen eingehen und erklären, warum ich hauptsächlich, aber nicht nur auf eigene Mailserver setze.
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.
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.
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.
