Der vorige Commit behauptete, der Websocket-Weg sei bei Hostsharing die offene
Frage. Das war ein Fehlschluss: Ich hatte den dokumentierten NODE-Weg
recherchiert (Apache + mod_passenger, das kann tatsächlich keine Websockets) und
daraus auf die Plattform geschlossen. Für einen Dienst wie Etherpad nimmt man
aber gar nicht Passenger, sondern „eigener Daemon + Reverse Proxy" — und genau
das ist dokumentiert.
Belege: Hostsharing hat eine eigene Feature-Seite „Reverse Proxy für
WebSockets", und das Wiki zeigt es an Mattermost vor — .htaccess in htdocs-ssl,
`RewriteCond %{HTTP:UPGRADE} ^WebSocket$` und `RewriteRule .*
ws://127.0.0.1:<port>%{REQUEST_URI} [proxy]`, dazu ein von Hostsharing
zugewiesener Daemon-Port und eine systemd-User-Unit für den Neustart. Matrix
Synapse steht ebenfalls im Wiki. Es hat also längst jemand zum Laufen gebracht.
Der Plan sagt das jetzt richtig: aus dem [!]-Knoten mit Ausweich-Alternativen
werden zwei gewöhnliche Aufgaben (Reverse Proxy, systemd-Unit). Übrig bleibt als
Risiko nur, was wirklich eines ist — das dauerhafte Patchen eines öffentlich
erreichbaren Dienstes.
Geprüft: 120 Knoten, keine Warnungen.
mhoennig
f61c043f92
