auf Port lauschen und erst dann Dienst starten

[Tunybrk]

Hallo,

ich lasse einen Proxy Server manchmal auf meinem Debian laufen.

Also ich startet diesen manuell über die Console und beende diesen nach dessen Nutzung wieder.


Gerne würde ich diesen start-prozess automatisieren.

Ich habe mir gedacht, ich müsste doch nur auf dem Proxy-Port auf irgendwelche Signale warten und lasse dann sofort den Proxy hochfahren.

Dabei erinnerte ich mich an inetd. Habe mich dahingehend etwas eingelesen. Doch wenn ich es richtig verstanden habe, wird der Port zum starten nicht freigegeben und der Proxy-Server könnte deshalb nicht anlaufen.

Ich hab mir gedacht, vielleicht könnte man den TCP Port einfach von inetd dann auf einen anderen (des alternativen Proxy-Ports) umleiten. Aber ich glaube das wird hier dann jetzt doch schon zu kompliziert, oder?

Gibt es hier vielleicht andere Methoden?
Es wäre nicht schlimm, wenn der Port beim ersten Versuch nicht richtig antwortet und erst beim zweiten Versuch eine Antwort vom Proxy erhält.

Vielleicht könnte man das irgendwie über die Firewall Regeln starten?


Grund für mein Vorgehen. Das System hat nicht ganz soviel RAM. Resourcen sparen. Der Proxy kommt vielleicht 2-3 mal im Monat in Einsatz.

[whisper]

gib mal apt search knock ein, da kommt einiges...

[MSfree]

Vielleicht könnte man das irgendwie über die Firewall Regeln starten?

Eventuell kannst du etwas mit knockd basteln.

Grund für mein Vorgehen. Das System hat nicht ganz soviel RAM. Resourcen sparen. Der Proxy kommt vielleicht 2-3 mal im Monat in Einsatz.

Welcher Proxy kommt denn zum Einsatz?

Ich habe bei mir viele Jahre einen Squid auf einem VIA Epia mit 600MHz Takt und 256MB RAM ohne Swap-Partition laufen lassen. Squid selbst hat dabei ca. 30MB RAM gebraucht, allerdings nicht in der Default-Konfiguration. Wenn man will, kann man den so sparsam konfigurieren, daß man den immer mitlaufen lassen kann.

[mat6937]

Dabei erinnerte ich mich an inetd. Habe mich dahingehend etwas eingelesen. Doch wenn ich es richtig verstanden habe, wird der Port zum starten nicht freigegeben und der Proxy-Server könnte deshalb nicht anlaufen.

Wenn der Proxy-Server mit dem inetd "zusammenarbeiten" kann, dann wird nach einem Portscan (Verbindungsversuch) auf den konfigurierten/lauschenden Port des inetd, der Proxy-Server schon gestartet und lauscht auf seinem (eigenen) Port bzw. steht zur Verfügung.

[heisenberg]

Ist das nicht eines der Basisfähigkeiten von systemd? socket based activation?

Das sieht mir danach aus.
https://unix.stackexchange.com/question ... -listening

Oder ohne systemd halt mit inetd bzw. xinetd?

[mat6937]

Ist das nicht eines der Basisfähigkeiten von systemd? socket based activation?

Das sieht mir danach aus.
https://unix.stackexchange.com/question ... -listening

Im Beispiel wird socat mit einer (vom Benutzer/user erstellten) service unit benutzt. socat gab es schon vor systemd und geht/ging auch mit SysV.

socat verbraucht auch Ressourcen, ist m. E. aber OK wenn die eigene Anwendung mit inetd nicht kann oder inetd nicht aktiv ist bzw. nicht genutzt werden soll.

[MSfree]

Oder ohne systemd halt mit inetd bzw. xinetd?

Ich habe bei mir zum Verteilen der Proxykonfiguration mittels WPAD einen ganz einfachen HTTP-Server an xinetd angeschlossen. Dabei öffnet der HTTP-Server selbst gar keine Ports, der bekommt über stdin/stdout seine Verbindung zum xinetd.

Meines Erachtens sind die Meta-Server wie inetd und xinetd (und eventuell auch systemd) gar nicht konzipiert, die Kontrolle über einen Netzwerkport abzugeben, und auch die aufgerufenen Slave-programme kommunizieren nur per stdin/stdout mit dem Meta-Server. Aus dem holen Bauch heraus hätte ich gesagt, daß Meta-Server nicht geeignet sind, den eigentlichen Sever zu starten.

Selbst, wenn man den Meta-Server auf einem anderen Port lauschen läßt als der eigentlich zu startende Dienst, würde doch mit jedem neuen Kontakt eine neue Instanz gestartet werden und mehrere squids will man eigentlich nicht gleichzeitig auf dem System.

Wie das bei systemd gelöst ist, weiß ich nicht. Sollte es aber ähnlich gelöst sein wie bei (x)inetd, funktioniert diese Methode auch nicht.

[mat6937]

Selbst, wenn man den Meta-Server auf einem anderen Port lauschen läßt als der eigentlich zu startende Dienst, würde doch mit jedem neuen Kontakt eine neue Instanz gestartet werden und mehrere ...

Nein, denn der Meta-Server weiß dann, dass der Dienst bereits gestartet ist und startet diesen dann nicht erneut.

Ich starte z. B. den ircd (eigener Port) mit dem inetd (eigener lauschender Port 43876, nur zum starten des ircd). Zeile in der inetd.conf:

Code: Alles auswählen

43876	stream	tcp	nowait	irc	/usr/sbin/ircd -i -c -b -s -p standalone -T /etc/ircd/ircd.tune

[scientific]

Ich würd auch auf systemd mit socket-activation setzen.

lg scientific