[erledigt] Dauerhafte Lösung für "could not connect to display"?

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
kalamazoo
Beiträge: 286
Registriert: 28.08.2017 11:31:49

[erledigt] Dauerhafte Lösung für "could not connect to display"?

Beitrag von kalamazoo » 27.07.2022 22:37:30

Verschiedene CLI-Anwendungen geben mir die Fehlermeldung "could not connect to display" zurück (e.g. kcmshell5 --list). Mit den Befehlen xhost + sowie export DISPLAY=:0 ist dies leicht zu beheben. Wo -- das heisst: in welche Datei -- kann ich diese Befehle am zweckmäßigsten eintragen, sodass diese bereits beim Booten geladen werden und ich diese Befehle nicht wieder und wieder eingeben muss? Die Lösung sollte sowohl für user als auch für root Gültigkeit haben.
Zuletzt geändert von kalamazoo am 17.11.2022 14:36:26, insgesamt 1-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von MSfree » 28.07.2022 08:10:02

kalamazoo hat geschrieben: ↑ zum Beitrag ↑
27.07.2022 22:37:30
Verschiedene CLI-Anwendungen geben mir die Fehlermeldung "could not connect to display" zurück
Reine CLI-Anwendungen tun das nicht.
(e.g. kcmshell5 --list).
Das ist ja auch keine reine CLI-Anwedung, sondern eigentlich für KDE intern gedacht.
Mit den Befehlen xhost +
Den Befehl sollte man nicht ausführen und auch nicht ausführen müssen. Damit gibst du das Display für das gesamte Netzwerk frei.
sowie export DISPLAY=:0 ist dies leicht zu beheben.
DISPLAY ist in den diversen Terminalemulatoren (KTerm, xterm, Konsole...) sowieso gesetzt.
Wo -- das heisst: in welche Datei -- kann ich diese Befehle am zweckmäßigsten eintragen, sodass diese bereits beim Booten geladen werden und ich diese Befehle nicht wieder und wieder eingeben muss?
Was willst du denn überhaupt erreichen. "Beim Booten" ist mir zu vage. Der Xserver steht Anwendungen nunmal erst zur Verfügung, wenn man eingelogt ist, so daß Bootpürozesse da sowieso nicht drauf zugreifen können.

Wenn du etwas beim Einloggen starten willst, so ist dafür der Autostart-Mechanismus zuständig, der Skripte und Programme nach dem Login startet, wo dann auch das Display zur Verfügung steht.
Die Lösung sollte sowohl für user als auch für root Gültigkeit haben.
Sowas für root einzurichten, reißt Sicherheitslücken auf. Grundsätzlich sollte man als root überhaupt keine graphischen Programme ausführen. Zum Editieren von systemrelevanten Konfigurationsdateien gibt es CLI-Editoren, die kein DISPLAY benötigen, z.B. nano oder vim. Mehr als so ein Editor und ein paar Befehle, um Dienst zu starten oder zu beenden, braucht man als root nicht.
Zuletzt geändert von MSfree am 28.07.2022 10:21:58, insgesamt 1-mal geändert.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von hikaru » 28.07.2022 09:26:14

Falls(!) man trotz der Sicherheitsbedenken xhost so einsetzen möchte wie hier diskutiert, dann wäre eine sinnvolle Stelle um das zu setzen der userspezifische Autostart-Mechanismus der Desktop-Umgebung.

Um es nicht dem ganzen Netzwerk zu ermöglichen, Schabernack mit dem X-Server zu treiben, könnte man die Freigabe zumindest eingrenzen:

Code: Alles auswählen

xhost +si:localuser:root
(Wenn root Schabernack treibt, hat man eh verloren.)
Das ändert allerdings nichts an der Tatsache, dass es als eher unfein gilt, überhaupt GUI-Programme als root zu starten, denn der X-Server insgesamt ist eigentlich ein Sicherheitsproblem. Wenn wir aber dieses Fass aufmachen, dann haben wir hier bald einen 10-seitigen Philosophiethread.

Ich kenne mich mit KDE nicht aus und das einzige System auf das ich gerade Zugriff habe, auf dem KDE überhaupt installiert ist, ist ein Suse das unter Xfce läuft. Aber wenn ich dort als normaler User (habe hier keinen root-Zugriff) im Xfce-Terminal kcmshell5 --list ausführe, dann bekomme ich eine augenscheinlich sinnvolle, reine Terminal-Ausgabe:

Code: Alles auswählen

$ cmshell5 --list
The following modules are available:
about-distro               - Information About This System
audiocd                    - Audiocd IO Slave Configuration
autostart                  - Automatically Started Applications
[..]
Ich kann also ad hoc nicht nachvollziehen, wozu hier überhaupt Zugriff auf den X-Server gebraucht wird.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von MSfree » 28.07.2022 10:27:55

hikaru hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 09:26:14

Code: Alles auswählen

xhost +si:localuser:root
Sehr viel sinnvoller als xhost ist die Nutzung des MIT-Magic-Cookies. Dieses steht in der Datei ~/.Xauthority und wird bei jedem Login neu erzeugt. xhost wird überflüssig, wenn man das Cookie des Display bessitzt, auf das man zugreifen will.
Wenn root Schabernack treibt, hat man eh verloren.
Das gilt allerdings auch, wenn man .Xauthority nutzt statt xhost.

kalamazoo
Beiträge: 286
Registriert: 28.08.2017 11:31:49

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von kalamazoo » 28.07.2022 13:50:14

MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
Reine CLI-Anwendungen tun das nicht.
Okay, besser formuliert: Terminalbefehle, die sich in irgendeiner Weise auf Monitor, Display, Fonts, et al., beziehen; mir fallen ein:

Code: Alles auswählen

xrandr
xev
xdpyinfo
nvidia-settings
plasmashell -v
xmodmap
xfd -fa "DejaVu Sans Mono"
xlsfonts -fn '*-*-*-*-*-*-*-*-*-*-*-m*'
etc.
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
Damit gibst du das Display für das gesamte Netzwerk frei.
Ist das bei einem Heimnetzwerk so tragisch? Und was könnte hier gehackt werden?
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
DISPLAY ist in den diversen Terminalemulatoren (KTerm, xterm, Konsole...) sowieso gesetzt.
Offenbar nicht

Code: Alles auswählen

echo $DISPLAY
gibt eine leere Ausgabe
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
Was willst du denn überhaupt erreichen. "Beim Booten" ist mir zu vage.
Soweit ich mich erinnern kann, konnten vor Buster xrandr etc. problemlos ausgeführt werden. Möglicherweise habe ich die Gefahren einer Freigabe noch nicht begriffen. Mit "Booten" ist hier sehr inkonkret das Hochfahren bis inklusive Einloggen in die Plasmashell und XServer gemeint.
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
... so ist dafür der Autostart-Mechanismus zuständig ...
Auch eine Möglichkeit, ich hatte ursprünglich an .bashrc oder ähnliches gedacht.
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
Sowas für root einzurichten, reißt Sicherheitslücken auf. Grundsätzlich sollte man als root überhaupt keine graphischen Programme ausführen.
Ich arbeite üblicherweise auch mit CLI-Editoren, nano ist phantastisch, vim noch etwas gewöhnungbedürftig. Es geht -- wie oben gesagt -- eher um Infos von CLI-Anwendungen zu Bildschirm, Fontsdarstelllung, etc.

hikaru hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 09:26:14
... dann wäre eine sinnvolle Stelle um das zu setzen der userspezifische Autostart-Mechanismus der Desktop-Umgebung.
Okay
hikaru hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 09:26:14
Das ändert allerdings nichts an der Tatsache, dass es als eher unfein gilt, überhaupt GUI-Programme als root zu starten, ...
Wie gesagt, es handelt sich um CLI-Befehle und nicht das Starten von GUI-Programmen via CLI.
hikaru hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 09:26:14
Ich kann also ad hoc nicht nachvollziehen, wozu hier überhaupt Zugriff auf den X-Server gebraucht wird.

Code: Alles auswählen

# kcmshell5 --list
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted
Ausgabe als root, als user funktionier es; da ist auch $DISPLAY gesetzt. Somit schränkt sich meine Frage wohl darauf ein, weshalb ein Root-Freigabe des Displays so schlimm ist und wo man diese -- unter Berücksichtigung aller Bedenken -- am Besten bewerkstelligt.
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 10:27:55
Sehr viel sinnvoller als xhost ist die Nutzung des MIT-Magic-Cookies.
Wie konkret setzt man dieses?
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 10:27:55
Das gilt allerdings auch, wenn man .Xauthority nutzt statt xhost.
Bitte um nähere Erklärung!

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von MSfree » 28.07.2022 14:23:11

kalamazoo hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 13:50:14
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 08:10:02
DISPLAY ist in den diversen Terminalemulatoren (KTerm, xterm, Konsole...) sowieso gesetzt.
Offenbar nicht

Code: Alles auswählen

