Monthly Archives: June 2008

Remote Administration – VNC oder ssh -X ?

Posted on by

Es gibt eine Reihe von Situation bei der Remote-Wartung eines Rechners, in denen es nicht damit getan ist, nur auf eine Shell zuzugreifen. Manchmal benötigt man den graphischen Zugriff – zumindest auf einzelne Applikationen. Dies gilt vor allem dann, wenn der User des Remote-Rechners Fehler im graphischen Bereich meldet. Genau so einen Fall hatten wir gestern, als wir auf einen Linux-PC (SUSE 10.2) in Frankreich zugreifen mussten, um das ordnungsgemäße Wirken von Firefox zu überprüfen.

Als rettender Engel steht man nun vor der Frage, wie man den Zugriff am besten erledigt. Mit einer verschlüsselten Verbindung natürlich. Klar. Aber ist im Einzelfall eine SSH-verschlüsselte X-Sitzung sinnvoller als eine VNC-Sitzung? Ich meine, dass man das nicht pauschal sagen kann. In unserem Fall erwies sich einen verschlüsselte VNC-Sitzung als die bessere und schnellere Lösung. Wir diskutieren nachfolgend kurz beide Möglichkeiten, da wir schon mehrfach gefragt wurden, wie man für Remote-Sitzungen vorgeht.

Möglichkeit 1: SSH -X

Eine einfache Möglichkeit ist zunächst einmal die, den Output der kritischen Applikation auf den eigenen lokalen X-Server umzulenken. Dies erreicht man bequem dadurch, dass man sich auf dem Remote-Rechner mit

ssh -X remote-rechner

oder

ssh -X user@remote-rechner

anmeldet. Die auf jeden Fall erforderliche SSH-Verschlüsselung für die Verbindung erhält man dann inklusive. In vielen Fällen genügt dies, um ein Problem zu lösen. Man startet einfach in der geöffneten Shell die zu untersuchenden Applikationen, die ihren graphischen Output dann (i.d.R.) auch brav auf dem lokal laufenden X-Server des Administrator-PCs darstellen. Zur Klarstellung: Der X-Server läuft hier auf dem eigenen lokalen System des Admins und nicht auf dem zu untersuchenden Remote-System! Der Remote-Rechner sendet den graphischen Output der Applikation über das Netz zum X-Server des lokalen Rechners, von dem aus der Administrator auf das Remote-System zugreift. (Beim nachfolgend diskutierten VNC-Verfahren ist dies anders!).

Nun gibt es u.U. leider Bedingungen, unter denen das Vorgehen über “ssh -X” nicht funktioniert oder der Datentransfer einfach zu unbequem wird.

Hindernis 1 – Performance: Bei einer X-Session werden (applikationsabhängig) relativ viele Daten übertragen. Das kann u.U. zu einem erheblichen Geduldspiel werden. Tödlich sind meiner Erfahrung nach bei rel. langsamen Remote-Rechnern und begrenzter Verbindungsbandbreite solche Applikationen wie Yast (z.B zur Paketverwaltung). Auch Anwendungen, deren Inhalt selbst komplex ist (Browser mit Flash) führen ggf. zu Zuständen wie in der Warteschlange bei großen Telekommunikationsanbietern.

Hindernis 2 – Sicherheitseinstellungen: Die Applikation lässt ggf. oder unter bestimmten Umständen keinen Output auf dem Remote-Xserver zu.

Hindernis 3 – fehlerhafte Anwendungen: Die Anwendung weist Fehler auf oder ist mit dem Remote X-Server nicht kompatibel.

In unserem Fall war es wie gesagt so, dass wir das Verhalten von Firefox auf dem Remote-Rechner testen mussten. Leider ließ sich der von uns remote gestartete Firefox-Prozess unter keinen Umständen dazu bewegen, sich auf unserem lokalen X-Server zu präsentieren. (Nach Aussagen des Remote-Anwenders ging Firefox auf dem Remote KDE-Desktop aber sehr wohl auf! Siehe zum seltsamen Verhalten von Firefox weiter unten!). Zudem wurde das Update von Software über Yast2 zu einer erheblichen Geduldsprobe.

