2 Defizite von Konqueror (KDE 3.5.8)

Posted on by

Wenn man täglich mit Webseiten-Entwicklung zu tun hat, bleibt es nicht aus, dass man über Fehler in diversen Browsern stolpert.

Ärgerlich finde ich Bugs, die entstanden sind und auch nicht entdeckt wurden, weil die Entwickler/Tester nur den Normalfall betrachtet haben. Zwei schöne Beispiele liefert hier der Konqueror in seiner Rolle als Web-Browser.

Bug 1: Nur teilweise Darstellung von Bildern, wenn Webseiten geladen werden, nachdem (!) der Browser auf einen Zoomfaktor > 1 eingestellt wurde

Konqueror behandelt Bilder, deren Größe mit “em”-Vorgaben festgelegt sind, solange richtig, wie man die entsprechenden Webseiten bei normaler Schriftgröße lädt. Selbst eine nachfolgende Vergrößerung der Schriften bzw. des Browser-Bildes über “Ctrl +” (bzw. Strg +) skaliert die Bilder im erwarteten Maße. Lädt man jedoch Webseiten mit Bildern (deren größe mit “em” definiert wurde) bei bereits eingestelltem Zoomfaktor >1 (z.B. 1.5 durch zweimalige Anwendung von CTRL +), so werden die Bilder nur abgeschnitten dargestellt. Der Browser vergisst, Bildbereiche zu rendern, die über die Bildgröße hinausgehen, die bei einem Zoomfaktor von 1.0 gültig wären.

Meine Meinung: Hier wurde unzureichend getestet.

Bug 2: Properties von Iframes werden beim Laden einer Seite zu spät für Scripts bereitgestellt

Tritt im Zuge des Ladens einer Webseite das sog. “onLoad” – Ereignis auf, so sollten zu diesem Zeitpunkt alle Webseiteninhalte fertig aus dem Netz geladen sein und im Browser alle relevanten Informationen zu den geladenen Objekten zur Verfügung stehen. Eine solche Eigenschaft ist die (Gecko-spezifische) Eigenschaft “innerWidth” von “window”- oder “(i)frame”-Objekten. Firefox und Opera stellen diese Eigenschaft auch bereit, wenn das Onload-Ereignis eintritt. Nicht dagegen Konqueror – er liefert zwar “genauere” Daten als die anderen Browser, da er auch die breite von evtl. auftreteden Scrollbars der “(i)frames” berücksichtigt. Diese Daten stehen u.U. aber erst zeitverzögert nach dem Eintreten des “onLoad”-Ereignisses für die Verarbeitung in Javascript-Programmen zur Verfügung.

Meine Meinung: Ich weiß nicht, wie oft man “innerWidth” beim onLoad-Ereignis in der Praxis benötigt. Ich meine aber, dass die Vorgehensweise beim Konqueror die Verletzung einer natürlichen Erwartungshaltung an die Verfügbarkeit zu Seitenelementen billigend in Kauf nimmt. Der Sinn des onLoad-Ereignisses ist in gewisser Weise in Frage gestellt, wenn Objektinformationen erst nach diesem Zeitpunkt bereitgestellt werden. Der Bug riecht förmlich nach einem konzeptionellen Fehler bei der Behandlung von Iframes.

Compiz: Fehler mit Nvidia Treiber x86_64_169

Posted on by

Compiz Fusion und Fehler mit Nvidia treiber x86_64_169

Beim Einsatz dieses Treibers kann es je nach Grafikkarte unter Opensuse 10.3 passieren, dass ein Starten von Compiz über das das Compiz-Fusion-Icon dazu führt, dass die Fensterrahmen (window decoration) nicht angezeigt werden.

Dies geschieht ggf. auch dann, wenn alle notwendige Einträge im xorg.conf File vorhanden sind.

Hier helfen:

1) Beibehalten des Nvidia-Treibers -> Starte Compiz über eine Konsole mit “compiz-manager &” . Hier werden dann offenbar sinnvolle Parameter beim Start gewählt, die mit dem Treiber kompatibel sind.
2) Downgrade des Treibers.

Der 169-Treiber ist dennoch interessant. Er erlaubt nämlich eine viel bessere Synchronisierung der OpenGL-Darstellung mit der Vertikalfrequenz des Monitors (Einstellung im Compiz Einstellungsmananger unter dem Punkt “Allgemein”). Dies beseitigt das bemerkenswerte und üble Tearing der Kanten von “wobbling windows”, das mit Compiz-Fusion Einzug gehalten hat.

Es bleibt zu hoffen, dass demnächst ein besseres Treiber erscheint.

Smb4K zerstört /etc/sudoers Datei

Posted on by

Es ist mir nun schon mehrfach passiert, dass bei der  Ersteinrichtung von smb4k ein kleines Unglück passiert:

Beim Einrichten des Zugriffsverfahren  (Einrichten -> Administrator) wird bei der Wahl von sudo das /etc/sudoers File editiert. Aus irgendeinem Grund geht dies ab und zu schief und die Formatierung der Datei wird zerstört.

Der korrekte Zeilenaufbau dieser Datei ist aber essentiell. Werden z.B. Zeilenumbrüche an der falschen Stelle gesetzt, funktioniert danach unter KDE “kdesu” nicht mehr.

Weder smb4k läuft danach, noch yast2, etc. – im Grunde funktioniert nichts mehr , bei dem kdesu vorgeschaltet wird. kdesu liest die Einstellungen in /etc/sudoers aus und stößt dabei auf Fehler.  Dies resultiert unter KDE dann in einer Meldung vom Typ “su meldet Fehler”.

Testen kann man das sehr einfach, indem man das Kommando “visudo” als root verwendet. Man nehme eine kleine Änderung vor und speichere das Ergebnis ab. Die resultierenden Fehlermeldungen zeigen i.d.R., was geändert werden muss.

Zusätzlich gilt, dass folgende Einträge  vorhanden sein sollten :

——-

Defaults targetpw   # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL   # WARNING! Only use this together with ‘Defaults targetpw’!

# Runas alias specification

# User privilege specification
root    ALL=(ALL) SETENV: ALL

# Uncomment to allow people in group wheel to run all commands
# and set environment variables.
# %wheel    ALL=(ALL) SETENV: ALL

# Same thing without a password
# %wheel    ALL=(ALL) NOPASSWD: SETENV: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now

# Entries for Smb4K users.
# Generated by Smb4K. Please do not modify!
User_Alias    SMB4KUSERS = userx

Defaults:SMB4KUSERS    env_keep=”PASSWD USER”
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_kill
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_umount
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_mount
# End of Smb4K user entries.
—-

“host” ist durch den lokalen Rechnernamen zu ersetzen

“userx” ist durch den User zu ersetzen, der/die smb4k benutzen darf. Hier kann auch eine komma-separierte Liste von Usernamen angegeben werden.

Ob root auch smb4k benutzen sollte, ist aus Sicherheitsgründen sehr diskutabel. Ich vermeide das.

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.