Author Archives: Ralph Mönchmeyer

OX5 – Login User “openexchange” per psql?

Posted on by

Open-Xchange – Login des Datenbankusers “openexchange” mittels psql?

Heute wurde ich von einem User gefragt, wieso er sich auf einem OX 5 Server nicht direkt als Datenbankuser “openexchange” auf der Postgres-Datenbank mit Hilfe von “psql” einloggen könne.

Dies ist zunächst etwas überraschend, weil in jeder Installationsanleitung zum OX-Server erwähnt wird, dass im Rahmen der Installation unter Postgres die Standarddatenbank “openexchange” angelegt und dem Owner “openexchange” zugeordnet wird.

Die OX 5 Installation war im Fall des Kollegen allerdings über eine SLOX Migration auf einen SLES 9 Server durchgeführt worden. Ein Blick in die hinterlassenen Konfigurationsdateien lohnt sich für ein tiefergehendes Verständnis der Berechtigungsmechanismen, mit denen die OX-Prozesse mit der Datenbank interagieren. Schreiten wir also zur Tat:

Zunächst klären wir die Verhältnisse auf der Postgres-Datenbank. Ein kurzer Blick als Datenbank-Superuser “postgres” mittels

oxserver:~ # su postgres
oxserver:~ # psql openexchange

openexchange-> \du
List of database users
User name | User ID | Attributes
————–+———+—————————-
openexchange | 100 |
postgres | 1 | superuser, create database
(2 rows)

openexchange-> \l
List of databases
Name | Owner | Encoding
————–+————–+———–
openexchange | openexchange | UNICODE
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
(3 rows)

zeigt, dass der Datenbankuser “openexchange” wirklich der Owner der Datenbank “openexchange” ist. Versuchte man allerdings, sich als Datenbankuser “openexchange” mit der Datenbank zu verbinden, so erhielt man folgende Meldung:

oxserver:~ # psql -U openexchange
psql: FATAL: »IDENT«-Authentifizierung für Benutzer »openexchange« fehlgeschlagen

Dies entspricht dem Befund des Kollegen:
Mittels des Datenbankusers “openexchange” führt kein Weg per “psql” in die Datenbank “openexchange”. Noch mehr wundert man sich, wenn man kontrolliert, wie die OX Server bzgl. des Zugriffs auf die Datenbank konfiguriert ist:
Hierzu öffnet man die Datei “/opt/openexchange/etc/groupware/server.conf” und verifiziert folgende Einträge:

# Database Connection Parameter
NAS_CON_CLASS_NAME: jdbc:postgresql://localhost/openexchange
NAS_CON_USER: openexchange
NAS_CON_PASS: “Your_Password”
NAS_CON_DRIVER: org.postgresql.Driver

Auch hier erkennt man, dass es tatsächlich der User “openexchange” ist, der vom OX-System für den Datenbankzugriff verwendet wird. Und aus der tägliche Praxis weiß man, dass man ja auf dem OX-Server erfolgreich arbeiten kann. Wieso also gelingt der direkte Zugriff mittels psql unter Verwendung des Users “openexchange” nicht?

Des Rätsels Lösung liegt in einer Einstellung, die der OX-Installer beim Einrichten des OX-Servers aus Sicherheitsgründen vornimmt:
Ausschlaggebend für die Verbindungsmöglichkeiten zu einem Postgres-Datenbankserver sind u.a. die Einstellungen in der Datei “pg_hba.conf”. Diese findet man je nach Installation unter “/usr/local/pgsql/data/” oder nach der SLOX -> SLES 9 Migration im Verzeichnis “/var/lob/pgsql/data”. Typisch ist dort etwa der Eintrag

#modified by oxinstaller
#local openexchange openexchange trust
host all all 127.0.0.1 255.255.255.255 password
host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff password
local all all ident sameuser

