Prof. Dr. Detlef Stern

Zettelstore reloaded

Bisher wurde der Quelltext der Software Zettelstore auf der Plattform GitHub verwaltet. Von Anfang an war ich darauf bedacht, mich nicht zu sehr an GitHub zu binden, ist es doch eine Art Facebook für Entwickler, bzw. vielleicht auch ein LinkedIn für Entwickler (was zumindest die Eigentümerstruktur besser trifft).

Wer meinen letzten Post, über Git, aufmerksam gelesen hat, bemerkte sicher meine ambivalente Haltung zu Git. Auch aus ganz anderen Gründen denke ich inzwischen über Git und GitXYZ (XYZ = Hub, Lab, oder ea) anders, als vor einigen Monaten.

Probleme

Da ist zum Beispiel die Administration des Servers, der hinter https://zettelstore.de/ steht. Das ist eine recht kleine virtuelle Maschine, betrieben von einem großen Hoster, natürlich mit einer Linux-Distribution. Als Webserver arbeitet dort Caddy, den ich schon in meinem Post über die Programmiersprache Go erwähnte. Dieser leitet Anfragen zum Zettelstore-Handbuch weiter, die dort aus Demonstrationszwecken läuft, natürlich selbst ein Zettelstore. Weiterhin sorgt Caddy für die Auslieferung der notwendigen Daten, um die sog. Go vanity URL zu implementieren. Mein Ziel ist es ja, mich nicht zu sehr an einen externen Dienst wie GitHub zu binden. Und zu guter Letzt liefert Caddy auch noch ein paar schnöde HTML-Seiten aus, etwa zum Download der Zettelstore-Software. Wenn ich eine neue Version des Zettelstore ausliefere, ist gerade hier viel zu tun. Einiges ist manuelle Arbeit. Hier suchte ich nach Alternativen.

Schön wäre es zum Beispiel, wenn ich eine neue Version der Zettelstore-Software in allen Varianten (Windows, Linux, Raspberry, macOs) erst in einer lokalen Version der Webseite ausprobieren und alles per Synchronisation publizieren könnte. Ich überlegte darüber hinaus, wie andere mit mir einfach über die Software diskutieren oder Fehler der Software melden könnten. Klar, das geht über GitHub, aber bindet einen sehr an die Plattform. Weiterhin überlegte ich, ob ich nicht besser ein Content Management System für die Inhalte der Webseite nutzen sollte, damit diese etwas ansprechender aussieht und weitere Inhalte einfacher ergänzt werden könnten.

All das schwirrte in meinem Kopf herum, als sich mein kleiner Server im Arbeitszimmer meldete, auf dem u.a. auch Gitea läuft, mit dem ich ja meine internen Git-basierten Projekte verwalte, wie z.B. dieses Blog. Na, eigentlich meldete es sich gerade nicht. Der Server kommt seit einem Update immer wieder spontan, etwa wöchentlich, in einen Zustand einer 30-bis 100-fachen Überlast. Damit reagiert dieser auf Anfragen nicht mehr, oder nur sehr sehr langsam. Wenn ich beispielsweise Gitea auf dem Server deaktiviere, tritt dieses Verhalten nicht mehr ein. Dieses Server-Problem liegt zwar nicht an Gitea allein, aber es ist ein auslösender Faktor. Eine erste Recherche zeigte schnell, dass es de facto keine alternative Software gibt, viele Git-Repositories mit weniger Rechenleistung zu hosten, wenn es nicht gerade nur um reines Bereitstellen geht. Sobald man etwas größere inhaltliche Anforderungen hat, z.B. ein Wiki, eine Aufgabenverwaltung, Mirroring, dann landet man bei Gitea oder vergleichbarer Software. Natürlich könnte ich mich hinsetzen und etwas selbst programmieren, aber das ist nur der letzte Ausweg.

Lösung?

Irgendwann erinnerte ich mich an die Software Fossil, über die ich vor mehr als fünf Jahren schon einmal geschrieben geschrieben habe und die sogar noch aktiv nutze. Allerdings hatte ich deren Weiterentwicklung nicht mehr verfolgt, auch wegen der Nutzung von Git / Gitea.

