OX5 – Login Problem mit Konqueror – Nachtrag 1

Posted on by

Wie man der Kommunikation zu den Konqueror-Bugs

http://bugs.kde.org/show_bug.cgi?id=150070 und http://bugs.kde.org/show_bug.cgi?id=149957

entnehmen kann, gibt es seit ein paar (Entwicklungs-) Versionen wohl tatsächlich Schwierigkeiten bei der Interpretation von HTTP Header Direktiven. Es handelt sich dann also nicht um ein OX5 spezifisches Problem des Browsers Konqueror.

Die KDE-Entwickler arbeiten anscheinend daran – das ist beruhigend, obwohl man sich natürlich fragt, wie denn die Tests aussehen, wenn in einen so wichtigen Bereich eines Browsers eingegriffen wurde. Auf der anderen Seite führt aber auch nicht jeder Benutzer mit so hoher Frequenz wie ich ein Update der KDE Umgebung durch.

Betrachten wir das Ganze also mal als Test, wie denn die Opensource Gemeinde mit so einem Problemchen umgeht. Ich bin jedenfalls gespannt, ob und in welcher der nächsten Versionen der von SUSE publizierten KDE rpms dieser Fehler behoben sein wird.

Ergänzung:
Mir ist bei der Analyse des HTTP-Datenverkehrs zwischen OX-Server und Browser (mittels Wireshark) aufgefallen, dass die OX-Leute für den Redirect im Login-Prozess eine “REFRESH”-Direktive im HTTP-Header benutzen. Das ist insofern bemerkenswert, als dies kein HTTP 1.1-Standard ist, wenngleich diese Direktive von Firefox, IE und Opera unterstützt wird. Bis zur Version 3.5.7-64.1 wohl eben auch von Konqueror. Nur danach halt leider nicht mehr!

Eine Lehre, die sich an diesem Beispiel erneut bestätigt, ist die Folgende:

Gerade beim produktiven Einsatz von Opensource muss jedes Update des Desktops vor dem Produktiv-Einsatz gründlich auf die Funktionstüchtigkeit der Standard-Arbeitsabläufe hin getestet werden. Es wird keineswegs alles besser, wenn ein neues (Zwischen-) Release auf den Markt kommt.    


VMware – bei anracon täglich im Einsatz

Posted on by

VMware – bei anracon unter Linux und Windows im produktiven Einsatz

Dies ist zwar ein Linux-Blog. Dennoch kommt in unserer Firma auch Windows zum Einsatz. Entscheidende Gründe hierfür sind:

  • Die weite Verbreitung von Windows bei unseren Kunden (im Besonderen bei Konzernkunden).
    Es wäre zu zeitaufwändig, Projektdokumente zwischen Openoffice und den MS Produkten hin- und her (!) zu transformieren. Dies funktioniert im professionellen Umfeld nur mit erheblichem Aufwand, der einem leider nicht bezahlt wird. (In eine Richtung – z.B. von Openoffice zu MS Office – arbeitet man allerdings deutlich aufwandsärmer. Beim Anlegen neuer Dokumente verwenden wir diese Richtung sehr oft. Leider tritt aber sehr viel häufiger der Fall ein, dass ein Dokument dauerhaft gepflegt werden muss. Dann arbeiten wir, wo immer erforderlich, direkt mit den MS-Produkten.)
  • WEB-Entwicklung: Wir setzen die Produkte von Adobe/Macromedia ein.
    Diese sind rein für MS Windows entwickelt worden. Man kann Flash und Dreamweaver 8 zwar unter Crossover Office (Wine) zum Laufen bringen. An einigen Details, die für den produktiven Einsatz zumindest störend sind, gibt es dann aber doch immer wieder Schwierigkeiten. Zudem ist die Performance unter Crossover Office wenig berauschend. Web-Entwicklungstools sind unter Linux zwar im Aufbau; ihre Leistungsfähigkeit und ihr Umfang scheinen uns aber noch nicht mit den Eigenschaften der Adobe/Macromedia-Produkte vergleichbar.

Es galt und gilt daher, bei aller Bevorzugung von Linux einen ausgewogenen Einsatz von Windows zu realisieren. Der Kompromiss bei anracon sieht wie folgt aus:

  • Serverbetrieb: Alle für den täglichen Betrieb benötigten Serverkomponenten (Groupware, LDAP, CUPS, Samba, MySQL, Postgres, Dateiserver, Apache etc.) laufen komplett auf dedizierten Linux-Systemen.
  • Clientbetrieb: PCs für Webentwicklung sind Windows-Rechner mit VMware oder Linux-Rechner mit VMware.

