Author Archives: Ralph Mönchmeyer

Resultset-Listen in PHP-IT-Templates

Posted on by

Im Rahmen der Programmierung von Datenbank-Abfragen mit PHP ist man immer wieder mit der Frage konfrontiert, wie man die Ergebnisse in listenartiger Form darstellen soll. Hierbei können u.a. folgende Schwierigkeiten auftreten:

a) Die Länge oder Größe des Inhalts einzelner Felder aus der Datenbank ist zunächst unbekannt. Die einzelnen Listenelemente müssen daher in der Höhe variabel sein.

b) Innerhalb eines Listenelementes hat man oftmals komplexe Unterformatierungen vorzunehmen. So ist das Listen-Aufzählungszeichen darzustellen. Hinzu kommen evtl. Feldbezeichnungen, die vom eigentlichen Feldinhalt abgesetzt werden sollen.

c) Der einzelne Satz der Datenbankabfrage beinhaltet i.d.R. mehrere Felder und entsprechende Inhalte, die pro Satz untereinander aufgelistet werden sollen. Um ein komplettes Resultset einer Datenbank-Abfrage darzustellen, braucht man also mindestens eine zweifach geschachtelte Liste. Damit erschwert sich die Formatierung.

d) Die Darstellung der (geschachtelten) Listen erweist sich bzgl. der Formatierung oft als browserabhängig. Dies gilt im besonderen für die Behandlung von Abständen der Aufzählungszeichen zum linken Rand der Liste wie zum Inhalt des Listenpunktes. Hinzu kommen weitere Standardabstände, die ggf. mühsam korrigiert werden müssen.

Will man die Darstellung einer Datenbankabfrage also etwa nach dem Schema

>

Inhalt des Satzes Nr. 11

*

Feldbezeichner 1
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
………., ……. , …..
………., ……. , …..

 

*

Feldbezeichner 2
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
………., ……. , …..
………., ……. , …..

 

>

Inhalt des Satzes Nr. 12

*

Feldbezeichner 1
Feldinhalt, Feldinhalt, Feldinhalt
Feldinhalt, Feldinhalt, Feldinhalt
………., ……. , …..
………., ……. , …..

 

formatieren, so erweist sich der simple Einsatz von “<UL><LI></LI></UL>” oft als unzureichend und – nicht zuletzt wegen der Browserabhängigkeit der Listenformatierung – auch als schwierig.

In vielen Fällen sind neben dem oben dargestellten Elementen pro Satz des Resultsets noch weitere schmuckvolle Bereiche darzustellen: etwa eine Leiste mit Buttons zum Auslösen von Pflegeoperationen für den Datenbank-Satzes oder zur Anzeige seines Status.

Gestern bin ich denn auch bei einem Kunden gefragt worden, ob wir zur Darstellung von solchen Resultsetlisten eigentlich Tabellen verwenden würden. Bzw.: Wie wir diese Probleme generell im Zusammenspiel mit serverseitigem PHP lösen würden.

