Stephan Seitz schrieb am Freitag, den 15. Oktober 1999:
> > Hinzu kommt dann noch ein Bug in allen 2.2.* Kernels bis
> > einschließlich 2.2.12 (seit 2.2.13ac10 ist das behoben und wird wohl
> Du meinst wohl 2.2.13pre10, oder? 2.2.13 ist doch noch nicht draußen.
Numeriert Alan Cox seine Patches nicht erstmal ac und später pre? Ist
ja auch egal, in pre15 ist der Patch auf jeden Fall drin, da habe ich
ihn selber gesehen.
> Ich habe außerdem knfsd-1.5.2 installiert, kompiliert mit
> --enable-nfsv3.
Warum verwendest Du NFSv3? NFSv2 funktioniert doch auch (auch mit
Locking), wenn man den knfsd verwendet.
> Auf Slink- und Potato-Systemen habe ich procmail (meinen lokalen
> MTA) mit fcntl und flock neben dotlock kompiliert. Der qpopper
> scheint nach einem grep durch die Sourcen nur fcntl zu benutzen.
Das ist dann auf jeden Fall ein Bug, der Probleme aufwirft, sobald der
Server kein Locking unterstützt. Dann kann ein per NFS zugreifender
Client nämlich nicht feststellen, daß sich auf dem Server was geändert
hat. Ein Locking zwischen Server und Client ist dann nicht mehr
möglich. Da die Debian-Policy (noch) vorschreibt, ausschließlich
Dotlocking zu verwenden, kracht das weiterhin zwischen qpopper und MDA
(z.B. procmail), wenn qpopper und procmail die Mailbox gleichzeitig
verändern und kein gemeisames Locking-Verfahren nutzen.
> Die neuen elm-me-Versionen kann ich ebenfalls mit mehreren
> Locking-Methoden kombinieren.
Die meisten Programme bieten das an, wobei die meisten halt gemäß
Policy so konfiguriert sind, daß sie nur Dotlocking verwenden.
> Aber was benutzen pine3.96M-4
Das habe ich noch nicht rausgefunden, aber irgendwie scheint pine
relativ sicher gegen Mailverluste zu sein. Bei meinen Tests mit elm,
pine und Mutt habe ich es jedenfalls nicht geschafft, mit Pine die
Probleme zu reproduzieren, die mit elm und Mutt aufgetreten sind. Aber
ich habe mir die Pine Sourcen nicht daraufhin angesehen.
> und die diversen X11-MUAs, vorallem KMail?
Keine Ahnung. Das ist eine Fleißarbeit für jemanden mit viel Zeit...
> Ich habe außerdem in der fstab die Zeile nfsvers=3 drin, trotzdem
> meldet der mountd: authenticated mountv1 request from ...
Wo ist das Problem? Der mountd sagt Dir doch nur, daß da jemand zu
Recht versucht, etwas per NFS zu mounten und daß dieser Versuch
geklappt hat. Warum sollte der mountd das bei NFSv3 nicht mehr melden?
Bei NFSv2 meldet er das jedenfalls und es ist sicherlich keine
Fehlermeldung, sondern nur eine Information.
> Gibt es eigentlich irgendeine Methode, um die Sicherheit des
> Lockings zu überprüfen?
Nicht wirklich. Du kannst fleißig testen (Mail an Dich selber
schicken, am besten via SMTP vom Client aus) und dann in dem Moment,
wo der Server die Mail ausliefert, die eigene Mailbox via NFS mit dem
Mailreader zurückschreiben. Wenn der Server schön langsam ist (bei mir
ein lahmer 486er mit VLB und IDE), sind die Chancen ganz gut, daß Du
den Schreibzugriff per NFS so timest, daß er die gerade ausgelieferte
Mail überschreibt. Damit kannst Du immerhin nachweisen, daß Mail
verloren geht. Der Beweis, daß Mail nicht verloren geht, ist deutlich
schwieriger. Ich teste halt ein paar zig Mails und wenn dabei nichts
verloren geht, glaube ich irgendwann, daß das Locking funktioniert...
Tschoeeee
Roland
--
* roland@spinnaker.de * http://www.spinnaker.de/ *
PGP (RSA): 1024R/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
GPG (DSA): 1024D/BD8B050D 3A63 2410 4B40 422D 1111 1D2C 3BBF CF77 BD8B 050D
Attachment:
pgpw3tRy24Xz7.pgp
Description: PGP signature