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. :-)

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

Submitted comments will be subject to moderation before being displayed.