ubuntuusers.de

Also TigerVNC 1.12 ist in den Quellen von Jammy: https://packages.ubuntu.com/jammy/tigervnc-standalone-server

Ich habe es mit Ubuntu Jammy getestet, damit funktioniert es jetzt so wie im Artikel dargestellt - was ja nach meinen ganzen Tests so auch erwartbar war.

LG, Newubunti

EDIT:

Ich habe mir noch erlaubt, das Kopieren der systemd-Unit Datei des Distributors nach /etc/systemd/system zu entfernen, weil das nur dann sinnvoll ist, wenn man Änderungen an der Datei vornehmen will, die bei einem Update des Pakets seitens des Distributors erhalten bleiben sollen. Da aber keine Veränderung im Artikel vorgenommen werden, ist es eher schädlich, weil so Updates an der Datei seitens des Distributors nicht zwangsläufig zur Anwendung kommen.

Außerdem habe ich der Einheitlichkeit auf der Plattform halber von "SystemD" auf "systemd" geändert.

Auch wenn ich strukturell einiges anders gemacht hätte, kann der Artikel IMO so ins Wiki.

Newubunti schrieb:

Ich habe mir noch erlaubt, das Kopieren der systemd-Unit Datei des Distributors nach /etc/systemd/system zu entfernen, weil das nur dann sinnvoll ist, wenn man Änderungen an der Datei vornehmen will, die bei einem Update des Pakets seitens des Distributors erhalten bleiben sollen.

Ist die Datei denn in /etc/systemd/system unter Ubuntu 21.10 in identischer Form vorhanden? In Debian 11 (bullseye) bzw. auf dem entsprechenden Raspberry Pi (Rasbian OS) musste ich diesen Schritt im November 2021 nach einem Dist-upgrade von Debian 10 Buster nämlich noch machen, deswegen habe ich das in den Artikel damals eingebaut. Wenn sie aber in funktionstüchtiger Defaultkonfiguration vorhanden ist, dann kann man diesen Schritt natürlich weglassen.

Da aber keine Veränderung im Artikel vorgenommen werden, ist es eher schädlich, weil so Updates an der Datei seitens des Distributors nicht zwangsläufig zur Anwendung kommen.

Ich weiß was du meinst, das ist immer ein mögliches Problem mit Konfigurationsdateien in /etc Voraussetzung für ein Belassen ist halt, dass die default Konfigurationsdatei in ihrer default Form schon funktionstüchtig ist. Bei meinem Wechsel von Rasbian OS (entspricht Debian 10) auf 11 war das in 11 nicht so.

Außerdem habe ich der Einheitlichkeit auf der Plattform halber von "SystemD" auf "systemd" geändert.

Ok.

Auch wenn ich strukturell einiges anders gemacht hätte, kann der Artikel IMO so ins Wiki.

Das dauert bestimmt noch ein Jahr. 😎

Cordess schrieb:

Ist die Datei denn in /etc/systemd/system unter Ubuntu 21.10 in identischer Form vorhanden?

Nein, und das muss sie auch gar nicht - siehe systemd/Units (Abschnitt „systemweite-Units“). Sie ist dort vorhanden, von wo Du sie Dir kopiert hast, also in /lib/systemd/system/.

Du kannst die Units direkt aus /lib/systemd/system/ grundsätzlich starten und aktivieren und zwar mit dem gleichen systemctl-Befehl, egal in welchem der von systemd vorgesehenen Verzeichnisse die Datei nun liegt.

Und wenn man die Unit-Datei NICHT anpasst, dann ist diese Vorgehensweise zu bevorzugen.

Würde man sie dagegen individuell anpassen, dann wäre die richtige Vorgehensweise die von Dir beschriebene, denn dann möchte man ja unter Umständen gerne verhindern, dass sie bei einem Update überschrieben wird.

Auf diese Weise behält man auch leichter den Überblick, welche Units man selbst angepasst/erstellt hat und welche man einfach so nutzt, wie sie vom Distributor vorgesehen sind.

Das alles funktioniert genauso auch für Debian Bullseye. Mit Buster habe ich TigerVNC nicht getestet.

