Posted on Mo 05 April 2021

Wie ich von Wordpress zu Pelican gekommen bin.

Vorgeschichte

Seit ca. 2006 betreibe ich ein Wordpress Blog, erst unter der Domain k-ita.de, das war das damalige Kunstprojekt, später als Abgeordneter in einer Subdomain von morlang.eu (sehr seriöslich) und danach habe ich es nach <{static}/> gezogen.

Immer als Wordpress Blog, mit unterschiedlich vielen Plugins, was gelegentlich von Vorteil war. So habe ich bsp. eine Zeit lang meine Bilder per Blog vertwittert, statt sie bei Twitter zu hosten. Das hat auch einigermaßen gut funktioniert, da ich seit langem eine 1HE Maschine im Rack des IN-Berlin hatte. Diese verfügte über hinreichend Dampf um mein Blog, einen Minecraftserver, meine Seafile-Cloud und alles andere zu betreiben und diente mir lange als Zuhause im Internet.

Inzwischen bin ich zurück nach Hause, nach Hamburg gezogen und so was wie sesshaft geworden. Das in Berlin sinnvolle Konzept der Kombination von Notebook im Rucksack und Server im Rack, welches für mein eher nomadenhaftes Leben in Berlin super war hatte sich überlebt. Ich besitze wieder einen Desktop, habe 2 Internetanschlüsse und der Microserver hat eine USV. Es wurde also langsam Zeit, mein letztes digitales Standbein in Berlin abzubauen.

Komponenten

Nun liefen auf dem Server eine Vielzahl von Diensten, welche zu migrieren waren:

  • mail (postfix/dovecot)
  • mincraft (Spigot mit diversen Plugins)
  • Seafile (Dropbox Ersatz)
  • Wordpress
  • DNS
  • Kalender/Adressen (SoGo)
  • Wikis (verweiste)
  • eine Shellbüchse

Mail

Mail habe ich seit Ewigkeiten selbst gemacht, es fing mit UUCP an. Doch die korrekte Pflege von Mailservern wurde zunehmend zum Problem.

“If you are not paying for it, you’re not the customer; you’re the product being sold.” - blue_beetle

Ich hatte also den Plan, für Mail zu bezahlen. Außer dem sollte der Anbieter zuverlässig, vertrauenswürdig und in deutscher Jurisdiktion beheimatet. Die Firma Heinlein Support betreibt den Dienst https://mailbox.org/, ist in Pregnant Hill und gilt als guter Arbytegeber.

Die Migration von Mail war problemlos, ich musste ein paar DNS-Records anlegen und das Thema war erledigt. Meine Filterregeln hatte ich vor einigen Jahren schon von procmailrc nach Sieve migriert, daher konnte ich diese leicht portieren.

DNS

Meine Domains waren bereits auf https://www.domaindiscount24.com/, allerdings gab es keine brauchbare, mir bekannte Importfunktion. Anlass, in dem gestrubbel mal aufzuräumen.

Mit DNS und Mail erledigt konnte ich den vServer, der als secondary DNS und MX diente, schon mal kündigen.

Kalender

Da habe ich mich nicht mit Ruhm bekleckert, das SoGo ging kaputt und ich habe es nicht mehr repariert. Statt dessen wohnen meine Kalender jetzt bei Google. Nicht schön, aber funktioniert. Vielleicht ziehe ich sie noch zu https://mailbox.org um.

Minecraft

Mein Mincraftserver braucht Liebe und muss gestreichelt werden. Leider wird dies immer schwieriger, da auch die Leute, die vor Jahren die Plugins geschrieben haben inzwischen Beruf und Kinder haben und immer weniger Zeit haben. Daher wird der Zeitraum, den es braucht, bis die aktuelle Mincraftversion unterstützt ist immer größer.

Ich werde den Server in Hamburg wieder in Betrieb nehemn, wenn die Hardware hier ist. So lange wird er im Archiv schlummern.

Seafile

Seafile ist ein Dropboxartiger Clouddienst, der damals ein vielfaches schneller als Owncloud war. Außer dem in Python geschrieben, daher für mich die erste Wahl. Seafile hat bsp. mein Googledrive aufgenommen und abgelöst. Seafile werden ich vermutlich durch Nextcloud ersetzen, was auch das Kalenderthema lösen kann.

Bis dahin wird es wohl eher Syncthing werden.

Das Blog

Das/Den Blog habe ich lange vor mir hergeschoben. Fast 200 Artikel, diverse Plugins.

Ein Ansatz war, einfach für Wordpresshosting zu bezahlen. So ab 5 Euro pro Monat gibt es das. Aber Wordpress ist überholt. Oder, wie ich gerne zu anderen sage:

Das macht man heute nicht mehr so.

Will ich das zu Hause betreiben, ohne mich groß kümmern zu müssen, dann ist eine LAMPe einfach zu gefährdet, zu aufwendig und zu leistungshungrig. Statische Seiten lassen sich mit einem Raspi ausliefern, eine Kommentarfunktion ist mir nicht mehr so wichtig und lässt sich ggf. auch extern nachrüsten.

Ein static site generator sollte es also werden. Davon gibt es deutlich über 300 verschiedene.