Hierdurch erklärt sich endlich der Befund: Der erste Eintrag, der mit “local” beginnt, ist auskommentiert! Dieser Eintrag würde es allerdings jedem User, der über einen Account auf dem Server mit der Postgres-Datenbank verfügt und vorgibt, der Datenbankuser “openexchange” zu sein, erlauben, sich auf die Datenbank einzuloggen (psql -U
openexchange). Ausprobieren kann man dies, indem man den Eintrag aktiviert, postgres neu startet (rcpostgres restart) und dann den genannten psql-Befehl (erfolgreich!) absetzt.

Ein solches Systemverhalten will in der Regel aber eigentlich niemand riskieren, und deshalb ist es gut, dass der Eintrag auskommentiert ist! Diesen Zustand sollte man also wieder herbeiführen.

Der zweite und der dritte Eintrag sorgen dafür, dass Programme sich lokal, aber im Sinne einer IPV4 bzw. IPV6 Verbindung auf die Datenbank einlogen können. Hierfür muss nun jedoch das Passwort für den Datenbankuser “openexchange” bekannt sein. Als User root oder postgres kann man den Zugang über das Loopback-Device nun dadurch überprüfen, dass man folgenden Befehl an der Konsole eingibt:

oxsserver:~ # psql -h 127.0.0.1 openexchange -U openexchange
Password:
Welcome to psql 7.4.17, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

openexchange=>

Hierdurch erklärt sich übrigens, warum die Programme des OX-Servers mit den Einstellungen in der Datei “/opt/openexchange/etc/groupware/server.conf” erfolgreich ihre Arbeit in der Datenbank verrichten können. (Sicherheitshinweis: Gestandene Postgres-Administratoren sollten allerdings auf die Nichtverschlüsselung des Passwortes in der Datenbank ein wenig allergisch reagieren und dieses Defizit beheben. Näheres findet man in den Postgres Manuals. )

Der allerletzte Eintrag ließe einen Login auf die Bank zu, wenn man als Datenbankbenutzer den gleichen Namen aufweist wie als Betriebssystembenutzer. Dies ist zwar für Postgres der Fall, nicht aber für den Datenbankuser “openexchange”: Ein entsprechender User-Account ist aus Sicherheitsgründen gar nicht angelegt.

Keiner der aktiven Einträge lässt also einen direkten Zugriff auf die Datenbank zu. Der zweite Eintrag verlangt den Umweg über das Loopback-Device, den die OX-Programme offenbar nehmen. Der dritte Eintrag führt jedoch zur oben erwähnten Fehlermeldung.

Nachdem wir das Verhalten nun verstehen, geben wir uns damit zufrieden, dass wir zu Verwaltungs- oder Recherchezwecken ja immer noch über den Datenbankuser “postgres” aktiv werden können, wenn einem die OX-Oberfläche nicht genug Möglichkeiten bietet. Zudem könnte man sich einen weiteren Datenbankuser für seine spezifischen Zwecke einrichten oder einrichten lassen – für Recherchezwecke etwa nur mit lesendem Zugriff.

————————–
Sicherheitshinweis:
————————–
Findet man in der Datei “/opt/openexchange/etc/groupware/server.conf” übrigens den Eintrag

NAS_CON_PASS: “secret”

so hat man die Migrationsanleitung vermutlich zu wörtlich genommen und wie dort angegeben das Passwort “secret” für den DB-User “openexchange” bei der ursprünglichen OX-Installatiion auf dem SLES Server angegeben. Da man hierdurch ein potentielles Sicherheitsproblem heraufbeschworen hat, sollte man das Passwort für “openexchange” umgehend ändern. Hierzu verbindet man sich mit der Datenbank (z.B. als Superuser “postgres”) und benutzt am psql-Prompt den Befehl

> ALTER USER openexchange WITH PASSWORD ‘new-password’

um das Password abzuändern. natürlich ist new_password durch das neue gewählte Passwort zu ersetzen. Danach korrigiert man auch den Parameter NAS_CON_PASS in der Datei “/opt/openexchange/etc/groupware/server.conf” entsprechend ab:

NAS_CON_PASS: “new_password”.

VMware Workstation und Kernel-Updates

Posted on by

Kernel-Updates werden immer wieder von den jeweiligen Distributoren angeboten. Gründe sind die laufende Fehlerbehebung und natürlich das Schließen erkannter Sicherheitslücken.