Voraussetzung für ein Belassen ist halt, dass die default Konfigurationsdatei in ihrer default Form schon funktionstüchtig ist. Bei meinem Wechsel von Rasbian OS (entspricht Debian 10) auf 11 war das in 11 nicht so.

Nun, läge Sie dort nicht in identischer, funktionstüchtiger Form vor, dann wäre Dein Kopier-Befehl auch irgendwie sinnlos, oder?

Davon abgesehen gab es bei Buster auch noch gar keine systemd-Unit, siehe: https://packages.debian.org/buster/amd64/tigervnc-standalone-server/filelist

Die systemd-Unit gibt es erst ab dem 1.11er Release: https://github.com/TigerVNC/tigervnc/tree/1.11-branch/unix/vncserver

in Bullseye: https://packages.debian.org/bullseye/amd64/tigervnc-standalone-server/filelist

Warum Du die Datei bei Dir von /lib... nach /etc/... hast umziehen müssen, liegt wahrscheinlich daran, dass Du für Buster eine eigene Unit angelegt hattest - das hattest Du glaube ich irgendwo weiter vorne so geschrieben.

Wenn Du dann sowohl in /lib... als auch in /etc/... eine Unit mit gleichen Namen hast, dann startet die Unit aus /etc. Und da Deine Unit von weiter vorne im Thread anders ist, als die Unit aus Bullseye hat es dann bei Dir nicht funktioniert.

Daraufhin hast Du wahrscheinlich die Unit von /lib nach /etc kopiert - also die neue die mit Bullseye kam - und damit die alte Unit überschrieben. So hat es dann bei Dir funktioniert. Es hätte aber auch gereicht, wenn Du Deine eigene Unit einfach aus /etc gelöscht hättest.

Ich war natürlich nicht dabei und mag deshalb falsch liegen, aber anhand was Du hier im Thread gepostet hast, halte ich es für möglich und wahrscheinlich, dass es so war.

LG, Newubunti

Hi!

Rein formal habe ich den Artikel jetzt wikikonform gemacht, inhaltlich kann ich leider nichts beitragen...

so long
hank

Hallo,

formell ist da doch IMHO eine Fehler drin: der Artikel sagt an mehreren Stellen, dass man sich per ssh auf dem Server einlogen muss, um dies und das (z.B. Paketinstallation) zu machen - aber warum? Oder anders: was wäre nicht möglich, wenn man physischen Zugriff auf den Server hat? Oder eine andere Art der Remote-Verbindung außer ssh? Wenn es #ausgründen ssh sein muss bitte den Grund explizit angeben. Wenn es nicht ssh sein muss bitte den Artikel so umschreiben, dass dem Leser die Wahl der Zugriffs auf den Server überlassen wird. Das Wiki gibt das Mittel der Wahl nur vor, wenn es genau das Mittel sein _muss_.

Gruß, noisefloor

Newubunti schrieb:

Du kannst die Units direkt aus /lib/systemd/system/ grundsätzlich starten und aktivieren und zwar mit dem gleichen systemctl-Befehl, egal in welchem der von systemd vorgesehenen Verzeichnisse die Datei nun liegt.

Und wenn man die Unit-Datei NICHT anpasst, dann ist diese Vorgehensweise zu bevorzugen.

Ok.

Davon abgesehen gab es bei Buster auch noch gar keine systemd-Unit, siehe: https://packages.debian.org/buster/amd64/tigervnc-standalone-server/filelist

Das war ja auch der Grund, warum ich sie nach dem Update von Bullseye dann aus dem /lib/.. Verzeichnis nach /etc/.. kopiert habe.

Warum Du die Datei bei Dir von /lib... nach /etc/... hast umziehen müssen, liegt wahrscheinlich daran, dass Du für Buster eine eigene Unit angelegt hattest - das hattest Du glaube ich irgendwo weiter vorne so geschrieben.

Exakt.

Wenn Du dann sowohl in /lib... als auch in /etc/... eine Unit mit gleichen Namen hast, dann startet die Unit aus /etc. Und da Deine Unit von weiter vorne im Thread anders ist, als die Unit aus Bullseye hat es dann bei Dir nicht funktioniert.

Weswegen ich sie aus /lib dann nach /etc kopiert habe. Ich dachte bisher, die Config Files in /lib wären nur Beispiele, aber gut zu wissen, dass die auch aktiv vom System genutzt werden.

