Website nicht erreichbar

Computerabsturz

Moin, moin,

ihr werdet euch sicher fragen, warum die Website einige Tage nicht wirklich erreichbar war, sondern beim Aufruf lediglich eine Meldung zu unvorhergesehenen Störungen auslieferte. Ich hasse die Meldung mittlerweile, zeigt sie doch ein schweres PHP-Problem an, das ich mit meinen Mitteln meistens nicht mehr unter Kontrolle bekomme und daher eine Neuinstallation der kompletten Architektur vorziehe. Das ist auch solange kein Problem, wie keine Blogs veröffentlicht wurden. Da ich in der Vergangenheit nicht zu den Musterknaben der Veröffentlichung selbiger Werke gehörte, war das schnell gemacht und nicht von Schmerzten begleitet. Nun hatte ich aber gerade meine Reiseblogs zu Südostanatolien veröffentlicht und deren Verlust wäre schon sehr traurig gewesen. Also habe ich alle Register gezogen die Seite wieder eingerichtet. das Ergebnis könnt ihr in den vorherigen Blogbeiträgen begutachten. Nicht zögern, denn man weiss ja nie, wann wieder mal eine technische Panne die Kommunikation mit der Welt verhindert.

Aber von Anfang an.

Wie ihr bestimmt schon bemerkt habt, wird die Webseite durch das Content Management System (CMS) Drupal verwaltet. Das ganze läuft auf einem Linux Server, was denn sonst? Ihr werdet sicher fragen, warum denn Drupal und nicht Wordpress? Gute Frage, klar. Aber auch hier gibt es, wie fast immer im Leben, mehrere Antworten. Ich habe parallel auch eine Wordpress Installation laufen und ich habe Wordpress auch für den Webauftritt eines Vereins genutzt. Läuft. Kein Problem. Irgendwie einfach zu handhaben und zumindest für den Nutzer und den Admin ohne größere Probleme zu nutzen. Zumindest sind das meine bisherigen Erfahrungen.

Tja, und warum dann Drupal? Das ist eine Entscheidung gewesen, die ich vor längerer Zeit, als ich begann mich mit CMS zu befassen getroffen habe. Irgendwie hatte ich das Gefühl, Wordpress sei zu einfach. Drupal biete mehr Herausforderungen und sei das ernstzunehmendere System. Etwas für die Hartgesottenen unter den Techis.

Wie recht ich hatte. Und wie recht diejenigen Zeitgenossen haben, die in Blogs oder Artikeln immer wieder auf die steile Lernkurve bei Drupal hinweisen.Soll heißen. Geht nicht mal eben so, ist nicht einfach, man muss schon etwas oder auch eine Menge dafür tun, das System unter Kontrolle zu bekommen. Wie Recht diese Leute haben. Vielleicht mit Ausnahm,e meiner persönlichen Lernkurve. da habe ich eher das Gefühl, es handelt sich um eine konstante Waagerechte, die sich standhaft weigert, Neigung himmelwärts aufzunehmen, um auch nur im entferntesten der steilen Kurve nahe zu kommen. Aber man lernt, mit Frustrationen klar zu kommen. Auch ein Wert für sich.

Da ich das Gebiet oder besser die Software nicht kampflos siegen lassen will, habe ich mich natürlich schlau gemacht oder sagen wir, den Versuch unternommen, die Geheimnisse des CMS zu entschlüsseln und das System mit all seinen Finessen in meine Dienste zu stellen. Dabei helfen einem alle möglichen Quellen im weltweiten Netz, begonnen mit der hervorragenden Dokumentation auf drupal.org, das dort beheimatete Forum, mannigfaltige Artikel sowie Bücher im Netz und nicht zuletzt die ganze Welt der Videoclips auf YouTube. Dort gibt es eine Reihe recht guter und umfangreicher Serien zu verschiedenen Fragen rund um Drupal. Und seit einiger Zeit verfolge ich die Videos von Ivan Zugec auf seiner Plattform Webwash. Ivan bringt die einzelnen Fragestellungen wirklich toll herüber und vermittelt in seinen Videos sehr gut die notwendigen Vorgehensweisen und Tricks, erklärt aber auch, warum Dinge in der einen oder anderen Weise zu behandeln sind. Hoffnung keimt in mir auf, die Lernkurve zumindest in die 45 Grad Position zu bewegen. So abonnierte ich hoffnungsfroh seinen Newsletter und freute mich auf tiefe Einblicke in die Welt der Display Suite. Ein Modul, dass in jede Drupal Installation gehört und manche Bremse der Seitengestaltung löst. OK, ihr werdet sagen, die sind aber immer noch angezogen. Ja, davon berichte ich ja gerade. Die Befreiung läßt noch etwas auf sich warten.