In solchen Fällen liegt es nahe, zumindest testhalber eine VNC-Verbindung über KDEs “krdc” aufzubauen und diese VNC-Verbindung ggf. für langsame Leitungen zu konfigurieren.

Möglichkeit 2: VNC
Auf dem Remote-System muss ein VNC-Server laufen. Die meisten Distributionen haben ein entsprechendes Paket, das man mit dem Paketmanager seiner Wahl installiert. Dann richtet man den VNC-Server und IPtables (oder die aktive Firewall) auf dem Remote-Rechner so ein, dass die Kommunikation überhaupt möglich wird. Typischerweise verwendet der VNC-Server auf dem Remote-Rechner als Default-Port den Port 5901.

Dieser Port muss für eingehende Verbindungen vom System des Administrators aus freigeschaltet werden – am besten nur für Verbindungen von diesem System aus! (Eine Diskussion der zugehörigen IPtables-Konfiguration führt an dieser Stelle zu weit – ich empfehle hierfür das sehr schöne Programm FWbuilder!). Unter Opensuse hilft einem Yast (s. den Punkt Netzwerkdienste). Nachteilig empfinde ich dabei allerdings die pauschale Freigabe des Ports auf allen Interfaces und für alle potentiellen IP-Adressen.

Nach dem Einrichten des VNC-Servers auf dem Remote-System ist ggf. ein Neustart von xdm, kdm oder gdm für den Anmeldebildschirm erforderlich (für SUSE und KDE hilft z.B.: “rckdm restart”). Das Einrichten des VNC-Servers macht man am besten über eine Standard SSH-Sitzung, wenn der Remote-Anwender sich mit der Konfiguration nicht auskennt.

Die Verbindung zwischen Administrator-System und dem Remote-Rechner (Port 5901) muss vor Beginn der VNC-Sitzung natürlich verschlüsselt werden. Hierzu baut man einen SSH-Tunnel vom eigenen Rechner zum Zielsystem auf. Wir setzen voraus, dass SSH auf beiden Systemen eingerichtet ist und dass der ssh-agent für eine automatische Passwortübergabe vorbereitet wurde. Der Tunnel wird dann vom PC des Administrators aus durch nachfolgenden Befehl aufgebaut:

z.B.: ssh -f -N -L8787:remote-rechner:5901 user@remote-rechner

Hierbei gilt Folgendes: “user” ist der Username unter dem die ssh-Sitzung auf dem Remote-Rechner aufgebaut wird. “remote-Rechner” ist durch den Namen oder die IP-Adresse des Remote-Systems zu ersetzen. Die Option “-f” bedingt die Option “-N”. “-f” sorgt für einen Fork-Prozess von ssh in den Hintergrund, “-N” sorgt dafür, dass kein Shell-Fenster geöffnet wird. Der ssh-agent muss hierbei – wie gesagt – in der Lage sein, Passwörter automatisch im Hintergrund auszutauschen. Als Zielport ist hier der Defaultport 5901 gewählt worden. Ob dieser gültig ist, muss man natürlich vorher wissen (Einrichtung des VNC-Servers). “8787” ist im Beispiel der Dummy-Port auf dem lokalen System, über den der lokale VNC-Client dann den Remote-Rechner auf Port 5901 – und damit den VNC-Server – anspricht.

Der SSH-Tunnel hat in diesem Beispiel also als Anfangspunkt den Port 8787 auf dem lokalen System des Administrators und als Endpunkt den Port 5901 auf dem Remote-System “remote-rechner”. Dort loggt sich der User ja gerade für die SSH-Sitzung ein. (Sonderfälle wie den Umweg über einen SSH-Relay-Rechner lassen wir hier mal der Einfachheit halber weg. )

Wichtiger Hinweis: Zu beachten ist, dass man nach getaner Arbeit nicht vergisst, den SSH-Tunnel (der ja im Hintergund läuft) wieder abzubauen und auch den Port 5901 wieder zu schließen !!!