Daraufhin hast Du wahrscheinlich die Unit von /lib nach /etc kopiert - also die neue die mit Bullseye kam - und damit die alte Unit überschrieben. So hat es dann bei Dir funktioniert. Es hätte aber auch gereicht, wenn Du Deine eigene Unit einfach aus /etc gelöscht hättest.

Ja, das hätte dann auch gereicht, war mir damals zu dem Zeitpunkt aber nicht klar.

Hallo,

Weswegen ich sie aus /lib dann nach /etc kopiert habe. Ich dachte bisher, die Config Files in /lib wären nur Beispiele, aber gut zu wissen, dass die auch aktiv vom System genutzt werden.

Na ja, du hättest auch einfach die systemd Artikel hier im Wiki lesen können. Da ist beschrieben, wo was liegt und wann was geladen wird. Und das Sahnehäubchen daran: das allermeiste davon gilt sogar auch für Debian, auch wenn das Wiki hier rein auf Ubuntu fokussiert.

Apropos Debian: bitte keine Diskussionen hier im Thread, wann wie wo was unter Debian Version $FOO funktioniert (oder eben nicht). Debian hat keine Relevanz für das Wiki hier.

Gruß, noisefloor

Heinrich_Schwietering schrieb:

Hi!

Rein formal habe ich den Artikel jetzt wikikonform gemacht, inhaltlich kann ich leider nichts beitragen...

so long
hank

Passt.

noisefloor schrieb:

Hallo,

formell ist da doch IMHO eine Fehler drin: der Artikel sagt an mehreren Stellen, dass man sich per ssh auf dem Server einlogen muss, um dies und das (z.B. Paketinstallation) zu machen - aber warum? Oder anders: was wäre nicht möglich, wenn man physischen Zugriff auf den Server hat? Oder eine andere Art der Remote-Verbindung außer ssh? Wenn es #ausgründen ssh sein muss bitte den Grund explizit angeben. Wenn es nicht ssh sein muss bitte den Artikel so umschreiben, dass dem Leser die Wahl der Zugriffs auf den Server überlassen wird. Das Wiki gibt das Mittel der Wahl nur vor, wenn es genau das Mittel sein _muss_.

Gruß, noisefloor

Das ist kein Fehler, der Artikel ist für eine Remoteeinrichtung geschrieben.

Beachte bitte, das ich den Artikel ursprünglich für einen Rasberry Pi 3 geschrieben habe und an dem ist bei mir kein Display angeschlossen und der steht auch ganz wo anders als meine Monitore. Das wird wahrscheinlich bei sehr vielen Nutzern so sein die einen Raspi haben und genau deswegen die VNC Verbindung haben wollen oder benötigen.

Der fehlende Monitor ist ja meist der Grund, warum man VNC überhaupt einsetzen will. Wer nen Rechner mit lokalen Bildschirm hat, der braucht VNC in den seltensten Fällen, wozu sollte man da VNC nutzen? Also musst du davon ausgehen, dass an einem solchen Server kein Bildschirm angeschlossen ist und die Einrichtung daher remote per SSH erfolgen muss. Und dafür ist der Artikel optimal geeignet und auch geschrieben.

Und dann gibt es Server, die haben nicht einmal eine Grafikkarte installiert, das ist bspw. bei vielen IPMI Mainboards der Fall, die werden Remote konfiguriert. Da kann man zwar via IPMI sich das BIOS und den Start des Rechners grafisch in reinem 2d VGA Remote auf dem Remote Client Rechner im Browser ansehen, aber spätestens wenn darin eine grafische Oberfläche gebootet werden sollte, die eine 3d Beschleunigung voraussetzt, funktioniert das auf einer solchen Hardware so nicht mehr. Dann bleibt nämlich der virtuelle Remote Bildschirm schwarz, da der IPMI BDM Chipsatz nur 2d VGA kann und mehr nicht.

Auf solchen Servern hast du zwar auch physischen Zugriff zur Hardware, aber weder eine Grafikkarte im Server stecken noch einen Bildschirm in Reichweite.

Würde man den Artikel jetzt umbauen und die Remote Installation nicht mehr berücksichtigen, dann wäre der Artikel von geringerem Nutzen, da dann jeder seinen Bildschirm zum Server schleppen müsste um ihn dort anzuschließen.