Also, gleich die erste Lektion, die per E-Mail kam verschlungen und nicht nur das, auch gleich nachvollzogen. Und das Desaster nahm seinen Lauf. Eigentlich nichts besonderes. Ich vermute, so beginnen viele Geschichten eines Desasters. Und auf einem Produktivsystem ist das dann ein wirklicher Showstopper, wenn es nicht funktioniert. Installiert werden sollten nur einige Module. Natürlich die Display Suite und das Modul Layout_Plugin. Und damit begann der Anfang vom Ende.

Die Installation läuft bei mir, da Drupal PHP basiert ist und daher von Abhängigkeiten nur so strotzt, mittels des Programms Composer. Das löst automatisch alle PHP Abhängigkeiten auf und wird mittlerweile von den Drupal Maintainern als die Standard Installationsmethode empfohlen. Klappt auch problemlos, wobei das natürlich nicht ganz stimmt, denn sonst würde ich ja nicht diesen Blog verfassen können oder besser gesagt, müssen.

Das Problem ist das Layout_Plugin Modul. Dies muss heute nicht mehr installiert werden, da sich die benötigten Abhängigkeiten mittlerweile im Drupal Core befinden. Seufz. das hätte man vorher wissen sollen. Ein Blick in die Fehlerdatenbank hätte wahrscheinlich auch zur Vorsicht gemahnt. Aber wie es so ist. Hinterher ist man immer schlauer. Lange rede, kurzer Sinn. Die Installation brach das komplette System. Mir ist immer noch schleierhaft, warum das so ist. Tatsache ist aber, dass ihr danach bei einem Aufruf der Webseite eben die berühmte Meldung erhaltet.

Aus dem Webserver Fehlerprotokoll sind ellenlange Fehlermeldungen zu erkenne, die letztendlich das Fehlen von Programmen oder deren Teile an bestimmten Stellen im Code monieren. Eine Suche mit Google hilft nur insofern weiter, als in den verschiedenen Foren, etwa bei Drupal, ServerVault oder Stackoverflow zwar alle möglichen Tipps zur Behebung des Problems oder für Work arounds gegeben werden, die aber in meinem Fall nicht geholfen haben.

Nach langem Lesen und Ausprobieren habe ich mich dann für eine Neuinstallation entschieden. Und wie bereits angedeutet. Eigentlich schnell zu machen, aber ....

Und da schlich sich doch noch ein Grinsen in mein Gesicht. ich hatte, und man glaubt es nicht, kurz vor dem Drama ein Backup Modul installiert und so eingerichtet, dass periodisch Datenbank Backups durchgeführt werden. Unglaublich. Das funktioniert sogar und ließ mich auf einen guten Ausgang dieser Geschichte hoffen. Aber, wenn es am Schönsten ist, muss man nicht lange auf den Rückschlag warten. Die gesicherte MYSQL Datenbank ließ sich zwar problemlos in die neu installierte Datenbank einspielen. Es müssen aber in der Datenbank die fehlerhaften Pfadbeschreibungen, die ich vorher erwähnte, mit gespeichert gewesen sein. Die Installation lief zwar glatt durch. Aber bei einem Aufruf verschiedener Menüs begrüßte mich immer wieder die kleine, aber wirklich unschöne Fehlermeldungen. Wieder einmal machte sich Frust breit und die Lernkurve schien eine negative zu werden und einer schrägen, um nicht zu sagen, sehr schrägen Ebene in die Tiefe zu folgen. Aber solche Momente führen dazu, dass man sich noch etwas mehr mit seinem System beschäftigt und so analysierte ich die einzelnen Felder der gesicherten Datenbank. Unter den Nodes, das sind alle irgendwie gestalteten Inhalte in Drupal, wurde ich fündig. Dort konnte ich die einzelnen Blogbeiträge (Node Body), die einzelnen Blogüberschriften und und auch die mit den Blogbeiträgen gespeicherten Fotos, bzw. deren Betitelung sehen. Und daraus liessen sich dann die einzelnen Artikel rekonstruieren. Das Ganze wurde dadurch vereinfacht, dass in jedem einzelnen Datenbankfeld die gleiche Nummerierung des Artikels auftauchte, womit eine einfache Zuordnung der verschiedenen Felder möglich wurde.

