Wechsel von WordPress zu Hugo

Seit 9 Jahren blogge ich mit WordPress auf diesem Blog. Auf meinem zweiten Blog, christoph.miksche.org blogge ich seit 7 Jahren mit WordPress. Zudem habe ich seit 2013 ebenfalls immer wieder eine Plattform (WebPage4.me) zum Erstellen eines eigenen WordPress-Blog betrieben und auch beruflich habe ich immer wieder WordPress Websites verwaltet.

Ich habe also eine ziemlich tiefe Beziehung mit WordPress. Allerdings habe ich in den letzten Jahren seit 2017 unter blog.m5e.de einen Blog ausschließlich mit statischen Generatoren betrieben. Hierbei war ich mit Jekyll zwar nicht so super zufrieden aber Hugo ist dafür wunderbar.

Nun will ich meinen zweiten Blog auf Hugo migrieren. Meine Hauptgründe dafür sind:

  • WordPress ist langsamer als Hugo
  • WordPress ist unsicherer als Hugo
  • WordPress benötigt mehr Aufwand (z.B. Aktualisierungen, …)
  • WordPress Hosting ist teurer und aufwändiger (da PHP und eine Datenbank benötigt wird)
  • Gerade bei Shared-Hosting kommt es öfter zu Problemen mit WordPress

Der letzte Punkt ist der heftigste. Denn ich habe mir z.B. für automatische Updates bei Shared-Hosting Anbietern, die keine automatischen Updates via JS möglich machen, ein Skript geschrieben: https://github.com/CMiksche/wp-remote-updater

Auch für automatische Backups habe ich ein Skript geschrieben: https://git.kernel.fun/cmiksche/php-sharedhost-backup

Trotz dieser beiden Skripte bleiben aber bei Shared-Hosting-Anbietern weitere Probleme. Aktuell funktioniert z.B. der Gutenberg-Editor bei meinem zweiten Blog nicht. Auch Updates von Plugins usw. müssen dort manuell gemacht werden, weil der Hosting-Anbieter anscheinend keine JS-Verbindungen zu WordPress zulässt.

Es gibt sogar einige Anbieter wie HelioHost, welche aktiv von dem Betreiben eines WordPress-Blogs auf der eigenen Plattform abraten. (Dieser Anbieter deaktiviert anscheinend sogar Kundenaccounts, deren WordPress-Instanz zu hohe Auslastungen haben)

Bei diesem Blog (blog.wronnay.net) und auch bei WebPage4.Me habe ich dieses Problem zwar nicht, weil ich die beiden Seiten auf eigenen Servern betreibe, allerdings will ich auch noch Online-Präsenzen haben, wenn mein Server mal ausfällt und deshalb setze ich bei meinem zweiten Blog auf einen anderen Anbieter.

Diese ganzen Probleme habe ich mit einer statischen Website aber nicht. Für statische Websites gibt es unzählige kostenlose Anbieter, statische Websites sind viel schneller und leichter umzuziehen. Typischerweise ist der größte Vorteil von WordPress zwar, dass man online von überall seine Beiträge schreiben kann und auch mehrere Autoren möglich sind aber alle meine aktuellen Blogs werden nur von mir geschrieben und es gibt auch Lösungen für statische Blogs, die das gleiche möglich machen.

Bei mir kommt dann noch hinzu, das ich als Softwareentwickler seit Jahren sehr gerne Markdown schreibe und meine Projekte in Git verwalte. Dies gibt es bei statischen Generatoren „out of the Box“ und ich fühle mich in so einer Umgebung richtig wohl.

Deshalb möchte ich nun versuchen, meinen persönlichen Blog (christoph.miksche.org) auf Hugo umzuziehen. Dieser Umzug wird vermutlich etwas aufwendig sein, da ich z.B. dort auch ein custom Theme verwende, allerdings werde ich danach unabhängiger von Hosting-Anbieter sein und muss mir keine Sorgen mehr machen, dass ein Update irgendwas kaputt macht.

Das Exportieren der Daten von WordPress

