Schon mehrfach habe ich erwähnt, dass im Juli 2019 bedingt durch einen Stromausfall bzw. Spannungsschwankungen trotz Steckdosenleist mit Spannungsschutz mein Desktop-PC bzw. die Boot-SSD den Geist aufgegeben hatte. Dieser Crash hatte Datenverluste zur Folge. Leider. Und das nur, weil ich zu blöde war, InnoDB-Datenbanken richtig zu sichern.

Ich hatte aber Glück im Unglück, denn die verlorengegangen Datenbanken waren so gesehen nicht wichtig. Es waren Datenbanken für WordPress-Installationen, Joomla!, q2a und einer privaten Datenbank mit Testdaten. Alle wichtigen Daten waren, warum auch immer, in MyISAM-Datenbanken abgelegt, die ich vollständig erhalten konnte.

Dennoch war dieses Erlebnis einschneidend. Zeigte es mir doch, dass ich als Privatmann meine Grenzen in Sachen Datenbanken, Datenhaltung und Datensicherheit erreicht hatte.

Nachdem ich wieder arbeitsfähig war, überlegte ich mir, was ich für mich auf dem lokalen Rechner würde verändern müssen. Es gab für mich nur zwei Wege. Entweder mein Wissen in Sachen Datenbanken aufbauen oder den Datenbanken entsagen. Weder privat noch beruflich muss ich eigene Datenbanken vorhalten. Beruflich arbeite ich mit Datenbanken, aber nur als Endanwender über Querys und Downloads in die Tabellenkalkulation. Privat fand ich es irgendwann mal cool, dass ich MySQL ansatzweise bedienen und später auch in PHP-Scripten einsetzen konnte. Mehr ist nie daraus geworden, weil auch nicht gewünscht bzw. benötigt.

Die Spielereien mit WordPress und Konsorten, die hauptsächlich auf PHP und MySQL/MariaDB aufsetzen, kann ich haben, muss ich aber nicht haben. Das war eine Feststellung.

Doch stopp! Den SQL-Datenbanken wollte ich entsagen. Aber was ist mit NoSQL-Datenbanken wie MongoDB oder CouchDB?

Eine kurze Stippvisite bei MongoDB war sehr interessant und aufschlussreich. Aber auch hier stellte ich schnell fest, dass ich mit Kanonen auf Spatzen zielte. Nein, einfach zu aufwendig für mich, auch wenn ich rein hobbymäßig tatsächlich mit vielen Daten zu tun habe. Ich verarbeite jeden Tag zwischen 600 und 1.000 Datensätze in verschiedenen Tools und für verschiedene Zwecke.

Aber wie sollte ich eine Umstellung nun bewerkstelligen. Den großen Sprung konnte ich nicht hinlegen. Keine Chance, da ich berufstätig bin und meine Freizeit eben begrenzt ist. Also musste es schrittweise passieren, wobei PHP und MySQL weiterhin in Betrieb bleiben mussten, bis alles umgestellt sein würde.

Eine erste Maßnahme, die ich Augut/September 2019 startete, war, dass ich versuchte meine lokalen als auch meine externen Webseiten auf Hugo, einem Generator für statische HTML-Seiten, umzustellen. Auch extern hatte ich ein paar WordPress-Installationen laufen, die ich auf Hugo umstellen konnte.

Warum Hugo?

Hugo hat und erzeugt ausschließlich textbasierte Dateien. Bilder, Videos und ähnliches sind zwar nicht textbasiert, lassen sch aber sehr gut sichern. Und das war mein Ziel. Ich wollte die Dateien, die ich erzeugte und selber beeinflussen konnte, einfach anpacken und irgenndwohin kopieren oder verschieben können. Mit einem PHP-MySQL-basierten System ist das für Otto-Normal-Verbraucher nicht immer einfach bzw. doch aufwendig.

Somit laufen extern keine Datenbanken mehr im Hintergrund meiner Webseiten. Die Artikel erstelle ich zu Hause auf dem lokalen Rechner, wie jetzt gerade eben, lasse Hugo darüberlaufen, und lade anschließend das Ergebnis auf den FTP-Server meiner Webseite oder belasse sie in meinem lokalen Intranet. Fertig. Auf den Webspaces, Hostings wie auch vServer, habe ich somit auch mögliche Einfallstore für kriminelle Hacker minimiert. Und so gesehen setze ich extern keine Software mehr von Dritten ein, die ich nicht beeinflussen kann. Ausgenommen sind davon natürlich die Programme, die zum Betrieb der Webseiten notwendig sind. Diese sind von mir nur auf dem vServer zu beeinflussen, nicht auf den Hostings. Da läuft nur noch HTML, CSS, ein bisschen JavaScript und das war es.

Auch im Privatbereich habe ich damit begonnen Hugo zu etablieren. Mein eigenes Wissensmanagement lief über PHP und MySQL. Teils hatte ich dafür WordPress, auch mal Joomla! im Einsatz. Es nervte mich aber irgendwann, auch schon vor dem Crash im Juli 2019, und daher hatte ich mir auf eine einfache Art und Weise ein eigenes Tool mit PHP und MySQL programmiert. Das hat viel Spaß gemacht, aber ein Profi sollte sich das besser nicht ansehen, will er nicht Gefahr laufen, vor lauter Lachen zu platzen. Aber das Teil läuft und macht das, was ich von ihm wollte. Nur das responsive Layout habe ich nie hinbekommen.