Hierzu gibt es mehrere Antworten:

  1. Wir verwenden zur Formatierung des HTML-Outputs grundsätzlich Templates – zumeist PEAR IT- oder ITX-Templates. (Smarty-Templates sind natürlich eine genauso gute Alternative). Hierdurch trennen wir die Datenbankinteraktion und evtl. Datensatzmanipulationen im PHP-Skript weitgehend von der Darstellung des Resultsets im Browser ab. (Das erleichtert im nachhinein auch den Schwenk von klassischer PHP-Interaktion mit HTML-Generierung zu moderneren Vorgehensweisen auf der Basis von Ajax-Technologien.)

    Alle nachfolgenden Hinweise zur Formatierung sind somit reine HTML- bzw. CSS-Hinweise für das Template.

  2. Bei der Formatierung des listenartigen Outputs im IT-Template setzen wir in der Regel keine Tabellen mehr ein, da wir deren Handhabung inzwischen eher als unflexibel empfinden. Vielmehr verwenden wir sehr wohl Listentags (<UL>, <LI>).
  3. Für die Listen schalten wir i.d.R. allerdings die Formatierung für linksseitige MARGINs und PADDINGs ab. Per CSS setzen wir solche “MARGINs” und “PADDINGs” auf 0, sowohl im <UL>-Tag wie auch im <LI>-Tag. Auch den “list-style-type” setzen wir i.d.R. auf “none”. Hiermit erzielen wir später eine Kompatibilität der Listendarstellung für praktisch alle gängigen Browser (s.u.).
  4. Grundsätzliche Breiteneinstellungen der Liste nehmen wir im <UL>-Tag und wg. des MS IE auch im <LI>-Tag vor. (Das UL-Element verhält sich grundsätzlich wie ein Block. Nur sieht das das der MS IE nicht so.) Die Höhenvorgabe für die gesamte Liste und auch die einzelnen Listenelemente lassen wir dagegen offen.
  5. Die Abstände zwischen den Listen-Elementen regeln “margin-bottom”-Anweisungen für die <LI>-Tags. Hintergrundsfarben für den gesamten Listenbereich regelt wir manchmal über ein DIV, das die Liste umfasst. Von der “normalen” Listenformatierung bleibt also bislang nur eine Breitenvorgabe und ein vorgegebener Abstand zwischen den Listenelementen übrig.
  6. Die Formatierung innerhalb eines Listenelements gestalten wir grundsätzlich mit DIVs. In das <LI>-Tag der Hauptliste binden wir deshalb zunächst ein Container-DIV (“Satz-Container”) vorgegebener Breite ein. Die Höhe dieses Containers bleibt offen.
  7. Innerhalb des “Satz-Container”-DIVs (in einem <LI>-Tag der Liste für die Sätze) positionieren wir nun ein weiteres DIV (“Header-Container”), das zusätzliche DIVs für den den satzspezifischen
    Header und das Aufzählungszeichen für den Satz aufnimmt. Die Positionierung dieser inneren DIVs im “Header-Container” erfolgt über float-Anweisungen; relative Abstände werden über “margin”-Anweisungen festgelegt. Wichtig ist hier noch, dass ein nachfolgendes Dummy-Element (z.B. ein <p>-Tag) das Floaten im Container wieder aufhebt. Breite und Höhe des Header-Containers können in der Regel fest vorgegeben werden. Zusätzlich dient ggf. eine “margin-bottom”-Anweisung zur Festlegung des minimalen Abstands zu weiteren nachfolgenden DIV-Elementen eines Satzes.

  8. Unterhalb des Header-Containers des Satzes positionieren wir nun eine weiteres DIV (“Container Feldliste”). Der Container “Feldliste” wird relativ (!) zum Header-Container positioniert (ggf. ist ein zusätzl. margin-top festzulegen). Seine Breite ist beliebig vorgebbar, seine Höhe bleibt offen.

    Damit die Positionierung auch richtig erfolgen kann, sollte man diesem DIV (Container Feldliste) zur Sicherheit noch eine Style-Anweisung “clear:both;” mitgegeben. Damit werden die vorhergehenden float-Anweisungen für die Header-Elemente aufgehoben, wenn man dies dort vergessen hat.

  9. Verschachtelte zweite Liste: In den “Container Feldliste” positionieren wir nun erneut eine <UL>-Liste, die dann der Darstellung der Feldelemente eines Satzes aus dem Resultset dient. Auch für diese Liste schalten wir evtl. intrinsische linksseitige margin- und padding-Vorgaben der Browser explizit ab und setzen den “list-style-type:none”. Zudem regeln wir den vertikalen Abstand der Listenelemente durch “margin-bottom”-Vorgaben.
  10. Pro Listenelement der feldbezogenen Liste erstellen wir nun einen weiteren DIV-Container (“Container Einzelfeld”). Auch seine Breite und Margins geben wir vor. Die Höhe bleibt dagegen offen.
  11. In den Container “Einzelfeld” werden nun weitere separate DIVs für ein evtl. Aufzählungszeichen, den Feldnamen und den Feldinhalt gesetzt. Die relative Positionierung der inneren DIVs zueinander erreichen wir erneut per CSS-float-Anweisungen. Die relative Positionierung der inneren DIVs zueinander regeln zusätzliche “margin”-Anweisungen. Auch hier heben wir die float-Anweisung wieder über ein abschliessendes Dummy-Element auf. Keines (!) der inneren DIVs wird also im Container über “position:absolute” positioniert. Es werden nur float- und margin-Anweisungen verwendet.
  12. Die Breite der einzelnen inneren DIVs für den Feldbereich geben wir per CSS vor. Die Höhe des DIVs zur Aufnahme des Feldinhalts lassen wir dagegen im Falle von Textfeldern offen, da die Länge und Größe des Feldinhalts dann ja vorab nicht bekannt ist.
  13. Um das Container-DIV “Einzelfeld” (wegen einer evtl. Rahmung oder Hintergrundsfarbe) an die vorab unbekannte Höhe der inneren DIVs – im besonderen des DIVs für den Feldinhalt anzupassen, ist folgender Schritt wichtig:

    Zusätzlich zu den inneren “gefloateten” DIVS bringen wir ein weiteres relativ positioniertes Dummy-Tag (z.B. ein P-Tag) an, das die “style”-Anweisung “clear:both;” enthält. Ohne diese Anweisung ist die Höhe des Container-DIVs “Einzelfeld” nur auf eine Minimum beschränkt und die gefloateten inneren DIVs ragen über den Minimalbereich des Containers weit hinaus. Das Dummy-Tag ermöglicht als reguläres Inhaltselement des Containers die Höhenbestimmung für das Elternelement, indem es die Float-Anweisungen aufhebt.

