RootForum Community

Guten Abend,

ich möchte eine Verbindung zwischen zwei Servern aufbauen,
um Informationen auszutauschen (Keine Dateien).

Ein Beispiel wäre, die Temperatur von Server A an Server B zu senden.
Server B arbeitet mit diesen Werten und sendet an Server A Lüfter an/aus.

Was ich versuche zu finden,
ist das Verfahren / ein Tipp, mit dem ich diese Aufgabe umsetzten kann.

z. B. auf beiden Servern ein bash-Script laufen lassen und auf einem bestimmten Port höhren.

Wäre super, wenn mir jemand einen Tipp geben könnte,
in welche Richtung / Software / Programmiersprache ich gehen muss.

Beste Grüße

Hmm - stunnel, SSH mit Port Forwarding oder ein VPN wären vielleicht ein Ansatz.
Wenn es auf Echtzeit nicht ankommt könnte man per Cron auch eine Mail triggern die an Server A bzw. Server B gesendet wird und dort ausgewertet wird.

Wenn Du quasi ein eigenes Protokoll, entwickeln möchtest, dann würde ich das auf basis socket Verbindung auf bauen.
Wenn aber ein bestehendes Protokoll ausreicht z.B. http dann würde ich ein einfaches PHP Script basteln und den Austausch der Daten per POST oder GET aufrufe erledigen.
Clientlibs für diverse Sprachen gibt es inzwischen zu genüge.
De Antwort kannst Du z.B. in form eines csv oder gar gleich als XML? ja ebenfalls einfach empfangen und auswerten.

Ein einfaches Sockel Beispiel in c:
https://github.com/dermesser/echosrv

Java Message Service:
http://de.wikipedia.org/wiki/Java_Message_Service
Quasi mit XML Dokumenten arbeiten.

httpd Requests:

http://www.webmasterworld.com/forum13/4172.htm

curl wäre u.a. ein nettes Tool.
Alternativ geht es auch mit Perl oder PHP.

Als SOAP Lösung:
http://users.skynet.be/pascalbotte/rcx- ... rlpost.htm

Und per PHP
http://www.php-faq.de/q-code-post.html

Natürlich geht das auch per GET Methode.
Dann genügt theoretisch schon
wget --output-document=OutputDATEI http://www.server.de/index.php?key=Value&key2=value2


Ob man dafür gleich nen ganzen Webserver betreiben will sei man dahin gestellt.

Die simpelste Lösung für die Temperaturgeschichte dürft sein: Die retunrvalues bzw, ausgabeu auf dem Zielsystem kann man per Backpipes in eine Variable umleiten oder z.B. per Pipe | an andere Dienste weiterleiten.

Wenn ssh keys hinterlegt wurden, sollte das perfekt klappen.

Das OpenSSL-Paket bringt einfache Client- und Serverkomponenten mit:

http://www.openssl.org/docs/apps/s_server.html
http://www.openssl.org/docs/apps/s_client.html

Damit und mit ein bisschen Shell-Skripting kann man einfache Informationen übermitteln - für komplexere Aufgaben bietet sich dann aber eine Skriptsprache wie Perl, PHP oder Python an - alle drei bringen geeignete Module mit, um einfache Listener zu bauen und Daten in artgerechter Haltung zu übermitteln (JSON, XML, YAML, ...).

daemotron wrote: Damit und mit ein bisschen Shell-Skripting kann man einfache Informationen übermitteln - für komplexere Aufgaben bietet sich dann aber eine Skriptsprache wie Perl, PHP oder Python an - alle drei bringen geeignete Module mit, um einfache Listener zu bauen und Daten in artgerechter Haltung zu übermitteln (JSON, XML, YAML, ...).

BTW: Welche Module bieten sich da an, in Punkto Sicherheit und Verschlüsselung.
Ich bin aus dem thema "länger" raus, daher kann ich nur auf früherer Erfahrungen zurück greifen und da hatte ich bisher kein gutes Gefühl. Entweder zu komplex in der Anwendung, zu instabil oder ein Sicherheits bzw. Berechtigungskonzept grundsätzlich nicht vorhanden.

Ich würde folgende Grundsatzregeln formulieren: "Wenn Du persistente Daten verschlüsseln musst, nimm GPG. Wenn Du hingegen eine Transportverschlüsselung realisieren musst, nimm SSL." (so oder zumindest sinngemäß hat sich auch Colin Percival auf der 2010er BSDCan geäußerst).

Zugegeben, SSL ist komplex. Egal welche Implementierung (OpenSSL oder GnuTLS); die Einbindung von SSL in eigener Programme bedarf umfangreicher Handbuch-Lektüre und etwas Erfahrung. Ich habe selbst mehrere Programme (sowohl Clients als auch Server) auf OpenSSL-Basis in C verzapft - es gibt da einige Fallstricke, und die Interfaces gerade von OpenSSL sind nicht ganz ohne. Dazu kommt noch, dass SSL schon konzeptionell an einigen Stellen "um die Ecke denkt" und auch einige Design-Schwächen aufweist. Trotzdem ist es momentan das beste (und besterprobte), was es an Protokoll und Implementierung gibt.

Wer selbst Hand anlegen und eigene Programme in C schreiben möchte, dem würde ich zu OpenSSL raten. Die Doku ist zwar gewöhnungsbedürftig, aber einigermaßen vollständig. Außerdem ist OpenSSL sauberer implementiert als GnuTLS und besser portabel.

Bei Perl bin ich nicht mehr so ganz auf dem laufenden, aber je nach Anwendung würde ich wahrscheinlich Socket::Class::SSL oder POE::Filter::SSL verwenden. Nach PHP fragt bitte jemand anderes - das Zeugs habe ich seit Jahren nicht mehr angefasst, mit Sockets o. ä. habe ich da noch nie rumgespielt (es sollte aber entsprechende Extensions geben).

Python bringt mit ssl einen Wrapper für "normale" Sockets mit (im Hintergrund basiert das Modul auf einer Extension, die wiederum OpenSSL einbindet und nutzt). Die Doku zeigt eigentlich schon, wie man das Modul zur Erstellung eigener SSL-Clients und -Server benutzt.

Kritisch ist bei allen Implementierungen die Validierung der angebotenen Zertifikate (sowohl Client- als auch Serverseite). Diese muss nämlich durch eigenen Code erfolgen - OpenSSL bietet zwar eine Schnittstelle an, die mit einer Callback-Funktion gefüttert werden kann, selbige muss man aber selbst implementieren. Hier liegt in meinen Augen das größte Fehlerpotenzial, denn ein Irrtum kann Verbindungen mit gefälschten oder ungültigen Zertifikaten Tür und Tor öffnen. Gerade eine zertifikatbasierte Authentifizierung bedarf hier größter Sorgfalt, sonst kann man sich den Aufwand mit der Transportverschlüsselung auch gleich schenken.

Wer also darüber nachdenkt, selbst eine transportverschlüsselnde Software zu schreiben, sollte sich vorher gut in die Materie einarbeiten und sich ggf. einschlägige Literatur beschaffen, um sich nicht die Finger an den "Randthemen" (wie Authentifizierung, Zertifikatvalidierung etc.) zu verbrennen.