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

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


    das da war gemeint:


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



    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,

    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"

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • 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.

    Das Genie beherrscht das Chaos

  • 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.

  • 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. DamalsTM als es noch keinen verschlüsselten Netz-Traffic gab … :tüdeldü:

    Das Genie beherrscht das Chaos

  • 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.

  • 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?

    Das Genie beherrscht das Chaos

  • 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).

  • ... mal zum jetzigen Oberthema:


    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).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • 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

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • 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 :)

  • 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.

  • 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).

  • Das ist mal wieder sowas, wie man es von/bei Apple auch erwarten würde.

    Und es läuft nach dem hier auch bereits mit/auf M1 Macs (ab version >= 2.7.11).


    . https://de.wikipedia.org/wiki/XQuartz

    . https://support.apple.com/de-de/100724 (official Apple statement)

    . https://www.xquartz.org/ ; https://github.com/XQuartz ; https://formulae.brew.sh/cask/xquartz#default


    oder

    . https://ports.macports.org/port/xorg-server/details/ ; https://ports.macports.org/port/xorg-server-legacy/details/

    ab v 1.20 fallen da aber ein paar AltSysteme raus und sind dann nur noch in legacy" verfügbar; die v 1.18 hat noch "alles".


    und hier steht noch, was man wie einstellen und configurieren muß, damit es "läuft"

    . https://www.cyberciti.biz/faq/…s-install-xquartz-server/

    .s

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Edited once, last by ThoralfAsmussen ().