In einem Linux-System bedeutet ein Kernel-Update einen Eingriff, der im Nachhinein Anpassungsarbeiten am System erforderlich machen kann. Betroffen sind u.a. (Treiber-) Module, die nicht mit den Kernelbibliotheken der Distribution mitgeliefert wurden und werden, sondern von externer Quelle stammen und für den vorherigen Kernel kompiliert wurden. In den meisten Fällen ist eine Neukompilation dieser Programme unumgänglich. Das gilt im Besonderen für Grafikartentreiber (z.B. von Nvidia) und eben auch für VMware und seine Module.

Im Falle von VMware ist das Vorgehen zur Neukompilation heute allerdings sehr einfach und unproblematisch:

1) Nach dem (obligatorischen) Reboot des Systems stoppt man zur Sicherheit zunächst die laufenden VMmware-Prozesse, die im Zuge der Systeminitialisierung über das Skript “vmware” in /etc/init.d automatisch gestartet wurden. Als root gibt man hierzu einfach “vmware stop” am Prompt seiner Konsole ein.

2) Dann startet man das Skript “vmware-config.pl” (i.d.R. zu finden in “/usr/bin” ) . Das Skript fragt einen der Reihe nach die Einstellungen ab, die bereits während der Erstinstallation festgelegt werden mussten, und führt auch eine Neukompilation der benötigten Module durch. Die meisten Einstellungen – u.a zum Netzwerk – kann man dabei bequemerweise auf dem bereits definierten Stand belassen, indem man die zugehörigen Nachfragen entsprechend beantwortet.

3) Im Normalfall startet das Skript abschließend die erforderlichen VMware-Prozesse neu. Geschieht dies nicht automatisch, so bedient man sich wieder des “/etc/init.d/vmware”-Skripts.

Es ist extrem selten, dass die Neukompilation zu anderen Problemen führt, als die die man bereits während der Erstinstallation durchlaufen hat. Mir ist es allerdings schon passiert, dass SuSE einmal nicht den passenden Source Code zum vorkompilierten Kernel ausgeliefert hatte. Für die Problemanalyse gibt es in der Regel kein Patentrezept. Man muss sich eben auf die Meldungen des Compilers seinen Reim machen.

Flash – Redraw/Reload-Verhalten von Browsern

Posted on by

So schöne Dinge man mit Flash machen kann: Beim Einsatz ist immer wieder Vorsicht geboten!

Wir haben z.T. sehr schlechte Erfahrungen mit dem Verhalten verschiedener Browser gemacht, wenn es darum geht, zwischen Seiten mit praktisch identischem Layout zu wechseln. Da in einem solchen Szenario viele Objekte im Browser gecached werden können, hofft man bei solchen Seiten auf einen sanften Übergang – also ohne viel Flackern beim Rendern der neuen Seite. Objekte die beim Seitenwechsel statisch bleiben, sollen auch im Browser statisch erscheinen.

Wichtig wird dies dann, wenn man auf einer Firmenseite viele einzelne Seiten hat, die im Hintergrund und in anderen Bereichen praktisch gleich aussehen. Hier möchte man als Betrachter einen ruhigen Wechsel ohne störende Reloads und ohne Neuzeichnen des Hintergrunds bzw. der statisch bleibenden Seitenelemente erleben. Nur veränderte Inhaltsbereiche sollen sich bei Rendern visuell sichtbar ändern.

Gerade dann, wenn die HTML-Seiten Flash-Objekte beinhalten, wird diese Erwartungshaltung an eine flackerfreies Browserverhalten aber oft genug nicht erfüllt. Im Gegenteil beeinträchtigt z.T. deutliches und wirklich störendes Flackern den Seitenaufbau. Zumal man hierfür als Betrachter keinen Grund erkennen kann und dies von Seiten ohne Flash-Inhalt auch nicht gewohnt ist.

Wir haben das “Redraw”-Verhalten von verschiedenen Browsern unter Linux und Windows ein wenig getestet. Hier unser Ergebnis, das wir auch an die Entwickler von Opera und Firefox weitergeleitet haben.