echo $DISPLAY
gibt eine leere Ausgabe
Bist du sicher, daß KDE überhaupt in einem Xserver läuft. Meines Wissens nach läuft KDE auch (wahlweise) in Wayland, was zumindest für Gnome Default ist. Möglicherweise wird DISPLAY nicht gesetzt, wenn deine Session in Wayland läuft.
Auch eine Möglichkeit, ich hatte ursprünglich an .bashrc oder ähnliches gedacht.
.bashrc wird bei jedem Login geladen, also auch bei einem Remote-Login via SSH. Bei solch reinen Textlogins will man eigentlich keine X-Programmaufrufe haben, die dann zwangsläufig mit der Fehlermeldungn, daß das DISPLAY nicht geöffnet werden kann, beendet werden.
Es geht -- wie oben gesagt -- eher um Infos von CLI-Anwendungen zu Bildschirm, Fontsdarstelllung, etc.
Und warum brauchst du dazu root-Rechte? Die meisten Befehle laufen auch ohne root-Rechte.

root-Rechte sollte man generell so sparsam wie nur irgend möglich eingesetzt werden, auch, wenn es sich um das vermeintlich sichere Heimnetz handelt. Vermeidung von root-Privilegien verhindert auch so manchen Unfall, z.B. versehntliches löschen von Systemdateien, was ohne root-Rechte nicht geht. Daher halte ich es auch nicht für sinnvoll, das Display mit xhost für jeden (inkl. root) freizugeben.

Benutzeravatar
Livingston
Beiträge: 1367
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von Livingston » 28.07.2022 14:38:34

Hier werden ja 1000 Fässer auf einmal aufgemacht. Ich gehe hier nur auf die ursprüngliche Frage ein.
Standardmäßig wird eine KDE-Session mit dem KDE-eigenen Displaymanager Debiansddm gestartet. Der sorgt normalerweise dafür, dass sämtliche wichtige Variablen exportiert werden. Oder benutzt Du einen anderen DM? Wenn Du Dir hier unsicher bist, schau einfach nach mit:

Code: Alles auswählen

$ cat /etc/X11/default-display-manager
Je nachdem, welcher DM im Einsatz ist, sollte man hierfür in dessen Konfiguration eine Stelle finden, wo zum Autostart Variablen definiert werden können.
Solltest Du ohne DM arbeiten und KDE per startx oder xinit starten, musst Du selbst für Startskripte sorgen. Den Fall könnten wir dann gesondert klären.

Kleine Anmerkung: Ich setze mich schon seit einiger Zeit selbst nicht mehr mit Displaymanagern auseinander. Hier sollte wer anderes aushelfen, wenn Du die Frage beantwortet hast.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams

kalamazoo
Beiträge: 286
Registriert: 28.08.2017 11:31:49

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von kalamazoo » 29.07.2022 00:11:48

MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 14:23:11
Bist du sicher, daß KDE überhaupt in einem Xserver läuft. Meines Wissens nach läuft KDE auch (wahlweise) in Wayland, was zumindest für Gnome Default ist. Möglicherweise wird DISPLAY nicht gesetzt, wenn deine Session in Wayland läuft.

Code: Alles auswählen

user$ loginctl show-session 1 -p Type
Type=x11
Wayland läuft bei mir nicht, da gibt es Probleme mit Nvidia.
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 14:23:11
Und warum brauchst du dazu root-Rechte? Die meisten Befehle laufen auch ohne root-Rechte.
Ja, mir ist mittlerweile bewusst, dass beim XServer ein Aufruf als root durchaus Nachteile gegenüber user hat. Ich habe es mit aber mittlerweile zur Gewohnheit gemacht, insbesondere Systemabfragen als root auszuführen, da ich irgendwann einmal feststellen musste, dass dem user manche Informationen vorenthalten werden, die root aber ohne weiteres bekommt. Und: sollte root nicht alles können? Was macht root beim XServer so gefährlich? Instabilität?
MSfree hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 14:23:11
root-Rechte sollte man generell so sparsam wie nur irgend möglich eingesetzt werden, ... Vermeidung von root-Privilegien verhindert auch so manchen Unfall
Völlig d’accord, ich erinnere mich nur mit Schaudern an die erste Zeit nach meinem Umstieg von Windows zu Linux, wo die einfachsten Dinge nicht funktionierten (e.g. Schreibzugriff auf einen eingehängten USB-Stick; Löschen irgendeiner Datei, die ich unter einem anderen Usernamen angelegt hatte; Suchen irgendwelcher Dateien oder Infos, etc. etc.), und ich verzweifelt nach Stunden daraufgekommen bin, dass mir schlicht die Rechte dazu fehlten. Somit habe ich jetzt in der Konsole immer zwei Tabs offen, einen als user und einen als root. Alles was Routine oder ungefährlich ist, mache ich als root, Löschen, Umbenennen, irgendwelche Experimente und Befehle, die ich nicht ganz beherrsche, als user
Livingston hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 14:38:34
Standardmäßig wird eine KDE-Session mit dem KDE-eigenen Displaymanager sddm gestartet ... Oder benutzt Du einen anderen DM?
Nein, es läuft sddm

