Hallo miteinander, ich hatte es schon gelegentlich, dass yast2 nicht starten wollte. Aber wenn ich es auf der Kommandozeile aufgerufen habe, hat es bisher immer eine Fehlermeldung gebracht. Nun habe ich einen neuen Zustand: yast2 lässt sich starten, wenn ich mich über die VMWare-Konsole an der VM anmelde, also quasi lokal. Es lässt sich aber nicht starten, wenn ich per ssh auf die Maschine gehe. OK, kann passieren - aber dann kommt meist eine Fehlermeldung wie "DISPLAY not set" oder ähnliches. Aber hier passiert gar nichts :( # yast2 & [1] 7606 # Tja, das wars. In der Prozessliste erscheinen "/bin/bash /sbin/yast2" und "/usr/lib/YaST2/bin/y2controlcenter", aber ein Fenster geht nicht auf. Ich kann mit "fg" den Prozess in den Vordergrund holen, aber nix zu sehen von einem YaST-Fenster. Gleiches kann ich mit "yast2 sw_single &" spielen, auch da tut sich nichts. Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht. Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen? Kann mir jemand sagen, wo ich suchen muss? Gruß Werner --
Werner Flamme [26.11.2014 12:56]:
Hallo miteinander,
ich hatte es schon gelegentlich, dass yast2 nicht starten wollte. Aber wenn ich es auf der Kommandozeile aufgerufen habe, hat es bisher immer eine Fehlermeldung gebracht.
Nachtrag: seit dem letzten yast-Patch lässt sich via ssh wenigstens wieder die Konsolenversion von YaST aufrufen. Die grafische Version verschwindet immer noch im Unsichtbaren. Eine Liste der aktuell installierten Module: # rpm -qa 'yast*' | sort yast2-3.1.110-1.1.i586 yast2-add-on-3.1.9-1.4.noarch yast2-apparmor-3.1.2-3.2.noarch yast2-bootloader-3.1.109-1.1.i586 yast2-branding-openSUSE-3.1.32-1.1.noarch yast2-control-center-3.1.5-1.1.i586 yast2-control-center-qt-3.1.5-1.1.i586 yast2-core-3.1.13-1.1.i586 yast2-country-3.1.13-1.2.i586 yast2-country-data-3.1.13-1.2.i586 yast2-firewall-3.1.2-1.1.noarch yast2-hardware-detection-3.1.3-4.1.i586 yast2-http-server-3.1.5-1.1.noarch yast2-inetd-3.1.9-1.1.noarch yast2-inetd-doc-3.1.9-1.1.noarch yast2-installation-3.1.121-1.1.noarch yast2-iscsi-client-3.1.19-1.1.noarch yast2-ldap-3.1.13-1.1.i586 yast2-mail-3.1.4-1.3.noarch yast2-metapackage-handler-3.1.4-1.1.noarch yast2-network-3.1.109-1.1.i586 yast2-nfs-client-3.1.11-1.1.noarch yast2-nfs-common-3.1.7-3.2.noarch yast2-nis-client-3.1.10-3.2.i586 yast2-ntp-client-3.1.12-1.3.noarch yast2-online-update-3.1.7-1.3.noarch yast2-online-update-frontend-3.1.7-1.3.noarch yast2-packager-3.1.54-1.1.i586 yast2-pam-3.1.1-3.2.noarch yast2-perl-bindings-3.1.2-3.2.i586 yast2-pkg-bindings-3.1.20-1.1.i586 yast2-printer-3.1.1-3.3.i586 yast2-proxy-3.1.2-1.1.noarch yast2-qt-branding-openSUSE-13.2-10.4.noarch yast2-ruby-bindings-3.1.25-2.1.i586 yast2-samba-client-3.1.14-1.1.noarch yast2-samba-server-3.1.11-1.1.noarch yast2-scanner-3.1.1-3.3.i586 yast2-security-3.1.5-1.1.noarch yast2-services-manager-3.1.36-1.1.noarch yast2-slp-3.1.7-1.3.i586 yast2-snapper-3.1.3-3.3.i586 yast2-sound-3.1.4-3.3.i586 yast2-storage-3.1.49-1.1.i586 yast2-sudo-3.1.1-3.2.noarch yast2-sysconfig-3.1.1-3.3.noarch yast2-trans-de-3.1.0-4.1.noarch yast2-transfer-3.1.1-3.2.i586 yast2-trans-stats-2.19.0-17.1.noarch yast2-tune-3.1.5-3.4.i586 yast2-update-3.1.24-1.1.i586 yast2-users-3.1.35-1.1.i586 yast2-vm-3.1.19-1.1.i586 yast2-x11-3.1.3-3.2.i586 yast2-xml-3.1.1-3.2.i586 yast2-ycp-ui-bindings-3.1.7-3.2.i586 Gruß Werner --
Hallo Werner Flamme, Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen?
Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su... -- Herzliche Grüße! Rolf Muth Meine Adressen dürfen nicht für Werbung verwendet werden! S/MIME Zertifikat 0x25F0E92D9AE21AE6
Hallo, On 12/04/2014 10:45 PM, Rolf Muth wrote:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen? Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
auf meiner Testinstallation von openSUSE 13.2 habe ich kein Problem remote per ssh das yast2 tool zu starten (yast2-3.1.109-4.2.x86_64). Im Gegensatz zum Start an der Konsole erscheint die Mitteilung libGL error: failed to load driver: swrast und das yast2 GUI oeffnet sich. Schon mal mit "strace yast2" oder "bash -x /usr/sbin/yast2" versucht ? Gruss, Kai -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Kai Grunau [05.12.2014 09:10]:
Hallo,
On 12/04/2014 10:45 PM, Rolf Muth wrote:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen? Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
auf meiner Testinstallation von openSUSE 13.2 habe ich kein Problem remote per ssh das yast2 tool zu starten (yast2-3.1.109-4.2.x86_64).
Im Gegensatz zum Start an der Konsole erscheint die Mitteilung
libGL error: failed to load driver: swrast
und das yast2 GUI oeffnet sich.
Schon mal mit "strace yast2" oder "bash -x /usr/sbin/yast2" versucht ?
strace ist der Standardratschlag, irgend jemand bringt ihn immer. Nur sagt kaum mal jemand dazu, wonach ich denn dann in dem Output suchen soll. Ich bin kein Linux-Programmierer, der sowas auswendig weiß, insofern ist der Output in weiten Strecken böhmisches Dorf für mich. Es ist ja auch nicht so, dass das Programm nicht startet - es kommt nur nicht in den Vordergrund. a) ich gehe per ssh auf den entfernten Rechner b) ich rufe "yast2 &" auf (bis openSUSE 13.1 kein Problem) c) "ps -aux | grep -i yast" bringt u. a. root 5606 0.0 0.1 4508 2556 pts/0 S 11:09 0:00 /bin/bash /sbin/yast2 root 5629 1.7 1.4 79220 29076 pts/0 Sl 11:09 0:00 /usr/lib/YaST2/bin/y2controlcenter also einwandfrei, das Programm läuft. Nur schade, dass es sich nicht zeigt. Auch nicht mit "fg". Dann kann ich es aber mit Strg-C abbrechen, was allerdings nicht der Sinn des Aufrufs war. Das ist mit einem remote System so (Tumbleweed) und mit meiner lokalen 13.2, wenn ich per "ssh root@localhost" draufgehe (spart den suoders-Eintrag ;)) # echo $DISPLAY localhost:10.0 ist passend zu ssh gesetzt... Werner --
Rolf Muth [04.12.2014 22:45]:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen?
Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
Hallo Rolf Muth, das Anlegen eines Extra-Users ist ein Sicherheitsfeature? Weil niemand weiß, wie er dann beim anschließenden su die .xauth* mitnehmen kann, und damit erst recht kein X-Programm aufgerufen wird? Verstehe ich jetzt nicht. Kopfkratzend, Werner --
Werner Flamme schrieb:
Rolf Muth [04.12.2014 22:45]:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen?
Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
Hallo Rolf Muth,
das Anlegen eines Extra-Users ist ein Sicherheitsfeature? Weil niemand weiß, wie er dann beim anschließenden su die .xauth* mitnehmen kann, und damit erst recht kein X-Programm aufgerufen wird?
Verstehe ich jetzt nicht.
Kopfkratzend, Werner
oben ist gesagt:
Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Wenn ich es richtig verstehe, kann sich root nicht als user anmelden, auch wenn root vorzeigt. root kann nicht user sein, es sei denn, das wurde vorher für alles so geregelt. Das bedeutet wieder entweder root oder user. Frank -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Frank [10.12.2014 12:48]:
Werner Flamme schrieb:
Rolf Muth [04.12.2014 22:45]:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen?
Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
Hallo Rolf Muth,
das Anlegen eines Extra-Users ist ein Sicherheitsfeature? Weil niemand weiß, wie er dann beim anschließenden su die .xauth* mitnehmen kann, und damit erst recht kein X-Programm aufgerufen wird?
Verstehe ich jetzt nicht.
Kopfkratzend, Werner
oben ist gesagt:
Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Wenn ich es richtig verstehe, kann sich root nicht als user anmelden, auch wenn root vorzeigt. root kann nicht user sein, es sei denn, das wurde vorher für alles so geregelt. Das bedeutet wieder entweder root oder user.
Den Absatz verstehe ich nicht. Ich bin als User wflamme lokal auf der Maschine, kann YaST2 wegen fehlender Berechtigungen nicht direkt (auf der Befehlszeile) aufrufen. Es geht über das Menü, aber davon spreche ich nicht. Also mache ich ein "ssh root@localhost" in einem Befehlsfenster innerhalb KDE, also konsole, und bin danach in diesem Fenster root (auf meinem Rechner). Dort habe ich - durch die Anmeldung via ssh - die Variable DISPLAY auf dem Wert localhost:10.0 stehen, wie das bei ssh-Anmeldungen gemeinhin der Fall ist, solange man in /etc/ssh/sshd_config nicht den Parameter X11DisplayOffset explizit anders setzt. Öffne ich stattdessen ein weiteres Root-Fenster/Unterfenster direkt in Konsole, kann ich YaST2 problemlos aufrufen. Das Problem liegt also beim Zugang über ssh. Aber ssh allein ist es auch nicht, ich kann "xeyes" problemlos laufen lassen. Warum per ssh auf den lokalen Rechner? Weil ich da einen Key benutzen kann, bei einem Extra-Fenster muss ich jedes Mal das Passwort eintippen :) Genau, kein Einzelbüro. Soweit zum lokalen Rechner. Bei der VM auf dem ESX-Cluster ist das mit dem weiteren Fenster so eine Sache - ich kontaktiere den Host eigentlich nur über ssh, und bis zur Tumbleweed-Umstellung 13.1 -> 13.2 hatte ich auch nie irgendwelche Probleme, via ssh auf den Host zu gehen und die Systemverwaltung via "yast2 &" zu starten, oder auch mal ein Untermodul direkt aufzurufen, z. B. "yast2 sw_single &". Das YaST2-Fenster wurde mir direkt auf dem Arbeitsplatz angezeigt und ließ sich wie der lokale YaST2 bedienen. Immerhin erscheint beim Aufruf von "yast" inzwischen die Konsolenversion, das ging am Anfang auch nicht. Xeyes läuft auch hier, brav im Vordergrund :) ssh transportiert also, aber YaST2 will sich nicht darstellen lassen. Ich versuche zu erraten, woran sowas liegen kann... Gruß Werner --
Hallo Werner Flamme, Am Mittwoch, 10. Dezember 2014 11:13 schrieb Werner Flamme:
Rolf Muth [04.12.2014 22:45]:
Hallo Werner Flamme,
Am Mittwoch, 26. November 2014 12:56 schrieb Werner Flamme:
... Wie gesagt, bei Anmeldung via (Grafik-)Konsole geht es... Und wenn ich mich per ssh als root@localhost (bei meinem Arbeitsplatz-PC) anmelde, geht es auch nicht.
Ist das ein Sicherheitsfeature, mit dem man Admins davon abhalten will, interaktive Fernwartung zu machen?
Könnte sein, aber dann geht vielleicht Anmeldung als anderer Benutzer und hinterher su...
Ich dachte da eher an eine Möglichkeit, die auch noch geht, wenn man sich nicht als root anmelden kann. Hatte mal einen Server so konfiguriert. Es war lustig zu beobachten, mit welchen root-PW'n sich die Einbrecher anmelden wollten, da auch das richtige nicht funktioniert hätte.
das Anlegen eines Extra-Users ist ein Sicherheitsfeature? Weil niemand weiß, wie er dann beim anschließenden su die .xauth* mitnehmen kann, und damit erst recht kein X-Programm aufgerufen wird? Nö, weil niemand weiß, wie der user heißt und sein PW und das root PW nicht kennt, also drei Unbekannte statt einer.
Aber Du hast recht, X habe ich da nie aufgerufen, auf dem Server nur per Konsole gearbeitet und nur über 'nen Tunnel zu Windowsrechern rdesktop benutzt. -- Herzliche Grüße! Rolf Muth Meine Adressen dürfen nicht für Werbung verwendet werden! S/MIME Zertifikat 0x25F0E92D9AE21AE6
participants (4)
-
Frank -
Kai Grunau -
Rolf Muth -
Werner Flamme