procmail
[Top] [All Lists]

Re: How to stop creation of BOGUS.xxx

1997-03-11 01:28:25

On Mon, 10 Mar 1997, Philip Guenther wrote:
By "userids" do you mean numeric UIDs or login names?

numeric ones.


Define a database doing the mapping, have ruleset 5 use the map and
pass the mapped address back to ruleset 0 on a match.  Users excluded
from the map would be delivered locally.

What about simply sticking all local users' site wide address into
/etc/aliases and running newaliases. As far as I tested it, it appears
to work.

a mail folder on an NFS-mounted volume where the symlinks in
/var/spool/mail in my case are directed. The nfs daemon on that server

By using a symlink as the last part of the path you make dotlocking
impossible.  More precisely, processes on different machines can lock
a given file at the same time as the lockfiles will be in different
locations.


I'm sorry to be the one to tell you this, but RedHat 4.0 (Linux 2.0.29)
DOESN'T SUPPORT KERNEL LOCKING ACROSS NFS!!!  I just tried it myself
here between a linux box running 2.0.29 and an nfs server running
solaris 2.5.  Kernel locking did work between the solaris box and
another one acting as a client, so it's not solaris's fault.  The Linux
people just haven't gotten to it yet (who know, it may work on newer
developmental kernels, but given the history of NFS file locking
implementations, I wouldn't trust it until it was moved to the stable
branch).

So, you basically are doing *no* locking.  Do you consider this
situation acceptable?

Right. Now we got to the core of the problem. I realise it now. I had
no idea nfs didn't take care of conflicts. I just tested it myself by
simultaneously pumping output from two machines into a file on the
server. The result was a garbled file. This is bad news.
 

It doesn't matter, how you present this problem, there will always be
someone from whose point of view the problem is most easily solved by
stopping procmail doing the system mailbox screening.

When "most easily solved" is broken, it isn't a solution.

It is if you can safely assume that the failure conditions are
prevented elsewhere. If nfs on Linux avoided simultaneous read/write
instances, my botch would work just fine for me, as far as I can see
it.

This nfs problem is quite severe. It also means that I run the risk of
a corrupted mailbox everytime I am using pine which I directed to
use the mailbox in the nfs mounted directory. That means I have to
think about imap or some other way for that problem, too.


If anyone is offended by the forcefulness of my writing, I ask your
forgiveness.  I just take this issue very seriously, and sometimes
my writing out-paces my editing.

No worries.

p

<Prev in Thread] Current Thread [Next in Thread>