Die Umstellung meines Intranets auf Hugo hatte ich begonnen, aber nicht zu Ende führen können. Zu viele Artikel, zu wenig Zeit und andere Prioritäten.

Dennoch fand ich zwischendurch heraus, dass ich durchaus in der Lage sein würde, vieles von dem, was ich mit PHP und MySQL veranstaltete, auch über textbasierte Dateien (txt-, csv- oder xml-Dateien) würde abwickeln können. Dass ich nur noch mit HTML und CSS zu tun haben würde, habe ich schnell aufgeben müssen. Um PHP komme ich nicht umhin und das ist auch nicht so schlimm. Denn nicht alles kann ich mit Hugo erreichen. Oder ich muss wiederum so tief in Hugo einsteigen, dass ich eine dynamische PHP-Seite auch in Hugo nachstellen kann. Dazu bin ich aber nicht in der Lage.

Und da sind wir auch wieder bei SQL. Aber nicht bei MySQL, nicht bei MariaDB, nicht bei PostgreSQL. Nein, wir sind bei SQLite3.

Warum SQLite3?

Die Antwort habe ich mehr oder weniger schon oben gegeben. Eine SQLite3-Datenbank ist eine Datei, die irgendwo auf einer erreichbaren Partition liegen muss. Datei! Das ist es. Ich kann sie sichern bis der Arzt kommt. Die Problematiken wie bei den 3 vorgenannten SQL-Datenbanken mit Dumps und ähnlichem sind nur bedingt vorhanden. Für die Sicherung reicht das, was ich sonst auch für Dateien vorsehe, die ich sichern möchte.

SQLite3 hat nicht den Funktionsumfang wie die großen Brüder. Aber den brauche ich auch nicht. Ich bin auf ganz einfacher und flacher Ebene unterwegs. Ich brauche nur Tabellen, die ich relational aufbauen kann, damit ich sie joinen und abfragen kann. Mehr nicht. Mein Datenvolumen ist zu gering als das ich Geschwindigkeitseinbußen befürchten müsste.

SQLite3 war also die Datenbank, die mich künftig unterstützen, aber keine Hauptrolle spielen sollte. Somit war eine Kombination von Hugo, Textdateien sowie SQLite3-Datenbanken mit PHP-Scripts mein Konzept, welches ich ab Sommer 2020 gezielt umsetzen wollte.

Wollte! Jo.

Und wieder war es ein Crash am oder im Desktop-PC, der mich in Schwung bringen sollte. Am 22.05.2020 stürzte mein Desktop-PC während einer ganz normalen Arbeitssitzung ab und ließ sich auf Grund von kernel panic nicht mehr starten. Nichts zu machen. Darüber habe ich berichtet. Auch darüber, wie unglücklich ich doch mit Ubuntu 20.04 LTS bin. Naja, im Moment egal.

Nein, nicht egal, denn ich kann derzeit mit dem ordinären Ubuntu meine lokalen Webseiten, also mein intranet, nicht mehr nutzen. Dafür gibt es zwei Gründe.

Der eine ist, dass bei der Installation von Apache2, PHP und PHPMyAdmin etwas schiefgelaufen ist. Ich weiß nicht was, aber ich vermute das Problem bei der Konfiguration der Datenbank bei der Einrichtung von PHPMyAdmin. Leider lässt sich der Kram nicht mehr deinstalliern. Der zweite Grund ist, und das ist erheblich, aber wäre auch lösbar, dass ich auf meiner alten Debian-8-Installation noch mit PHP5.6x unterwegs war, Ubuntu 20.04 LTS aber im Standard mit PHP7.4x ankommt. Meine PHP-Scpte würden also nicht mehr laufen - und das tun sie auch wirklich nicht. Ich könnte PHP5.6x versuche zu installieren, aber ich habe keine Lust darauf.

Darum habe ich eine zweigeteilte Lösung erschaffen.

Teil 1
In VirtualBox habe ich Debian 8 Jessie installiert und alles so vorbereitet, wie es auf der abgestürzten Plattform möglich war. Über einen gemeinsamen Ordner habe ich die wichtigsten Teile meines Webservers in die virtuelle Maschine kopiert und war wieder Herr meines Intranets, meine Wissens. Die von mir benötigten Tabellen konnte ich als csv-Dateien exportieren, um sie in SQLite3, also auf dem realen Teil meines Computers, importieren zu können. Siehe Teil 2. Der ganze Kram, der jetzt in der virtuellen Maschine liegt, wird nach und nach auf- und abgearbeitet.