Weitere Hinweise zum Tunneln: Schlägt der Fork-Prozess in den Hintergrund fehl, oder will man die Passwort-Verankerung in den Systemen nicht dem ssh-agent überlassen, so hilft

z.B.: ssh -L8787:remote-rechner:5901 user@remote-rechner

Allerdings öffnet man damit eine bleibende Remote-Shell im Vordergrund des lokalen eigenen Systems. Verwendet man

ssh -X -L8787:remote-rechner:5901 user@remote-rechner

so hat das den Vorteil, dass man bei Bedarf schnell noch eine Remote-Applikation für den eigen X-Server öffnen kann – zusätzlich zu den Vorgängen, die im VNC-Client dargestellt werden (also Vorgänge, die in einer X-Session auf dem Remote-System laufen).

Konfiguration des lokalen VNC-Clients: Im VNC-Client (z.B.
“krdc”) muss man im gegebenen Beispiel als Zielrechner natürlich “localhost:8787” eingeben, um die VNC-Sitzung über den Tunnel aufzubauen. Der Client spricht über den lokalen Port 8787 den Remote-Rechner an und erhält vom dortigen VNC-Server die Bilddaten der dortigen X-Sitzung zugeschickt. (Die X-Sitzung läuft auf dem Remote-Rechner ab! Der lokale VNC-Client erhält hiervon nur die Bilddaten, die er auf dem Schirm des Admin-PCs als spezielle lokale X-Applikation darstellt.).

Hat man bisher alles richtig gemacht, so öffnet sich im lokalen VNC-Client der graphische Anmeldeschirm des Remote-Systems und man gelangt nach dem Login in eine graphische X-Sitzung des Remote-Systems unter dem dortigen Window-Manager (z.B. KDE).

In unserem Fall stellten wir tatsächlich fest, dass das Arbeiten über VNC relativ zügig vonstatten ging und zwar schneller als mit einer “ssh -X” – Sitzung. Ob das allgemeingültig ist, trauen wir uns aber keinesfalls zu sagen.

Hinweis zu Remote-Tests von Firefox:
Firefox für Linux stellt fest, auf welchem X-Server und Screen ein bestimmter User eine erste Instanz des Firefox-Programms geöffnet hat und lässt die Öffnung weiterer Instanzen für andere X-Server nicht zu (vermutlich aus Sicherheitsgründen). Das führt für Remote-Zugriffe aber zu folgender unguter Situation:

Hat der Remote-User (nennen wir ihn “James”) noch irgendein Firefox-Fenster offen, so lässt sich auf dem lokalen X-Server des Administrators keine weitere Firefox-Instanz öffnen, wenn der Administrator als “James” auf dem Remote-System eingeloggt ist. Umgekehrt gilt das Gleiche: Hat der Administrator als User “James” auf dem Remote-System eine Firefox-Instanz für den lokalen X-Server geöffnet, so kann der User James auf dem Remote-System und in seiner eigenen X-Sitzung keine neue Firefox-Instanz öffnen, sondern erhält eine Warnung !
Man lernt nie aus!
Merke: Will man Firefox als Remote Administrator auf seinem eigenen lokalen X-Server testen, so muss der User auf dem entfernten Remote-Rechner alle Firefox-Fenster (Firefox-Programme) vollständig geschlossen haben – oder der Administrator muss unter einer anderen User ID eingeloggt sein.

Kmail: (Mit-) Leid mit Outlook-Empfängern

Posted on by

Heute bekam ich es mit einem wütenden Kunden zu tun, der Outlook benutzt. Ich hatte ihm für ein Projekt eine Excel-Datei mit Kalkulationsdaten geschickt. Diese Datei konnte er nicht öffnen. Vielmehr sei Nero mit einer Fehlermeldung am Schirm erschienen, hielt er mir entgegen. Ob ich ihm Musik statt Zahlen verkaufen wolle? Glücklicherweise hatte ich die Mail in Kopie noch an einen anderen Empfänger verschickt, der Thunderbird unter Windows XP benutzt. Letzterer konnte den Anhang – also die Excel-Datei – sofort und ohne Schwierigkeiten öffnen und weiterverarbeiten. (Ein erster aufmunternder Pluspunkt für mein gekränktes Gemüt!)