Blieb nur noch das Problem der Reihenfolge. In der Datenbank tauchten die Artikel der zeitlichen Reihe nach auf und zwar der erste Artikel ganz oben. Da der erste Artikel im Leben eines CMS nach unten rutscht, war es recht einfach, die Blogs der zeitlichen Reihe nach zu rekonstruieren. Zusätzlich half noch eine Spalte mit Zahlenwerten. Bei genauerem Hinsehen stellten sich diese als UNIX Zeitstempel heraus. Da machten sich frühere Lesestunden in diversen Linux Handbüchern und ein offensichtlich noch funktionierendes Gedächtnis bezahlt. Ich hatte über die Thematik damals schon gelesen und konnte daher mit den Zahlenwerten etwas anfangen. Eigentlich ganz einfach. Bei der Unixzeit werden die vergangenen Sekunden seit Donnerstag, dem 1. Januar 1970, 00:00 Uhr UTC, wobei Schaltsekunden nicht mitgezählt werden, gemessen. Der 02. Mai 2018, 13:45 Uhr wird also als Zahlenwert 1525261500 dargestellt. Also mußte nur noch ein Unixzeitumrechner her. Und wieder war das Netz mein Freund. Die Konvertierung des Zeitstempels in die gregorianische Form geht schnell und gibt den auf die Zehntelsekunde genauen Zeitpunkt der Erstellung des Artikels wieder. damit ausgerüstet, wurde die zeitliche Sortierung der Blogbeiträge noch einmal bestätigt und die Artikel weisen den ursprünglichen Zeitstempel auf. Der Chronist ist glücklich. Allerdings war es schon etwas mehr Arbeit. Abgesehen vom Copy and Paste, mußten noch eine Reihe von HTML-Steuerzeichen entfernt werden, die in der Datenbank mitgespeichert wurden. Aber das sind nur Kleinigkeiten im Vergleich zu der großen Aufgabe der Restaurierung meiner Webseite.

Ich freue mich, Euch weiter mit Blogbeiträgen versorgen zu können. Ivan werde ich auch noch schreiben. mal schauen, was er sagt. Und dann hoffe ich auf einen künftigen reibungslosen Betrieb meiner Webseite. Es müssen ja nicht immer die Fehler sein, aus denen man lernt. Ist anders auch ganz schön. Aber zunächst werde ich mal ein Backup machen.

Man weiß ja nie.

Bis dann

Euer omongkosong

Kommentare

Ja, das habe ich mich Tag und Nacht gefragt, wo Du bzw Dein Auftritt geblieben sind. Hatte dann gedacht, Du hättest das Bloggen dran gegeben 😁😂. Aber man empfindet tatsächlich ein Verlust-Schmerz, wenn die Einträge plötzlich weg sind, oder? Gibs zu!

Ruby 

Antwort auf von Ruby Tuesday

Moin, moin, Ruby,

