ubuntuusers.de

Hallo,

wer auch immer TigerVNC für Ubuntu paketiert hat, hat wohl kein Interesse daran, dass der Server via systemd gestartet wird.

sudo cp /lib/systemd/system/tigervncserver@.service /etc/systemd/system/ ist eigentlich auch überflüssig, wenn man die Service Unit, sofern es unter Ubuntu denn eine gäbe, OOTB benutzen möchte. Und wenn man sie anpassen wollte wäre dieses Vorgehen richtig.

Es ist zwar schade für den Aufwand des Artikelschreibens, aber zeigt auch wieder, dass sich Sachen von Debian auf Ubuntu eben nicht immer einfach so 1:1 übertragen lassen.

Gruß, noisefloor

noisefloor schrieb:

wer auch immer TigerVNC für Ubuntu paketiert hat, hat wohl kein Interesse daran, dass der Server via systemd gestartet wird.

Ich glaube in dem Fall weniger, dass es an Unterschieden zu Debian liegt, denn ich habe mir eben auch noch mal die Dateiliste zu Buster angeschaut:

https://packages.debian.org/buster/amd64/tigervnc-standalone-server/filelist

Ich glaube im übrigen eher, dass das Problem allgemein im Zusammenspiel xauthority, display, systemd liegt. Das muss da wahrscheinlich entsprechend berücksichtigt werden.

Bei x11vnc habe ich bei mir z.B. auch das Problem, dass ich eine Systemd-User-Unit direkt am Rechner starten kann, die gleiche Unit startet aber nicht, wenn ich sie mit dem betreffenden Nutzer über ssh starten will. Ich hatte bis jetzt aber noch keine Zeit, dem Problem genauer auf den Grund zu gehen.

Um noch mal auf diese Anleitung hier zurückzukommen:

Hauptproblem ist vor allem, dass bei fast allen Schritten eine kurze Erklärung fehlt, warum man etwas macht. Da ist es dann auch schwer Fehler zu suchen bzw. zu beheben. Es wird auch insgesamt nicht klar, ob es sich hinsichtlich der Konfigurationsdateien um Ausschnitte handelt oder ob das jeweils die vollständige Konfigurationsdatei ist, bzw. wäre es hilfreich, wenn man jweils die vollständige Konfiguration sehen würde.

Klar ich kann jetzt suchmaschineln und dann bekäme ich das wahrscheinlich auch ans laufen, aber dann brauche ich den Artikel ehrlich gesagt nicht. In der Form wäre das im Moment ein Artikel, über den ich mich als Leser jedenfalls ärgern würde, weil zu viele Probleme im Verhältnis zu zu wenigen Lösungsansätzen.

LG, Newubunti

Hallo,

ja, gute Zusammenfassung und für deine Bemühung. Heißt unterm Strich: leider nicht tauglich für's Wiki.

Gruß, noisefloor

Ich habe jetzt eine unter Focal funktionierende Lösung:

Unter dem VNC-Benuter auf dem Server-Rechner legt man folgendes an:

Verzeichnis für Systemd-Benutzer-Dateien:

mkdir -p ~/.local/share/systemd/user 

Anlegen der folgenden Systemd-Benutzer-Datei ~/.local/share/systemd/user/vncserver@.service:

nano ~/.local/share/systemd/user/vncserver@.service 

Inhalt der ~/.local/share/systemd/user/vncserver@.service:

[Unit]
Description=TigerVNC Service

[Service]
Type=forking
ExecStartPre=/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -verbose :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=default.target

Man beachte hier das vncserver. Das ist ein Link nach /etc/alternatives/vncserver der dann wiederum auf /usr/bin/tigervncserver zeigt. Ich weiß noch nicht warum, aber bei mir funktioniert /usr/bin/tigervncserver direkt angegeben nicht. Möglicherweise hat das irgendwie etwas mit AppArmor oder so zu tun. Noch keine genaue Ahnung an der Stelle. Vielleicht lag es auch nur am Herumprobieren.