Durch diese zweifach verschachtelte Liste und die erwähnten Maßnahmen erreicht man eine sehr schöne und im nachhinein per CSS sehr einfach anpassbare Listendarstellung der Ergebnisse von Datenbankabfragen. Da die eigentliche Formatierung jedes Listenelements inkl. Aufzählungszeichen innerhalb
eines DIV-Containers erfolgt, wird man bzgl. der Listendarstellung der Sätze und der inneren Liste der Felder praktisch browser-unabhängig.

Natürlich lagert man die CSS-Anweisungen für die Listen und die inkludierten DIVs zur besseren Pflegbarkeit in eine separate Datei aus.

Orange – eine Farbe mit Flecken

Posted on by

Vor kurzem waren wir in Frankreich. Dort gibt es auch einen DSL-Provider, der sich einer bestimmten Farbe verschrieben hat. Die Freunde, bei denen wir zu Besuch waren, haben sich den Luxus geleistet, in ihrer Ferienwohnung einen DSL-Anschluss dieses Providers zu installieren.

Wir fanden das ganz toll – den Laptop raus, Linux anwerfen, Emailen und Surfen ……. – dachten wir.

Aber nein – mit Verwunderung mussten wir feststellen, dass die von uns vorgegebenen DNS-Server nicht akzeptiert wurden. Port 53 funktionierte nur für die DNS-Server dieses Providers. Noch viel interessanter wurde es dann bei Mails – der Port 25 ist für alle Server außer den eigenen SMTP-Servern des Providers geblockt. Hinzu kam die Erfahrung unserer Freunde, dass es nicht möglich war, eine verschlüsselte VPN-Verbindung zu ihrer Firma aufzubauen. Bei einem anderen Provider funktionierte dies dagegen ohne weiteres und auf Anhieb.

Im Internet fand ich dann den Hinweis, dass dieser Provider zumindest das Blockieren des SMTP-Ports für andere Server ohne Benachrichtigung an die eigenen Kunden durchgeführt hat. In diversen Foren gab es hierzu bereits hitzige Debatten.

Warum diese Eingriffe und die Begrenzung der Freiheit des Anwenders? Angeblich, um die Spamflut, durch die der französische Provider anscheinend besonders betroffen war, besser in den Griff zu bekommen. (Als ob es dazu nicht andere Methoden gäbe … ) Warum dann aber keine offizielle Ankündigung in diesem Sinne? Warum sich den Hass vieler internationaler Geschäftsleute zuziehen, die über ihre eigenen SMTP-Server operieren wollen oder müssen?

Interessant ist, dass der besagte Provider fest in der Hand der französischen Telekom und damit des Staates ist. Ein Schelm, wer dabei Böses denkt …. zumal nach den kürzlichen Erfahrungen mit anderen großen nationalen Telefongesellschaften …..

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