Unter Linux muss man feststellen, dass die von uns verwendeten Browser “Konqueror Firefox und Opera” generell den Bereich des Flashobjektes beim Wechsel zwischen nahezu gleichen Seiten neu zeichnen.

U.U. werden aber auch andere Objekte neu gerendert bzw. nachgeladen – gerade Firefox spielt hierbei eine unrühmliche Rolle! Dieser Browser zeichnet generell Layer (DIVs und ihren Inhalt) sowie Images neu, sobald die Seiten auch nur ein einziges (identisches) Flash-Objekt beinhaltet. Auch wenn sämtliche Elemente der Seiten gecached wurden. man muß allerdings festhalten: Das geschieht ausschließlich beim Wechsel zwischen Seiten, die Flashobjekte beinhalten. Hier kommt es – selbst bei 99% identischem Layout – zu deutlichen sichtbaren Beeinträchtigungen beim Bildaufbau. Interessanterweise zeigt die Windows-Version von Firefox dieses Verhalten nicht !

Dass es unter Linux auch viel besser geht, zeigen dagegen Konqueror und Opera. Beide Browser zeichnen nur den Flashbereich neu, wenn der Inhalt der Seiten zwischen denen gewechselt wird, praktisch identisch ist.

Überraschenderweise bietet Opera unter Windows das schlechteste Verhalten an. Hier wird alles neu gezeichnet, sogar der Hintergrund (bzw. die Hintergrundsfarbe) einer Seite. Resultat ist ein massives Flackern beim Seitenaufbau, da immer auch die Standardfarbe des Hintergrunds – nämlich Weiß – kurz sichtbar wird. Damit wird ein Wechsel zwischen Seiten mit einer Mischung aus HTML- und Flash-Content zu einem Erlebnis der besonderen, wenn auch negativen Art.

Das beste Verhalten bei unseren Tests zeigte der IE 7 unter MS Windows – allerdings auch nur, wenn die Seiten keinen komplizierten Layeraufbau mit vertikaler Schichtung aufwiesen. Mit vertikal geschichteten Layern kann der IE unserer Erfahrung nach beim Seitenwechsel insgesamt nur schlecht umgehen – im Gegensatz zu Firefox (solange kein Flash im Spiel ist).

Entfernt man die Flashinhalte aus Testseiten, so reduzieren sich die Flackereffekte, die mit dem Rendervorgang beim Seitenwechsel auftraten, sehr deutlich. Daraus ist zu schließen, dass das Zusammenspiel zwischen Flash-Plugin und der jeweiligen Browser-Engine in den betrachteten Browser-Varianten unterschiedlich gelöst wurde.

Deutliches Verbesserungspotential besteht unserer Meinung nach beim Firefox (Linux) und Opera (Windows).

Mehr und detailliertere Informationen sowie ein Testszenario findet man im Anhang (s.
nachfolgender Link).

Test zum Redraw Verhalten von Browsern beim Wechsel zwischen Seiten mit Flash-Content

Testdateien bitte per Mail vom Verfasse anfordern!

OX5 – Login Problem mit Konqueror – Nachtrag II

Posted on by

Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.

VMware und Athlon Dual Core Prozessor – Tipp 1

Posted on by

VMware und Athlon Dual Core Prozessoren – Teil 1: Nutze nur einen (virtuellen) Prozessor !

Ich gebe hier meine Erfahrungen mit der Installation von VMware (Workstation Versionen 5 und 6) auf einem Athlon X2 4800+ Prozessor unter Linux (Opensuse) wieder. Linux ist dabei also das sog. VMware “Host”-System”. Als “Gast-System” kam Windows XP SP2 zum Einsatz.

Wenn man eine virtuelle Maschine unter VMware aufsetzt, hat man auf einem Host-System mit einem Dual Core Prozessor die Möglichkeit, dem Gast-System 1 oder 2 (virtuelle) Prozessoren zuzuordnen. Nach etlichen Versuchen mit der Auswahl von 2 (virtuellen) Prozessoren bleibt festzuhalten:

Finger weg von einem Setup mit 2 virtuellen Prozessoren!