Bevor man irgendwas mit Hugo macht, sollte man die Daten von WordPress exportieren.

Für Hugo gibt es z.B. WordPress Plugins wie wordpress-to-hugo-exporter, dieses hat bei meinem Hoster aber leider wegen einer Zeitüberschreitung bzw. Netzwerkfehlers nicht geklappt.

Es gibt auch den wordpress-to-jekyll-exporter, den man nach dem Export dann mit dem Jekyll Importer von Hugo importieren könnte, allerdings war ich mit dem Export von dem Plugin nicht zufrieden. Oft war in den Posts z.B. noch HTML vorhanden…

Deshalb habe ich eine andere Methode gewählt: Man kann man einfach via “Werkzeuge“ > „Daten exportieren“ > „Alle Inhalte“ > „Export-Datei herunterladen“ eine XML-Datei mit den WordPress-Daten herunterladen, die man anschließend konvertieren kann.

Das Exportieren

Konvertieren in Hugo Format

Es gibt verschiedene Tools zum Konvertieren. Von WordPress-Plugins bis zu CLI-Tools. Wie schon beschrieben, habe ich keine guten Erfahrungen mit den WordPress-Plugins gemacht.

Die Ausgabe von blog2md war jedoch besser, auch wenn dort keine Bilder exportiert werden und es bei manchen Posts z.B. an Absätzen fehlt.

D.h. jetzt gehen wir jeden Beitrag durch und prüfen, ob alles passt. Wir fügen Absätze hinzu, korrigieren evtl. URLs und Bilder usw…

Erstellen des Hugo-Projekts

Mit dem folgenden Befehl legt man eine neue Website mit Hugo an:

hugo new site mein-toller-blog

Nun kann man die konvertierten Dateien in den /content Ordner verschieben. Die Bilder habe ich nach /static verschoben.

Erstellen / Anpassen des Theme

Unter /themes legen wir einen neuen Ordner für unser Theme an. Als Vorlage kann man so einfache Themes wie https://github.com/J-Siu/hugo-theme-sk1 oder https://github.com/yanlinlin82/simple-style verwenden.

Anschließend musste ich mühsam mein WordPress-Theme auf die Hugo Syntax anpassen…

Fazit

Trotz der Mühe hat sich das gelohnt! Meine Seite lädt nun viel schneller und hat weniger Wartungsaufwand. In Zukunft werde ich wohl eher Hugo-Seiten als WordPress-Instanzen aufsetzen.

PC Engines APU2 coreboot / BIOS aktualisieren

Wer meinen englischsprachigen Blog liest, weiß, dass ich eine APU2C4 besitze und darauf pfSense als Router verwende.

Gestern habe ich festgestellt, dass darauf eine relativ alte Version von coreboot installiert war und habe daraufhin das BIOS aktualisiert. In diesem Artikel möchte ich möglichst generisch erklären, wie man die Firmware eines dieser PC Engines Boards richtig aktualisiert.

Herunterladen der aktuellen Rom

Unter https://pcengines.github.io/ kann man die aktuelle Firmware für die Boards (APU1 – APU5) herunterladen. Auf der Seite steht auch, was sich geändert hat und welche Probleme es aktuell bei welchen Boards gibt.

Nach einem Download der Binary sollte man den SHA256 Wert checken und kann dann den Upload der File zur APU starten.

Wenn man eine pfSense hat, sollte man die Binary auf seinen Rechner herunterladen und dann unter Windows z.B. mit Powershell den SHA256-Wert checken:

CertUtil -hashfile apu2_v4.11.0.6.rom SHA256

Unter Linux kann der Download und sha256 Überprüfung z.B. so ausgeführt werden:

wget https://3mdeb.com/open-source-firmware/pcengines/apu2/apu2_v4.11.0.6.rom
sha256sum apu2_v4.11.0.6.rom

Den Hashwert kann man dann mit dem Hash von der Download-Seite vergleichen. Er sollte übereinstimmen.

Upload der Rom-File unter pfSense

