Details zu Migration und Zukunftsplänen

In meinem letzten Post versprach ich mehr Details über die Migration der crowbyte.org webseite und des Blogs, sowie mehr zu meinen Plänen für die Zukunft, zu verraten und halte mit diesem Post nun mein Versprechen.

Migrationsdetails

Nach über einem halben Jahr der Abwesenheit, hatte ich die Zeit und Gelegenheit die Richtung der Webseite und des Blogs noch einmal grundlegend zu überdenken.

Bisher nutzte ich Nikola als Seitengenerator für den Blog und die Webseiten. Dies war eine wohl überdachte Entscheidung, der viele Tests erhältlicher Systeme vorausging. Schlussendlich entschied ich mich für Nikola, da es am besten meinen Anforderungen entsprach: performant und mit allem ausgestattet, das ich wollte. Der Vorteil war zudem, dass es nur eines einfachen Texteditors bedarf, um Posts und Seiten zu erstellen, woran ich viel Freude hatte. Nach einiger Zeit jedoch musste ich feststellen, dass dieses Konzept aber auch seine Schattenseiten hatte.

Das Nikola-Paradoxon

Ironischerweise ist Nikola's stärkster Punkt gleichzeitig auch sein schwächster: vorgenerierte HTML Dateien.

Der Vorteil von vorgenerierten HTML-Seiten ist, dass Webserver statischen Inhalt blitzschnell ausliefern und kein PHP Code ausgeführt, der unter Umständen anfällig für Angriffe ist. Der Nachteil jedoch ist eine logische Folge daraus: HTML Dateien müssen jedes mal generiert werden, sobald Änderungen an den Markup-Dateien gemacht werden, die Nikola nutzt um daraus HTML Dateien zu erzeugen, welche der Webserver dann ausliefern kann. Zudem bedeutet die Nutzung von Markup-Sprachen auch, dass auf den Seiten unliebsame und große Fehlermeldungen angezeigt werden, sobald einen Syntaxfehler in einer Markup-Datei hat.

Kurzum, Posts und Seiten zu erstellen ist eine einfache Angelegenheit, heißt: eine Textdatei erstellen, den Artikel oder Seiteninhalt in der favorisierten Markup-Sprache niederschreiben, die Datei speichern, sie auf den Server kopieren, sich mit dem Server verbinden, die HTML-Dateien mit einem einfachen nikola build erstellen und die Seiten veröffentlichen, indem man sie in das Stammverzeichnis des Webservers kopiert. Erledigt.

Das heißt aber auch, dass der gleiche Prozess noch einmal ausgeführt werden muss, wenn man einfach nur ein paar kleine Tippfehler oder Syntaxfehler beseitigen möchte: die Textdatei öffnen, den Artikel oder Seiteninhalt in der favorisierten Markup-Sprache bearbeiten, die Datei speichern, sie auf den Server kopieren, sich mit dem Server verbinden, die HTML-Dateien mit einem einfachen nikola build erstellen und die Seiten veröffentlichen, indem man sie in das Stammverzeichnis des Webservers kopiert. Endlich erledigt.

Wie man also sehen kann, braucht das Korrigieren von kleinen Fehlern eine Menge an kleinen Schritten, genauso wie das Erstellen. Und auch wenn Nikola schlau ist und nur die geänderten Markup-Dateien neu in HTML-Dateien umwandelt, braucht auch dieser Vorgang noch einmal eine gewisse zusätzliche Zeit. Letztendlich benötigt man also für eine eigentlich so einfache Aufgabe wie das Beseitigen von Fehlern zu viele Schritte und zu viel Zeit.

Dieser Mehraufwand nahm so eine Menge Spaß aus dem Veröffentlichen von neuen Posts und verlangsamte das Schreiben von Posts, obwohl ich eigentlich vor hatte mit Nikola den Prozess vereinfachen, um produktiver und nicht weniger produktiv zu sein. Aus diesem Grund entschied ich noch einmal October CMS zu testen, was damals schon der engste Herausforderer für Nikola war. Und da das October CMS mittlerweile gereift ist und mehrsprachige Webseiten unterstützt, entschied ich mich dazu in Zukunft crowbyte.org damit zu betreiben.

Konzept für die neue Webseite

Die Migration gab mir die Gelegenheit zu entscheiden, was ich migrieren und ändern möchte und somit das Konzept für die neue Webseite und den Blog anzupassen.

Zunächst einmal brauche ich wahrscheinlich nicht extra erwähnen, dass in jedem Fall alle Posts von Nikola zu October CMS migriert werden sollten. Ich plante dabei die Struktur des Seitenaufrufs von Blog Posts (www.crowbyte.org/posts/.. und www.crowbyte.org/de/posts/..) zu belasse, wie er war, um auch weiterhin alte Links zu bedienen. Letztendlich entschied ich mich jedoch dazu die Struktur in eine logischere und standardisiertere Form zu bringen, d.h. www.crowbyte.org/blog/post/.. und www.crowbyte.org/de/blog/post/... Dies bedeutet zwar, dass alte Links nicht mehr funktionieren, dafür aber die Struktur deshalb logischer ist, weil der Blog nur ein der der crowbyte.org Webseite darstellen soll.

