Programme, die mit AFS Probleme bereiten

Diverse Programme streiken oder funktionieren nicht richtig im Zusammenhang mit AFS. Das liegt praktisch immer an den diversen Unterschiedenen des AFS zu Unix-Filesystemen.

Liste der Problemkinder

Unix, Linux

Comodo

Problem: Named-Pipe im Homedirectory - ein Standardproblem.

Kile

Programmbeschreibung: Ein KDE-LaTeX-Editor

Problem: Namend-Pipe im Homedirectory - ein Standardproblem.

Im Konfigurationsdialog ( General / Let Kile process LyX^? commands ... ) läßt sich die Benutzung dieser Pipe abschalten. Welche Features dann genau nicht mehr funktionieren, ist nicht bekannt.

gconfd

Programmbeschreibung: Ein Daemon, der Gnome-Programmen Funktionalität vergleichbar mit der Windows-Registry zur verfügung stellt. gconfd wird von vielen Gnome-Programmen automatisch gestartet.

Probleme:

• gconfd benutzt Byte-Range-Locks, die unter Unix nicht unterstützt werden. Folgende Fehlermeldung taucht dazu im Kernel-Log auf:
  afs: byte-range lock/unlock ignored; make sure no one else is running this program.
• Der gconfd wird gelegentlich nach einer X-Session nicht beendet und läuft in Hintergrund weiter. Da AFS-Tokens nur begrenzte Gültigkeit haben, ist er nach einer Weile nicht mehr funktionstüchtig.

fam

Der File Access Monitor ist ein Dienst, der Änderungen am Filesystem überwacht und bei Bedarf Programme (vor allem Filemanager) benachrichtigt. Leider ist es ein systemweiter Dienst, der natürlich keine Ahnung von den AFS-Tokens eingeloggter Benutzer hat. Man sollte die Benutzung von fam vermeiden. Russ Allbery schlug in einer Mail an die AFS-Mailingliste als Ersatz das Programm gamin vor.

Windows

Office 2003

Office 2003 benutzt sehr merkwürdige Filesystem-Operationen, um Dateien zu schreiben. Das bringt in manchen Konfiguratione den AFS-Client so sehr aus dem Tritt, dass ein Neustart nötig ist. An dem Problem wird gerade gearbeitet - der OpenAFS-Client 1.4.2 soll das Problem beheben.

Lösungen für Standard-Probleme

Named-Pipe oder Socket im Homedirectory

Wenn eine Anwendung ins Homedirectory eine Named-Pipe legen will, tut sie das glücklicherweise meist nicht direkt im Homedir, sondern mindestens eine Ebene tiefer. Hier kann man ansetzen und das Verzeichnis dieses Programmes - am Beispiel von kile - in ein geeigneteres Filesystem verlegen - z.B. tmp :

user@host > cd ~
user@host > cp -a .kile /var/tmp/kile-$UID && rm -rf .kile
user@host > ln -s /var/tmp/kile-$UID .kile

Hinweise:

• Diese Variante ist nicht sicher auf Mehrbenutzersystemen - das Verzeichnis in /var/tmp darf nicht durch cp angelegt werden, sondern müsste mit etwas wie tmpdir (gibt's leider so nicht) erzeugt werden.
• Es ist viel günstiger - evtl. aber auch schwieriger - die Named-Pipe zu verlegen, anstelle aller Konfigurationsfiles der Anwendung. Das geht auf mindestens 2 Arten:
  1. Mittels eines symbolischen Links im Homedirectory kann man auf eine Namend-Pipe in einem temporären Verzeichnis zeigen.
  2. Freier Quellcode ist klar im Vorteil: Man kann natürlich das Programm umschreiben und anweisen, die Namend-Pipe woanders zu erzeugen.

Zugriffsrechte werden falsch interpretiert

Gelegentlich sind Programme so clever, die von stat() zurückgelieferten Modebits selbst auszuwerten und daraus zu berechnen, ob ein Dateisystemobjekt les- bzw. beschreibbar ist. Da die Modebits unter AFS nichts mit den Zugriffsrechten zu tun haben, ist das keine gute Idee - der access() -Systemaufruf kann das viel besser.

Perl-Skripte

Perl kennt die unter der Bash üblichen Zugriffstest-Operatoren wie -r , -w, ... . Diese werden unter Perl per stat() -Aufruf realisiert - es seie denn, man verwendet ein bestimmtes Pragma:

use filetest 'access';
[Zurück zum Start]