so schnell wird nicht aufgegeben, wo doch das Bloggen mit dem Reisebericht über Südostanatolien erst richtig angefangen hat. Verlust Schmerzen gab es nicht. Aber das Malheur hat natürlich den Techi in mir wieder mal geweckt. Wenn der sich auch nach wie vor in einem infantilen Stadium befindet. Aber kann ja noch wachsen und da sind solche Gelegenheiten günstig :). War allerdings einiges an Arbeit. da kann man schon fast froh sein, dass die Blog Ausbeute noch sehr gering war. Und da ich gerade dem englischen Begriff "Lazy Bone" die Ehre erweise, hatte ich auch Zeit, dass Malheur zu einem guten Ende zu bringen. Eine alte Admin Regel "Backup first" oder "There is nothing worth, then no backup" bekommt da einen ganz anderen Klang. Klingt ja ziemlich trivial. Aber Backups sind gar nicht so einfach zu handhaben, wenn es an die Wiederherstellung geht. Da erlebt man dann seine Überraschungen. Also sollte man Testsysteme vorhalten, um die Szenarien vorab schon einmal durchzuspielen. Wird langsam aufwändig. Und das nur für ein paar Zeilen :). Aber es macht Spaß und man muss nicht die Vorabendserien schauen. das beflügelt doch.

Bis dann

omongkosong

... ich einen neuen Kommentar schreiben.

Was ist aus der Pressefreiheit geworden. Mein Kommentar wurde zensiert. Oder stand da was im Kooperationsvertrag für Versuchskaninchen 🐇? 

Ruby

Antwort auf von Ruby Tuesday

Pressefreiheit bestimmt der Admin. Und Versuchskaninchen braucht man doch bei einer voll funktionsfähigen Spitzen Website nicht.

Antwort auf von omongkosong

Ach so, für Admin gibt's aber auch noch andere Bezeichnungen. Mir fällts grad nicht mehr ein 🤔😈☻. In den Nachrichten hört man schon mal davon.

Es grüßt die Ruby 

Antwort auf von Ruby Tuesday

ist doch schön, wenn man so bekannt ist, dass einem schon Sendeplätze gewährt werden. Alles richtig gemacht 😁😉.

Antwort auf von omongkosong

Sowieso, Du machst ja grundsätzlich alles richtig. Ich hätte da mal einen Tipp um Deinen Blog visuell noch attraktiver zu machen, auch wenn das kaum möglich ist. Ich würde bei Deinem Namen ein Bild hinterlegen. Einen Balinesischen Drachen fänd ich gut. Würde zu Deinem Namen passen. Ich weiß, Indonesien ist nicht ausschließlich Bali, trotzdem, sähe bestimmt gut aus. Wollte Dir ein Bild schicken, habe ich jetzt aber so einfach nicht hinbekommen. Was hältst Du davon? 

Hatte ich noch gar nicht so gesehen, dass es nicht noch besser werden kann. Aber man lernt ja nie aus :). Wieso ein Drachen zu dem Begriff omong kosong passt, erschließt sich mir zwar nicht, aber warum nicht. Muss mal schauen, welche lizenzfreien Bilder es so im Netz gibt. Bei dem Stichwort "Indonesian Dragon" wimmelt es nur so von Komodo Varanen. Wohl nicht das Richtige. Bei dem Stichwort "Balinese Dragon" ist die Auswahl ziemlich trüb. Schaue mal auf anderen Plattformen als Google.
Noch weitere sachdienliche Hinweise?

 

Antwort auf von omongkosong

Ja, so schnell gehen mir die sachdienlichen Hinweise nicht aus. Ich fände es praktisch, wenn man einen Kommentar schreibt und Du darauf antwortest, dass ich bzw der Autor eine Mailbenachrichtigung bekommt. Hatte ich zwar neulich schon mal gefragt, aber noch keine Antwort bekommen. Wahrscheinlich war meine Frage mal wieder unpräzise formuliert. 

Nun zum Drachen und omong kosong. Wenn man einen indonesischen Namen wählt, wäre es doch nett, wenn das Bild dazu passt. Zu bla bla wirst Du nichts finden. Wie gesagt, der balinesische Touri Drachen war ja nur eine Idee. Vielleicht geht auch ein Tempel. Finde es irgendwie schön, wenn man eine visuelle Wiedererkennung hat, die dann auch noch im Zusammenhang zum Namen steht. So wie bei mir die Stones Zunge zur Ruby Tuesday.

Verstehst Du?