X11 auf andere Maschine umleiten (Offtopic aus Linux - kein Start nach...)

Wildfire · 16. Dezember 2023

Du meinst bestimmt die export display Geschichte - die ist aber nur nötig wenn Du auch das x auf einem anderen Rechner darstellen möchtest...

ThoralfAsmussen · 17. Dezember 2023

Zitat von IchBinAlt

Habe ich "lokal" geschrieben? Kann das gerade nicht finden.

das da war gemeint:

Zitat von IchBinAlt

Ansonsten würde ich auf eine Konsole booten, mich von dort einloggen und dann den X-Server "per Hand" starten. Vorzugsweise auch per ssh ...

Zitat von Wildfire

Du meinst bestimmt die export display Geschichte - die ist aber nur nötig wenn Du auch das x auf einem anderen Rechner darstellen möchtest...

Nicht nur . Die Display Variable muß schon auch stimmen,

Zitat von IchBinAlt

wobei ich mich zu erinnern glaube, dass man da vorher noch eine Environment-Variable setzen musste, damit das klappt.

und gemeint ist bestimmt, daß man unter ssh das X11-forwarding anschalten muß. Das verbirgt sich irgendwo in so einer config Datei zu ssh und man kann stundenlang um ein Bild kämpfen, wenn man das nicht anmacht und von außen per ssh kommt. Das klappt dann einfach nicht.

edit: in /etc/ssh/ssh_config muß stehen "ForwardX11 yes" und u.U. auch noch "ForwardX11Trusted yes"

ChaosRom · 28. Dezember 2023

Zitat von Wildfire

Du meinst bestimmt die export display Geschichte - die ist aber nur nötig wenn Du auch das x auf einem anderen Rechner darstellen möchtest...

Wenn man von einem entfernten Rechner über ssh X starten will und das Bild aber auch der Maschine, auf der man eingeloggt ist, dargestellt werden soll (und das soll ja hier getestet werden) muss man tatsächlich mit

Code

export DISPLAY=:0.0

die Anzeige umstellen. Ansonsten würde versucht die Ausgabe auf den Rechner, von dem das ssh gestartet wurde, umzuleiten.

tofro · 28. Dezember 2023

Zitat von ChaosRom
Wenn man von einem entfernten Rechner über ssh X starten will und das Bild aber auch der Maschine, auf der man eingeloggt ist, dargestellt werden soll (und das soll ja hier getestet werden) muss man tatsächlich mit
Code
export DISPLAY=:0.0
die Anzeige umstellen. Ansonsten würde versucht die Ausgabe auf den Rechner, von dem das ssh gestartet wurde, umzuleiten.

Die Weiterleitung des Displays auf den entfernten Rechner passiert nur, wenn man dort ssh mit der "-X" oder "-Y" - Option (die genau das aktiviert) aufgerufen hat. Ansonsten sollte das Display schön lokal bleiben. Die ssh-man-Page empfiehlt, die "DISPLAY"-Variable schön in Ruhe zu lassen.

ChaosRom · 28. Dezember 2023

Soweit ich weiß, schlägt es ohne das Einschalten des X-Forwards beim ssh halt fehl. Der Mechanismus des Forwards ging aber schon zu Telnet-Zeiten und da war es kein Tunnel über die Verbindung, sondern einfach ein separater Kanal. Damals^TM als es noch keinen verschlüsselten Netz-Traffic gab …

frank128 · 28. Dezember 2023

Zitat von ChaosRom

Soweit ich weiß, schlägt es ohne das Einschalten des X-Forwards beim ssh halt fehl. Der Mechanismus des Forwards ging aber schon zu Telnet-Zeiten und da war es kein Tunnel über die Verbindung, sondern einfach ein separater Kanal.

X11 erlaubt vom Konzept her ein remote Display, wobei der "X11-Server" das System ist, wo die Anzeige der Grafik Daten erfolgt (ein System mit Grafikkarte). Das System, wo das X11-Programm läuft (egal ob lokal oder remote) ist der "X11-Client". Beides kann auf unterschiedlichen Systemen laufen. Wenn X11-Client und X11-Server auf demselben System laufen (heute Normalfall), ist DISPLAY=:0.0. Wenn nicht, läuft X11 über das Netzwerk (mit den damit verbundenen Performance Verlusten). Ein SSH X11-Forwarding ist in diesem Fall nicht nötig, da eine direkte (unverschlüsselte) X11-Verbindung möglich ist. Das X11 SSH Tunneling macht die Sache noch langsamer. Der einzige Grund für die SSH-X11-Weiterleitung ist Security - Verschlüsselung des X11 Trafik und weniger offen zugängliche Ports auf der Seite des X11-Servers. Bei einer X11 Remote Konstellation enthält die DISPLAY Variable die IP-Adresse des X11-Servers, beim X11 SSH forwarding ist sie wie bei einer lokalen X11 Konstellation DISPLAY=:0.0.

ChaosRom · 29. Dezember 2023

Das mit dem Server und dem Client hab ich bewusst versucht zu umschiffen. Fand ich schon immer verwirrend.

Weiter oben ging es ja aber um etwas ganz anderes, nämlich die lokale Anzeige auf dem X-Client, obwohl das Programm von Remote gestartet wurde. Die heute übliche Form des Remote-Zugriffs ist ssh. Ich habe versucht zu erklären, was es mit -X und DISPLAY auf sich hat.

Das eigentliche Problem ist aber ja, dass das System nach dem Prozessor—Downgrade nicht mehr funktioniert wie vorher.

ThoralfAsmussen : Du hast in deinem Eingangspost geschrieben, dass du das BIOS-Setup auf Standardwerte zurückgesetzt hast. Hast du das vor dem Downgrade auch gemacht? Linux-Kernel sind schon lang nicht mehr so spezifisch wie früher. Wird die neue CPU vom Chipsatz und vom BIOS unterstützt?

