Synerwas?
Synergy ist eine Software um eine Tastatus/Maus-Kombination mit mehreren Rechnern nutzen zu können. Bewegt man z.B. die Maus am Haput-PC an den rechten Bildschirmrand steuert man fortan den danebenstehenden Laptop. Sehr praktisch, wenn man viele Systeme nebeneinander stehen hat. Alles konfigurierbar, versteht sich.
Leider hat die Software einen faden Beigeschmack: Zwar ist der Kern Open Source (GPL), wird vom Hersteller aber nur noch gegen Geld zum Download angeboten. Neue Funktionen sind ebenfalls nur noch mit DRM-online-Aktivierung verfügbar und während die Anpassung an neue Betriebssysteme soweit zügig von statten geht ist die Stabilität in meinen Augen eher auf dem absteigenden Ast.
Wie auch immer: Ich komme nicht drumrum. An einem Arbeitsplatz stehen 4 Rechner nebeneinander und ich habe keinen Nerv ständig die Tastaturen zu wechseln. Da ich dank einer Spende aus Full-Open-Source-Zeiten einen Zugang zu den Downloads habe und meine bisherige Version mit Windows 10 und Server 2016 einige Probleme hat heißt es Aktualisieren.
TLS? Proxy? WTF?
Also rauf auf die Webseite, Login-Formular ausgefüllt und … man landet auf einer HTTP-Seite. Auf der das Login-Cookie unverschlüsselt durch die Gegend geht. Great.
Weiter mit dem Windows-Setup. Installieren, aktivieren. Immerhin: Bei der Aktivierung wird offenbar die OS-API verwendet und der Request augenscheinlich per TLS mit OCSP-Abfrage über den Systemproxy übermittelt. Beim anschließenden Download der Plugins ist dann jedoch Schluss: Direktes CONNECT ohne Möglichkeit einen Proxy einzustellen. Ohne direkten Internetzugriff am Rechner also nicht viel Möglichkeiten.
Konfigurationsterror
Die Konfiguration gestaltet sich mühselig, da Dienst und GUI ständig abstürzten. Letztendlich griff ich auf den Texteditor für die Konfigurationsdatei zurück. Das ging in der Vorversion rigendwie besser. Immerhin: Im Betrieb scheint es bisher stabil zu funktionieren.
Linux? Eat my binary!
Etwas mehr Probleme hatte ich jedoch mit Linux: Im Konstrukt ist ein Gentoo-Rechner, welcher ebenfalls gesteuert werden soll. Die aktuelle Version ist dank GPL über Portage verfügbar und schnell kompiliert und installiert. Nach Eingabe meiner Zugangsdaten verwandelt sie sich nach kurzem Plugin-Download zur Pro-Version. Immerhin. Nur Verbinden geht nicht.
Auslöser ist die Pro-Version: Diese kann – im Gegensatz zum OSS-Kern – eine Verschlüsselte Verbindung zwischen den beteiligten Rechnern nutzen, sodass nicht jeder Netznutzer alle Tastenanschläge mitlesen kann. Dieses Pro-Feature ist jedoch nicht in den Quellcodes vorhanden sondern wird als „Plugin“ bei der Installation heruntergeladen und in ~/.synergy/plugins/ deponiert. Plugin heißt hierbei .so-Library. In Binär. Natürlich gelinkt gegen Bibliotheken bzw. Dateinamen, die ich nicht habe.
Konkret geht es um folgende Liste:
- linux-vdso.so.1
- libpthread.so.0
- libcurl.so.4
- libSM.so.6
- libICE.so.6
- libXtst.so.6
- libX11.so.6
- libXext.so.6
- libXinerama.so.1
- libXrandr.so.2
- libXi.so.6
- libssl.so.10
- libcrypto.so.10
- libdl.so.2
- libstdc++.so.6
- libm.so.6
- libgcc_s.so.1
- libc.so.6
- libidn.so.11
- libldap-2.4.so.2
- liblber-2.4.so.2
- libresolv.so.2
- libgnutls.so.28
- libgcrypt.so.20
- libz.so.1
- libuuid.so.1
- libxcb.so.1
- libXrender.so.1
- libtasn1.so.6
- libnettle.so.6
- libhogweed.so.4
- libgmp.so.10
- libgpg-error.so.0
- libXau.so.6
- libXdmcp.so.6
Die Libraries selbst sollten auf einem Desktop-System meist vorhanden sein, nachinstallieren musste ich jedenfalls bei mir nichts. Problematisch waren jedoch libssl.so.10 und libcrypto.so.10 – diese sind unter Gentoo nicht verfügbar und dürften sich auf OpenSSL mit einer Version >= 1.0 beziehen. Die Dateibenennung scheint dabei von Debian(?) zu stammen und wird bei Gentoo anders durchgeführt. Da hierdurch das Plugin nicht lädt wird es ignoriert und die Verbindung zu dem bereits eingerichteten Windows-Clients schlägt, wegen der fehlenden Cryptofunktion, fehl. Zwar erscheint dies auch im Synergy-Log, versteckt sich aber zwischen den ganzen Connect-Nachrichten und ist schnell zu übersehen:
ERROR: failed to load plugin 'libns.so', error: libcrypto.so.10: cannot open shared object file: No such file or directory
Als Quick’n’Dirty-Workarround habe ich bei mir die angemeckerten Dateinamen als Symlink auf die echten OpenSSL-Files angelegt.
cat /usr/lib64/
ln -s libssl.so.1.0.0 libssl.so.10
ln -s libcrypto.so.1.0.0 libcrypto.so.10
Zumindest für’s erste ist hiermit das Plugin funktionsfähig und die Software wieder nutzbar. Sonderlich schön ist es trotzdem nicht.