Anlegen der Datei ~/.vnc/xstartup mit folgendem Inhalt (auch auf dem Server-Rechner):

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
vncconfig −nowin &
dbus-launch --exit-with-session env GNOME_SHELL_SESSION_MODE=ubuntu gnome-session --session=ubuntu &

Die ~/.vnc/vnc.conf auf dem Server-Rechner sieht bei mir so aus:

$geometry = "1024x768";
$localhost = "yes";
$session=ubuntu

VNC-Server starten mit:

systemctl start vncserver@1 --user 

Status abfragen mit:

systemctl status vncserver@1 --user 

Und im Detail bei Problemen:

journalctl -xe --user

Stoppen mit:

systemctl stop vncserver@1 --user 

So läuft das aber mal grundsätzlich. Ich probiere jetzt mal noch eine Lösung über /etc/systemd/system, welche den Vorteil hätte, dass man das starten kann, ohne dass der Nutzer am VNC-Rechner angemeldet sein muss.

Wie ich vermutet habe, kann man beim Herstellen der Verbindung vom Client auch wie folgt vorgehen:

ssh -fL 6001:localhost:5901 USERSERVER@HOSTNAME sleep 10; xtigervncviewer -SecurityTypes VncAuth localhost:6001  

Mann muss dann zwei Passwörter eingeben - sofern man bei ssh nicht irgendwie auf andere Weise authentifiziert.

LG, Newubunti

Newubunti schrieb:

So ich habe jetzt mal angefangen zu testen. Testsysteme sind zwei virtualisierte Standard-Ubuntu-Desktops 20.04.3 - also direkt nach der Standard-Installation alle Updates eingespielt und dann die Anleitung befolgt: ... "Editiert" meint hier wohl "erstellt" denn diese Datei gibt es weder im tigervnc-standalone-server Paket von Bionic oder Focal:

Bitte verwende ein aktuelle Ubuntuversion die nach Debian 11 Bullseye erschienen ist. Der Artikel wurde mit Debian stable Bullseye erstellt und getestet und das erschien im Sommer dieses Jahres.

Eine aktuelle Ubuntu Version, nämlich 21.10 hat die gesuchte Datei. Ich habe das hier nämlich gerade mit Xubuntu in einer VM nachgeprüft.

Ich habe dann die tigervncserver@.service aus 9219482 in /etc/systemd/system erstellt. Die führt - egal ob über ssh oder direkt am Server-PC gestartet - zu folgendem Fehler:

Der Hinweis in Kommentar 9219482 wurde damals unter Debian Buster erstellt und funktioniert in Bullseye nicht mehr. Der Hinweis ist daher nicht mehr relevant. Im Artikel ist eine systemd Anleitung für ein aktuelles Debian bullseye oder zeitliche *Ubuntu Nachfolger.

Dann habe ich noch folgende Fragen:

> Would you like to enter a view-only password (y/n)? 

Verneint man diese mit (n)ein.

Warum?

Weil du ja nicht nur zugucken willst, sondern auch mit der Oberfläche interagieren möchtest.

Warum starte man den VNC-Server über systemd nicht als Benutzer unit? Weiter oben starte man den Server ja auch als Benutzer (beim) ersten Test. Das ist möglicherweise/vermute ich bei VNC einfacher/weniger Konflikt geladen. Also eine Unit in

• ~/.config/systemd/user

Wenn du eine Lösung für eine "system user unit" hast, bei der sich der Nutzer via VPN verbinden kann und dann der VPN Server automatisch gestartet wird, sobald eine VPN Verbindungsfrage hereinkommt, dann kannst du das gerne aufzeigen. Ich bin davon ausgegangen, dass ein VNC Server bereits laufen muss, zu dem man sich dann einloggen kann. Deswegen habe ich eine globale system Systemd Konfiguration dafür erstellt.

Noch eine Ergänzung.

Falls du eine alte Ubuntu Version nutzen willst, dürfte der Artikel in einer alten Revision vom Januar für dich am hilfreichsten sein, den habe ich nämlich noch unter Debian Buster erstellt und dann Anfang Oktober für Bullseye modernisiert.