Ich habe nach folgenden Kriterien gefiltert:

  • Es soll in Python geschrieben sein, weil ich auch anderes Sachen damit mache.
  • Es soll Jinja Templates benutzten, da ich diese schon von ansible kann.
  • Es soll einen brauchbaren Wordpress Importer haben.
  • Es soll Themes und Plugins können.
  • Es soll eine mir möglichst bekannte Sprachen benutzen, bsp. Markdown
  • Es soll von der verbleibenden Menge möglichst populär sein, so das ich im Problemfall auf möglichst viel Wissen zurückgreifen kann.

Es ist dann Pelican geworden.

Pelican

Infrastruktur

Mein Blog sollte zu Hause wohnen, auf dem Microserver. Das Offsite-backup ist ein privates Repository auf https://gitlab.com. Rendern kann ich das da, wo ich git&python habe. Deployen kann ich das per ssh, dafür habe ich einen Funktionsuser mit einer authorized_keys angelegt.

Als Webserver dient ein nginx mit letsencrypt. Auf dem OpenWrt Router musste für IPv4 zwei Portforwardings und für IPv6 zwei Firewallrules eingerichtet werden.

Import

Ich habe mit ein Wordpress-export XML aus der Adminoberfläche meiner Wordpress Instanz gezogen.

Nach dem Anlegen des Projektes mit Hilfe von pelican-quickstart konnte ich mit

pelican-import --wpfile -m markdown  --dir-page    --wp-attach <export.xml>

den Import starten.

Ich wollte Markdown, also -m markdown, die "Seiten" sollten separat, dafür --dir-page und mit --wp-attach hat es alle Attachments, Bilder, etc. runtergeladen.

Dann hagelte es Fehlermeldungen, pelican beschwerte sich darüber, das diverse ALT-Tags nicht gesetzt waren. Finde ich gut, da diese ein Merkmal von Barrierearmut sind, da soll mich die Software gerne drauf hinweisen.

Außer dem waren alle Attachments von den "Seiten" im falschen Verzeichnis, dies ließ sich recht einfach durch verschieben der Dateien lösen.

Auch ist aufgefallen, das einige Dateien bei der letzten Migration verloren gegangen sind, andere waren auf Hosts, die schon seit 10 Jahren nicht mehr existent sind.

Auch gibt es (immer noch) einige fehlerhafte Formatierungen, die sich aber meist schnell fixen lassen, git grep zeigt, ob es noch mehr gibt und sed -i bringt das dann in Ordnung.

Damit war es inhaltlich schon so gut wie fertig (Also quasi nur noch 5 Minuten).

Themes

Das war das schlimmste Thema, es hat mich bestimmt ein Jahr davon abgehalten, das Blog anzufassen. Ich musste eine Entscheidung treffen! Keine technische! PANIC!

Die Pelican Themes Seite hat es nicht einfacher gemacht.

Ich habe das Thema dann einfach nach ganz hinten verschoben, was die einzig richtige Entscheidung war. So konnte ich die Themes an meinem eigenen Content testen, was deutlich besser ist als mit Screenshots. Also, nicht, das es für alle Themes Screenshots gab.

Also habe ich als erstes alle Themes und Plugins eingesammelt:

git submodule add -f https://github.com/getpelican/pelican-themes.git theme
git submodule add -f https://github.com/getpelican/pelican-plugins.git plugins
git submodule update --init --recursive

Dann make devserver in einem Fenster und

for bla in theme/*; do
    pelican-themes -s $bla
    sed -i '$ s/^THEME.*/THEME = "'$(echo $bla|sed 's/\//\\\//')'"/' pelicanconf.py
    echo $bla
    read foo
done

in einem anderen Fenster und ich konnte mir alle Themes anschaun, welche ohne Anpassungen liefen. Diese habe ich in themes geschrieben und konnte danach dann mit

for bla in $(grep -v '^#' themes |cut -f 1 -d ' '); do
sed -i '$ s/^THEME.*/THEME = "'$(echo $bla|sed 's/\//\\\//')'"/' pelicanconf.py
echo $bla
read foo
done

so lange durch iterieren, bis ich eins hatte.

Dies verlange noch einige kleine Anpassungen (Bilder und Farben) und schon war der Tresor offen.

Fazit

Es lohnt sich. (für mich).

  • Ich muss jetzt nur noch handeln, wenn nginx kritische Sicherheitslücken hat, TLS Versionen und Cyphers werden von certbot gemanagt.
  • Die Anforderungen an den Server sind minimal, ein NAS würde in Zukunft reichen. Oder der Rock64, den ich noch liegen hab. Also deutlich unter 10 Watt, wenn es sein muss. Oder halt klassisches Webhosting.

ToDo

  • Eine kleine CICD Pipeline, die mit einem Push in den richtigen Branch deployed, so das ich keine make ssh_upload mehr eingeben muss.
  • Irgendwo im Internet einen kleinen haproxy, der als Endpunkt im Internet die Verbindungen annimmt und die dann über beide Internetanschlüsse rein reicht. Allerdings muss ich dann das IPv6 Multihoming zusammen mit dem OpenWrt Mwan3 verstehen und umsetzen.