Wirklich überzeugt hat das meinen Kunden aber noch nicht. Selbst neugierig geworden, bat ich ihn, mir meine Mail zurückzuschicken. Sie enthielt meinen ursprünglichen Anhang tatsächlich in stark modifizierter Form – nämlich als Datei mit der Endung “.dat” und einem von Outlook dazugedichteten Namen. Beim erbosten Kunden führte diese Endung dazu, dass sich Nero öffnete und gleich wieder mit einer Fehlermeldung verabschiedete. (Auf einem Windows-System ohne Nero hätte wahrscheinlich der MS Media-Player versucht, den Anhang darzustellen.) Unter Linux öffnete Openoffice den verunstalteten Anhang übrigens ohne Klagen (Ein zweiter Pluspunkt – ich entspanne mich langsam wieder !).

Mails aus dem Microsoft Outlook/Exchange-Umfeld mit seltsamen dat-Datei-Anhängen kannte ich schon aus alten Lotus Notes und Domino Tagen. Diesmal war die Problemrichtung aber umgekehrt … Und nachdem die Excel-Datei eine Original-Excel-Datei war und nicht eine Datei, die ich mit OpenOffice erstellt und ins xls-Format umgewandelt hatte, kam ich dann doch ins Grübeln.

Was macht mein Kmail hier falsch? Liegt es vielleicht an Einstellungen von Cyrus und Postfix auf meinem Email-Server? Und natürlich stellt sich die Frage: Warum kann Outlook eigentlich eine von einem Microsoft-Programm erzeugten Datei als Email-Anhang nicht richtig verarbeiten?

In meiner Ratlosigkeit habe ich erst mal in den Einstellungen von Kmail gestöbert. Irgendwas mit Outlook hatte ich da doch schon mal gesehen … Und richtig: Unter “Komposer -> Anhänge” fand ich schließlich eine Option zur Outlook-Kompatibilität. Aktiviert man die, so erhält man einen netten und vielsagenden Hinweis der KDE-“Kontakt”-Entwickler:

“Sie haben sich dazu entschieden, die Namen von Anhängen, die nicht-englische Zeichen enthalten, so zu kodieren, dass Outlook(tm) und andere nicht den Standards folgende Programme diese verarbeiten können. Beachten Sie bitte, dass auch KMail in dieser Einstellung E-Mails erstellt, die eventuell nicht den Standards entsprechen und daher Probleme bei E-Mail-Programmen verursachen können, die sich an die Standards halten. Sie sollten diese Option also nur dann aktivieren, wenn es unbedingt nötig ist.”

Das ist wirklich deutlich genug und braucht nicht weiter kommentiert zu werden ! Balsam für die gedemütigte Linux-Seele !

Wie hatte ich doch gleich die Excel-Datei genannt ? Ach ja: “übersicht.xls”. Das war natürlich wenig vorausschauend – ist aber mal passiert.

Nachfolgende Tests und ein paar Recherchen im Internet ergaben:
Outlook hat vielfältige Schwierigkeiten mit der Behandlung von Umlauten (in Adressen, in Anhangsnamen, im Inhalt). Das Problem mit der Behandlung von Umlauten im Namen anhängender Dateien ist ein relativ spezielles. Die Schwierigkeiten rühren wohl daher, dass Outlook – im Gegensatz zu aktuellen Linux-, Apple- und Opensource Mailclients – einen veralteten RFC-Standard für den Transfer solcher Anhänge benutzt. Beim Empfang wandelt Outlook dann die betroffenen Dateien in “.dat”-Dateien mit selbst generiertem Namen um.