Da es aber viele Änderungen und Neuerungen bei Systemd und tigervnc gab, wäre es wohl am sinnvollsten, den Artikel für zukünftige Ubuntu Versionen auszulegen. 22.04 LTS kommt ja bald, daher wäre ein Test mit 21.10 am sinnvollsten.

noisefloor schrieb:

Hallo,

wer auch immer TigerVNC für Ubuntu paketiert hat, hat wohl kein Interesse daran, dass der Server via systemd gestartet wird.

sudo cp /lib/systemd/system/tigervncserver@.service /etc/systemd/system/ ist eigentlich auch überflüssig, wenn man die Service Unit, sofern es unter Ubuntu denn eine gäbe, OOTB benutzen möchte. Und wenn man sie anpassen wollte wäre dieses Vorgehen richtig.

Die TigerVNC Pakete sind in Ubuntu Bestandteil des universe Repositories, d.h. Canonical kümmert sich darum gar nicht.

Wenn es Änderungen gibt, dann stammen die von Änderungen, die in Debian SID stattfinden und dann über eine Kopie bzw. Merge eines Stands von Debian SID (dem Entwicklungszweig von Debian) für einen neuen Ubuntu Release dann nach Ubuntu gelangen.

Am sinnvollsten wäre es also, den Debian Maintainer anzuschreiben und ihn darauf hinzuweisen bzw. ihm gleich passende Configs mitzugeben. Der kann dann das Paket neu paketieren und dann kommt das mit dem nächsten "Debian SID nach Ubuntu" Merge dann auch in den nächsten Ubuntu Release. Zu beachten wäre hier der DebianImportFreeze Termin für Ubuntu, also der Zeitpunkt, wenn Canonical nichts mehr aus Debian SID nach Ubuntu für den nächsten Release holt.

Jede Ubuntu Version ist praktisch immer ein neuer Fork des Debian Entwicklungszweiges zu einem bestimmten beliebigen Zeitpunkt. Es gibt somit quasi keine fortführende Entwicklung auf Basis alter Ubuntuversionen.

Die alten Ubuntu Versionen enden praktisch immer und werden dann weggeworfen. Lediglich Canonical Eigenentwicklungen werden auf die nächste Debian Kopie via merging rübergebracht und für diese dann angepasst und daraus dann erst eine neue Ubuntu Version erstellt.

Siehe dazu auch:

The first phase of the release cycle is characterized by bringing new releases of upstream components into Ubuntu, either directly or via Debian. We merge from Debian because it's the single most effective way to keep up to date with upstream code (Debian maintainers package new upstream releases on a frequent basis, often faster than we are able to do so), and because Debian and Ubuntu are similar in many ways so their bug-fixes are often bug-fixes for us too. We do it every release cycle rather than taking the occasional cycle off because if we didn't it would be significantly harder ever to come back into sync.

https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess

Es ist zwar schade für den Aufwand des Artikelschreibens, aber zeigt auch wieder, dass sich Sachen von Debian auf Ubuntu eben nicht immer einfach so 1:1 übertragen lassen.

Nein, Newubunti hat einfach nur eine uralte Ubuntuversion, (Uralt aus Debiansicht) verwendet. Da ist es dann klar, dass man mit alten Softwareversionen von tigervnc und systemd nicht mehr neue Configs benutzen kann, wenn vor allem die Software bei Tigervnc und Systemd in den neuen Versionen Veränderungen erfahren und die dann auch die Configs betrifft.

Newubunti schrieb:

Man beachte hier das vncserver. Das ist ein Link nach /etc/alternatives/vncserver der dann wiederum auf /usr/bin/tigervncserver zeigt. Ich weiß noch nicht warum, aber bei mir funktioniert /usr/bin/tigervncserver direkt angegeben nicht. Möglicherweise hat das irgendwie etwas mit AppArmor oder so zu tun. Noch keine genaue Ahnung an der Stelle. Vielleicht lag es auch nur am Herumprobieren.

