Programme auf anderen Linux-Rechern starten ohne SSH

[Herschel]

Liebe Freunde,

wahrscheinlich suche ich nur nach dem richtigen Begriff, der mich weiterbringt... bin leider kein Experte. Folgendes Problem:

Ein Linux-Rechner "R1" soll die Ausführung verschiedener Programme auf einem anderen Linux-Rechner "R2" veranlassen.

Beide Rechner befinden sich in einem Netzwerk, allerdings lässt R2 aufgrund restriktiver Sicherheitsregeln keinen Zugriff (z.B. per SSH) zu. Umgekehrt ist ok.


Folgende Ideen hatte ich schon:


R1 legt in einem lokalen File die Nachricht/Codewort für R2 bereit: zum Beispiel "shutdown".
R2 schaut sich dieses File regelmäßig per SSH an, ob es etwas zu tun gibt. Ggf. führt R2 dann das zum Codewort gehördende Programm aus und löscht das File.
-> finde ich aber nicht wirklich elegant.
R1 legt in einem lokalen File die Nachricht für R2 bereit und "stupst" R2 an, woraufhin R2 per SSH nachsieht, was es zu tun gibt
-> schon besser, aber ich weiß nicht, wie man das "anstupsen" realisieren könnte.
R1 schickt R2 eine E-Mail -> damit kenne ich mich nicht aus.. braucht es einen Mailserver auf R2?


Aber vielleicht denke ich auch in die falsche Richtung und es gibt etwas viel Einfacheres?

Danke!

[Sauerland1]

Ein Linux-Rechner "R1" soll die Ausführung verschiedener Programme auf einem anderen Linux-Rechner "R2" veranlassen.

Beide Rechner befinden sich in einem Netzwerk, allerdings lässt R2 aufgrund restriktiver Sicherheitsregeln keinen Zugriff (z.B. per SSH) zu. Umgekehrt ist ok.
Dann ist ersteres aber das aushebeln der Sicherheitsregeln......

Da würde ich eher einen ssh-Server einsetzen.

[Herschel]

Hm, vielleicht habe es nicht gut erklärt.

R2 lässt keinen Zugriff von Außen zu. R2 darf aber selbst auf andere Rechner (hier R1) zugreifen. Falls das nötig ist.

Die Programme laufen auf R2 und sollen genau dann ausgeführt werden, wenn R1 es triggert...

[corresponder]

R2 öffnet ein VPN/SSH Tunnel
R1 darf auf R2 Dinge tun

;-)

[marce]

Welche Möglichkeiten / Rechte hast Du denn auf den beiden Systemen? Grundlegend gibt's da viele Möglichkeiten - sei's 'ne kleine Rest-API, Pull seitens R2 ("grob" die Idee, die Du hattest), zusätzliche Deaemons, ...

[Herschel]

Dass man eine SSH Verbindung von der einen Seite aufbauen und in die andere Richtung Befehle ausführen kann, war mir neu. Da aber R1 den Zeitpunkt der Ausführung angibt, müsste der Tunnel ja dauerhaft aufrecht erhalten werden oder?

@marce: Auf R1 habe ich alle Rechte. R2 hat keinen Zugriff auf das Internet, es dürfen keine SSH-Schlüssel erzeugt werden, kein Zugriff über das Netzwerk (Nutzerinteraktion nur über lokale Eingabegeräte). R2 hat aber den SSH-Schlüssel von R1 und kann dort "Dinge tun" :-)
Danke für den Tipp mit der Rest-API, ich schaue es mir mal an.

[nopes]

Die einfache Variante, also R1 schreibt eine Datei, die von R2 ausgewertet wird, finde ich am besten.
Heute gibt es diverse Message Broker - https://en.wikipedia.org/wiki/Message_broker
Damit kannst du dir relativ einfach eine API schaffen. Das ist im Rahmen von IOT entstanden, also potenziell nicht stabil/gut getestet/unsicher.

[Dukel]

[...]Message Broker[...]
Damit kannst du dir relativ einfach eine API schaffen. Das ist im Rahmen von IOT entstanden, also potenziell nicht stabil/gut getestet/unsicher.

Es gab Message Broker schon sehr lange vorher. Sind aber im Rahmen von IoT gewachsen.
z.B.:

IBM MQ is a family of message-oriented middleware products that IBM launched in December 1993

[ThorstenHirsch]

Ich denke auch dass die Variante "R2 pullt eine Datei, die er ausführt" am einfachsten umzusetzen ist. Ein Message Broker wäre mit Kanonen auf Spatzen geschossen.

[Herschel]