Desweiteren habe ich geplant noch weitere Features hinzuzufügen, welche mir mit Nikola nicht für den Blog zur Verfügung standen. Neben den beiden Standards wie Kategorien und Tags, wollte ich nun auch verwandte Artikel verlinken können und Share-Links zu den bekanntesten und meistgenutzten Sozialen Netzwerken anbieten. Als netter Zusatz würde ich gerne auch eine Suchfunktion integrieren, welche bisher noch nicht vorhanden ist, aber demnächst folgen soll.

Auch wenn ich mehrere Features hinzugefügt habe und auch noch weitere in der Zukunft hinzukommen sollen, habe ich mich von einem Feature dieses Mal verabschieded: die Kommentarfunktion. Der Grund ist dabei einfach: Nikola hatte keine Kommentarfunktion und um diese für meinen Blog anbieten zu können, musste ich auf externe Dienste wie Disqus, oder wie in meinem Fall IntenseDebate, zurückgreifen. Nicht nur, dass ich externe Dienste vermeiden möchte, so habe ich auch die Erfahrung gemacht, dass dieses Feature schlicht so gut wie ungenutzt blieb. Die meisten Diskussionen zu Artikeln liefen ohnehin über Soziale Netzwerke, welche ich auch in Zukunft für den richtigen Ort halte.

Zuletzt, aber nicht vergessen, sollte das Menü rein auf relevante Einträge reduziert werden, das Design der ganzen Seite einen moderneren und hübschen Look bekommen und es sollte HTTPS als sichere Verbindung nutzen.

Software, Plugins und Tools

Ich entschied mich also mit der folgenden Software, den Plugins und Tools zu arbeiten:

Implementation

Nach Erhalt des neuen Servers und dem Abschluss der Installation von Arch Linux, habe ich einen normalen Nutzer hinzugefügt, den Zugriff über SSH für den root Account eingeschränkt, meinen SSH public key auf dem Server gespeichert, eine Systemaktualisierung durchgeführt, sowie Hiawatha, PHP, PHP-Erweiterungen, MariaDB und Let's Encrypts certbot über den pacman Paket Manager installiert. Sollte jemand mehr Details dazu wissen wollen, so kann man mich dazu entweder kontaktieren oder Google nutzen, um Anleitungen zu suchen, die es reichlich dafür im Internet zu finden gibt.

MariaDB kann einfach installiert werden, indem man

mysql_secure_installation

ausführt und den weiteren Anweisungen folgt.

Ich habe anschließend Hiawatha konfiguriert und einen virtuellen Host für October CMS angelegt. Dieser sollte für andere auch in etwa wie folgt aussehen:

VirtualHost { 
        Hostname = domain.tld
        WebsiteRoot = /path/to/website/root/domain.tld/
        StartFile = index.php
        TLScertFile = /path/to/tls_cert/domain.pem
        RequireTLS = yes
        ExecuteCGI = yes
        TimeForCGI = 5
        UseToolkit = october
}

Zusätzlich muss die Auskommentierung des Eintrags CGIhandler = /bin/php-cgi:php entfernt werden, um PHP für Hiawatha lauffähig zu machen.

Wie man sieht, nutzt der virtuelle Host ein URL Toolkit, das noch nicht existiert.

Daher müssen noch die "Rewrite Rules" für October CMS der Konfigurationsdatei hinzugefügt werden. Diese Regeln kann man einfach auf der Hiawatha Webseite finden. Dazu geht man dort einfach auf Support, klickt dann auf HOWTO und wählt dann Punkt 10. "URL rewrite rules for CMSes, wiki's, webmails, etc" aus und sucht den Eintrag für October CMS. Unglücklicherweise ist darin ein Fehler enthalten: RequestURI file Return muss richtig RequestURI isfile Return heißen.

Das funktionierende URL Toolkit sieht dann wie folgt aus:

UrlToolkit {
        ToolkitID = october
        Match /themes/.*/(layouts|pages|partials)/.*.htm Rewrite /index.php
        Match /uploads/protected/.* Rewrite /index.php
        RequestURI isfile Return
        Match .* Rewrite /index.php
}

Damit sind wir auch so gut wie fertig. Ich musste lediglich noch das Zertifikat beschaffen. Dafür nutze ich certbot. Achtet dabei jedoch darauf, dass certbot richtig konfigurierte DNS Einträge braucht, um korrekt zu funktionieren. Das heißt, ihr solltet wie auch ich DNS A Einträge in eurem DNS haben, die auf die IP-Adresse des Servers verweisen, auf dem Hiawatha laufen soll.

Trifft das für euch ebenfalls zu, kann man einfach ein Zertifikat mit folgendem Befehl anfordern:

sudo certbot certonly --standalone -d domain.tld

Certbot sagt euch dabei, wo es die Zertifikate speichert und ob ihr diese überhaupt erfolgreich erhalten habt. Man findet sie in dem Pfad /etc/letsencrypt/live/domain.tld. Da dieser Ordner geschützt ist, benötigt man jedoch root-Rechte, um darauf zuzugreifen. In den root-Account kann man einfach mit sudo su wechseln.