Die Aktivierung der Option in Kmail zur Outlook-Kompatibilität hilft denn auch tatsächlich, dieses Problem zu umgehen. Dann schaltet Kmail auf den alten Standard um. Aber will man sich eigentlich dem Diktat unzureichender Software beugen?

nNein: Die viel bessere Lösung ist natürlich, gar keine Dateinamen mit landesspezifischen Umlauten zu verwenden, wenn man als Linuxer über Kmail Anhänge an Kunden verschickt, die Outlook benutzen müssen. (Man muss halt nur wissen, dass es hier überhaupt ein Problem gibt!) Und bzgl. der Option in Kmail sollte man lieber die Warnung beherzigen und sie nicht aktivieren.

Mein Kunde hat inzwischen die schöne Kmail-Warnung und Hinweise auf entsprechende Artikel im Internet als Abendlektüre erhalten. Plus einer Datei namens “uebersicht.xls”. Ich vermute, der Vorgang wird nicht zur Abschaffung von Outlook in der Firma des Kunden führen – aber ein gutes Gefühl bleibt einem als Linux-Anwender am Ende doch.

Bei Kmail habe ich innerlich schon Abbitte geleistet – dort ist diese Sache vorbildlich geregelt und kommentiert. In Thunderbird gibt es übrigens eine entsprechende Option – viel Spaß beim Suchen.

Links:
http://forum.univention.de/viewtopic.php?f=28&t=128
http://www.maczeug.de/page1/page28/page28.html

VMware – Windows – kein Sound ?

Posted on by

Gestern hatte ich einen dummen Fehler zu beheben, an dem ich möglicherweise selbst schuld war. Die zugehörigen Meldungen des Systems aus Redmond waren aber auch nicht dazu angetan, der Sache schnellstmöglich auf die Spur zu kommen. Da diese Meldungen z.T. widersprüchlich bis kurios sind, hilft der folgende Beitrag vielleicht auch anderen:

MS Win XP läuft bei anracon auf Opensuse Hosts als VMware-Gastsystem. Da ich fast nie den Bedarf verspüre, auch noch Töne aus dem Windows-System zu hören, ist die virtuelle Soundkarte bei mir normalerweise deaktiviert. Nun ergab sich gestern doch einmal der Bedarf, dem Windows-Gast ein paar Töne zu entlocken (Grund war eine Flash-Programmierung). Da ich wusste, dass mir das früher schon gelungen war (allerdings unter Opensuse 10.2 statt meinem aktuellen 10.3 und mit der VMware Workstation 5 statt der WS 6), fügte ich meiner virtuellen Maschine frohgemut eine virtuelle Soundkarte hinzu.

Windows erkennt diese Karte – eine Soundblaster PCI 128 – im Normalfall auch anstandslos und lädt den passenden, im Windows Treiber-Resevoir befindlichen Treiber. Der Windows Gerätemanager zeigte mir dann auch brav, dass die Soundkarte funktionstüchtig sei.

Leider war aber schon beim obligatorischen Windows-Neustart die übliche Redmonder Startmelodie nicht zu vernehmen. Da dachte ich noch optimistisch, dass der Ton vielleicht zu leise eingestellt sei. Also: Linux-Soundsystem und Mixereinstellungen überprüfen – alles OK.

Im nächsten Schritt rief ich dann die Lautstärekregelung bzw. den Mixer im Windows-System auf. Antwort des Systems: ” Es ist kein Mixer installiert. Gehen Sie zu “Drucker und sonstige Hardware”, um einen geeigneten Mixer zu installieren.” So einen Punkt gibt es zwar gar nicht und was der Drucker damit zu tun haben soll, bleibt auch rätselhaft. Aber wer weiß schon, wie Windows-Entwickler denken …..

Früheren Erfahrungen folgend werfe ich erst mal einen kleinen Blick in die Registry. Sieht alles OK aus. Auch hier ist die Soundblasterkarte verzeichnet. Anderen schlechten Erfahrungen mit Windows folgend, entferne ich die Soundkarte dennoch aus der Hardwareliste und lasse sie danach neu erkennen und installieren. Keine Veränderung. Die Karte läuft angeblich, aber “No Sound” – kein Ton vom Windows VMware Gast. Also doch ein Problem mit VMware WS 6 unter Opensuse 10.3 ?