Ob wir auf einem Client-PC Windows oder Linux als Primärsystem (im VMware Chargon: “Host-System”) einsetzen, machen wir (nach vielen Tests) heute rein von der HW-Konfiguration abhängig:

  • Auf neueren Maschinen mit Doppelcoreprozessor (z.B. Athlon X2, ab Baureihe 4000+) und ausreichendem Speicher (> 2GByte) verwenden wir als Host-System Linux. Hier gibt es bei dedizierter Zuordnung von VMware und des Gastsystems (noch XP) keinerlei Probleme mit der Performance der benötigten Applikationen. Die komplette Web Premium Suite CS3 läuft heute auf einem System mit einem Athlon X2 4800 anstandslos.
  • Auf älteren Maschinen mit Einzelprozessor und geringerem Hauptspeicher ist dagegen MS Windows das Hauptsystem. Linux-Applikationen bieten wir hier im Rahmen einer maßgeschneiderten Linuxinstallation auf einer virtuellen VMware-Maschine an. Dies ist insbesondere bei plattformübergreifenden Tests sehr angenehm.

Wir haben mit dieser Vorgehensweise seit ca. sehr positive Erfahrungen gemacht und können den Einsatz von VMware sehr empfehlen.

Wir wollen an dieser Stelle nicht unerwähnt lassen, dass VMware natürlich auch unschätzbare Dienste leistet, wenn es gilt, neue Betriebssysteme, Applikationen, Netzwerkkonfigurationen und Firewall-Einstellungen vor dem Produktiveinsatz zu testen.

In einem kommenden Beitrag befassen wir uns näher mit der VMware-Istallation auf Systemen mit inzwischen betagteren Athlon X2 Prozessor. Hier gibt es Besonderheiten bzgl. der problematischen Synchronisation der CPU Cores zu beachten.

FwBuilder – eine Perle von einem Programm

Posted on by

Auch Linux-Systeme benötigen Firewalls. Auch wenn ganze Firmennetzwerke nach außen hin durch kommerzielle Firewalls abgeschottet werden, treten innerhalb des Netzwerkes immer wieder Situationen auf, bei denen man bestimmten Rechnern nicht gestatten will, mit anderen Systemen im Netz frei zu kommunizieren oder von anderen Rechnern beliebige Zugriffe anzunehmen. Eine Anwendungssituation ist z.B. die Begrenzung des Schadens durch evtl. Trojaner.

Zur schnellen Konfiguration von server- und generell rechnerspezifischen Firewalls auf der Basis von Iptables setzen wir bei anracon das Programm fwbuilder ein. Ich werde in weiteren Beiträgen hierzu mehr berichten.

Im Moment möchte ich festhalten: Es gibt immer mal wieder Momente, in denen man außerordentlich positive Erfahrungen mit Opensource-Programmen unter Linux macht. Mein Einstieg vor etwa einem Jahr in die Anwendung FWBuilder war ein solcher Moment:

Diese Anwendung

  • ist leicht verständlich
  • prüft die Konsistenz der Firewall-Bedingungen sehr weitgehend
  • hat eine ansprechende graphische Oberfläche, die sehr klar strukturiert ist
  • und entpuppt sich nach einer rel. kurzen Einarbeitungszeit als echte, langfristig wirksame Arbeitserleichterung.

Kurzum: Es handelt sich um echte Perle von einem Programm! Es macht Freude, damit zu arbeiten.

Leute, macht euch mit diesem Programm vertraut und setzt es ein!

Open-Xchange 5 und Konqueror – Login-Problem

Posted on by

Ein permanentes Ärgernis beim Einsatz von Open-Xchange unter Linux sind Unzulänglichkeiten, die im Zusammenhang mit dem Standard KDE (Web-) Browser Konqueror auftauchen.
Das neueste Beispiel ist ein fehlerhafter Login-Vorgang, bei dem Konqueror die Anforderungen des Servers nicht richtig handhabt. Ich beschreibe kurz das Problem, so wie es sich mir darstellt:

Ein Login auf dem Open-Xchange Server setzt wie üblich die Angabe einer Userid und eines Passwortes voraus. Der OX-Server (bzw. das dortige Sessionmanagement) vergeben eine SessionId. Dies wird dem Client zurückgemeldet und daraufhin wird ein Redirect zu einem Servlet des Servers vorgenommen, dass dafür sorgt, dass die Portalseite des Servers für den authentifizierten User aufgebaut und dem Client übermittelt wird. (Ich vermute, dass nach der Vergabe der SessionId der Client aufgefordert wird, die User-Daten nochmal zu übermitteln.)