Bleibt noch eine Herausforderung: Hiawatha erwartet das Zertifikat in einer etwas spezielleren Form, daher muss man dieses generieren, um die erhaltenen Zertifikate für Hiawatha nutzbar zu machen. Ich weiß, dass es mittlerweile wohl mit Hiawatha auch ein Skript gibt, das dies für einen übernimmt, ich bleibe aber erst einmal bei der 'Zu-Fuß-Methode'.

Das erforderliche Zertifikat habe ich wie folgt generiert:

cat privkey.pem cert.pem chain.pem > /path/to/tls_cert/domain.pem

Dabei kann man das Zertifikat natürlich an jedem Ort speichern, der einem am besten gefällt. Allerdings sollte man aus Sicherheitsgründen darauf achten, das dies kein Ort ist, der öffentlich zugänglich ist.

Nicht vergessen sollte man die Anpassung der Zugriffrechte:

chmod 400 /path/to/tls_cert/domain.pem

Nun sollte alles an seinem Ort sein, also Zeit die Probe auf's Exempel zu machen und Hiawatha zu starten:

sudo systemctl start hiawatha

Startet Hiawatha ohne Fehler, ist alles gut. Wenn nicht und man etwas falsch konfiguriert hat, wir einem dies von Hiawatha gemeldet. Wo genau der Fehler liegt, zeigt einem der Befehl sudo systemctl status hiawatha.

Alles was nun noch blieb war October CMS herunter zu laden, das Archiv zu entpacken und alles in den konfigurierten Pfad des virtuellen Hosts zu verschieben und anschließend October CMS wie in der October CMS Dokumentation beschrieben zu installieren.

Migration des Inhalts

Da Nikola ohne Datenbank arbeitet und reine Textdateien nutzt, war die Migration der Blog Posts ziemlich ermüdend. Zwar besitzt das Blog Plugin von October CMS eine Importfunktion, doch diese benötigt eine CSV-Datei mit allen Daten. Ich hätte allen Inhalt des Blogs in eine solche CSV schieben können, zusammen mit allen weiteren benötigten Werten, um diese dann für einen Import zu nutzen, entscheid mich jedoch dazu das per Hand zu machen. Ich habe diese Gelegenheit genutzt, um kleinere Fehler in den Artikeln zu beseitigen und nicht übersetzte Artikel zu übersetzen. Da das Blog Plugin jedoch Markdown als Markup Sprache nutzt und ich bei Nikola RestructuredText genutzt hatte, habe ich pandoc zur Hilfe genommen, um die RestructuredText-Dateien in Markdown-Dateien zu konvertieren und habe daraus dann die Artikeltexte in das Neuer Post-Formular kopiert.

Da ich die Anordnung der Seiten und deren Inhalt umstrukturiert habe, habe ich für diese beinahe alle Texte neu geschrieben, damit diese dem neuen Layout entsprechen und wieder auf einem aktuellen Stand sind.

Anders als der technische Teil klingt das alles ziemlich simpel, brauchte aber letztendlich sehr viel mehr Zeit, als das gesamte Aufsetzen der neuen Systeme, dem Schreiben und Anpassen von HTML und CSS Vorlagen und was es noch brauchte, um die neue Seite so zu gestalten, wie ihr sie jetzt seht.

Fazit

Eigentlich war dieser Artikel gedacht einen kleinen Einblick hinter die Kulissen zu erhalten. Tatsächlich aber sprengt er nun den Rahmen dessen, was ich ursprünglich vorhatte.

Auf dem Weg hatte ich das eine oder andere Problem die Ausgaben des Blog Plugins so anzupassen, dass es mir die Artikel wie gewünscht auflistet. Ich fand heraus, dass es einfacher ist, erst einmal den Video Tutorials zu folgen, die einem das Aufsetzen eines Blogs zeigen, und erst hinterher Anpassungen zu machen (wie beispielsweise die Components mit Partials zu ersetzen).

Zukunftspläne

Wie bereits erwähnt, plane ich noch eine Suchfunktion hinzuzufügen. Außerdem möchte ich noch den verbliebenen Fehler beheben, bei dem trotz Wechsel auf die Deutsche Seite die Teaser-Texte der Blog Artikel in Englisch angezeigt werden. Und natürlich nicht zu vergessen, möchte ich das Kontaktformular zum Laufen bringen und die Seite mit meinen aktuellen Projekten füllen. Doch sobald das geschieht, werde ich euch natürlich mit einem Blog Artikel darüber informieren und euch mehr dazu schreiben.

Noch Fragen?

Ihr habt noch Fragen zu Teilen des Artikels oder generell? Dann zögert nicht mir diese zu stellen und mich entweder per E-Mail oder auf Facebook, Twitter, Diaspora oder Google+ anzuschreiben!

Danke für's Lesen!

pb

Published by

Pierre Böckmann

Born 1985 in Berlin, I am Software Developer, Blogger, Author, Open Source Enthusiast, openSUSE member and passionate openSUSE Leap user.