Ach je, das war ein Schaff! đ
Auf einem unserer Server im Institut setzen wir Redmine als Ticketsystem ein, welches auf Ruby on Rails basiert. Das bedeutet im Umkehrschluss, dass unser freundlicher Indianer-Webserver Apache die Anwendung nicht einfach mit Bordmitteln ausgeben kann. (Nginx ĂŒbrigens auch nicht, welchen ich inzwischen aus Performance-GrĂŒnden bevorzuge đ )
Der Apache wird daher um einen kleinen Web-App-Server namens „Passenger“ von Phusion erweitert. Das ganze lĂ€uft erstaunlich stabil, auch wenn der Passenger nach einem Reload oder Neustart von Apache tatsĂ€chlich 10-20 Sekunden benötigt, um wieder hochzufahren. Wenn es dann mal lĂ€uft, lĂ€uft es.
Um den Passenger zu installieren sind mehrere Konfigurationsdateien notwendig, u.a. auch in „mods-enabled“ und im „conf.d“ vom Apache. Als ich nun neulich auf Debian Buster upgraden wollte, scheiterte es nach erfolgreichem Upgrade dann allerdings an der Tatsache, dass der Passenger sich konstant weigerte zu laufen.
…zumindest glaubte ich das, denn der Apache war nur einen 403-Fehler mit dem Logeintrag, dass er keine Index-Datei im Verzeichnis finden konnte. An sich korrekt, wenn kein Passenger lĂ€uft, denn im Regelfall sollte die Anfrage an den Passenger weitergeleitet werden, der dann den entsprechenden Output generiert (einfach ausgedrĂŒckt).
Meine Vermutung war also, dass Passenger einfach nicht lĂ€uft. Ein Blick in die Prozessliste sagte aber, dass der Passenger fröhlich vor sich hin lĂ€uft und ich konnte partout keine Problemursache finden. Ich habe in meiner Verzweiflung den Passenger sogar noch mal neu kompilieren lassen – was ĂŒbrigens hundert Milliarden Jahre dauert, gefĂŒhlt.
Bis ich dann irgendwann auf StackExchange (wo auch sonst) den rettenden Hinweis gefunden habe! Es gibt einen sehr versteckten Befehl der Passenger-Konfiguration:
passenger-config validate-install
Dieser prĂŒft die Installation auf mögliche Probleme, also quasi die „Windows Fehlerbehebung“, nur in sinnvoll und nĂŒtzlich. Und was soll ich sagen: Beim Upgrade auf Debian Buster – und dem damit einhergehenden Upgrade von RoR und dem Phusion Passenger – wird eine neue Version des Passengers installier (6.x).
Freundlicherweise legt der Upgrade-Installer auch einen Link in den „mods-enabled“ und „conf.d“ an, entfernt aber nicht den alten Eintrag. Dieser alte Eintrag wiederum stört Apache nicht solange der Dateipfad zur alten Version noch existiert. Ob der alte Passenger lĂ€uft oder nicht ist dann auch egal, Apache leitet stoisch den Datenverkehr ins Nirvana. Und aus irgendwelchen GrĂŒnden meldet sich auch Passenger nicht, wenn zwei Versionen parallel laufen – oder eben nicht laufen.
So kam es also, dass Apache den Passenger 5.3.7 ansteuern wollte, in der RealitÀt aber nur der Passenger 6.0.4 lief. Die beiden Anwendungen redeten also unbemerkt aneinander vorbei.
Durch den o.g. Validate-Befehl wurde mir dann aber der richtige Hinweis gegeben, nĂ€mlich dass zwei Konfigurationsdateien fĂŒr Passenger existieren und ich möge mich doch bitte fĂŒr eine entscheiden, wenn ich nicht zwei Versionen parallel laufen habe.
Nichts leichter als das!
Alle Konfigurationsdateien, v.a. im Apache-Verzeichnis, vom 5.x gelöscht und sicherheitshalber noch mal die Configs vom 6.x geprĂŒft – zack, lĂ€uft. đ