Die alternatives sind einfach dpkg-reconfigure Sachen, die man nutzt, wenn man bspw. zwei völlig verschiedene Softwareimplementierungen von etwas, z.b. eine VNC Lösung oder ein Java Runtume Environment oder ein Mailserver installiert hat und nun festlegen will, welche man überhaupt standardmäßig benutzen will.

Oder anders gesagt, hättest du zwei Implementierungen von Obst, z.B. Apfel und Birne, dann wäre der Link /usr/bin/obst der Link, der auf /etc/alternatives/obst verweist und das wiederum wäre dann ein Link, der dann festlegt, ob nun Apfel /usr/bin/apfel oder Birne /user/bin/birne verwendet werden soll.

D.h. wenn du in deinem systemd unit File auf vncserver verweist, dann muss die systemd unit File unabhängig von der VNC Implementierung sein, so dass sie für alle möglichen VNC Implementierungen benutzbar ist.

Sinnvoller wäre es daher, die unit File ~/.local/share/systemd/user/tigervncserver@.service zu nennen, dann ist klar, dass sie explizit für tigervnc geschrieben wurde und dann kannst du bzw. solltest du tigervnc, also /usr/bin/tigervncserver auch direkt in der Unit File erwähnen und angeben. Falls du nämlich keine direkte Konfiguration verwendest, dann wäre spätestens bei der Installation einer andere VNC Implementierung und dpkg-reconfigure Durchlauf durch den Nutzer, wodurch sich der altnativelink dann auf /usr/bin/andere_VNC_server_Implementierung ändert, der VNC Dienst bzw. die Konfiguration broken.

Würde er dann den tigerclient auf seinem Gastsystem starten, in der Hoffnung, dass da auf der anderen Seite ein tigervnc Server lauscht, dann würde das nicht mehr klappen. Stattdessen würde der /usr/bin/andere_VNC_server_Implementierung Server lauschen und wenn der dann Spezialfeatures vom Client erwartet, würde das nicht mehr zusammen harmonieren.

Wie ich vermutet habe, kann man beim Herstellen der Verbindung vom Client auch wie folgt vorgehen:

ssh -fL 6001:localhost:5901 USERSERVER@HOSTNAME sleep 10; xtigervncviewer -SecurityTypes VncAuth localhost:6001  

Mann muss dann zwei Passwörter eingeben - sofern man bei ssh nicht irgendwie auf andere Weise authentifiziert.

Die passwd Datei auf dem Client hinterlegen ist einfacher. Dann harmoniert das auch bestens, wenn man bei SSH passwortlos mit public und private keys arbeiten will.

Newubunti schrieb:

Um noch mal auf diese Anleitung hier zurückzukommen:

Hauptproblem ist vor allem, dass bei fast allen Schritten eine kurze Erklärung fehlt, warum man etwas macht. Da ist es dann auch schwer Fehler zu suchen bzw. zu beheben. Es wird auch insgesamt nicht klar, ob es sich hinsichtlich der Konfigurationsdateien um Ausschnitte handelt oder ob das jeweils die vollständige Konfigurationsdatei ist, bzw. wäre es hilfreich, wenn man jweils die vollständige Konfiguration sehen würde.

Ich finde es schon recht dreist, die Fehler vor dem Bildschirm auf den Artikel zu schieben, wenn der Fehler vor dem Bildschirm nichtmal aktuelle Software verwendet und dann erwartet, dass neue Configs, die für neue Softwareversionen geschrieben wurde, mit der alten Software laufen soll. Und dann wird über den Artikel auch noch geurteilt, bevor man überhaupt mal abwartet, was der Artikelschreiber dazu zu sagen hat.

Auch ist deine Frage bezüglich der "view-only" Frage überflüssig, da es ein Artikel ist, der zu einer nutzbaren Konfiguration hinarbeiten soll und kein Handbuch, in dem man jedes Detail einer Software nachlesen kann. Würden die Nutzer nämlich die Handbücher lesen, dann bräuchte man auch keine Wiki und auch keine solche Artikel. Willst du jetzt das Handbuch kopieren?

