Nach meinem Umzug nach Passau habe ich leider nicht mehr die schnelle Internetverbindung, die ich ich vorher hatte. Das betrifft vor allem den Uplink. Ärgerlich, wenn das früher genutzte NAS im Elternhaus steht, und die Bandbreite beim Hochladen über das Internet so gering ist, dass man Backupvorgänge immer wieder frustriert abbrechen muss, um überhaupt noch im Internet surfen zu können.
Um das Problem zu entschärfen, habe ich beschlossen, ein weiteres, aber deutlich kleineres NAS für meine Wohnung zu bauen. Es sollte keine Speichererweiterung darstellen, sondern lediglich Backups meines Laptops beherbergen. Im Folgenden will ich euch die Komponenten meines NAS und das Resultat vorstellen.
Ein Kunde wollte mir kürzlich bei meiner Arbeit über die Schulter schauen, um einen Serverfehler und dessen Behebung live nachvollziehen zu können. Mein erster Gedanke ging in Richtung TeamViewer und Co. Ich könnte doch meinen Desktop einfach für ihn freigeben - oder gibt es eine bessere Alternative? Bei meiner Recherche habe ich ein paar Wege gefunden, meine Kommandozeile ohne TeamViewer freizugeben.
Leider kommt der Gnome Keyring nach wie vor nicht mit ED25519-SSH-Schüsseln zurecht. Das heißt: Standardmäßig muss bei jeder Verwendung eines SSH-Keys das dazugehörige Passwort erneut eingegeben werden. Mit dem Tool “Keychain” kann der Prozess vereinfacht werden: Auf meinem Fedora-Rechner ist die Eingabe des Passworts für einen Schlüssel von nun an nur noch bei der ersten Verwendung notwendig.
Wer bereits ein Mail-System für den Versand und Empfang von E-Mails aufgesetzt hat, weiß, dass das je nach Funktionsumfang viel Arbeit sein kann. Wenn nicht nur ein Host E-Mails verschicken soll, sondern mehrere, kann es sich lohnen, einen zentralen Mailserver als “Mail-Gateway” zu nutzen. Das bedeutet: Für den Versand von E-Mails in das Internet und den Empfang aus dem Internet ist nur dieser eine Mailserver zuständig. Alle weiteren Hosts (“externe Hosts”) benötigen keine aufwendige Mailserver-Konfiguration, sondern kommen mit einer Minimalkonfiguration aus, welche es ihnen erlaubt, beim Versand auf das Gateway zurückzugreifen. DKIM, SPF und weitere Versand-spezifische Merkmale müssen dann nur auf dem Gateway eingerichtet und gewartet werden.
In meinem letzten Beitrag habe ich mein PeerVPN-Setup zur Realisierung meines Wartungsnetzes vorgestellt. Wenige Stunden später musste ich feststellen, dass ich bei meinem Setup etwas wichtiges nicht bedacht hatte: Bei einem Server-Neustart versuchen die Dienste, die nur über das Wartungsnetze 10.8.1.0/24 erreichbar sein sollen, sich an das srvnet0-Interface zu binden. Das schlägt allerdings fehl, denn der Docker-Container mit dem PeerVPN-Node startet erst wesentlich später, und die srvnet0-Schnittstelle existiert bis zu diesem Zeitpunkt noch nicht. Das wird mit Fehlermeldungen und nicht verfügbaren Diensten bestraft. Die Lösung ist, diese Dienste warten zu lassen, bis srvnet0 verfügbar ist.