Soziale Netze müssen niemandem gehören. Genau das ist der Reiz des Fediverse: ein Verbund unabhängiger Server, die über ein gemeinsames Protokoll miteinander reden, statt sich einer zentralen Plattform unterzuordnen. Auf meinem Lab betreibe ich deshalb unter this-is-fine.social eine eigene Mastodon -Instanz. Dieser Beitrag erklärt, warum mir das wichtig ist — und wie der Stack auf Kubernetes konkret zusammengesetzt ist.

Jedes Lab braucht ein Stück Blech, auf dem es steht. Bei mir ist das ein Turing Pi -Board — ein Mini-ITX-Träger für vier Compute-Module, den ich seinerzeit in der Kickstarter-Kampagne mitfinanziert habe. Die Idee, einen kleinen, lautlosen und stromsparenden Cluster aus austauschbaren Knoten in einem einzigen Gehäuse zu betreiben, hat mich sofort überzeugt. Diese Geschichte handelt davon, wie aus der ersten, etwas naiven Bestückung über ein paar Umwege die heutige Basis von hydra wurde.

Mal etwas, das nichts mit dem Lab zu tun hat: mein IRC-Client. Ich nutze seit Jahren WeeChat , und wie bei fast allem auf meinen Maschinen gilt auch hier — nichts wird von Hand zusammengeklickt, alles ist reproduzierbar. WeeChat samt Konfiguration kommt deshalb aus einem Home-Manager -Modul und verbindet sich ausschließlich mit meinem Bouncer.

WeeChat als Nix-Modul#

Der Client soll auf jeder meiner Maschinen identisch dastehen — gleiche Plugins, gleiche Skripte, gleiche Tastenbelegung. Genau dafür ist Nix gemacht. Mein Modul baut WeeChat über pkgs.weechat.override mit exakt den Bausteinen, die ich brauche, und nicht mehr:

1weechat = pkgs.weechat.override {
2  configure = { availablePlugins, ... }: {
3    plugins = [ (availablePlugins.python.withPackages (_ps: [ ])) ];
4    scripts = with pkgs.weechatScripts; [ autosort weechat-grep ];
5  };
6};

Das Python-Plugin und die beiden Skripte — autosort zum automatischen Einsortieren der Buffer und weechat-grep zum Durchsuchen der Logs — sind damit Teil des Build-Outputs, nicht etwas, das ich nach der Installation noch nachziehen müsste.

Vor einiger Zeit kam ich mit der - doch recht zeitintensiven - Pflege meines Mailserver-Setups nicht mehr nach und so entschloss ich mich diese Bürde in professionelle Hände abzugeben.

Natürlich vertraue ich mein - mittlerweile - recht umfangreiches E-Mail Archiv nicht jedem dahergelaufenen Provider an. Nein! Selbstverständlich muss dieser höchsten Ansprüchen genügen.

Was lag also näher, als diese Aufgabe an Posteo abzutreten - einem deutschen E-Mailanbieter mit Sitz in Berlin und zudem Arbeitgeber eines Freundes. Hauptaugenmerk dort liegt auf Sicherheit, Datenschutz und Nachhaltigkeit. Der Dienst ist zwar nicht kostenlos, aber günstig und zudem werbefrei. Selbst das Mailserver-Setup, natürlich bestehend aus Open Source Software, entspricht in etwa dem vormals von mir verwendeten. Wunderbar, also nichts wie rüber migriert!

Leider gibt es einen kleinen Haken, Posteo bietet - aus gutem - Grund keine Unterstützung für kundenspezifischen Domains an. Wie das allerdings doch möglich ist, erkläre ich nachfolgend..

Heute hatte ich nach einer BIOS-, bzw. UEFI-Aktualisierung meines Mainboards ein unerwartetes Problem; alle meine EFI-Booteinträge wurden zurückgesetzt. Selbstverständlich hatte ich kein (freies) Medium zur Hand, von dem ich entweder eine Live-Linux Umgebung oder eine EFI-Shell hätte booten können. Glücklicherweise bringen die meisten UEFIs heutzutage eine gute Unterstützung für PXE (Preboot eXecution Environment), bzw. iPXE mit. Hierfür muss dann im BIOS oder UEFI lediglich der Netzwerkstack aktiviert und der richtige Booteintrag ausgewählt werden.

PXE-Server#

Mit Pixiecore gibt es eine all-in-one Lösung, um schnell einen PXE-Server bereitzustellen. Für die Installation unter Archlinux steht ein AUR-Paket bereit.

In dem entsprechenden Artikel im Archlinux Wiki steht beschrieben, wie man den quick Parameter verwenden, um direkt den Archlinux Kernel zu laden: