OpenSUSE 13.1 und Remote Administration (VNC)

Einen guten Tag…

…und ein herzliches “Hallo” von einem Neumitglied. Ich wende mich ans Forum, weil ich trotz mehrwöchiger, sporadischer Suche für folgendes Problem keine Lösung gefunden habe:

  • Microserver mit OpenSUSE 13.1 aufgesetzt, alle Updates gezogen
  • Samba-Server im Heimnetzwerk, funktionierend
  • Remote Administration (VNC): Service erlaubt, und auch Port der Firewall freigegeben

von anderen Rechnern kein Aufbau eines Fernzugriffs möglich:

  • unter Windows 7 Pro 64 Bit mit Tight VNC 2.7.10 für 64 Bit → Hintergrund des Login-Screens noch sichtbar, bricht mit Fehlermeldung “Connection has been gracefully closed” ab

  • unter Ubuntu 14.04 mit Remmina bzw. SSVNC Viewer gleiches Ergebnis, Hintergrundbild wird kurz angezeigt, dann sofortiger Abbruch ohne Hinweis auf Ursachen

  • Firewall scheint es nicht zu sein, denn wenn ich den Port nicht freigebe, kommt es wie zu erwarten von Vornherein zu einer Ablehnung der Verbindung, mit freigegebenm Port sehe ich wenigstens kurz das übertragene Hintergrundbild

Auszug aus Message Log des Rechners, der dem Fernzugriff unterliegen soll:


2014-06-30T14:41:02.449973+02:00 linux-h5vd xinetd[2350]: START: vnc1 from=192.168.2.111
2014-06-30T14:41:02.527846+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [General] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:02.528116+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [Xdmcp] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:02.528249+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [X--Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:02.528366+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [X-
-Greeter] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:02.528482+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [X-:*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:02.528573+02:00 linux-h5vd kdm_config[4539]: Multiple occurrences of section [X-:0-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
2014-06-30T14:41:03.274093+02:00 linux-h5vd kdm_greet[4546]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Datei oder Verzeichnis nicht gefunden
2014-06-30T14:41:03.298186+02:00 linux-h5vd kdm: localhost:1[4545]: Abnormal termination of greeter for display localhost:1, code 1, signal 0
2014-06-30T14:41:03.301805+02:00 linux-h5vd xinetd[2350]: EXIT: vnc1 status=0 duration=1(sec)

Hmm, und hier ist bei mir dann Schluss mit dem Halbwissen, aber vielleicht kann mir hier jemand weiterhelfen.

Mit bestem Dank im Voraus…

Micha

Tja, gerade heute hab ich mich etwas damit herumgespielt…

Also: es liegt an kdm, mit dem funktioniert das überhaupt nicht (mehr). Der stürzt sofort ab wegen Rechte-Problemen. Ich hab ihn zwar zum Laufen bekommen, Einloggen funktioniert dann aber trotzdem nicht…

Benutze einen anderen Displaymanager, dann sollte es gehen.
Das kannst du in /etc/sysconfig/displaymanager machen, xdm sollte standardmäßig installiert sein, evtl. wird dir aber gdm oder lightdm besser gefallen, die musst du aber erst installieren.
(bei gdm bekam ich aber eine Root-Passwort-Abfrage wegen ungenügender Rechte für das Farbmanagement, die mein Root-Passwort nicht akzeptieren wollte, “Abbrechen” hat aber geholfen…:sarcastic:)

Mit KDE4 bzw. KDE4-/Qt4-Programmen wirst du aber evtl. trotzdem noch Probleme haben. Da hilft dann ein Hinzufügen von “QT_X11_NO_MITSHM=1” in /etc/environment, bzw. das Setzen dieser Umgebungsvariable auf einen anderen Weg (QT_GRAPHICSSYSTEM=“native” sollte auch gehen).

Hm, ich habs jetzt nochmal probiert, und diesmal hab ich das Problem nicht…
Und auch KDE4 funktioniert jetzt ohne dass ich die obengenannten Umgebungsvariablen setze.

Scheinbar ist da bei meinem ersten Versuch was anderes schiefgelaufen.

Also, das Setzen dieser Variablen muss nicht unbedingt nötig sein, kann aber helfen falls es Probleme gibt… :wink:

Hi,

Du bist nicht zufällig noch lokal an der openSUSE (grafisch) angemeldet?
Das geht nicht gleichzeitig mit dem Fernzugriff; außer mit Hilfsprogrammen, wie x11vnc, die Dich auf die existierende Session verbinden.

mfg
Hendrik

Doch, das geht schon (standardmäßig, mit Xvnc also YaST->Remote Adminstration (VNC)), so hab ichs ja hier getestet. Ich hab mich via VNC auf localhost verbunden…
Der Xvnc läuft auf Display :1, die lokale X-Session ist auf :0.

Hi allerseits !

@Wolfi323: danke erstmal für die Bestätigung des Verdachts, das es mit KDM nicht mehr geht (ist da etwas in Arbeit oder zerfasert die openSUSE immer mehr ?). Mit XDM komme ich zumindest bis zur Anmeldung, danach nur noch Absturzfenster.

Mit gdm funktioniert es besser, allerdings lässt sich die Maschine nicht mehr herunterfahren - aber das ist sicher eine andere Baustelle (in der /etc/sysconfig/displaymanager ist DISPLAYMANAGER_SHUTDOWN=“all” gesetzt (war auf “auto”, aber nach Beschreibung bei DISPLAYMANAGER_ROOT_LOGIN_REMOTE kann sich dann unter Umständen Root nicht anmelden).

Aber auf jeden Fall besser als vorher.

@hendwolt: ich brauche keinen Zugriff auf eine bestehende Session, die Eröffnung einer neuen Session ist völlig ausreichend. Und das war bisher zumindest (OpenSUSE 11x 12x) nie ein Problem. Normalerweise wird am Server nie jemand in einer Session angemeldet sein, das Teil soll im stillen Kämmerlein werkeln und nur über Remote bei Bedarf besucht werden. Allerdings nicht im Dauerbetrieb (Wecken bei Bedarf über WOL, nach erfolgter Nutzung als Backupserver etc. dann über Remote runterfahren).

VG Micha

Nein, aber KDM.
Der ist schon seit Jahren praktisch tot und unmaintained.

Und in Hinblick auf “KDE 5” wurde sogar schon vor einigen Monaten der KDM Source Code komplett rausgeschmissen…

Da wird dann auf SDDM gewechselt.
Den gibts zwar auch schon irgendwo am OBS, den hab ich mir aber noch nicht angeschaut.

XDM hat aber bei mir auch funktioniert…

Mit gdm funktioniert es besser, allerdings lässt sich die Maschine nicht mehr herunterfahren - aber das ist sicher eine andere Baustelle (in der /etc/sysconfig/displaymanager ist DISPLAYMANAGER_SHUTDOWN=“all” gesetzt (war auf “auto”, aber nach Beschreibung bei DISPLAYMANAGER_ROOT_LOGIN_REMOTE kann sich dann unter Umständen Root nicht anmelden).

Bzgl. Herunterfahren kann ich jetzt leider nichts sagen.
Dass sich root nicht anmelden kann bei DISPLAYMANAGER_SHUTDOWN=“auto”, gilt aber scheinbar nur wenn die Security Einstellungen auf “paranoid” sind (lt. Kommentar zu DISPLAYMANAGER_ROOT_LOGIN_REMOTE). Bei “auto” hängt aber die tatsächliche Erlaubnis wer runterfahren darf ebenfalls von /etc/sysconfig/security ab.

Für deine Zwecke könnte aber XDMCP (sh. DISPLAYMANAGER_REMOTE_ACCESS) besser geeignet sein (hab ich früher gern benutzt), das funktioniert aber mit KDM auch nicht mehr (zumindest als Client in dem Fall nicht, k.A. wies beim Server ausschaut). Anmelden kannst du dich dann indem du am Client Login Screen “Auf Fremdrechner anmelden” auswählst oder so. Weiß nicht wie das genau bei GDM heißt, und bei KDM geht das wie gesagt ja auch schon seit einer Weile nicht mehr. Wenn dus probierst, kannst du dich nicht mal mehr lokal anmelden, weil er keine Tastatureingaben mehr akzeptiert…:sarcastic:

Mit GDM sollte XDMCP aber noch funktionieren soweit ich weiß.

Oder du loggst dich einfach über SSH ein (mit X Forwarding), das funktionert eigtl. am besten. Du hast dann zwar keinen Desktop vom Remote-Rechner, kannst aber natürlich schon beliebige GUI-Applikationen starten (das Fenster wird dann natürlich lokal angezeigt, also am Client).

Guten Morgen,

der Tip mit lightdm war gut (gdm bringt ebenfalls die root-Abfrage zum farbverwalteten Gerät, deren Beantwortung wiederum egal ist und trotzdem immer wieder kommt), der funktioniert ohne Probleme.
SSH mit X-forwarding muss ich mich mal “aufschlauen”, noch nie probiert.

Besten Dank, ich betrachte dieses Problem des Remote Access als gelöst !

VG Micha

Freut mich! :slight_smile:

Das Problem mit dem farbverwalteten Gerät ließe sich sicher mit einer Polkit-Regel umgehen.
Manche Sachen sind halt standardmäßig nur für lokal angemeldete Benutzer erlaubt, obwohl ich in dem Fall finde dass die Default-Regel geändert werden sollte… :wink:

Ähnliches kann natürlich auch fürs Herunterfahren gelten, evtl. kann das für den Remote-User via Polkit verboten sein, da müsste man eben die Regelungen entsprechend in /etc/polkit-default-privs.local setzen.

Aber nach meinen Tests gestern würde ich gdm eigtl. eh nicht unbedingt empfehlen. Der benutzt ja zum Beispiel auch ohne Kompromisse OpenGL (so wie das ganze GNOME) was gerade über VNC recht langsam sein kann (sogar auf localhost)…

Evtl. wäre auch noch der alte KDM3 eine Alternative, auf den hab ich komplett vergessen gestern. Vielleicht funktioniert der diesbezüglich noch besser.
Aber lightdm ist wahrscheinlich auch eine gute Wahl.

SSH mit X-forwarding muss ich mich mal “aufschlauen”, noch nie probiert.

Kannst du natürlich auch einfach zusätzlich benutzen.
Manchmal gehts halt einfacher, schnell mal eine SSH-Verbindung zu machen, als einen VNC-Client zu starten und dort graphisch anzumelden.
Außerdem kann man so natürlich auch im Textmodus remote arbeiten…

Einrichten ist kein Problem, einfach den sshd Dienst in YaST->System->Dienste-Verwaltung aktivieren und den entsprechenden Port in der Firewall freigeben. YaST->Sicherheit und Benutzer->Firewall enthält natürlich ein entsprechendes “Secure Shell-Server”-Profil unter “Erlaubte Dienste”.

Danach kannst du dich als beliebiger Benutzer übers Netzwerk einloggen, z.B. mit “ssh” von der Kommandozeile oder einem grafischen Terminal-Programm wie z.B. PuTTY. Und auch Sachen wie WinSCP kannst du dann benutzen um auf Dateien zuzugreifen.

X-Forwarding sollte eigentlich standardmäßig aktiv sein, beim Client musst du es evtl. einschalten.
Z.B. via Konsole:

ssh -X -l *username* *host*

Um grafische Programme zu starten musst du allerdings am Client einen X-Server laufen haben. Kein Problem unter Linux natürlich, aber auch für Windows gibts welche. Den da hab ich selbst schon erfolgreich benutzt:

Hi Wolfi323,

das mit dem X-Clienten auf Windows war mir völlig neu, interessante Sache. Werd ich mal in einem virtuellen Setup austesten sobald mal Zeit für sowas ist.

Ich denke, ich werde die ganze Geschichte (den Server) konsequent mal auf LXDE umbauen (mein Favorit, aber unter Suse bisher noch nicht probiert, da ich KDE als funktionierenden Standard erwartet hatte - (hust)) und sehen, wie sich das anlässt. Aber Danke für den Tip mit PolKit, damit hab ich mich noch nicht befasst, scheint aber auch anderen bei der Thematik “Shutoff” via Remote geholfen zu haben…

VG Micha

…tsooooo…

Nachtrag zu den Lernerfolgen:

  • neue 13.1 aufgesetzt
  • bei Installation LXDE als Arbeitsumgebung gewählt
  • erstes Einloggen nicht möglich, im Displaymanager “LXDE” anwählen, dann geht’s (vorher wird “Standard” als Oberfläche angeboten, da ist dann nach dem Login Schluss)
  • im Yast VNC erlaubt / Firewallfreigabe zugelassen
  • bei Zugriff per Remote erstmal keinen Displaymanager zu sehen bekommen
  • lightdm nachinstalliert, in /etc/system/displaymanager den “lxde” gegen “lightdm” ausgetauscht
  • vnc läuft (noch Auflösung anpassen in /etc/xinetd.d/vnc)
  • Samba einrichten, Nameserver einrichten

Fertig. Läuft.

Hmm, es sind immer kleine, nicht selbsterklärende Stolperfallen und als Standard angenommene, aber nicht funktionierende Dinge, die einen aufhalten. Hoffentlich weiss ich das alles in zwei…drei Jahren noch, wenn wieder eine Neueinrichtung fällig ist :o)

Und am seltsamsten: jetzt funktioniert der Shutdown via Remote. Ohne PolKit-Anpassungen.

Gruß Micha