Variante "R2 pullt eine Datei" hatte ich sogar schon implementiert und funktioniert gut. Aber wie könnte das "anstupsen" durch R1 funktionieren? Ich denke da immer an so eine Art Ping, den R2 erkennt...

Schön wäre auch, wenn R2 den Absender des Pings erkennt, sodass R2 gezielt dort nach dem Auftrag nachsehen kann.

[marce]

R2 [...] kein Zugriff über das Netzwerk (Nutzerinteraktion nur über lokale Eingabegeräte)
macht das schwer.

[pferdefreund]

Ich habe sowass mal per mail gemacht. Die hatte ein bestimmtes Format und ein Programm überwachte den Eingang in /var/spool/mail. Heute mache ich das auch mit virtuellen Lochkarten aus Hercules. Da läuft eine selbstgeschriebene Jobverwaltung die "Lochkarten" ins Linux-Dateisystem schreibt (mit Append) und ein kleines c-programm wertet das aus und läßt dann scripte und Programme laufen.

[marce]

wenn das Ding keine eingehenden Netzwerkverbindungen zulässt dürfte das Ding auch nicht per Mail erreichbar sein.

So Insel-Systeme sind immer doof - und saubere Lösungen oftmals ein wenig kompliziert zu erreichen.

QnD dürfte weiterhin die Pull-Variante sein - ggf. noch angetriggert via minütlichem cron, der prüft oft das Steuersystem erreichbar ist, dort die Liste der Jobs holt, diese in die lokale Queue packt und dann die Jobliste auf dem Trigger-System löscht. Noch ein wenig Hirnschmalz drumherum um das sowas wie Failsafe, Transaktionssicher und was auch sonst noch alles an gewünschten Anforderungen reinpasst zu bekommen.

[nopes]

Es gab Message Broker schon sehr lange vorher. Sind aber im Rahmen von IoT gewachsen.
z.B.:

Das ist richtig.
Damit hier auch mal ein paar konkrete Message Broker stehen - ich hatte das "Vergnügen" mit allen arbeiten zu müssen und Kanonen auf Spatzen passt ganz gut; vermutlich bin ich da etwas vorbelastet ;):
Apache ActiveMQ: https://github.com/apache/activemq/
RabbitMQ: https://www.rabbitmq.com/
Eclipse Mosquitto: https://mosquitto.org/
ZeroMQ: https://github.com/zeromq/libzmq/

Gibt bestimmt noch ein paar andere, die relevant sind. Diese haben gemeinsam, dass sie ziemlich stark durch IoT entwickelt/gepusht worden sind. Gerade Apache's ActivMQ & Co sind Konfigurationsmonster und ich bin mir sehr sicher, dass man da sehr einfach Fehlkonfigurationen erstellen kann, wo man den Fehler erst bemerkt, wenn es zuspät ist. Bzgl. Einfachheit ist ZeroMQ mein Favorit, damit könnte man auch relativ einfach bescheid sagen, dass etwas zu tun gibt, es liegen auch tolle Tutorials vor, am Ende wirst du aber merken, wie viel weniger Code pollen/pullen braucht.

Bzgl Bescheid geben, wenn es nur um Netzwerk geht, evt einfach auf was serielles dafür ausweichen. Auf der anderen Seite Cron oder Daemon beides nicht so aufwendig zu machen.

[ThorstenHirsch]

ZeroMQ hat keinen Broker.

[nopes]

Jein muss man halt selber implementieren, es wird halt schon in diesen Message Broker Kontext geführt, wobei mir genau der "fehlende Broker" gefällt...

[marce]

Lustige Idee könnte sein: Das Ziel nimmt kein Netzwerk entgegen, hängt aber in diesem - damit könnte man das via PortKnocking machen - nach außen kein Port offen, wenn man aber den "Schlüssel" kennt geht "intern" irgendwas los...

[pferdefreund]

Wieso eingehende Netzwerkverbindung - ein fetchmail im Minutentakt als Hintergrund-Task ist doch eine ausgehende Verbindung. Die wird doch von fetchmail aufgebaut...

[marce]

ah, ok, du willst das so herum lösen - ich vermutete, Du schickst eine Mail an den Server selbst und hoffst, daß da darauf ein Mailserver läuft, der die dann entgegen nehmen würde...

... aber mal ehrlich, bevor ich dann noch anfange, Mails zu parsen lasse ich es bei der aktuellen Lösung via scp.

[pferdefreund]

Kommt halt immer drauf an, von welcher Maschine so was gemacht werden soll. Damals wars ein IBM-Mainfraime mit Z/OS. Der konnte zwar mailen, aber nicht auf Linux-Dateisysteme zugreifen und da hatte ich es halt so gelöst.