Hierfür gibt es vor allem zwei Gründe:

1. Unnötig verschlechterte Perfomance des Gesamtsystems durch Verwaltungsoverhead
Vor allem die Performance des Hostsystems leidet bei einem solchen Setup. Wie man diversen Beiträgen im Workstation-Forum von VMware entnehmen kann, wird das System mit den Verwaltungsaufgaben zur

  • Verteilung der Gastsystemlast zwischen den virtuellen Prozessoren und
  • der resultierenden Verteilung der Host-System-Last auf die 2 realen Prozessorkerne

insgesamt über Gebühr belastet. (Das wirkt sich natürlich dann auch auf die Performance des Gastsystem aus.)

In meinem Fall drängte sich oftmals der Eindruck auf, dass das System deutlich mehr mit der Auflösung der Anforderungen aus der Lastverteilung – also mit sich selbst – beschäftigt war als mit dem Abarbeiten von Applikationsanforderungen im Gast- oder Hostsystem.

Ich habe z.T. eine durchschnittliche Auslastung von 50% im Host-System gesehen, die durch Systemprozesse verursacht wurde, während sowohl im Windows-Gastsystem als auch unter Linux die Auslastung durch Userprozesse kleiner als 10% war. Die Aufgabe der Abstimmung von Lastverteilungsanforderungen zwischen Gastsystem und Hostsystem ist nach meinem Eindruck (noch) nicht optimal gelöst. Manchmal konnte ich ein fast zyklisches Hin- und Herschaufeln der Last zwischen beiden Prozessorkernen beobachten. Es war so, als ob eine Entscheidung des Gastsystems zur Lastumverteilung eine gegenteilige Reaktion des Hostsystems und diese dann wiederum die umgekehrte Reaktion im Gastsystem hervorrief. Ein solche Interpretation würde die beobachtete permanente (und völlig überflüssige) zyklische Lastumverteilung zumindest im Ansatz erklären.

VMware selbst rät übrigens wegen der Gefahr einer verschlechterten Gesamtperformance von einem Setup des Gastsystems mit 2 (virtuellen) Prozessoren ab. Der übliche Kommentar ist, dass dies nur auf größeren als Quadcore-Systemen sinnvoll sei.

Verschärft wird das ganze ggf. auch noch durch Bedingungen, wie Sie nachfolgend beschrieben werden.

2. Taktung und Schwierigkeiten mit der Synchronisation der Prozessorcores
Nach einigen Recherchen im Internet kommt man zu dem Schluss, dass bestimmte frühe Baureihen des AMD X2 Prozessors das Manko aufweisen, dass die Cores unabhängig voneinander getaktet wurden. Jeder Core hat(te) sozusagen seinen eigenen Zeitgeber. Applikationen, die die CPU-Zyklen der Cores abfragen, haben damit erhebliche Schwierigkeiten, wenn das Betriebssystem zwischenzeitlich die Last zwischen den Cores umverteilt: die Applikation erhält dann ggf. eine andere Antwort zum Zyklus, als sie erhalten hätte, wenn die Applikation auf dem ursprünglichen Core verblieben wäre.

Bei den ersten 5er-Versionen der Workstation hatte ich den Eindruck, dass dies der Grund für Instabilitäten im Gastsystem war, wenn man VMware linuxseitig nicht genau einem – und zwar dauerhaft ein und demselben – Prozessorkern zuordnete. Die Einschränkung, VMware dauerhaft einem Prozessorkern zuzuweisen, gilt heute nach meiner Erfahrung jedoch nicht mehr.

Fazit: Man sollte dem (virtuellen) Gastsystem im Setup
genau eine (virtuelle) CPU zuweisen.

In einem weiteren Beitrag werde ich darstellen, wie man die Frequenz der CPU ermittelt und im VMware-Setup der virtuellen Maschine als feste Größe verankert. Damit lassen sich Probleme umgehen, die die vmware-seitige eigenständige Frequenzbestimmung hervorrufen kann. Bei der Gelegenheit werde ich auch erläutern, wie man VMware bei Bedarf genau einem Prozessorkern zuweist.