Fossil bietet als verteilte Versionsverwaltung das Modell der revisionssicheren Versionen, die nachträglich nicht mehr geändert werden können. Eine Änderung ist aber über eine Art „Umbuchung“ zu erreichen, die wie bei jeder guten Buchhaltung nachvollzogen werden kann. Es eignet sich für eingespielte Entwicklungsteams, bei denen man sich untereinander vertrauen kann. Also quasi das Gegenteil von Git mit seiner primären Unterstützung von Tausenden Entwicklern, die man nicht einmal kennen muss.

Fossil bietet immer noch eine Aufgabenverwaltung / Ticketsystem, ein Wiki und eine Art Blog an. Das hatte ich noch in Erinnerung. Inzwischen kann man damit auch Foren betreiben, um Fragen von Nutzern zu beantworten oder um im Team zu diskutieren. Es erlaubt mit Hilfe von Markdown den Inhalt der Website zu formulieren (leider nicht mit Zettelmarkup). Für grafische Darstellungen steht Pikchr in einer eingebetteten Variante zur Verfügung. Und inzwischen funktioniert auch das unversionierte Speichern von Dateien, etwa um diese für einen Download anzubieten. Für Version 2.14 ist ein (einfacher) Chat geplant.

All das funktioniert auch in einer verteilten Umgebung. Per fossil clone https://zettelstore.de zettelstore.fossil kopiert man sich seine eigene Instanz und kann diese mit fossil sync immer aktuell halten. Möchte man sich mit einer anderen Instanz synchronisieren, so muss man zusätzlich die passende URL angeben. Im Unterschied zu Git werden nicht nur die Quellcodedateien synchronisiert, sondern alles andere auch. Also Tickets, Wiki, Dokumentation, Blog, Download-Dateien (unversioniert), Foren.

Und noch einen weiteren Unterschied zu Git gibt es. In den über zehn Jahren, die ich Fossil nutze, hatte ich noch nie einen Datenverlust durch eine unsachgemäße Bedienung. Die unwiederbringlichen Verluste von Git habe ich aufgehört zu zählen.

Fossil lässt sich auf der Kommandozeile gut bedienen. Vieles lässt sich auch über den eingebauten Webserver erledigen. Darüber hinaus gibt es inzwischen für einige Entwicklungsumgebungen entsprechende, funktionierende Plugins, etwa für Visual Studio Code.

Dabei arbeitet Fossil recht genügsam, was die Anforderung an die Leistungsfähigkeit eines Servers oder Entwicklercomputer angeht. Wahrscheinlich könnte ich meinen Server im Arbeitszimmer demnächst durch einen Raspberry ersetzen.

All das ist wesentlich einfacher als Gitea zu installieren. Wer will kann Fossil noch als ein CGI-Skript installieren. Viele Server unterstützen das nicht mehr. Ich empfehle den Betrieb als eigenständigen Service, mit davor geschaltetem Webserver als „Reverse Proxy“. So läuft Fossil bei mir inzwischen auf drei Servern, die sich alle regelmäßig synchronisieren. Sollte ein Server ausfallen, kann ich immer noch auf die anderen zugreifen. Geschätzt erreiche ich damit eine Ausfallsicherheit wie der von GitHub. Zur Not ergänze ich das Ganze um einen weiteren Server bei einem anderen 1€-Hoster.

Vom Aufwand her habe ich weniger als einen Arbeitstag benötigt, um alles umzustellen. Davon brauchte ich etwa drei Stunden, um meine etwas veraltete Fossil-Instanz auf die neuen Möglichkeiten umzustellen. Der Rest war in fünf Stunden erledigt.

Oh, ich vergaß: mit dem Befehl fossil git export wird, nachdem man alles richtig eingestellt hat, der Quelltext des Zettelstore auch zu GitHub gespiegelt. Es soll ja noch Menschen geben, die nicht ohne ihr Programmierer-Facebook auskommen wollen.

Wer auch Alternativen in Betracht ziehen kann, sollte sich Fossil näher ansehen, das „GitHub-in-a-box“.