Teil 2
Nun sollte SQLite3 doch eine tragende Rolle bekommen, obwohl das nicht so geplant war. Aber ich hatte herausgefunden, dass ich die im csv-Format exportierten MySQL-Tabellen im DB Browser for SQLite in die Datenbanken, die ich vorher angelegt hatte, importieren konnte. Ratzfatz war das erledigt. Mein Intranet hatte ich innerhalb von 3 Stunden von MySQL auf SQLite3 umgestellt. Ich konnte alle Artikel, die vorhanden waren bzw. sind, wieder aufrufen. Der endgültige Todesstoß für MySQL bzw. MariaDB.

Und es kommt noch besser. Ich nutze Galeriesoftware zur Verwaltung meiner Bilder für die verschiedenen Interessensbereiche. Aus alter Tradition habe ich Coppermine im Einsatz und, weil ich mal was neues haben wollte, auch Piwigo. Coppermine als auch Piwigo nutze ich nur als Sammler meiner Bilder. Die Auswertung der Bilder bzw. dessen Gebrauch findet nur in meinen PHP-Scripten statt. Die Datenbanken anzuzapfen und die Tabellen auszuwerten, um Bilder im Browser in einem Artikel darzustellen, hatte ich schon vor langer Zeit gelernt. Jetzt wollte ich aber nicht mehr, denn MySQL war für mich außer Reichweite und PHP5.6x nicht mehr vorhanden.

Zwar habe ich XAMPP installieren können, aber mein Wunsch ohne MySQL auszukommen, war so stark, dass ich meine eigene Bildergalerie erschaffen habe. Dazu werde ich noch einen Artikel schreiben. Für den Hausgebrauch ist das echt gut. Das einzige, was derzeit noch fehlt, ist die automatische Erstellung von Thumbnails im Code zur Laufzeit. Davon später mehr.

Nach dem Crash ist vor dem Crash. 25 Jahre lang bin ich von Computer-Crashes verschont geblieben. Meinen ersten und letzten Crash für diese lange Zeit hatte ich im Mai 1994. Damals war mir meine Fisch-Datenbank um die Ohren geflogen und war kaputt. Ich hatte mehr als 3.000 Einträge gemacht zu Fischen, die in der Aquaristik gepflegt werden können.

Und dann innerhalb von 10 Monaten ereilt mich das Schicksal zwei Mal. Ob ich etwas daran hätte ändern oder verhindern können, weiß ich nicht. Ich bin mir keine Schuld bewusst. Es scheint wohl Kismet zu sein.

Die Datenverluste beim Crash im Juli 2019 waren nicht schmerzlich. Der Crash im Mai 2020 hat keinerlei Datenverluste verursacht. Alles war schön ordnungsgemäß im Generationenmodus gesichert. Dass ich MySQL nicht nutzen kann, weil die Installation nicht funktionierte, ist eben auch hier eher Schicksal.

Das bedingt für mich nun folgende Konsequenzen und einen Batzen Arbeit:

Hugo
Mein komplettes Intranet mit mehr als 1.000 Artikel aus dem Privat- wie auch Hobbybereich wird auf Hugo mit dem Theme Mainroad umgestellt. Ca. 250 Artikel sind schon drin, davon sind ca. 50 Artikel in den letzten Tagen hinzugekommen.

PHP
Mit PHP werde ich weiterhin arbeiten. Dabei spielt es keine Rolle, ob ich mit einer Datenbank oder mit textbasierten Daten etwas mache. Die Vorteile von PHP, insbesondere bei der Strukturierung von Webseiten, möchte ich mir nicht nehmen lassen. Die Umstellung von PHP5.6x auf PHP7.4x wird mir nicht so schwer fallen, da MySQL keine Rolle mehr spielt.

SQLite3 In den letzten Tage habe ich SQLite3 so richtig liebgewonnen. Ich gehe davon aus, dass SQLite3 nicht die Dominanz von MySQL haben wird. Aber die Vorteile einer Datenbank sind auch von mir nicht von der Hand zu weisen. Es gibt zwar Möglichkeiten, die Datensätze in textbasierten Dateien vorzu halten und diese durch PHP-Scripte auszuwerten, aber der Programmieraufwand ist mir zu hoch. Ich habe es versucht, aber bin an meine Grenzen gestoßen. Etwas habe ich aber doch geschaffen:

… eine Playliste für Video- und Audiodateien mit einem kleinen JavaScript im Hintergrund, da HTML5 keine m3u-Dateien untersützt.

Dieses Tool setzt keine Datenbank ein. Auch davon werde ich berichten und mich gerne dafür auslachen lassen. Ich finde das Teil megageil.

Natürlich setze ich noch viele andere Tools ein. Aber um meinen Webserver zu betreiben und zu nutzen, sind die 3 vorgenanten Programme von großer Bedeutung.

Das ganze Chaos im vergangenen, aber auch in diesem Jahr hat vieles bei mir verändert. Aus dieser Veränderung schöpfe ich Ideen und auch den Mut zur Umsetzung. Die Änerung ist ja mehr oder weniger vorgegeben. Ich habe zwei eigene Tools programmiert, die meine Bedürfnisse abbilden können bzw. sollen (fertig ist man ja nie). Das sind folgende Tools:

Zu diesen beiden Scripten werde ich Artikel schreiben. Auch um zu zeigen, mit wie wenig Aufwand etwas herstellbar ist.

Geschrieben am 03.06.2020