How to reproduce this error: Use phpgroupware 0.9.16.000, her with PHP 4.2.3; register_globals = on for all apps except notes, projects, qmailldap, stocks, todo.

  1. Install phpGroupWare correctly, including the apps
  2. Point your browser to /setup below your phpGroupware Installation URL
  3. Choose “Click here to setup an admin account and (optionally) 3 demo accounts.*” Then only setup the admin account. This is how to recover from the phpgw crash (step 6), too.
  4. Login as admin user into phpgw and choose “Preferences > Change Your Settings > Your Preferences”. Or, choose “… > Default Preferences > Your Preferences”.
  5. Choose these Options and then “Save”: Language: German and Show number of current users: Yes
  6. Now, phpGroupWare outputs approx some 100 kB of error messages. This is reproducible for me. See below for the kind of error messages I get, all the time jumping between lines 208, 209, 210 in the specified script.
  7. Workaround: use a Forced Preference for language or number of current user information that prohibits the above mentioned combination of settings to be done by your users.

Here are the error messages that are generated:

Warning: fopen("/tmp/sess_66bb6b04ba1ddd84eec30c9665360181", "r") - Permission denied in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 208
Warning: fread(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 209
Warning: fclose(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 210
Warning: fopen("/tmp/sess_e46ac33657b1d69993c7fc104a9cf71a", "r") - Permission denied in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 208
Warning: fread(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 209
Warning: fclose(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 2101.
Install phpGroupWare correctly, including the apps

And now, something about the same error when installing.

Problematisch ist: in der Konfiguration von PHP4 (php.ini an unbekanntem Ort) steht session.save_path = /tmp . Das gilt für alle User. Der Webserver läuft aus der Sicht jedes Users unter seinem eigenen Benutzernamen, etwa p3002017. Es ist nun möglich, dass phpGroupWare-Installationen verschiedener Benutzer in /tmp Session-Dateien mit gleichem Namen anlegen, also einander überschreiben. Sie beginnen mit sess_ und haben danach eine lange hexadezimale Zeichenkette. Wenn dies ein Hashwert ist, könnte es das Überschreiben erklären. Somit werden Session-Dateien also ungültig. Erkennbar ist das daran, dass sie für den eigenen Benutzer nicht mehr lesbar ist und phpGroupWare etwa folgende Meldungen ausgibt:

Warning: fopen("/tmp/sess_dc4886a4eec5f", "r") - Permission denied 
in /somepath/phpgwapi/inc/class.sessions_php4.inc.php 
on line 208

Diese Problemanalyse wird dadurch bestätigt, dass die Fehlermeldungen in phpGroupWare verschwinden, wenn man einen neuen Benutzer anlegt und sich als solcher einloggt: klar, denn es wurden neue Session-Dateien angelegt statt dass alte gesucht wurden, und es ist sehr unwahrscheinlich, dass die neuen Dateien bereits von anderen phpGroupWare-Installationen überschrieben wurden. Das Prefix sess_ wird von phpGroupWare generiert, so dass nur phpGroupWare-Installationen miteinander im Konflikt stehen. Das Problem tritt selten auf, wenn die Server wenig genutzt werden, z.B. nachts. Es ist möglich, dieses Problem durch eine eigene php.ini zu beheben. Man lege sie ins Webserver-Rootverzeichnis der Domain oder Subdomain. Sie enthalte den vollständigen Pfad zum persönlichen tmp-Verzeichnis (mit entspr. Zugriffsrechten). Beispielinhalt:

session.save_path = /somepath/mytmpdir

Das Problem wird nicht gelöst, indem man Einstellungen in »Admin :: Site configuration :: Use cookies to pass sessionid:« und »Admin :: Site configuration :: check ip address of all sessions:« macht.

Eine weitere Möglichkeit sind evtl. Einstellungen in der .htaccess wie beschrieben in phpGroupware Mailingliste, 2003-09, Nachricht 241.

Dort steht auch ein möglicher Grund des Folgeproblems »Your session could not be verified.«: Cookies werden neben phpGroupWare noch von sitemgr verwaltet und abgelegt in /tmp wie bisher. Das muss noch umgestellt werden.

Tatsächlich wird auch nach Umstellung des /tmp-Verzeichnisses sowohl dort als auch am neuen Ort eine sess_-Datei zur aktuellen Session angelegt. Die session-ID der aktuellen Session kann man im Source-Code der HTML-Seite nach dem Einloggen nachlesen.

Aber: das Problem mit nicht lesbaren sess_*-Dateien tritt nur auf (dann aber für alle Benutzer) wenn man als Admin die Default-Preferences (oder einen bestimmten Teil davon) ändert. Und zwar tritt es dann unabhängig von der Serverbenutzung auf. Bisher hilft dann nur, im Setup-Bereich alle Benutzer zu löschen und einen neuen Admin-Benutzer anzulegen. Löschen der Cookies hilft nur, um zum Login-Screen zu gelangen wenn man nur den Domain-Namen eingibt.

Dies ist z.B. praktisch, um auf effiziente Art einen Upload seiner persönlichen Homepage durchzuführen (wenn diese auch statischen HTML-Inhalten besteht die man lokal editiert).

Lösung: man verwendet das folgende Kommando:

find . -newer .lastupload 
  -path './path-to-local-website-copy/*' | 
  xargs -i 
  ncftpput -u username -p password -R example.com 
  /path-on-ftp-server {} 
  && touch .lastupload

Dabei bedeuten:

  • -path './path-to-local-website-copy/*': Pfade, in dem die Dateien auf dem lokalen System liegen dürfen.
  • -newer .lastupload .lastupload ist der Name einer Datei, deren Modifikationszeit die Zeit des letzten Uploads ist. Alle neueren Dateien sind also jetzt upzuloaden.

Um nur einige wenige Dateien per Hand hochzuladen (wobei lokalen Dateien / Verzeichnisse ohne Wildcards angegeben werden können):

ncftpput -u username -p password -R example.com 
  /path-on-ftp-server localfiles-1* localfiles-2*

Die volle Fehlermeldung nochmal:

Xlib: connection to ":0.0" refused by server
Xlib: invalid MIT-MAGIC-COOKIE-1 key
xhost: unable to open display ":0.0"

Seit neuem kann nur der Benutzer xhost + ausführen, der die gerade laufende X-Session gestartet hat. Es funktioniert also nicht, als root xhost + in einem xterm ausführen zu wollen, wenn die gerade laufende X-session vom user matthias gestartet wurde. Damit wird verhindert, dass jeder Benutzer sich Zugang zu einem X-Display eines beliebigen anderen Benutzers verschaffen kann.

Symptome: Wenn man versuche, in Netscape eine mit wwwoffle gespeicherte Seite aufzurufen, die ein cgi-Script mit Parametern ist, während man offline ist, so sagt wwwoffle, dass diese Seite zum Download vorgemerkt sei (obwohl das Anzeigen dieser Seiten mit konqueror möglich ist). Dies ist ebenfalls der Fall, wenn in der gewählten Seite eine zu ladende Referenz mit Parametern vorkommt (z.B. zu AudioMedien). Anschließend kann in Netscape keine einzige Seite mehr eingeladen werden, weder aus dem Internet noch vom lokalen System. Der Neustart von Netscape ist unmöglich: es wird keine Fehlermeldung angezeigt, es erscheint kein Fenster.

Workaround: nach dem Neustart von X kann Netscape zumindest wieder gestartet werden. Eine vollständige Problemlösung steht noch aus.

Notebook in POS-Modus verwenden, PCMCIA-Karte einstecken, Notebook aufwecken. Jetzt ist der Link richtig gesetzt worden: /dev/modem -> /dev/ttyS2. Das Modem sollte jetzt ohne weitere Einstellungen funktionieren. Das modem kann durch den Befehl /etc/init.d/slmdm restart (für das SLMDM-Winmodem eines Gericom Webboy) wieder auf das interne Modem umgestellt werden.

Wenn das benötigte Trident-Kernelmodul /lib/modules/2.4.7/kernel/drivers/sound/trident.o nicht existiert, muss es zuerst in den Kernel als Modul einkompiliert werden: cd /usr/src/linux; make menuconfig; nun das trident-Modul aufnehmen; make modules modules_install. Die Verwendung des ALSA-Soundtreibers ist nur mit dem von SuSE veränderten Kernel 2.4.4-4GB möglich, daher empfiehlt sich im Hinblick auf spätere Kernel-Updates die Verwendung des trident-Kernelmoduls. Dazu muss das ALSA-Soundsystem aus der Datei /etc/modules.conf rauskommentiert werden, sofern es bereits einmal aktiviert war. Stattdessen ändert man die Zeile “alias char-major-14 off” in “alias char-major-14 trident“.

Verwendung des ALSA-Treibers: Die Konfiguration des im Notebook vorhandenen Soundchips SiS 630 mit YaST2 scheitert (entweder wird per PnP nicht erkannt, oder »Carddatabase not faound, please check your installation.«). Man verwende also das textbasierte alsaconf. Vorher unbedingt den kernelbasierten Soundtreiber entladen (rmmod trident), sonst kann natürlich ALSA die Soundkarte nicht belegen (alsasound gibt aber auch keine richtige Fehlerausgabe zurück, nur der Testsound funktioniert dann nicht und auch sonst keine auf ALSA basierenden Programme wie noteedit). Ansonsten löst alsasound die Aufgabe richtig, wenn man die Soundkarte SiS 630 auswählt.

Wie kann man nun erreichen, dass ALSA beim Systemstart automatisch geladen wird? Das wurde schon automatisch von alsaconf in /etc/modules.conf eingerichtet.

Bedienung von ALSA

  • Die Mixereinstellungen werden in /etc/asound.conf gespeichert und bei jedem Start von ALSA wiederverwendet und bei jeder Beendigung von ALSA werden die aktuellen Mixereinstellungen dorthin gespeichert.
  • ALSA kann manuell mit rcalsasound start gestartet, und mit rcalsasound stop gestoppt werden (z.B. um das den trident-Kerneltreiber wieder zu laden).
  • Mixer für ALSA: alsamixer für Textmodus, gamix für Grafikmodus.
  • ansonsten können alle Soundprogramme wie bisher verwendet werden. Bei timidity gibt man dazu z.B. an: timidity -Os *.mid, um auf ALSA PCM-Device auszugeben.

Dazu muss eine Soundausgabe von ALSA auf den MIDI-Devices erreicht werden. Gelistet werden sowohl in kmid als auch in noteedit folgende Devices:

  • External MIDI 0 MIDI 0-0
  • SiS 7018 SiS 7018 port 0
  • SiS 7018 SiS 7018 port 1
  • SiS 7018 SiS 7018 port 2
  • SiS 7018 SiS 7018 port 3

In kmid wird parallel auf Konsole ausgegeben, dass all diese Devices geöffnet und initialisiert wurden. Allein, es wird kein Sound gespielt. Eine Änderung der Lautstärke in kmid scheint korrekt zu funktionieren, denn es wird auf der Konsole jeweils »Position reached!« ausgegeben. Es liegt nicht daran, dass keine Lautstärke eingestellt ist (vgl. z.B. die Ausgabe von amix für Kanal »Music«). Da sonst wirklich alles fuktioniert, scheint es eher so, als sei in diesem Notebook nicht nur die MIDI-Schnittstelle nicht eingebaut, sondern auch die interne MIDI-Synthese zumindest nicht mit der Lautsprecher-Ausgabe verbunden worden. Sie ist als Device vorhanden, läuft sich aber irgendwie tot. So als habe das Notebook gar keine MIDI-Unterstützung. Zwar sagt noteedit beim Start »TSE3 ALSA MIDI Scheduler created«, aber dieses Gerät kann hardwaremäßig gar keinen Sound ausgeben!

Den Symptomen nach (erkannte MIDI-Devices, Abspielen funktioniert, nur der Sound fehlt; Abspielen unter Windows funktioniert) besteht das Problem darin, dass die interne MIDI-Synthese der SiS 7018 mit Wavetable funktioniert und deshalb zuerst ein Soundfont geladen werden muss. Wie geschieht das? Bei normaler AWE32/64-Synthese verwendet man dazu sfxtest und sfxload. Der Treiber für normale AWE32/64-Synthese funktioniert nach /usr/src/linux/Documentation/sound/AWE32 aber nur mit ORIGINAL SoundBlaster-Wavetable-Soundkarten.

Das Device zur Wiedergabe durch interne MIDI-Synthese ist /dev/music (noch zu überprüfen).

General MIDI Sound font: http://members.xoom.com/yar/synthgm.sbk.gz . Einträge am Ende von /etc/modules.conf zur Verqwendung von AWE32/64:

alias sound-slot-0 sb alias sound-service-0-1 awe_wave
post-install awe_wave /usr/local/bin/sfxload PATH_TO_SOUND_BANK_FILE

Benötigt wird Information, um die Wavetable-Funktionalität beim Treiber snd-card-trident.o nutzen zu können. Nach Informtionen aus dem Sourcecode des ALSA-Treibers (/usr/src/packages/SOURCES/alsa-driver-0.5.10b/cards/card-trident.c) hat dieser Treiber nur ein RawMidi-Device, aber keines, das interne Synthese beherrscht. Die Wavetable-Funktionalität kann also mit diesem Treiber nicht genutzt werden. Anscheinend sind die 4 in kmidi angezeigten Ports alles externe MIDI-Devices (die aber hardwaremäßig nicht implementiert sind: keine MIDI-Schnittstelle), die Devices für interne Synthese existieren nicht.

Besteht eine Möglichkeit, die MIDI-Ereignisse auf /dev/midi mit aconnect / alsaseq abzufangen und per Streaming an eine Software-Synthese mit timidity weiterzuleiten?

Neuere Version des ALSA-Treibers verwenden oder OSS-Treiber oder Kerneltreiber?