Grund für meine etwas intensivere Beschäftigung mit dem Display ist, dass ich die Zeichenkodierung (Fonts, Codepoints, Glyphen und deren Darstellung) unter KDE oder Linux besser verstehen möchte, insbesondere auch wie das mit den Fallback Fonts funktioniert (siehe dazu meine einschlägige Frage im Forum: viewtopic.php?t=184157). Deshalb verwende ich derzeit eine Menge CLI-Befehle, die sich auf das GUI beziehen, und da bekomme ich halt immer wieder die im Titel genannte Fehlermeldung, die mich mitterweile schon ein wenig nervt.

tobo
Beiträge: 1964
Registriert: 10.12.2008 10:51:41

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von tobo » 29.07.2022 01:40:51

Livingston hat geschrieben: ↑ zum Beitrag ↑
28.07.2022 14:38:34
Oder benutzt Du einen anderen DM? Wenn Du Dir hier unsicher bist, schau einfach nach mit:

Code: Alles auswählen

$ cat /etc/X11/default-display-manager
Das ist nicht aussagekräftig (Edit: bei mir ohne Displaymanager):

Code: Alles auswählen

$ cat /etc/X11/default-display-manager
/usr/sbin/lightdm
$ aptitude search lightdm$
p   lightdm                                                                      - simple display manager
$

kalamazoo
Beiträge: 286
Registriert: 28.08.2017 11:31:49

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von kalamazoo » 29.07.2022 05:01:31

tobo hat geschrieben: ↑ zum Beitrag ↑
29.07.2022 01:40:51
$ cat /etc/X11/default-display-manager
Das ist nicht aussagekräftig
Habe ich auch nicht verwendet, sondern:

Code: Alles auswählen

root# ps -ely | egrep sddm
S     0    1147       1  0  80   0 16060 87206 -      ?        00:00:00 sddm
S     0    1989    1147  0  80   0 14800 67967 -      ?        00:00:00 sddm-helper
... der Gewohnheit halber als root

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Dauerhafte Lösung für "could not connect to display"?

Beitrag von MSfree » 29.07.2022 09:21:03

kalamazoo hat geschrieben: ↑ zum Beitrag ↑
29.07.2022 00:11:48
Was macht root beim XServer so gefährlich? Instabilität?
root ist grundsätzlich gefährlich, nicht nur im Zusammenhang mit einem Xserver. Jedes Programm, das du mit root-Rechten ausführst hat Zugriff auf wirklich alles im System. Und das Ausführen eines per Email zugesandten oder aus dem Internet runtergeladenen Shellskripts mit root-Rechten kann halt auch Malware mit root-Rechten nachladen, ausführen und im System verankern. Der Xserver ist halt eine zusätzliche Angriffsflächeh.
Somit habe ich jetzt in der Konsole immer zwei Tabs offen, einen als user und einen als root. Alles was Routine oder ungefährlich ist, mache ich als root,
Und genau da liegt dein Problem. Du solltest wirklich gar nichts mit root-Rechten machen, Routineaufgaben schon gar nicht, weil gerade Routine auch mal Flüchtigkeitsfehler einschleifen. Aber genau da liegt auch dein DISPLAY-Problem. DISPLAY ist, wie oben schon geschrieben, für deinen eingelogten Benutzer immer gesetzt, aber für den root-Nutzer, wenn man sich mit su - root-Rechte verschaft, ist diese Umgebungsvariable nicht gesetzt, aus gutem Grund.

Gewöhne dir lieber an, root überhaupt nicht zu nutzen. Das führt letztlich nur dazu, daß Dateien der falsche Besitzer zugeordnet wird, so daß man diese als "normaler" Benutzer nicht mehr manipulieren darf.

root sollte man nur für folgende Tätigkeiten verwenden:
  • (de)installieren und aktualisieren von Software (apt, apt-get, aptituge, dpkg)
  • einrichten von VPN-Zugängen (Zertifikate erstellen/löschen)
  • einrichten von diversene Serverprogrammen (MariaDB, Bind9, Squid, Apache, nginx, SSH...)
Und wenn man doch mal eine "verklemmte" Dateiberechtigung beheben muß, dann führt man

Code: Alles auswählen

su -
chown...
exit
aus, um genau diesen einen Befehl mit root-Rechten auszuführen. Ein zweiter Tab, mit der man dauerhaft als root arbeitet und Routineaufgaben erledigt, ist weder nötig noch sinnvoll.

@all: mit dem Loginmanager (aka Displaymanager) hat das ganze also überhaupt nichts zu tun.

Antworten