Hat man den beschriebenen Linux-Weg ausgeführt, hat man jetzt wahrscheinlich die File schon direkt auf die APU heruntergeladen. Über den pfSense Weg muss man die Datei jetzt aber erst auf das Gerät hochladen.

Das kann man über die Weboberfläche von pfSense mit dem Menüpunkt „Diagnostics“, „Command Prompt“ und dann „Upload File“ machen.

Flashen des neuen BIOS / coreboot

Dieser Schritt ist nun wieder weitgehend gleich – egal, ob man eine pfSense oder Linux verwendet.

Zuerst installiert man mit seinem Paketmanager „flashrom“. Unter pfSense kann man über „Diagnostics“, „Command Prompt“ und dann „Execute Shell Command“ die Befehle auch alle in der Web-UI eingeben.

Unter pfSense verwendet man dazu den folgenden Befehl und klickt danach auf „Execute“

pkg install -y flashrom

Anschließend führt man das eigentliche Flashen aus:

flashrom -w /tmp/apu2_v4.11.0.6.rom -p internal:boardmismatch=force

Wenn der Flash am Ende „VERIFIED“ wurde, passt alles und man sollte das System Neustarten. Den Reboot kann man unter pfSense über den Menüpunkt „Diagnostics“ und dann „Reboot“ durchführen.

Weil dieser Prozess meiner Meinung nach automatisiert werden könnte und ich schon viele Programme erstellt habe, die ähnliche Prozesse automatisieren, überlege ich hier auch ein Programm für automatische coreboot Updates auf PC Engines APUs zu erstellen…

WordPress: Kann Kategorie nicht bearbeiten bzw. setzen

Vor Kurzem hatte ich das Problem, das ich auf einem WordPress Blog eine bestimmte Kategorie nicht setzen konnte. Nach eine Suche bin ich auf https://stackoverflow.com/questions/41880458/wordpress-sorry-you-are-not-allowed-to-edit-this-item gestoßen und ein Post konnte mir wirklich helfen.

Anscheinend trat der Fehler bei mir auf, weil ein Begriff für eine Kategorie gleichzeitig auch als Schlagwort gesetzt war. Das ist wohl nicht möglich / erlaubt. Daher war die Lösung, sich entweder für die Kategorie oder dem Schlagwort zu entscheiden.

Zuerst sollte man in der Datenbank nach den doppelten Einträgen suchen:

SELECT term_id, COUNT(term_id) FROM wp_term_taxonomy GROUP BY term_id HAVING COUNT(term_id) > 1;

Anschließend habe ich die Einträge mit der term_id in der Tabelle anschaut und den Eintrag für den Tag gelöscht.

Arch Linux: Paket- und Journal-Cache leeren

Ich habe heute festgestellt, das Arch Linux sehr viel Speicherplatz für Paketcache verwendet. Nur alleine das Leeren diesen Caches konnte mir auf meinen Server ca. 10 GB und auf meinem Laptop ca. 20 GB freien Speicherplatz mehr verschaffen.

Es lohnt sich also, diesen Speicherplatz freizugeben, wenn man eine kleine Festplatte hat. Zum Löschen des Paketcaches verwendet man am besten „paccache“.

Installation von paccache:

pacman -S pacman-contrib

Einmaliges Ausführen von paccache:

paccache -r

Regelmäßiges Ausführen von paccache – jede Woche:

systemctl enable paccache.timer
systemctl start paccache.timer

Zudem kann man übrigens auch das Journal begrenzen:

journalctl --vacuum-size=500M

Vue.js für Angular Entwickler

Ich habe bisher mehr mit Angular als mit Vue.js gearbeitet. Für ein kleines Projekt wollte ich aber lieber Vue.js (aufgrund der geringeren Größe) verwenden.

Dabei sind mir ein paar Fragen in den Sinn gekommen, die ich hier in Form von einem kleinen Cheatsheet auch für andere Angular Entwickler festhalten möchte.

Grundsätzlicher Aufbau

Vue.js und Angular sind vom grundsätzlichen Aufbau nicht so verschieden. Vue.js hat sich ja auch bei der Erstellung von Angular.js (welches grundsätzlich anders als Angular v2+ aufgebaut ist) inspirieren lassen und wurde von einem ehemaligen Google-Entwicker gestartet.