Bis zur kdebase-Version 3.5.7-64.1 (in meinem Fall über ein SuSE x86-64 rpm unter Opensuse 10.2 eingespielt) lief dieser Login-Vorgang einwandfrei. In der neuesten Version 3.5.7-90.2 klappt dies jedoch nicht mehr. Es erfolgt zwar noch die Anzeige der Meldung, dass eine SessionId vergeben wurde, der anschließende Redirect wird aber nicht mehr ausgeführt und die Portalseite wird nicht angezeigt. Interessanterweise kommt man weiter, wenn man die Seite mit der redirect-Meldung nochmal lädt -> Die Login-Daten des usprünglichen Formulars werden nochmals geschickt, eine neue SessionId wird vergeben und die Portalseite erscheint unmittelbar danach.

Weder Firefox noch Opera zeigen ein derartiges Verhalten.

Wie man der Bug-Datenbank zu Konqueror entnehmen kann, gab es bereits in früheren Versionen von Konqueror Probleme mit Redirects (auch im Zusammenhang mit Authentifizierungs-Dialogen).

Es ist ärgerlich, dass solche Problemchen immer wieder auftauchen und einen flüssigen, produktiven Arbeitsablauf unter Linux (KDE) verhindern. Da es noch weitere Probleme im Zusammenspiel zwischen Konqueror und einem OX5-Server gibt (siehe weitere kommende Beiträge in diesem Blog), rate ich jedem OX5-User eher auf Firefox oder Opera als CLient-Browser zu setzen.

AIGLX/Beryl oder XGL/Compiz?

Posted on by

Nach meinem Verständnis erweitert AIGLX den vorhandenen X11-Server von X.org um 3D-Komponenten. Erst der X-Server arbeitet dann mit den 3D Funktionen der OpenGL-fähigen Grafikkarte zusammen (indirect rendering). 3D-Grafikkartentreiber sind in der Theorie nicht zwingend erforderlich; in der Praxis sind sie aber aus Geschwindigkeitsgründen unerläßlich.
XGL ersetzt dagegen den X-Server an bestimmten Punkten. Ein laufender X11-Server muss dennoch vorhanden sein, in dem dann ein spezielles XGL-Fenster direkt mit der OpenGL-Karte kommuniziert (direct rendering). Eine funktionierende 3D-Unterstützung durch Grafikkartentreiber ist hier zwingend erforderlich.

Als Anwender ist es zumindest anfänglich müßig, die Vor- und Nachteile beider Vorgehensweisen theoretisch aufzuarbeiten und für sich abzuwägen. Zunächst ist man sicher froh, überhaupt mal einen 3D-Desktop zu sehen. Und das klappt nicht immer (s.u.) oder nicht ohne größeren Aufwand. Ich bin der Meinung, dass NVidia bessere Treiber für Linux liefert als ATI und setze daher seit einiger Zeit nur NVIDIA-Karten ein. Für Besitzer von NVIDIA-Karten lautet meine Message:
Nimm Beryl ohne AIGLX und nutze die unterstützenden Rendering-Funktionen der NVIDIA-Treiber.

Bei mir schlugen erste Anläufe, XGL und Compiz unter OpenSuSE 10.2 zum Laufen zu bringen, fehl. Ich habe ein System mit einem Asus Board, einem Athlon Dual Core 4800+ und einer NVidida-7800-Grafikkarte. Als Desktop setze ich KDE unter OpenSuSE 10.2 ein. Das System fror beim Starten regelmäßig ein. Ich vermute, dass die von SuSE mitgelieferten Gnome-Pakte zu XGL/Compiz besser funktionieren würden. Insgesamt erschien mir die Konfiguration für KDE aufwändiger und vielleicht habe ich dabei auch Fehler gemacht.
Etwas entnervt habe ich dann AIGLX und Beryl ausprobiert – hier bekam ich wenigstens einen Würfel auf den Schirm – allerdings mit weissen Seiten. Dieses Phänomen ist bekannt und läßt sich vermutlich beheben (s. hierzu die Anweisungen unter http://wiki.beryl-project.org/wiki/Troubleshooting_AIGLX).

Ich habe dann aber beide Lösungen nicht weiter verfolgt, weil mein dritter Anlauf – nämlich mit der Kombination Beryl ohne AIGLX, aber mit unterstützenden Funktionen des NVidia-Treibers direkt zum Erfolg führte.

Aus bisher gelesenen Artikeln vermute ich, dass man XGL/Compiz auch unter OpenSuSE mit KDE zum Laufen bringen. Über Schwierigkeiten mit AIGLX is eigentlich wenig bekannt und ich denke, dass man den weissen Würfel, der bei mir auftrat, relativ einfach wegbekommt. Bestätigen kann ich das im Moment aber nicht.

Deshalb empfehle ich – wenn man eine Nvidia-Karte besitzt und schnell zum Erfolg kommen möchte – den Einsatz von Beryl zusammen mit den aktuellen Nvidia-Treibern
(für Treiber siehe http://www.nvidia.de/page/drivers.html).

Zur Konfiguration von X11 für den Einsatz der Nvidia-Treiber und Beryl siehe einen nachfolgenden Beitrag.