In banger Erwartung werfe ich nun einen Blick ins Internet und in diverse VMware Foren – wenig überrascht stelle ich fest, dass bemerkenswert viele Leute Probleme mit dem Sound eines Windows-VMware-Gastes auf einem Linux-Host haben – wenn auch eher im Ubuntu/Debian-Bereich als unter SUSE.

Ich befolge dann zur Sicherheit den ersten Ratschlag, aus alten Archiven den letzten Creative-Treiber für diesen Typ Soundkarte im Gastsystem zu installieren. Die Installation verlief zwar erfolgreich, zeitigte aber keinen Effekt in puncto “hörbare” Töne. Ich folge weiteren intelligent klingenden Diskussionen darüber, dass VMware evtl. Probleme mit Alsa habe und dass das liebe, alte “OSS” statt “Alsa” aktiviert werden müsse. Ich probiere diverse Varianten und Einstellungen des Linux-Soundsystems unter KDE aus. Keine Wirkung. Kein Ton. Auch andere Ratschläge in diversen Foren helfen nicht weiter.

In dem sicheren Bewusstsein, dass das alles doch schon mal lief, gebe ich die Schuld nun endgültig irgendeiner verpfuschten Einstellung unter Windows. Ein wenig dumpfes Suchen führt mich zu “Sounds und Audiogeräte” unter der “Systemsteuerung”. Hier kommt die interessante Meldung “Kein Audio-Device”, die in krassem Widerspruch zu den Informationen des Gerätemanagers steht, der eine funktionstüchtige Soundkarte meldet.

Etwas genervt kommt mir der Gedanke, dass die Soundkarte vielleicht zwar läuft, aber nicht ins System eingebunden ist – was vielleicht auch den fehlenden Mixer erklären könnte. Für letzteren sollte ich ja meinen Drucker checken, ha, ha, ha … . Das tue ich nicht, sondern wende mich
nun der Zwischenschicht der “Dienste” unter Windows zu und studiere die entsprechende Rubrik in der “Verwaltung”. Und da werde ich endlich fündig: Der Dienst “Windows Audio” befindet sich im Status deaktiviert.

Wie kam er denn in den Zustand? Liebe Leut’, glaubt es mir, ich weiß es nicht. Da ich für Windows nur eine sehr schlampige Buchführung zu administrativen Änderungen führe, kann ich nicht ausschließen, dass ich diese Einstellung irgendwann mal selbst vorgenommen habe. Vielleicht war es aber doch eines der vielen Updates ?

Na ja, die Umstellung des Dienstes auf einen öminös klingenden “Autostarttyp: Automatisch” bringt die Erlösung – endlich vernehmbare Töne aus dem Windows-Gast-System. …

Hmm …. “Autostarttyp Automatisch” – da braucht man auch erst mal Zeit, um über diese Alliteration hinweg zu kommen … Toll ist auch “Autostarttyp: Manuell “….. Wer sich sowas wohl ausgedacht hat ? Aber ich schweife ab ….

Was lernen wir nach 1 Stunde Nervenverlust zum Thema “Kein Ton vom Windows Gast auf einem Linux-Host”:

  1. Prüfe zunächst, ob die virtuelle Soundkarte erkannt wurde und ob der zugehörige MS Treiber geladen wurde (der reicht nämlich).
  2. Überprüfe dann die Anzeige des Soundblaster-Devices unter “Sounds und Audiogeräte” in der Systemsteuerung.
  3. Prüfe dann, ob der Audio-Service überhaupt aktiv ist.
  4. Fange erst dann, wenn die oberen Punkte alle OK sind, an, über Probleme von VMware und/oder Linux nachzudenken.

……und – fast hätte ich es vergessen – führe ein Logbuch auch über administrative Veränderungen am Windows-Gast-System ……selbst wenn es nervt …..