Bei beiden Projekten gibt es Components, welche aus einem HTML, CSS und JavaScript (oder TypeScript) bestehen. Diese Components kann man entweder in einer Datei (HTML und CSS inline) oder in getrennten Dateien erstellen.

TypeScript und class-style Components

Der gemeine Angular-Entwickler ist TypeScript mit schönen Decorators gewohnt. Wenn er also das Standard-Vue.js einrichtet (JavaScript ohne Decorators) ist er erst mal geschockt. Das muss aber nicht sein!

Vue.js unterstützt auch TypeScript: https://vuejs.org/v2/guide/typescript.html und mit der https://github.com/vuejs/vue-class-component sieht eine Vue.js Component fast wie eine Angular-Component aus!

Dependency Injection

Gibt es in Vue.js auch: https://vuejs.org/v2/guide/components-edge-cases.html#Dependency-Injection

RxJS

Auch hier muss der gewohnte Angular-Liebhaber auf nichts Neues setzten: https://github.com/vuejs/vue-rx

Material Design

https://vuetifyjs.com/en/ ist quasi das äquivalent für Angular Material.

Fazit

Gerade über die letzten Jahre sind viele Standard-Features von Angular auch zu Vue.js gekommen und man muss sich nicht einmal großartig umgewöhnen, wenn man mal statt Angular Vue.js in einem neuen Projekt verwenden will.

Xfce: Start-Skript einrichten

Ein Start-Skript nach dem Anmelden eines Benutzers kann bestimmte Aufgaben wie z.B.: das Pullen von einem Git Repository oder das Öffnen von Anwendungen gleich beim Start ausführen.

Da ich mir unter Xfce ein solches Skript eingerichtet habe, möchte ich nun zeigen, wie das funktioniert. Als Beispielsystem werde ich Xfce unter Manjaro Linux verwenden.

Zuerst sollte man natürlich sein Skript (z.B.: als Bash-Skript) schreiben. Hierauf gehe ich allerdings in diesem Artikel nicht genauer ein. Seiten wie „ubuntuusers“ bieten dazu genügend gute Anleitungen.

Anschließend kann man über die Xfce-Einstellungen den Punkt „Sitzung- und Startverhalten“ auswählen.

Über „Automatisch gestartete Anwendungen“ kann man mit dem Button „Hinzufügen“ auch eine neue Startanwendung in die Liste aufnehmen.

Das anschließende Fenster möchte mit einem verständlichen Namen und dem Pfad zu unserem Skript gefüllt werden.

Nun sollte das Skript immer nach der Anmeldung automatisch ausgeführt werden.

Arch Linux: Bildschirmhelligkeit anpassen

Ich wollte heute unter Manjaro Linux meine Bildschirmhelligkeit anpassen. Leider gibt es direkt von Manjaro / Arch Linux hier keine GUI-Einstellung zum Regeln der Helligkeit.

Was es aber gibt, sind zwei nützliche Pakete: light und Clight. Mit light kann man die Helligkeit über die Konsole anpassen, Clight erkennt die aktuelle Umgebungshelligkeit über die Webcam und passt dementsprechend die Bildschirmhelligkeit an.

Da Clight aber nur über Arch AUR erhältlich ist, habe ich mal light ausprobiert und bin damit zufrieden.

Light kann man ganz einfach über pacman installieren:

pacman -S light

Anschließend kann man die aktuelle Helligkeit als Prozentwert ausgeben lassen:

$ light -G
23.99

Und die Helligkeit um x Prozent erhöhen:

$ light -A 70

Automatische Gitea Updates

Bereits im Januar dieses Jahres habe ich über meine Erfahrungen mit Gitea Updates berichtet. Das große Problem von Gitea ist, dass es sich nicht automatisch selbst aktualisiert. Ein Issue für das Problem ist schon seit fast 2 Jahren offen: https://github.com/go-gitea/gitea/issues/518#issuecomment-441742904

