Reparatur eines verschachtelten CGI-Verzeichnisses
1. FEHLER
Bei einem fehlerhaft installierten Release kann das komplette GoeChem-Repository als zusätzliches Unterverzeichnis im CGI-Verzeichnis landen, statt korrekt in die beiden vorgesehenen
Zielverzeichnisse (CGI-Verzeichnis und HTML-/DocumentRoot-Verzeichnis) aufgeteilt zu werden.
Beispiel (CGI-Verzeichnis sei /var/www/cgi-bin/goechem-cgi):
/var/www/cgi-bin/goechem-cgi/
cf00.cgi <- richtig, sollte hier liegen
cfsa02.cgi <- richtig, sollte hier liegen
module/ <- richtig, sollte hier liegen
aktualisierungen/ <- richtig, sollte hier liegen
goechem-cgi/ <- FALSCH, gehört nicht hierher
cf00.cgi <- eine zweite, meist AKTUELLERE Kopie
module/
aktualisierungen/
...
goechem/ <- FALSCH, gehört ins HTML-Verzeichnis
css/
js/
...
Die beiden fehlerhaft angelegten Verzeichnisse "goechem-cgi" und
"goechem" innerhalb des CGI-Verzeichnisses sind das Erkennungsmerkmal
für dieses Problem.
2. AUSWIRKUNG
Der Webserver führt weiterhin ausschliesslich die ALTEN Skripte im CGI-Wurzelverzeichnis aus. Die eigentlich aktuellen, gerade
installierten Skripte liegen ungenutzt im Unterverzeichnis "goechem-cgi/goechem-cgi" und werden nie ausgeführt.
Da jede weitere Installation über genau diese veralteten Skripte läuft, wiederholt sich der Fehler bei jeder weiteren Aktualisierung
von neuem - das System aktualisiert sich dadurch dauerhaft NICHT mehr, auch wenn die Installation in der Weboberfläche als erfolgreich gemeldet wird.
3. URSACHE
Ein sehr alter Stand des Release-Workers (aktualisierungen/gca_release_worker.cgi) verwendet noch eine Auto-Erkennung statt der mittlerweile mitgelieferten Datei "release.json", die eindeutig
vorgibt, wohin welche Verzeichnisse aus dem Release-Paket gehören.
Diese alte Auto-Erkennung kann durch einzelne Dateien im Wurzelverzeichnis des Pakets fehlgeleitet werden und kopiert dann das gesamte Paket unaufgeteilt in das CGI-Verzeichnis.
Da der fehlerhafte Kopiervorgang selbst wiederum eine aktuelle Kopie des Release-Workers mit ausliefert (nur eben am falschen Ort), kann
sich das System aus eigener Kraft nicht mehr reparieren: der aktive, alte Worker wird nie durch den mitgelieferten neuen ersetzt, weil dieser nie an der richtigen Stelle landet.
4. WIE MAN DAS PROBLEM ERKENNT
a) Im CGI-Verzeichnis prüfen, ob dort ein Unterverzeichnis mit dem
gleichen Namen wie das CGI-Verzeichnis selbst existiert
(im Beispiel oben: "goechem-cgi"), das seinerseits Dateien wie
cf00.cgi, ein Unterverzeichnis "module" und ein Unterverzeichnis
"aktualisierungen" enthält:
ls -la /var/www/cgi-bin/goechem-cgi/
b) Zusätzlich findet sich dort meist auch ein Unterverzeichnis
"goechem" (die fälschlich mitkopierten Web-Assets, die eigentlich
in das HTML-/DocumentRoot-Verzeichnis gehören).
c) Im Installationsprotokoll (in der GoeChem-Weboberfläche unter
"Log anzeigen" bei einem Release, oder direkt in der Logdatei
«Datenverzeichnis»/hglog/prot_cfsa02_«commit».gcl) erscheint eine
Zeile ähnlich:
Auto-Detection: 1 funktionale Datei(en) im Root - deploye
Root-Inhalt direkt nach {cgi_root}
oder (bei einem noch älteren Stand):
Kein manifest.json - keine Tasks, Fallback-Deploy wird verwendet
Beide Formulierungen bestätigen, dass der aktive Release-Worker
veraltet ist und die Auto-Erkennung statt der korrekten
release.json-Regeln verwendet hat.
5. REPARATUR
Voraussetzung: Zugriff auf die Serverkonsole (SSH) mit ausreichenden
Rechten, um im CGI-Verzeichnis Dateien zu verschieben und Rechte zu
setzen (i.d.R. derselbe Benutzer, dem das CGI-Verzeichnis gehört,
oder root/sudo).
Im Repository liegt für genau diesen Fall das Werkzeug "admin/repair_nested_cgi.cgi" bereit. Es ist bewusst vollständig
unabhängig von der GoeChem-Konfiguration geschrieben (kein Zugriff auf Datenbank oder Konfigurationsdatei nötig) und funktioniert daher
zuverlässig auch dann, wenn es selbst - wie im obigen Beispiel - nur in der fehlerhaft verschachtelten Kopie vorliegt.
Schritt 1 - Werkzeug finden:
Zuerst prüfen, ob "admin/repair_nested_cgi.cgi" im richtigen
(obersten) CGI-Verzeichnis vorhanden ist:
ls /var/www/cgi-bin/goechem-cgi/admin/repair_nested_cgi.cgi
Ist die Datei dort NICHT vorhanden, liegt sie stattdessen in der
verschachtelten Fehlkopie:
ls /var/www/cgi-bin/goechem-cgi/goechem-cgi/admin/repair_nested_cgi.cgi
(Pfad ggf. an das tatsächliche CGI-Verzeichnis des Servers
anpassen.)
Schritt 2 - Probelauf (empfohlen):
Mit dem Schalter --dry-run zeigt das Werkzeug an, was es tun würde,
ohne etwas zu verändern:
perl /var/www/cgi-bin/goechem-cgi/admin/repair_nested_cgi.cgi --dry-run
bzw., falls das Werkzeug nur in der Fehlkopie liegt:
perl /var/www/cgi-bin/goechem-cgi/goechem-cgi/admin/repair_nested_cgi.cgi --dry-run
Erwartete Ausgabe bei einem tatsächlich betroffenen System:
Verschachtelte Fehlkopie erkannt: /var/www/cgi-bin/goechem-cgi/goechem-cgi
-> Inhalt wird nach /var/www/cgi-bin/goechem-cgi übernommen
(--dry-run: keine Änderung durchgeführt)
Erscheint stattdessen "Weder als echtes CGI-Root noch als
verschachtelte Fehlkopie erkennbar - nichts zu tun.", liegt kein
Fall dieses bekannten Problems vor - in diesem Fall nicht
fortfahren, sondern die Ursache anderweitig klären.
Schritt 3 - Reparatur ausführen:
Denselben Befehl ohne --dry-run erneut ausführen:
perl /var/www/cgi-bin/goechem-cgi/admin/repair_nested_cgi.cgi
Das Werkzeug kopiert alle Dateien und Unterverzeichnisse aus der
Fehlkopie eine Ebene nach oben in das echte CGI-Verzeichnis
(bestehende gleichnamige Dateien werden dabei durch die aktuellere
Fassung aus der Fehlkopie ersetzt), setzt die Ausführungsrechte der
*.cgi-Dateien korrekt und entfernt anschliessend die nun leere
Fehlkopie.
Schritt 4 - Ergebnis prüfen:
ls /var/www/cgi-bin/goechem-cgi/
Das Unterverzeichnis mit dem verschachtelten Duplikat sollte jetzt
nicht mehr vorhanden sein.
6. NACH DER REPARATUR
Die Reparatur betrifft ausschliesslich das CGI-Verzeichnis. Das fälschlich mitkopierte Verzeichnis "goechem" (Web-Assets) sowie
weitere überflüssige Dateien/Verzeichnisse (z.B. ".claude", "validierung", lose Markdown-Dateien im CGI-Verzeichnis) werden davon NICHT berührt.
Dafür ist die Aktualisierung "aktualisierungen/gcautakt00054.cgi" zuständig, die ab jetzt automatisch greifen sollte: entweder beim
nächsten Login eines beliebigen Benutzers (über cf00.cgi) oder bei der nächsten Installation über die GoeChem-Weboberfläche. Sie
findet die Datei jetzt am richtigen Ort, weil Schritt 3 sie mit an die richtige Stelle gebracht hat.
Ist nach einem erneuten Login/einer erneuten Installation immer noch kein Erfolg zu beobachten, kann diese Aktualisierung ebenfalls manuell angestossen werden:
perl /var/www/cgi-bin/goechem-cgi/aktualisierungen/gcautakt00054.cgi
Abschliessend empfiehlt sich ein Blick in die Weboberfläche (Systemaktualisierungen / Releases), ob eine erneute Installation des aktuellen Commits jetzt korrekt und mit den erwarteten zwei getrennten
Zielverzeichnissen ("Deploy: .https://newsletter-admin.goechem.de/goechem-cgi -> {cgi_root}" und "Deploy: .https://newsletter-admin.goechem.de/goechem -> {htdocs_root}" im Log) durchläuft.
7. SICHERHEITSHINWEIS
Sowohl "admin/repair_nested_cgi.cgi" als auch die bereits länger vorhandenen Werkzeuge "admin/install.cgi" und "admin/setup_service.cgi"
sind bewusst NICHT über den Webserver aufrufbar (Dateirechte 0600, kein Ausführungsrecht für den Webserver-Benutzer). Sie dürfen
ausschliesslich von der Konsole mit ausreichenden Rechten gestartet werden. Ein Aufruf über eine Web-URL funktioniert nicht und ist auch nicht vorgesehen.
Mit freundlichem Gruß,
Ihr GoeChem-Support