noisefloor schrieb:

Hallo,

ja, gute Zusammenfassung und für deine Bemühung. Heißt unterm Strich: leider nicht tauglich für's Wiki.

Gruß, noisefloor

Noisefloor du hattest 11 Monate Zeit den Artikel, damals noch für Buster und somit für 20.04 passend, zu testen und gegebenfalls auch anzupassen. Stattdessen kommt ein Meckern "für die Wiki nicht geeignet" und machst dabei ebenfalls den Fehler, die Ursache, dass eine alte Softwareversion verwendet wurde, nicht zu erkennen und fragst mich nichtmal bevor du urteilst.

Mir ist das Problem sofort aufgefallen und am Artikel liegt es nicht.

Cordess schrieb:

Ich finde es schon recht dreist, die Fehler vor dem Bildschirm auf den Artikel zu schieben, wenn der Fehler vor dem Bildschirm nichtmal aktuelle Software verwendet und dann erwartet, dass neue Configs, die für neue Softwareversionen geschrieben wurde, mit der alten Software laufen soll.

Warum steht das dann bitte nicht in dem Artikel, wenn Du schon genau weist, dass es mit 20.04 nicht funktioniert? Denn:

Cordess schrieb:

Schaut ihn euch mal an und testet ihn auf eine der Ubuntu Versionen. Ich hatte hier leider keine Ubuntu Maschine zur Hand und das ganze daher auf Debian stable (Client) und dem Raspberry Pi (Server) getestet. Da Ubuntu auf Debian aufbaut, sollte das aber problemlos funktionieren. Wer den Artikel dann auf einer Ubuntu Maschine getestet hat, trägt die getestet Ubuntu Version dann bitte noch in den Artikel ein.

Ich persönlich nutze nur LTS-Versionen und 20.04.3 ist die aktuelle. Wenn der Artikel dafür nicht funktioniert ist das solange nicht schlimm, solange das im Artikel steht.

Ich habe hier nicht einfach nur auf den Artikel drauf gehauen. Ich haben den ausführlich getestet und sogar alternative Lösungswege für die getestet Version aufgezeigt. Da stecken mehrere Stunden Test und Recherche drin.

Dass Du mich jetzt dafür hier als "Fehler" bezeichnest - sag mal geht es eigentlich noch? Komm mal bitte wieder runter! Ich verstehe Deinen Frust als Autor ja, wenn man Monate auf eine Rückmeldung warten muss. Aber dafür kann ich nichts!

Wenn du eine Lösung für eine "system user unit" hast, bei der sich der Nutzer via VPN verbinden kann und dann der VPN Server automatisch gestartet wird, sobald eine VPN Verbindungsfrage hereinkommt, dann kannst du das gerne aufzeigen. Ich bin davon ausgegangen, dass ein VNC Server bereits laufen muss, zu dem man sich dann einloggen kann. Deswegen habe ich eine globale system Systemd Konfiguration dafür erstellt.

Meinst Du hier wirklich VPN oder sollte das jeweils VNC heißen?

LG, Newubunti

Newubunti schrieb:

Cordess schrieb:

Ich finde es schon recht dreist, die Fehler vor dem Bildschirm auf den Artikel zu schieben, wenn der Fehler vor dem Bildschirm nichtmal aktuelle Software verwendet und dann erwartet, dass neue Configs, die für neue Softwareversionen geschrieben wurde, mit der alten Software laufen soll.

Warum steht das dann bitte nicht in dem Artikel, wenn Du schon genau weist, dass es mit 20.04 nicht funktioniert?

Weil ich beim Schreiben des Artikels es noch nicht kannte, es aber sich recht schnell erschließt, wenn man weiß, wie Ubuntu entwickelt wird und auf Debian aufbaut. Dieses erschließen war eigentlich deine Aufgabe beim Testen. Mit einfachem Nachdenken, Gedankengang "Debian bullseye kam nach Ubuntu 20.04 raus, falls Probleme auftreten, müsste ich also mal eine Ubuntuversion nach Debian bullseye nehmen", hättest du recht leicht darauf kommen können, dass man da mal nachgucken könnte, ob das Paket vielleicht zu alt ist, anstatt "mecker mecker, das und das geht nicht und überhaupt, erklärt dies und das nicht, nicht geeignt für die Wiki."