Ich hasse es wirklich, wenn sich eine sicherheitskritische Webanwendung nicht von selbst aktualisiert – das erlaubt Hackern ein leichtes Spiel. Vor vier Monaten habe ich nun schon die Entwicklung eines automatischen Gitea Update Skripts begonnen, welches ich nun vorstellen möchte.

Hinweise vor der Benutzung

Wie ich bereits erwähnt habe, bin ich kein Fan von manuellen Updates und schreibe deshalb für viele meiner Systeme Skripts zum automatischen Aktualisieren. Diese Programme sind schnell erstellt worden und auf meine Bedürfnisse angepasst und können unsauberen Code enthalten. Ich bin allerdings für Verbesserungsvorschläge in Form von Issues und Pull-Requests offen!

Manche Entwickler – wie der Ersteller von Kanboard – haben eine grundsätzliche Skepsis gegenüber automatischen Updates. Es gibt hierfür gute Gründe – du möchtest ja sicher nicht, dass deine Anwendung plötzlich aufgrund eines fehlerhaften Upgrades nicht mehr geht – deshalb empfehle ich automatische Upgrades nur, wenn auch automatische Backups eingerichtet sind.

Das Skript

Die veröffentliche Version meines Skripts kann auf GitHub gefunden werden: https://github.com/CMiksche/gitea-auto-update

Ich habe das Skript nur für mein Debian System entwickelt und getestet. Wenn das Skript einfach so auf Windows, MacOS oder Linux Systemen ohne Systemd ausgeführt wird, können Fehler nicht vermieden werden! Für diese Systeme muss das Skript definitv angepasst werden.

Wenn das Design von Gitea angepasst wurde, kann es sein, dass ein automatisches Upgrade dieses Template zerstört. Hierauf wird im Skript nicht geprüft.

Wie man mein Skript benutzt

Bitte zuerst die oberen Absätze lesen, ohne Beachtung dieser Hinweise kann es schnell in die Hose gehen!

Die Anwendung ist recht einfach:

  • Installiere mein Skript auf dem Zielsystem:
    pip install gitea-auto-update
  • Erstelle eine settings.ini:
    [Gitea]
    site=https://your-gitea-instance.com/api/v1/version
    apiUrl=https://api.github.com/repos/go-gitea/gitea/releases/latest
    system=linux-amd64
    file=/usr/local/bin/gitea
    tmpDir=/tmp/
    buildFromSource=None
    sourceDir=/home/git/go/src/code.gitea.io/gitea
    logFile=update.log
  • Führe den Befehl gite-auto-update --settings=/path/to/settings.ini aus, um das erste Upgrade zu testen
  • Wenn die Updates regelmäßig automatisch ausgeführt werden sollen, bearbeite die /etc/crontab Datei und rufe dort einen Aufruf des Skripts aus

So einfach geht das. Wenn du auf Probleme stößt, zögere nicht einen Issue oder Pull-Request auf Github zu erstellen oder hier einen Kommentar zu hinterlassen.

Diesen Beitrag habe ich auch auf Englisch veröffentlicht.

Debian 9 Upgrade mit nginx und PHP 7.2

Ich habe nun alle meine Debian Systeme auf die neueste Version „Stretch“ ohne größere Probleme aktualisieren können.

Da ich in den letzten Jahren allerdings immer größere Probleme hatte und weiß, dass eine gute Anleitung hilfreich sein kann, möchte ich hier meine Vorgehensweise anhand eines Webservers mit Debian 8 beschreiben.

Hintergrund

Gerade bei Webservern ist eine Aktualisierung wichtig, da Sicherheitslücken den Server schnell zu einer Virenschleuder verwandeln können.

Sollte PHP auf dem Webserver verwendet werden, führt kaum ein Weg an einem Upgrade vorbei, da Debian 8 keine aktuelle PHP-Version ausliefert. (Debian 9 zwar auch nicht wirklich aber dazu später mehr …)

Vorbereitung

