Es kann ziemlich verwirrend sein.
Es kann auf einem Server ein, oder mehrere X-Server laufen.
Jeder X-Server kann mehrere Displays haben.
Es können also auch viele XServer mit jeweils vielen Displays laufen.
Ohne die jeweiligen Configs, macht es wenig Sinn.
Da bleibt nur der Hinweis: Doku lesen.
Am Rande: Auch die Wahl des Displays muss bei Nummer 2 nicht notwendigerweise auf dem Port 5902 landen.
(Zumal prinzipiell alle Ports verbogen werden können)
Falls mir jemand sagen kann, welche Dateien hier relevant sind, wäre das ja mal ein Ansatz.
Das scheint alles nicht so einfach zu sein - ich lege dir daher noch einmal die x11vnc-Lösung ans Herz. Die erfüllt immer noch auf ihre Weise die minimalistischen Ansprüche.
Aber aufdrängeln werd ich sie dir natürlich nicht .. 
ZitatIch installiere eh per Yast das ganze System, KDE / GNOME ist auch Wurst, da ich 99% mit Konsole arbeite.
und warum dann nicht ssh?
Ein X-Server stellt für eine graphische Oberfläche alle Mittel bereit.
Dafür kontrolliert er Maus, Tastatur, Tablets, Pens und der gleichen.
Er ist -wie Linux selbst- multiuser/multitasking fähig.
Und er kann via Netzwerk arbeiten.
Man kann sogar mehrere X-Server laufen haben.
Ein X-Server stellt dafür für jede graphische Konsole einen sogenannten Displayport bereit. Diese Ports werden schlicht mit Null beginnend durchnummeriert.
Heute liegt die erste graphische Konsole auf <strg><alt><f7>.
Die verwendet Display:0 (auch per Konvention).
Auf den vorherigen Konsolen liegen schlicht normale Terminals, bei denen bereits das login Programm läuft.
Das ist aber noch nicht alles. Man kann sich z.B. mit ssh -X (was -X-Server forwarding heißt) auf einen Server verbinden. Dort kann man dann auf einer ssh-Konsole z.B. firefox aufrufen. Dort startet dann ein Firefox, der seine Ausgabe auf dem dort laufenden X-Server macht, dessen Displayport via ssh an den lokalen X-Server weiterleitet, der dann auf dem lokalen Bildschirm das Fenster der remote laufenden Firefoxinstanz anzeigt.
Ein X-Server kann auch selbst TCP/IP Verbindungen akzeptieren, was heute ein gewaltiges Sicherheitsloch darstellt, und deshalb bei allen Distris von Haus abgeschaltet wird.
Dafür verwendet man heute vnc (=VirtualNetworkComputing) oder rdp (=RemoteDesktopProtocol) (vnc==Linux, rdp==Microsoft). Natürlich kann Linux beide Protokolle. Ein sehr guter VNC/RDP Client ist Remmina
Ein modernes, sehr schnelles Protokoll für diese Fensterverschiebebahnhöfe ist spice, das hauptsächlich bei Virtualisierungen eingesetzt wird.
Im wesentlichen muss dieses Protokoll Mausbewegungen, Keyboardanschläge und alle Fenster übertragen. Da das eine ziemliche Menge an Daten sein kann, wird das komprimiert und verschiedene Algorithmen versuchen möglichst wenig "Bilder" des "Desktops" zu übertragen (nur was geändert wird, usw.).
Damit man nun einen entfernten X-Server verwenden kann, braucht man einen VNC-Server, der sich darum kümmert.
Der ist quasi eine zwischen remote-X-Server und lokalem X-Server zwischengeschaltete "Netzwerkinstanz".
Und damit wären wir bei dem Problem der Autorisierung. Ein Linuxserver hat zu prüfen und tut das auch, wer für den Zugriff berechtigt ist. Das ist im einfachsten Falle schlicht ein normaler Linuxuser Account, und man autorisiert sich mit dem zugehörigen Spasswort. Es könnte aber auch mit einem kerberisierten LDAP Server, der wiederum in einer echten SQL-DB alle Daten speichert, gemacht werden.
Oder mal ganz abgedreht: Ein Linuxuser wird in einer Mircosoft ActiveDirectory Domain verwaltet, die via Kerberos entsprechende Rechte vergibt. Geht auch. Kann man ganz schön wild und kompliziert machen.
Aber irgendwie muss es gemacht werden.
ODER man will eine "persistente VNC-Verbindung". Das heißt nichts anderes, als dass ein X-Server-user einfach auf einem Server einen Displayport belegt hat, und den anderen über das Netzwerk zur Verfügung stellt. Damit können sich viele User in EINER X-Session EIN Display teilen. Es wird dazu ein Einmalspasswort generiert.
Falls ich dich recht verstanden habe, willst du aber eine "singuläre VNC- Verbindung". Die läuft halt (und alle darin laufenden Fenster/Programme) solange diese Netzwerksitzung halt läuft.
Da muss sich jetzt der vncserver drum kümmern, dass der User korrekt eingeloggt wird, bevor er den Zugriff auf einen Displayport des dortigen X-Servers gestattet. Und das kann kompliziert sein.
Der xinetd ist der sogenannte "Superserver". Eine etwas antiquirte Konstruktion, die auf allen Ports für alle dafür konfigurierte Server lauscht, und bei Verbindungseingang dann den jeweiligen Server startet, die Anfrage dorthin weiterleitet. Ist die Anfrage beendet, beendet sich auch der eigentliche Serverdienst wieder und der xinetd lauscht wieder stellvertretend für den Serverdienst auf diesem Port. xinetd kann auf vielen Ports für viele Serverdienste lauschen. Aber man braucht ihn nicht. Man jeden Serverdienst auch ohne ihn laufen lassen. Zum Preis für mehr Ressourcenverbrauch (mehr RAM, mehr Rechenleistung...).
Er ist NICHT für den Betrieb eines vncservers essentiell.
Es ist halt so konfigurierbar, weil man VNC-Sessions nicht so oft braucht und hauptsächlich RAM und Rechenzeit sparen will.
Der vnchttpd dient nur dazu das ganze VNC- Gedöns via http: abwickeln zu können. Was einem viel Ärger mit "ahnungslosen Kandidaten" sparen kann, weil man nicht an der Firewall viel rumfrickeln muss.
Letztlich genügt es also EINEN vncserver zu starten und sich auf den -mit den passenden Einstellungen- mit EINEM vncviewer zu verbinden. Done.
Die wichtigsten Einstellungen sind vncserver -geometry 1024x768 :8 , die du dann beim viewer ebenso angibst. Siehe man vncserver und man vncviewer
Ebenso, wie man z.B. auf der graphischen Konsole <strg><alt><f7> KDE starten kann UND gleichzeitig auf <strg><alt><f8> dann Gnome starten kann, können natürlich auch dem vncserver entsprechende DEs zugewiesen werden.
Das lesen wir aber erst in der nächsten Märchenstunde.
Mach also allen Krempel mit xinetd aus.
Starte einfach gemäß man vncserver eine Instanz und verbinde dich mit korrekten Parametern.
Klappt das, kann man gucken, welche Methode für einen evtl. gewünschten "Autostart" sinnvoll ist.
Würdest du -statt deinen Mutmaßungen- eher die konkreten Konfigs posten, könnte man evtl. besser helfen.
Würdest du -statt deinen Mutmaßungen- eher die konkreten Konfigs posten, könnte man evtl. besser helfen.
Aber danach hatte doch der TE anfangs gefragt. "Wo sind diese zu finden!"
Er würde diese dann doch selber anpassen.
