Zu kleine Fonts von YaST, systemsettings5 , dolphin etc., wenn von Root aus Terminal gestartet

Deutsch (German) KDE
1

Habe vor kurzem Leap42.1 installiert und alle wesentlichen Packete upgedated. Das meiste funktioniert inzwischen (fast) so, wie ich das haben will.
Nun schlage ich mich mit folgendem KDE-(Qt)-Problem rum:

Ich arbeite als normaler unpriviligierter User auf dem Plasma 5 Desktop. Wenn ich mich als Root (!) in einem Terminalfenster (konsole5) einlogge und dann z.B. die Anwendungen “yast2” oder “systemsettings5” starte, so erhalte ich viel zu kleine und ungeglättete Fonts (ca. 10px - leider auf einem 4K-Schirm). Starte ich YaST dagegen als unpriviliguerter User über das Startmenü und authentifiziere mich als Root, oder starte ich YaST direkt über “/usr/bin/xdg-su -c /sbin/yast2”, so sieht alles normal aus.

Das Problem entsteht nur, wenn ich als Root an einem Terminalfenster angemeldet bin. Obwohl ich die “systemsettings5”-Einstellungen des Users Root bereits hinlänglich modifiziert habe - sowohl für Qt- als auch GTK-Anwendungen. Unter früheren Opensuse-Versionen und KDE 4 wurden diese root-spezifischen Einstellungen brav beachtet, wenn man als Root Anwendungen aus einem Terminalfenster (unter der KDE-Oberfläche eines unpriviligierten Users) heraus startete.

Starte ich dann mal testweise KDE 5/Plasma 5 als Root, und teste die Applikationen direkt in der rootpezifischen KDE5-Umgebung, so zeigen sie die richtigen Font-Größen, wenn die Anwendungen über das Startmenü oder aber über ein gewöhnliches “xterm” gestartet werden. Nicht jedoch aus dem “konsole5”-Terminalfenster.

“env” für Root zeigt interessanterweise auch einige gravierende Unterschiede zu den Environment-Setzungen normaler User (so fehlen u.a die Variablen GTK2_RC_FILES, GTK_RC_FILES).

Auch bestimmte andere Anwendungen wie etwa das VMware-User-Interface reagieren nicht auf die Font-Vorgaben für Root. Libreoffice sieht dagegen normal aus, Firefox auch. Dolphin, kate, kwrite, kcalc reagieren dagegen nicht und zeigen zu kleine Fonts. Es sind wohl nur bestimmte Qt-Anwendungen, die streiken.

Ergänzung: Möglicherweise sind es gerade native Qt5-Anwendungen.

Ist das normal? Ich sehe das hier bereits auf 2 völlig unabhängigen Leap-Installationen, bei denen die Pakete über die Standard-Repositiories upgedated wurden.
Was kann ich ggf. tun, um größere Fonts zu bekommen, wenn ich Anwendungen wie “yast2” als Root aus einem konsole-Terminalfenster starten will?

2

Und wie genau loggst du dich als root in Konsole ein?
Probier mal “su -” statt “su” oder umgekehrt.
Der Unterschied zwischen beiden ist eben welche Umgebungsvariablen vom normalen Benutzer übernommen werden, und welche von root.

Wie schaut’s mit dem “Root Shell” Profil in Konsole aus? (“Terminal - Super User Modus”) im Anwendungsmenü)

3

Ich logge mich (normalerweise) mit “su -” ein - hätte ich natürlich bereits im ersten Post erwähnen sollen. Das Problem hängt ja gerade am entsprechenden root-Environment. Selbiges wird auch beim “Terminal - Super User Modus”) gezogen. Ich frage mich halt, warum bei diesem speziellen Environment Qt5-Anwendungen verstümmelt werden.

Mit “su” kommt yast2 (erwartungsgemäß ;)) so, wie es aussehen soll. Nach “export $(dbus-launch)” auch dolphin, systemsettings5, etc. .

4

Tja, bei “su -” laufen die Anwendungen komplett in root’s Environment, bei “su” werden gewisse Sachen vom Benutzer übernommen.

Hilft es nicht wenn du die Schriftarteneinstellungen von root änderst, speziell die DPI (Option "DPI für Schriften erzwingen)? Also systemsettings5 nach “su -” aufrufen.

Ansonsten probier auch mal die Systemeinstellungen in YAST->Fonts zu ändern, und/oder root’s Einstellungen zu löschen (/root/.config/fontconfig/)

Oder auch die Qt-Einstellungen, /root/.config/QtProject.conf.

5

Zum ersten Punkt: Es sollte halt meiner bescheidenen Meinung nach nicht so sein, dass die nativen Qt5-Anwendungen des Plasma 5 Desktops unter den Voraussetzungen eines (ggf. suse-spezifischen) “root”-Environments die Schriftarteneinstellungen nicht beachten. Vielleicht ist das auch nur bei mir so … Wäre hilfreich zu wissen, ob auch andere diesen Effekt sehen.

Die Schriftarteneinstellungen habe ich bereits mehrfach geändert. Über ein Terminal mit anschließendem Aufruf von systemsettings5 - das dann ziemlich kaputt aussieht (kleine Fonts, keine Icons). Aber auch direkt unter einem für Root gestarteten KDE5-Desktop und Aufruf der “systemsettings5” über das dortige Startmenu. Hilft im gestarteten Desktop des Users Root schon was - nicht aber für den Start von Applikationen in einem root-Terminal im Desktop eines nicht priviligierten Nutzers. Leider! Es ist fast so, als ob des Root-Terminal-Fenster andere Umgebungsvariablen sieht/exportiert als das konsole5-Terminal-Fenster im Root-Modus.

Habe auch bereits (nach einer Sicherung) mal testweise das gesamte “/root/.config”-Verzeichnis gelöscht und wieder aufbauen lassen. Das half leider nichts. Auch eine Änderung der Einstellungen von YaST->Fonts nicht.

6

Wie du selber schreibst, funktionierts ja mit kdesu z.B.

Wenn aber Anwendungen komplett als root laufen, nehmen sie natürlich root’s Einstellungen, nicht die des Benutzers.
Du würdest ja auch nicht erwarten dass ein anderer Benutzer die selben Einstellungen wie du bekommst, oder?
Würde ja ein Mehrbenutzersystem komplett untergraben.

Die Schriftarteneinstellungen habe ich bereits mehrfach geändert. Über ein Terminal mit anschließendem Aufruf von systemsettings5 - das dann ziemlich kaputt aussieht (kleine Fonts, keine Icons).

Ok, hört sich mehr danach an dass Qt5 nicht merkt dass es unter KDE läuft, und deshalb auch nicht die KDE Einstellungen (Fonts, Icon theme, usw.) verwendet.
Probier mal vorher das auszuführen (in der root-Konsole), bevor du eine Anwendung startest:

export XDG_CURRENT_DESKTOP=KDE

Ists dann besser?

7

Habe gerade noch etwas für mich im Moment Unverständliches gesehen.

Wenn ich mich über den Breeze SDDM-Anmeldebildschirm als Root (!) anmelde und dann im gestarteten KDE 5 über "Startmenü -> System -> XTerm " ein XTerm starte und dort “env” abfrage, erhalte ich ein anderes Setting von Umgebungs-Variablen als nach einem “su -” im gleichen Terminal !

Wie kann denn das sein???
Letztlich ist es doch Root, unter dem alle Prozesse ab Login laufen sollten. Wann und durch welchen Prozess werden da die Umgebungsvariablen beeinflusst?

Ein aus einem XTerm heraus (ohne “su -”) gestartetes YaST sieht dann wie gewünscht aus - ebenso beim direkten Start aus dem Startmenü der für Root hochgefahrenen KDE 5 - Desktop-Umgebung. Offenbar legt der KDE-Desktop für seine Subprozesse andere Umgebungsvariablen fest als für eine mit “su -” gestartete Shell ! Obwohl der Desktop in diesem Fall durch einen SDDM-Root-Login gestartet wurde.

Nach einem “su -” im gleichen XTerm und nachfolgendem Start von YaST => zu kleine Fonts.

8

Wie gesagt, “su -” erzeugt eine komplett neue, unabhängige Umgebung, ähnlich zu einem Textmodus-Login.
Environmentvariablen die vom Plasma5 Startprozess oder dem Displaymanager gesetzt werden, sind dort eben auch nicht vorhanden oder haben einen anderen Wert.

Letztlich ist es doch Root, unter dem alle Prozesse ab Login laufen sollten. Wann und durch welchen Prozess werden da die Umgebungsvariablen beeinflusst?

Jede Anwendung kann Umgebungsvariablen setzen, alle Kinderprozesse “erben” diese. “su -” legt aber eine völlig neue Sitzung an.

Offenbar legt der KDE-Desktop für seine Subprozesse andere Umgebungsvariablen fest als für eine mit “su -” gestartete Shell ! Obwohl der Desktop in diesem Fall durch einen SDDM-Root-Login gestartet wurde.

Ja, aber es ist eben “su -” das die (Benutzer-)Umgebung “löscht”. (auch root ist in dieser Hinsicht ein Benutzer wie jeder andere)

Nach einem “su -” im gleichen XTerm und nachfolgendem Start von YaST => zu kleine Fonts.

Sh, mein vorheriger Post.

9

wolfi323: Erstmal vielen Dank für deine Geduld, deine Kommentare und deine Unterstützung !

Natürlich erwarte ich das nicht. Da hast du mich aber, glaube ich, mißverstanden. Mein Punkt war/ist gerade der, dass die Font- und andere Einstellungen für den User ROOT (!!) bei einem “su -” und einem nachfolgenden Start einer Qt5-Applikation NICHT beachtet werden. Zumindest nicht für Qt5-Anwendungen. Die Einstellungen für GTK- und Qt4-Anwendungen, die ich für den User Root getroffen habe, werden übrigens ganz korrekt umgesetzt. Auch nach einem “su -”. Nur die Vorgaben für Qt5-basierte Anwendungen nicht.

Bislang war es unter KDE 4.14 aber so, dass die von “su -” erzeugte Umgebung unter Opensuse offenbar dafür hinreichend war, um zumindest die Font-Einstellungen, die für Root getroffen wurden, auch unter einem anderen Desktop umzusetzen.

Environmentvariablen die vom Plasma5 Startprozess oder dem Displaymanager gesetzt werden, sind dort eben auch nicht vorhanden oder haben einen anderen Wert.

Ok, akzeptiert. Ist mir verständlich. Ich erzeuge über Scripts ja laufend selber solche modifizierten Prozess-Umgebungen … Der Plasma-Startprozess (muss mal nachsehen unter welcher UID der läuft) baut auch für einen vom User Root (z.B. per startx) gestarteten Desktop eine Umgebung mit anderen oder zusätzlichen Umgebungsvariablen auf, als denjenigen, die für eine interaktive root-Shell gelten. Kann ich verstehen, über Sicherheitsimplikationen mag ich im Moment nicht nachdenken. Man soll ja als root eh’ nicht unter einer X-Window arbeiten …

export XDG_CURRENT_DESKTOP=KDE

Ok, das brachte eine Veränderung in die richtige Richtung! Super ! Danke!

Bleibt die Frage offen, wie unter Opensuse 13.x mit KDE4 / Qt4 eine mit “su -” gestartete Shell das von Haus aus und ohne User-Eingriffe richtig gemacht hat …
Ist das deiner Meinung nach ein Bug unter Leap ?

10

GTK und Qt4-Anwendungen verwenden eben einfach die GTK oder Qt4/KDE4-Einstellungen.
Qt5 versucht sich aber dem Desktop (bzw. sogar dem Betriebssystem) anzupassen, unter LXQT verwendet es dann z.B. eben die LXQT-Einstellungen.

Ok, Qt4 besitzt auch schon gewisse “Anpassungsfähigkeiten”, bin mir jetzt aber nicht sicher wie das dort genau gemacht wurde. $XDG_CURRENT_DESKTOP gabs jedenfalls zu Qt4 Zeiten noch nicht, das ist eine relativ neue “Erfindung”.

Bleibt die Frage offen, wie unter Opensuse 13.x mit KDE4 / Qt4 eine mit “su -” gestartete Shell das von Haus aus und ohne User-Eingriffe richtig gemacht hat …
Ist das deiner Meinung nach ein Bug unter Leap ?

Nicht wirklich.
Es ist mehr eine Änderung in Qt5’s Desktopunterstützung.

Qt5 versucht rauszufinden in welchem Desktop es läuft, und lädt dann ein bestimmtes Plugin (“Platform Plugin”) das sich um die Einstellungen kümmert.
Dafür wird unter Linux eben $XDG_CURRENT_DESKTOP verwendet. Wenn es den Desktop nicht erkennen kann (weil $XDG_CURRENT_DESKTOP z.B. eben nicht gesetzt ist) oder kein Plugin dafür findet, nimmt es ein generisches Plugin. Leider gibts dafür kein Einstellungsprogramm mehr wie früher qtconfig.

Es gibt da libqt5-qtct das diese generischen Einstellungen “überschreibt”, das würde ich aber nicht wirklich empfehlen, da es meines Wissens nach sogar die KDE-Einstellungen “überschreibt”, d.h. dann verschwinden evtl. sogar die Icons in KDE. Dafür gibts einen Bug-Report.

Zu deinem Problem jetzt: ein Workaround wäre vielleicht, das “export XDG_CURRENT_DESKTOP=KDE” z.B. in /root/.profile oder /root/.bashrc zu schreiben. Hätte halt den Nachteil, dass immer die KDE-Einstellungen verwendet werden, selbst wenn du eine Qt5 Anwendung als root in GNOME z.B. startest. (und kann auch negative Effekte haben wenn du wirklich mal als root in einen grafischen Desktop einloggst, außer KDE eben)

Man könnte jetzt argumentieren, dass “su -” zumindest $XDG_CURRENT_DESKTOP von der Benutzerumgebung übernommen werden sollte, $DISPLAY z.B. wird ja auch “weitergeleitet” (sonst könntest du gar keine grafischen Anwendungen starten).
Ich glaube aber nicht, dass man das konfigurieren kann, da müsste wohl su selbst “angepasst” werden. Bei sudo würds per Config-File gehen (in /etc/sudoers).

Keine Ahnung ob das wünschenswert/akzeptabel wäre, aber wenn du das als Fehler siehst hilft aber wohl nur ein Bug Report…

Der Vollständigkeit halber, das steht in der Man-Page von su:

       -, -l, --login
              Starts the shell as a login shell with an environment similar to
              a real login:

                 o      clears all the environment variables except TERM

                 o      initializes  the  environment  variables  HOME, SHELL,
                        USER, LOGNAME, and PATH

                 o      changes to the target user's home directory

                 o      sets argv[0] of the shell to '-' in order to make  the
                        shell a login shell

$DISPLAY ist da nicht erwähnt, das wird aber offensichtlich auch nicht gelöscht. Könnte aber auch ein openSUSE spezifischer Patch sein.

Und wie gesagt, für Konsole kannst du in den Profileinstellungen festlegen, was für ein Kommando genau gestartet wird. Du könntest also z.B. das “Root Shell” Profil dahingehend ändern dass nur “su” aufgerufen wird, oder ein neues Profil anlegen wenn du willst.

11

PS, als Warnung: “su” zu benutzen ist aber vielleicht auch nicht ideal, da das z.B. dazu führen könnte dass die root-Anwendungen Dateien in deinem Benutzer-Home verändern und die Rechte ändern.

12

Hmm… In meinen eigenen Worten: Eine (root) Login-Shell sollte am besten irgendwie erkennen, ob sie unter einer KDE-Desktop-Umgebung gestartet wurde und XDG_CURRENT_DESKTOP=KDE setzen, damit Qt5 -Anwendungen korrekt behandelt werden können.

Ist eigentlich ein interessantes Problem(chen). Mir gefällt ein explizites, generelles Setzen der Umgebungsvariable über /root/.profile oder /root/.bashrc ohne Validierung nicht, da ich manchmal tatsächlich auch andere Desktop-Umgebungen verwende und Nebeneffekte vermeiden möchte. “su” alleine ist ggf. für manche Arbeiten unzureichend, da ich selbst eigene Umgebungsvariable für bestimmte Scripts benötige, die beim Login über /root/.profile gesetzt werden. Hinzu kommt dein letzter Kommentar.

ich tendiere mehr dazu, dass im Rahmen der /root/.profile eine Auswertung der Kette von Parentprozessen der gestarteten Shell - also genauer der PPIDs - sowie zugehöriger UIDs vorgenommen wird. Dabei stößt man zwangsläufig auf eine UID > 1000, wenn “su -” in einer unpriviligierten Desktop-Umgebung aufgerufen wurde. Habe das gerade mal für den Start der “konsole5” geprüft. Für diese UID kann man wiederum prüfen, ob “kdeinit5” oder “klauncher” gestartet wurde. Evtl. noch besser: “konsole5” weist einen direkten SESS-Bezug zum vom gleichen User gestarteten “kdeinit5” auf. Muss ich mir aber noch genauer ansehen. Damit hat man wohl genügend Entscheidungskriterien an der Hand, um dann XDG_CURRENT_DESKTOP=KDE mit Fug und recht zu setzen.

Was hältst du von diesem Ansatz?

13

Naja, die Shell kann das nicht wirklich erkennen. XDG_CURRENT_DESKTOP zu setzen ist nicht die Aufgabe der Shell.

Was hältst du von diesem Ansatz?

Wäre wohl möglich, denke ich.

Noch besser wäre es meiner Meinung nach allerdings, wenn “su -” eben XDG_CURRENT_DESKTOP von der Benutzerumgebung übernehmen und nicht zurücksetzen würde. Aber wie gesagt, ich kenne keine Möglichkeit das zu konfigurieren, man müsste vermutlich su patchen.
Ein Bugreport wäre evtl. sinnvoll um herauszufinden was die Maintainer davon halten.
Vielleicht schreib ich ja selber einen, wenn ich die Zeit dazu finde. Würde Sinn machen, denke ich, und mir fällt jetzt auch kein Nachteil oder evtentuelles Problem ein das dadurch verursacht werden könnte…