Cordess schrieb:

Schaut ihn euch mal an und testet ihn auf eine der Ubuntu Versionen. Ich hatte hier leider keine Ubuntu Maschine zur Hand und das ganze daher auf Debian stable (Client) und dem Raspberry Pi (Server) getestet. Da Ubuntu auf Debian aufbaut, sollte das aber problemlos funktionieren. Wer den Artikel dann auf einer Ubuntu Maschine getestet hat, trägt die getestet Ubuntu Version dann bitte noch in den Artikel ein.

Dieses Kommentar ist vom Januar, als Buster noch der Standard war. Hättest du den Artikel gleich getestet, hätte er in Ubuntu 20.04 wahrscheinlich auch funktioniert. Denn Buster erschien im Sommer 2019 und Ubuntu 20.04 im April 2020. Der Artikel wurde von mir im Oktober aber jetzt überarbeitet und basiert somit auf bullseye. Damit gilt das alte Kommentar bezüglich 20.04 natürlich nicht mehr.

Ich persönlich nutze nur LTS-Versionen und 20.04.3 ist die aktuelle. Wenn der Artikel dafür nicht funktioniert ist das solange nicht schlimm, solange das im Artikel steht.

Wie schon gesagt, ich habe ja gesagt, dass ich den Artikel unter Ubuntu nicht testen würde. Das ist also eure Aufgabe das zu erkennen.

Ich habe hier nicht einfach nur auf den Artikel drauf gehauen. Ich haben den ausführlich getestet und sogar alternative Lösungswege für die getestet Version aufgezeigt. Da stecken mehrere Stunden Test und Recherche drin.

Du hast nicht einmal eine Antwort von mir abgewartet. Was meinst denn du, wie lange ich dran saß den Artikel zu schreiben. Da ging viel mehr Zeit drauf und dann folgen solche dreisten Kommentare zum Artikel.

Dass Du mich jetzt dafür hier als "Fehler" bezeichnest - sag mal geht es eigentlich noch? Komm mal bitte wieder runter! Ich verstehe Deinen Frust als Autor ja, wenn man Monate auf eine Rückmeldung warten muss. Aber dafür kann ich nichts!

Ja, aber man kann etwas dafür wenn man aufgrund der Basis eigener Fehler einfach sagt, dass der Artikel nichts für die Wiki wäre.

Wenn du eine Lösung für eine "system user unit" hast, bei der sich der Nutzer via VPN verbinden kann und dann der VPN Server automatisch gestartet wird, sobald eine VPN Verbindungsfrage hereinkommt, dann kannst du das gerne aufzeigen. Ich bin davon ausgegangen, dass ein VNC Server bereits laufen muss, zu dem man sich dann einloggen kann. Deswegen habe ich eine globale system Systemd Konfiguration dafür erstellt.

Meinst Du hier wirklich VPN oder sollte das jeweils VNC heißen?

Ich meinte VNC.

So, alles muss man leider selber machen. 😠

Ich habe meinen Artikel jetzt in Xubuntu 21.10 getestet und er funktioniert wie eine Eins.

Das einzige was man noch ändern könnte, wäre, sytemd so zu konfigurieren, dass der VNC Server neu gestartet wird, falls der Nutzer sich via vnc eingeloggt und dann im remote Desktop ausgeloggt hat, anstatt das Fenster mit der VNC Sitzung einfach zu schließen. Dieses remote ausloggen auf dem Server über die Auslogbuttons des Desktops bewirkt nämlich, dass auch der vnc server beendet wird und dann nicht mehr zur Verfügung steht, es sei denn, der Nutzer startet ihn über systemd manuell oder bootet die Remote Maschine. Da habe ich aber leider noch keine zufriedenstellende Lösung gefunden. Man kann zwar systemd dazu veranlassen, dass beendete Server wieder gestartet werden, aber im Fall von tigervnc führt das aus mir noch unerfindlichen Gründen zu ständigen Beendigungen und Neustarts des Servers und somit zu vielen Logeinträgen.