Und wenn du sowieso nen Bildschirm am Server angeschlossen hast, dann brauchst du auch kein VNC.

EDIT:

Ach und dann noch etwas. Und wenn du das remote per SSH konfigurierst, dann ist auch das Testen der VNC Verbindung viel einfacher und das musst du ja dann sowieso machen. Ein Artikel, der für eine lokale VNC Einrichtung vorgesehen ist, ist somit nicht nur nutzlos, sondern auch noch extrem umständlich, da man dann zum Prüfen, ob alles klappt und das VNC Bild auf dem Client dargestellt wird, zum Client rennen muss. Wozu also so umständlich? Per remote SSH Konfiguration kann man die VNC Verbindung nicht nur remote per SSH vom Client aus konfigurieren, sondern auch noch gleich testen ob sie funktioniert.

@Cordess:

noisefloor sagt gar nicht, dass Deine Darstellung falsch ist.

Es geht um etwas anderes:

Wenn Du, wie in Deinem Fall, auf einem "Headless"-System installierst, dann verbindest Du Dich dahin doch sowieso ohnehin immer remote - wie auch immer - könnte z.B. auch RDP statt SSH sein. D.h. diese Personnengruppe kann auch darauf verzichten, dass vor

sudo apt-get install tigervnc-standalone-server 

noch

ssh user@server 

steht.

Wer einen Desktop hat, der kann aber nun mal - wenn wir nur über die Paket-Installation reden -

sudo apt-get install tigervnc-standalone-server 

nun mal auch lokal ausführen - ohne dass irgendetwas kaputt geht. Man kann es so wie es jetzt ist, halt auch so missverstehen, dass es zwingend notwendig sei, sich per SSH zu verbinden um speziell tigervnc-standalone-server zu installieren.

IMO kann man bei der Paketinstallation da schon drauf verzichten, ohne dass Dein Artikel weniger wert wird. D.h. ja nicht, dass das mit dem ssh überall raus soll.

LG, Newubunti

Hallo,

Das ist kein Fehler, der Artikel ist für eine Remoteeinrichtung geschrieben.

Ok. Vorschlag: wir machen das zum Howto und gut ist = der Artikel wird aus der Baustelle entlassen.

Gruß, noisefloor

Newubunti schrieb:

IMO kann man bei der Paketinstallation da schon drauf verzichten, ohne dass Dein Artikel weniger wert wird. D.h. ja nicht, dass das mit dem ssh überall raus soll.

Dann installiert der Leser das tigervnc-server Paket auf dem Client weil er vergisst, es auf dem Server zu machen oder sich dort einzuloggen.

Ich denke, man sollte es so lassen wie es jetzt ist, denn jetzt ist es "DAU"-Sicher. Man muss nur befolgen was da steht und schon bekommt man eine brauchbare Konfiguration. Alles andere verkompliziert die Sache nur unnötig, denn nicht jeder Nutzer ist auch ein erfahrener Nutzer.

noisefloor schrieb:

Hallo,

Das ist kein Fehler, der Artikel ist für eine Remoteeinrichtung geschrieben.

Ok. Vorschlag: wir machen das zum Howto und gut ist = der Artikel wird aus der Baustelle entlassen.

Gruß, noisefloor

Wo ist der Unterschied? Meiner Aufassung nach sind alle Wiki Artikel Howto

Wichtig ist mir, dass im Artikel VNC/#TigerVNC dort auf diesen Artikel verwiesen wird, damit der Artikel auch gefunden wird.

Hallo,

Meiner Aufassung nach sind alle Wiki Artikel Howto

Nee, eben nicht. Der Unterschied bzw. der Unterschied hier bei uu.de ist in der Doku des Wikis und für Howtos erklärt. Kann man alles nachlesen. Macht in der Regel auch Sinn, dass vorher zu machen, weil das viele beschleunigt.

Egal, letzte Frage für das Howto: wann hast du das Howto in der aktuellen Form durchgetestet und für welches *buntu? Bitte den Namen und die Version des Derivates angeben.

Gruß, noisefloor

Steht eigentlich im Artikel. Ubuntu 21.10 Impish Indri

22.04 ist ja noch nicht draußen.