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

[kalamazoo]

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.

[MSfree]

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.

[hikaru]

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.

[MSfree]

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]

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.

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?

DISPLAY ist in den diversen Terminalemulatoren (KTerm, xterm, Konsole...) sowieso gesetzt.

Offenbar nicht

Code: Alles auswählen

echo $DISPLAY

gibt eine leere Ausgabe

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.

... so ist dafür der Autostart-Mechanismus zuständig ...

Auch eine Möglichkeit, ich hatte ursprünglich an .bashrc oder ähnliches gedacht.

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.

... dann wäre eine sinnvolle Stelle um das zu setzen der userspezifische Autostart-Mechanismus der Desktop-Umgebung.

Okay

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.

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.

Sehr viel sinnvoller als xhost ist die Nutzung des MIT-Magic-Cookies.

Wie konkret setzt man dieses?

Das gilt allerdings auch, wenn man .Xauthority nutzt statt xhost.

Bitte um nähere Erklärung!

[MSfree]

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.

[Livingston]

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

[kalamazoo]

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.

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?

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

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]

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]

$ 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

[MSfree]

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.