Daily Archives: 22. September 2007


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.