OX5 – Login Problem mit Konqueror – Nachtrag 1

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

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.