dirkt · 29. Dezember 2023

Zitat von ChaosRom

Das mit dem Server und dem Client hab ich bewusst versucht zu umschiffen. Fand ich schon immer verwirrend.

Ist eigentlich gar nicht verwirrend: Der Server ist das Programm, dass den Framebuffer kontrolliert. Clienten sind die Programme, die sich mit dem Server verbinden, und dann per Protokoll etwas in den Framebuffer hineinmalen lassen. "DISPLAY" ist das, was dem Client sagt, wo der Server sitzt, mit dem er sich verbinden möchte. Also:

Lokale Maschine: Server und Clienten laufen beide auf der gleichen Hardware, DISPLAY ist ":0" (lies: lokale Hardware, Nummer 0).

Mit X-Terminal-Hardware: Der Server läuft auf dem X-Terminal, die Clienten laufen auf der Unix-Kiste, DISPLAY ist "<IP-addresse des X-Terminals>:0". Der Anmeldebildschirm wird durch den Display Manager hingezaubert.
Mit ssh von A nach B: Der sshd auf B tut so, als ob er ein lokalen Server hätte, aber schickt alles an den echten X-Server, der auf A läuft. Auf B ist "DISPLAY" so etwas wie ":10" (oder ":11", ":12", usw., wenn es mehrere Verbindungen gibt). Auf A ist das DISPLAY der lokale X-Server.
Variante: Läuft auch auf B ein X-Server, und möchte derjenige, der an A sitzt, die Programme auf B auch auf dem Bildschirm von B anzeigen, dann setzt man von Hand in der ssh-Sitzung auf B das DISPLAY auf ":0" (und macht evtl. noch "xauth" Kram etc., falls nötig).

Ich hoffe, das klärt die Verwirrung etwas. (Und ja, OT).

ThoralfAsmussen · 29. Dezember 2023

... mal zum jetzigen Oberthema:

Zitat von frank128

Wenn X11-Client und X11-Server auf demselben System laufen (heute Normalfall), ist DISPLAY=:0.0

Das kann so sein, muß aber nicht.

Man kann nämlich auch eine weitere "Sitzung" auf einem anderen DISPLAY starten. Die läuft dann parallel zum normalen Desktop. Prinzipiell könnten das sogar beliebig viele sein, nur daß sich die Desktops und WindowManager gelegentlich nicht gut vertragen und dann doch immer mal was abstürzt oder nicht starten mag.

startx /usr/bin/mwm -- :1 vt8 -nolisten tcp

würde eine weitere Instanz aber mit dem uralt Fensterverwalter "mwm" starten - und zwar als DISPLAY :1.0 auf der Konsole Ctrl+Alt+F8. Die nolisten Option kann man auch weglassen. Man hat dann quasi einen Zwietdesktop in einem Gerät und kann mit Tastenkombination zwischen beiden wechseln. In der mwm Variante ist aber die DISPLAY Variable dann natürlich immer :1 bzw. :1.0 (kann man mit env überprüfen).

**yalsi** · 29. Dezember 2023

Für den Zugriff auf entfernte Maschinen von einem Linuxrechner aus ist Xephyr das Mittel der Wahl. Der startet einen XServer in einem Fenster einstellbarer Größe in der laufenden X11 Session:

Xephyr › Wiki › ubuntuusers.de

dirkt · 29. Dezember 2023

Zitat von ThoralfAsmussen

... mal zum jetzigen Oberthema:

Zitat von frank128

Wenn X11-Client und X11-Server auf demselben System laufen (heute Normalfall), ist DISPLAY=:0.0

Das kann so sein, muß aber nicht.

Man kann nämlich auch eine weitere "Sitzung" auf einem anderen DISPLAY starten.

Alles anzeigen

Ich hatte mal eine Zeitlang einen X-Server für meinen Monitor und einen für meinen Fernseher (zum Filme gucken), weil der Hardware-Video-Scaler sonst nicht lief, aber außer Leuten wie mir machen das normalerweise nicht viele

frank128 · 29. Dezember 2023

Zitat von ChaosRom

Das mit dem Server und dem Client hab ich bewusst versucht zu umschiffen. Fand ich schon immer verwirrend.

In der alten IT-Steinzeit gab es neben dem Großrechner separate spezialisierte Geräte für die User Kommunikation. Anfangs eine Art Fernschreiber „teletype“, später intelligente Text-Terminals mit Bildschirm. In der Unix Welt wollte man dieses Konzept neben reinen Text Output auf für Grafik Output nutzen, also X11-Terminals (Grafik Terminals via X11 Protokoll). Daher wurde über das Client/Server Konzept das Programm und die Anzeige logisch (und wenn gewollt auch physikalisch) entkoppelt. Bei sowas wie DOS und Windows gab es diese Entkoppelung nicht mehr. Und mit Wayland (dem Ersatz für X11) wird es das unter Linux auch nicht mehr geben.

masi · 30. Dezember 2023

Ich benutze ständig XQuartz, um Fenster der in der Rumpelkammer stehenden Linux-Maschine auf dem Mac mini-Desktop anzuzeigen. Einfach mit schon genannten "ssh -Y" reingehen, dann z.B. "emacs &" bzw. sicherheitshalber "nohup emacs &" (für den Fall, daß ich das Terminalfenster aus Versehen schließe).

masi · 30. Dezember 2023

Mit XQuartz werden unter macOS auch gängige X-Anwendungen installiert, so daß man auch lokal x-en kann. glxgears meldet auf dem Mac mini M1 zum Beispiel ungefähr 10.000 FPS.