Folgende Punkte führe ich immer vor einer Webserver-Aktualisierung durch:

  • Wartungsmodus in WordPress / anderen CMS aktivieren
    • Bei größeren Projekten die Nutzer über das Upgrade informieren
  • Wichtige Verzeichnisse sichern (sollte man generell regelmäßig machen), z.B.:
    • Webserver-Verzeichnis (/var/www)
    • /opt Verzeichnis (bei manuell hinzugefügter Software)
    • /home Verzeichnisse (Daten der Unix-Nutzer)
  • Wichtige Dateien sichern
    • z.B.: /etc/crontab mit regelmäßig ausgeführten Skripten
  • Alle Datenbanken sichern

Aktuelle Pakete herunterladen

Mit

apt update

und danach

apt upgrade

aktualisiert man die aktuellen Pakete.

Alte Sources sichern

Damit man bei Problemen schnell wieder auf Debian Jessie wechseln kann, ist eine Sicherung der alten Sources List hilfreich:

cp /etc/apt/sources.list /etc/apt/sources.list_backup

Wichtig: Sollte es auch Dateien unter /etc/apt/sources.list.d geben, ist auch eine Sicherung dieser Dateien nicht überflüssig!

Neue Sources pflegen

Nun sollte man den Namen der alten Version durch den Namen der neuen Version in der Sources.list und allen anderen Dateien unter z.B.: /etc/apt/sources.list.d aktualisieren. sed ist für solche Aufgaben perfekt geeignet:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

Pakete aktualisieren

Nachdem wir nun die Quellen auf die neue Version geändert haben, können wir die Paketquellen mit den folgenden Befehl aktualisieren:

apt update

Anschließend aktualisieren wir die Pakete wieder mit:

apt upgrade

Hier kann es sein, dass wir den Befehl mehrmals ausführen müssen und gefragt werden, ob wir die aktuellen Konfigurationsdateien behalten wollen oder neue Konfigurationsdateien übernehmen (letzteres sollte nur gemacht werden, wenn nichts an den Konfigurationen geändert wurde).

Systemupgrade abschließen

Mit den bisherigen Befehlen wurden noch nicht alle Pakete aktualisiert. Um das Systemupgrade abzuschließen, benötigen wir eine Ausführung des folgenden CLI-Befehls:

apt dist-upgrade

Systemupgrade prüfen

Nach einem großen Upgrade empfiehlt sich ein Neustart, welcher mit

reboot

durchgeführt werden kann.

Um festzustellen, ob wir die gewünschte Version haben, kann man diese mit cat ausgeben lassen:

cat /etc/issue

PHP aktualisieren

Zum Zeitpunkt dieses Posts gibt es noch keinen mir bekannten Weg, um PHP direkt von den Debian Sources zu beziehen. Deshalb müssen für PHP 7.2 Fremdquellen genutzt werden. Bei Fremdquellen sollte immer auch auf das Sicherheitsrisiko geschaut werden.

Vorerst sollten wir PHP deinstallieren:

apt purge php*

Anschließend den Schlüssel des fremden Repos importieren:

wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -

Um dann die Quelle in eine Sources List zu speichern:

sudo echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Die Paketquellen aktualisieren wir wieder mit:

apt update

Nun können wir endlich die neue Version von PHP installieren:

sudo apt install php7.2

(hier können natürlich auch noch weitere Pakete wie php7.2-imap gewählt werden)

nginx anpassen

Da ich gerne nginx als Webserver verwende, musste ich für die neue PHP-Version auch den Socket in den sites-available aktualisieren.

Dafür wechseln wir erst in das Verzeichnis der virtual Hosts:

cd /etc/nginx/sites-available/

Danach bearbeiten wir die gewünschte Website mit einem Editor unserer Wahl – z.B.: nano.

Wir suchen erst nach fastcgi_pass und passen die Zeile dann wie folgt an:

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

Um die Änderung aktiv zu schalten, müssen wir den Webserver noch neu starten:

systemctl restart nginx.service

Ich hoffe, meine Erklärung des Debian Upgrades war hilfreich. Wenn ihr zukünftig Tutorials zu Themen wie Debian Webserver erhalten möchtet, könnt ihr mir gerne auf Twitter folgen.