dovecot - May 2012 - Authentication process holding open filehandles

Hi,

We're using dovecot to provide pop3 for a number of mailboxes.  The setup is
pretty simple:

Each user / domain has a mailstore in
/data/mailstore/<domain>/<user>/Maildir (backed by NFS).

Passwords are in simple passwd-file format in the top level domain directory eg:

# cat /data/mailstore/foo.com/.passwd 
user:{plain}password

The passdb setup looks like this.

passdb {
  args = username_format=%n /data/mailstore/%d/.passwd
  driver = passwd-file
}

The problem we're having is that when we want to remove a domain from the
system and we go to rm -rf /data/mailstore/<domain>/ we are unable to
because the auth process is still holding onto the file handles for the password
file.

Can somebody suggest an alternative pattern that I could use for storing
password files?  Ideally, we'd avoid one large file to prevent locking
issues and would also keep the passwd-file setup since it's simple.

It would be possible to have the password files in a separate dir, but over time
I'm guessing that would lead to nfs turds?  Easy to clean up I suppose, but
maybe there's a simpler solution I'm missing?

George

On Mon, May 07, 2012 at 10:53:53AM +1000, George Barnett
wrote:
> We're using dovecot to provide pop3 for a number of mailboxes.
> The setup is pretty simple:
I would suggest trying to educate your users to move off of POP3.
> Each user / domain has a mailstore in 
> /data/mailstore/<domain>/<user>/Maildir (backed by NFS).
> 
> Passwords are in simple passwd-file format in the top level domain 
> directory eg:
> 
> # cat /data/mailstore/foo.com/.passwd 
> user:{plain}password
> 
> The passdb setup looks like this.
> 
> passdb {
>   args = username_format=%n /data/mailstore/%d/.passwd
>   driver = passwd-file
> }
> 
> The problem we're having is that when we want to remove a domain 
> from the system and we go to rm -rf /data/mailstore/<domain>/ we 
> are unable to because the auth process is still holding onto the 
> file handles for the password file.
> 
> Can somebody suggest an alternative pattern that I could use for 
> storing password files?  Ideally, we'd avoid one large file to 
> prevent locking issues and would also keep the passwd-file setup 
> since it's simple.
SQLite. Learn a bit of SQL, which is not difficult, and it is not 
hard to manage. My own little howto, including the schema and a 
complete explanation of everything is here:

http://rob0.nodns4.us/howto/
> It would be possible to have the password files in a separate dir, 
> but over time I'm guessing that would lead to nfs turds?  Easy to 
> clean up I suppose, but maybe there's a simpler solution I'm 
> missing?
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: