Virtualhere-Client als Service oder als GUI

[Dremus]

Hallo zusammen,
ich habe auf meinem Server VirtualHere installiert, um verschiedene USB-Geräte für alle Rechner verfügbar zu haben.

Auf einem Client (LinuxMint 21.1 Cinamon) habe ich die entsprechende Clientsoftware installiert; wenn der Virtualhere-Client als Service läuft, sind zunächst mal alle angeschlossenen Geräte für diesen Rechner reserviert. Es ist dann relativ umständlich, eins der Geräte zu deaktivieren, wenn ein anderer Rechner darauf zugreifen soll.

In der Bedienung einfacher ist die GUI für diesen Clienten. Dazu fallen mir zwei Möglichkeiten ein: Den Clienten bei Systemstart direkt starten, oder den Clienten über ein Desktop-symbol starten.

Wo wird festgelegt, welche Programme beim Systemstart ausgeführt werden?
Oder: Wenn ich ein Desktop-Symbol anlege (mit desktop-entry-Datei), wie kann ich die sudo-Eingabe abschalten, die bei virtualhere immer abgefragt wird. Mittlerweile bin ich mit meiner Suche bei pkexec (gksu ist wohl obsolet), aber auch bei sudoers gelandet. Bin da etwas verwirrt.

 

[susejunky]

Hallo @Dremus ,

... Wo wird festgelegt, welche Programme beim Systemstart ausgeführt werden?

Soweit mir bekannt erfolgt der Systemstart bei Linux Mint mit Hilfe von systemd.

Wenn Du also einen Dienst direkt beim Systemstart mit starten willst, legst Du dafür am besten einen entsprechenden systemd-Service an.

Hier findest Du die erforderliche Dokumentation.

Viele Grüße

susejunky

 

[Dremus]

Hallo Leute,

zunächst habe ich versucht, ein Desktop-Symbol für den Start der GUI anzulegen. Dies dazughörige Datei sah so aus:
[Desktop Entry] Type=Application Encoding=UTF-8 Icon=/usr/share/vhui/3.ico Name=VirtualHere Client Comment=Netzwerkfunktionalität für USB-Geräte Exec=sudo /usr/share/vhui/vhuit64 Terminal=false Comment[de_DE]= GenericName[de_DE]=Netzwerkfunktionalität für USB-Geräte
Die von susejunkie empfohlene Dokumentation ist für jemanden, der nicht so tief in der Materie drinsteckt, ziemlich harte Kost - zumal ich Englisch immer erst übersetzen muß.

Hatte mich allerdings auf eine Idee gebracht: Ich hatte mir die Installationsroutine für den virtualhere-Client-Dämon angesehen und habe probeweise einfach mal die Dämon-Datei (vhclientx86_64) gegen die Programmdatei für die Virtualhere-GUI (vhuit64) ausgetauscht. Ergebnis negativ - und dann habe ich mal bei der Supporthotline vom Hersteller per Mail angefragt.

Dort erhielt ich die Antwort:

No you cant use the vhuit64 as a boot daemon because its a GUI
program. The gui system is not available when daemon's load unless
you carefully set it up and its not really supported because generally
its not done in linux.

You must run vhuit64 in your .bashrc script instead. That will load
the program when you login. However looks like opensuse has a gui for
this to make it easier. Remove the virtualhere service file and
vhclientx86_64 and use this instead for vhuit64.
OpenSUSE Desktop - Starting Applications on Login - Techotopia

Ich fand dann heraus, daß die Entsprechung von openSuSE's "Computer->Control Center->System->Sessions" für Linux Mint die "gnome-session-properties" sind. Also habe ich Virtualhere als zusätzliches Startprogramm über diese Oberfläche hinzufügen wollen. Die so erzeugte Datei 'Virtualhere Client.desktop' im Verzeichnis ~/.config/autostart sah so ähnlich aus wie die o.g. für das Desktop-Symbol:
[Desktop Entry] Type=Application Exec=sudo /usr/share/vhui/vhuit64 Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true Terminal=false Name[de_DE]=Virtualhere Client Name=Virtualhere Client Comment[de_DE]=Netzwerkfunktionalität für USB-Geräte Comment=Netzwerkfunktionalität für USB-Geräte GenericName[de_DE]=Virtualhere
Auch die Support-Hinweise auf gksu (seit Ubuntu 18.04 nicht mehr Im Repo) und pkexec (Fehlermeldung) halfen nicht weiter. Allerdings konnte ich das umständliche Hantieren bei pkexec mit dem PolicyKit dadurch vereinfachen, indem ich mit folgendem Befehl einen alias in die ~/.bashrc eingefügt habe:

echo "alias gksu='pkexec env DISPLAY=\$DISPLAY XAUTHORITY=\$XAUTHORITY DBUS_SESSION_BUS_ADDRESS=\$DBUS_SESSION_BUS_ADDRESS'" >> ~/.bashrc

Quelle

Auf diese Weise sollte die Fehlermeldung bei der Ausführung von pkexec verschwinden und meine GUI endlich mit dem Hochfahren zu starten sein (sudo in der o.g. Desktop-Datei durch gksu ersetzt). Leider funktionierte der Befehl mittels gksu nur im Terminal. Weder als Start durch Anklicken des selbst erstellten Programmsysmbols als auch beim Hochfahren mittels des Startprogramm-Eintrages tut sich irgendwas.

Letzte Antwort von der Support-Hotline war, ich könnte es noch über sudoers versuchen, aber er wüßte jetzt auch nicht weiter ...
Meine Idee wäre da noch, in die Crontab eine @reboot-Zeile einzubauen.

Hat von Euch jemand 'ne Idee?

 

[josef-wien]

Wenn Du etwas aus der grafischen Oberfläche heraus startest (Menü-Eintrag, Datei *.desktop, ...), wird das nicht in einer shell ausgeführt, daher steht alias (und vieles andere) nicht zur Verfügung. Du kannst versuchen, den gesamten Aufruf (pkexec blablabla /pfad/programm) einzutragen, ob es funktioniert, kann ich bei dieser Konstruktion nicht sagen.

 

[susejunky]

Hallo @Dremus ,

Hat von Euch jemand 'ne Idee?

nun ich würde es einmal mit der Anleitung von der VirtualHere-Web-Seite probieren:

Running the Client as a Background Service (Daemon)

# Die Datei virtualhereclient.service herunterladen
wget https://www.virtualhere.com/sites/default/files/usbclient/scripts/virtualhereclient.service

# Die Datei vhclientx86_64 herunterladen
wget https://www.virtualhere.com/sites/default/files/usbclient/vhclientx86_64

# Die Datei vhclientx86_64 ausführbar machen.
chmod +x ./vhclientx86_64

# Die Datei  vhclientx86_64 nach /usr/sbin verschieben
sudo mv ./vhclientx86_64 /usr/sbin

# Die Datei virtualhereclient.service (d.h. den systemd Service) nach /etc/systemd/system verschieben (bitte keinen anderen Ort wählen)
sudo mv virtualhereclient.service /etc/systemd/system/virtualhereclient.service

# systemd neu starten, damit der neue Service mit geladen wird
systemctl daemon-reload

# Einrichten, dass der systemd Service (virtualhereclient.service) bei jedem Neustart automatisch gestartet wird
systemctl enable virtualhereclient.service

# Den systemd Service (virtualhereclient.service) starten
systemctl start virtualhereclient.service

Wenn Du für vhclientx86_64 einen anderen Ort wählst als /usr/sbin (z.B. nach /usr/bin oder /usr/local/bin), dann musst Du den Inhalt von virtualhereclient.service entsprechend anpassen.

Viele Grüße

susejunky

 

[Dremus]

Hallo sysejunkie,
falls ich mich unklar ausgedrückt haben sollte: Mir geht es darum, daß die GUI beim Systemstart ausgeführt wird und nicht der client-daemon.

 

[susejunky]

Hallo @Dremus ,

... Mir geht es darum, daß die GUI beim Systemstart ausgeführt wird und nicht der client-daemon.

tut mir leid, ich habe mir gerade noch einmal Deinen ersten Beitrag durchgelesen und da ist mir das auch klar geworden.

Muss das GUI-Programm als "root" gestartet werden?

Falls ja, probiere einmal Deine Desktop-Datei wie folgt anzupassen:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Icon=/usr/share/vhui/3.ico
Name=VirtualHere Client
Comment=Netzwerkfunktionalität für USB-Geräte
Exec=/usr/bin/xdg-su -c /usr/share/vhui/vhuit64
Terminal=false
Comment[de_DE]=
GenericName[de_DE]=Netzwerkfunktionalität für USB-Geräte

Viele Grüße

susejunky

 

[Dremus]

Hallo susejunky,

wahrscheinlich könnte Dein Vorschlag klappen (root ist erforderlich), aber im Verzeichnis /usr/bin gibt es allerlei xdg-utils, aber kein xdg-su.
Kann ich über Synaptic auch nicht installieren, habe in einer ersten Google-Suche auch nichts gefunden.

 

[susejunky]

Hallo @Dremus ,

... im Verzeichnis /usr/bin gibt es allerlei xdg-utils, aber kein xdg-su.
Kann ich über Synaptic auch nicht installieren ...

Welche Möglichkeiten Dir unter Linux Mint konkret zur Verfügung stehen kann ich nicht sagen, da ich ausschließlich mit openSUSE Tumbleweed und Plasma5-Desktop arbeite.

Auf meinen System funktionieren noch folgende Varianten:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Icon=/usr/share/vhui/3.ico
Name=VirtualHere Client
Comment=Netzwerkfunktionalität für USB-Geräte
Exec=kdesu -c /usr/share/vhui/vhuit64
Terminal=false
Comment[de_DE]=
GenericName[de_DE]=Netzwerkfunktionalität für USB-Geräte

und

[Desktop Entry]
Type=Application
Encoding=UTF-8
Icon=/usr/share/vhui/3.ico
Name=VirtualHere Client
Comment=Netzwerkfunktionalität für USB-Geräte
Exec=su -c /usr/share/vhui/vhuit64
Terminal=true
Comment[de_DE]=
GenericName[de_DE]=Netzwerkfunktionalität für USB-Geräte

bei letzterer wird eine Konsole (zur Kennworteingabe) mit geöffnet.

Viele Grüße

susejunky

 

[josef-wien]

Das Skript xdg-su wird seit Jahren nicht mehr gewartet und daher von vielen Distributionen nicht mehr im Paket xdg-utils zur Verfügung gestellt.

Es steht zwar auf GitHub - tarakbumba/xdg-su: xdg-su — run a GUI program as root after prompting for the root password zur Verfügung (unter "Code" die ZIP-Datei herunterladen, entpacken und scripts/xdg-su.in als xdg-su nach /usr/local/bin (oder wo immer Dein Pfad es findet) kopieren), aber zuerst würde ich die 2. Lösung von susejunky bzw. meinen Vorschlag aus Beitrag 4 probieren.

 

[Dremus]

Hallo susejunky,

openSuSE habe ich bisher noch nicht getestet. Kommt noch ...

Jedenfalls habe ich erstmal begriffen, daß es sich hier um ein Script handelt. Es gibt wohl kein Repo, in dem für Ubuntu/Linux Mint das fertige Script vorhanden ist. Als fertiges Script habe ich es nur für Arch-Linux gefunden, weiß aber nicht, ob ich es einfach so in Mint übernehmen kann. Die Quelle dieses Scripts ist hier.

Dann fand ich noch diese Seite, weiß aber nicht, ob es okay ist, wenn ein Seitenbetreiber in Russland sitzt.

Und dann ist da noch die Seite bei freedesktop.org. Jetzt bin ich nur etwas überfordert, was ich damit machen muß, um das Script für mich zu kompilieren - muß ich alle auf dieser Seite gelisteten Dateien runterladen und das Makefile.in anstoßen, oder erst ausführbar machen? ...

 

[Dremus]

Das Skript xdg-su wird seit Jahren nicht mehr gewartet

Hallo Josef,
bestehen dann eventuell Sicherheitsbedenken?

Achja, und Dein Vorschlag (pkexec blablabla /pfad/programm) führte dann wieder zu einer Fehlermeldung ,die ich auch ohne das BlaBla schon hatte:

Error: Unable to initialize GTK+, is DISPLAY set properly?

 

[susejunky]

Hallo @Dremus ,

... jetzt bin ich nur etwas überfordert, was ich damit machen muß, um das Script für mich zu kompilieren - muß ich alle auf dieser Seite gelisteten Dateien runterladen und das Makefile.in anstoßen, oder erst ausführbar machen?

der von Dir gezeigte Link verweist auf das Paket xdg-utils, das mehrere Skripte enthält. xdg-su.in ist das Skript xdg-su. Da muss nichts kompiliert werden, aber ob Du das Skript einfach so unter Linux Mint einsetzen kannst, kann ich Dir nicht sagen.

In diesem Paket von openSUSE ist die Version des Skripts enthalten, wie sie von openSUSE Tumbleweed verwendet wird. Vielleicht kannst Du aus einem Vergleich der beiden Skript-Versionen ableiten, ob und ggf. wie Du das Skript für Linux Mint anpassen musst.

Viele Grüße

susejunky

 

[Dremus]

Hallo susejunky,
sowas in der Art habe ich mir schon gedacht. Aber ich denke, da brauche ich 'ne Weile.

Ich melde mich demnächst, wenn ich Ergebnisse habe.
Danke sehr.

 

[josef-wien]

Sicherheitsbedenken sehe ich eher nicht. Das Skript stellt fest, in welcher Desktop-Umgebung es aufgerufen wird, und wählt dann eine der definierten Möglichkeiten aus. Sowohl die Art der Feststellung als auch die jeweiligen Möglichkeiten unterscheiden sich in den verschiedenen Versionen.

Da es das Skript für Deine Distribution nicht gibt, wirst Du nur durch Ausprobieren feststellen können, welche Version für Dich geeignet ist. Ich halte das aber für den falschen Weg. Die Standardlösung für einen im Skript nicht definierten Desktop und der "Notausgang" für die anderen Möglichkeiten ist der Start eines Konsol-/Terminal-Fensters (meistens xterm) und dort die Durchführung von

su -c command [user]

(also das 2. Beispiel im Beitrag 9).

Nachtrag: Was mir noch als eventuell mögliche Lösung einfällt: Die *.desktop-Datei startet ein Skript, damit ist die Bash im Spiel, und in diesem Skript wird dann der Programmstart samt notwendigen Vorbereitungen ausgeführt.

P. S. Ein Skript brauchst Du nicht zu kompilieren. Es reicht, es herunterzuladen (das Skript und nicht die HTML-Seite, die es anzeigt), die Datei ausführbar zu machen und an einem Ort (üblich ist /usr/local/bin für systemweite und ~/bin für benutzerspezifische lokale Ergänzungen) zu speichern, der im Pfad enthalten ist.

 

[Dremus]

Hallo alle miteinander,

es ist zum Mäusemelken: su ist ja bei ubuntu/Mint (sozusagen) abgeschaltet. Ich kann aber sudo su verwenden.
Wenn ich das im laufenden System im Terminal ausprobiere, funktioniert das auch, nachdem ich mein Passwort für sudo eingegben habe.

Aber: Weder das Starten des Programms über das Desktop-Sysmbol noch der Programmstart beim Systemstart ("gnome-session-properties") hat irgendeine Wirkung (vielleicht nur in den log-dateien?)

 

[susejunky]

Hallo @Dremus ,

... su ist ja bei ubuntu/Mint (sozusagen) abgeschaltet.

wenn Linux Mint genauso funktioniert wie Kubuntu, dann ist lediglich kein Kennwort für "root" festgelegt; d.h. mit

sudo passwd

solltest Du ein Kennwort für "root" festlegen können. Anschließend sollte su -c in .desktop-Dateien eingesetzt werden können.

Viele Grüße

susejunky

 

[Dremus]

Hallo susejunky,

ich fand diese Erklärung hier ganz einleuchtend:

Vermutlich aufgrund der potenziellen Risiken, die mit der Verwendung von ’su‘ oder der direkten Anmeldung als root verbunden sind, deaktivieren einige Linux-Distributionen – wie Ubuntu – standardmäßig das root-Benutzerkonto. Benutzer werden ermutigt, ’sudo‘ zu benutzen, wann immer sie Root-Privilegien benötigen.

Sie können jedoch immer noch erfolgreich ’su‘ machen, d.h. ohne Eingabe des Root-Passwortes. Sie müssen nur den folgenden Befehl ausführen:

sudo su

Da Sie den Befehl mit ’sudo‘ ausführen, müssen Sie nur Ihr Passwort eingeben. Sobald das erledigt ist, wird der Befehl ’su‘ als root ausgeführt, d.h. es wird nicht nach Passwörtern gefragt.

Also müßte es doch auch funktionieren, oder?

 

[susejunky]

Hallo @Dremus ,

Also müßte es doch auch funktionieren, oder?

Nun, was soll ich dazu sagen?

Laut Deinem Beitrag #16 scheint es nicht zu funktionieren ...

Viele Grüße

susejunky

 

[Dremus]

Entschluß:
Ich werde das Programm mal auf meiner openSuSE-Installation ausprobieren, da gibt's ja erstmal nur su ...