Der Artikel kann aber so wie er jetzt ist in die Wiki gestellt werden, da er nun unter Xubuntu 21.10 getestet ist und auch funktioniert. Ich werde das jetzt noch in den Artikel eintragen.

Das Einrichten war übrigens in unter 15 min erledigt.

Cordess schrieb:

Wenn du eine Lösung für eine "system user unit" hast, ...

Ich meinte VNC.

Das kann man erreichen indem man zunächst die betreffende Benutzer-Unit aktiviert, also

systemctl enable <UNIT> --user 

und dann das lingering für den betreffenden Nutzer aktiviert:

sudo loginctl enable-linger <BENUTZER> 

Gegenüber des Posts 9288005 weiter oben sieht meine ~/.vnc/xstartup nun unter Focal so aus:

#!/bin/sh

test x"$SHELL" = x"" && SHELL=/bin/bash
test x"$1"     = x"" && set -- default

vncconfig -iconic &
"$SHELL" -l << EOF
if [[ ! "$DISPLAY" -eq ":1" ]]; then
  # wird im Zusammenspiel mit systemd benötigt um x zu starten,
  # falls der Benutzer nicht lokal bereits eingeloggt ist
  export XDG_SESSION_TYPE=x11
fi
export GNOME_SHELL_SESSION_MODE=ubuntu
dbus-launch --exit-with-session gnome-session --session=ubuntu
EOF
vncserver -kill $DISPLAY

Hintergrund ist, dass meine Lösung weiter oben nur funktioniert hat, sofern der betreffende Nutzer am Server-Rechner lokal eingeloggt war und andernfalls nur zu einem schwarzen Fenster innerhalb des VNC-Viewers führte.

LG, Newubunti

Newubunti schrieb:

Cordess schrieb:

Wenn du eine Lösung für eine "system user unit" hast, ...

Ich meinte VNC.

Das kann man erreichen indem man zunächst die betreffende Benutzer-Unit aktiviert, also

systemctl enable <UNIT> --user 

und dann das lingering für den betreffenden Nutzer aktiviert:

sudo loginctl enable-linger <BENUTZER> 

Gegenüber des Posts 9288005 weiter oben sieht meine ~/.vnc/xstartup nun unter Focal so aus:

#!/bin/sh

test x"$SHELL" = x"" && SHELL=/bin/bash
test x"$1"     = x"" && set -- default

vncconfig -iconic &
"$SHELL" -l << EOF
if [[ ! "$DISPLAY" -eq ":1" ]]; then
  # wird im Zusammenspiel mit systemd benötigt um x zu starten,
  # falls der Benutzer nicht lokal bereits eingeloggt ist
  export XDG_SESSION_TYPE=x11
fi
export GNOME_SHELL_SESSION_MODE=ubuntu
dbus-launch --exit-with-session gnome-session --session=ubuntu
EOF
vncserver -kill $DISPLAY

Hintergrund ist, dass meine Lösung weiter oben nur funktioniert hat, sofern der betreffende Nutzer am Server-Rechner lokal eingeloggt war und andernfalls nur zu einem schwarzen Fenster innerhalb des VNC-Viewers führte.

LG, Newubunti

Der Artikel funktioniert, so wie er ist, unter Xubuntu 21.10. Siehe mein vorheriges Kommentar, ich habe das jetzt nämlich getestet.

Ja, ist doch schon wenn er unter 21.10 funktioniert. Und unter Ubuntu 20.04 würde er halt mit Modifikationen auch funktionieren. Im übrigen hatten sich die Posts zeitlich auch überschnitten.

Ist halt die Frage, ob Du an den Modifikationen interessiert bist oder nicht?

LG, Newubunti