On Wed, Oct 04, 2000 at 01:40:53PM -0700, [EMAIL PROTECTED] wrote:
[snip]
> >
> > Ok, let's do this out of order.
> > .qmail tricks - doing a deferral from ~alias/.qmail-default if the user
> > seems valid?
> >
> > Or, *duh*: the homedir check is in qmail-getpw. Since you've already
> > modified it, modify it some more :)
>
> Right. But he may not actually have to check for the existance of HOME currently
> and in any event there is a timing window between qmail-getpw and the
> invocation of qmail-local. So it may disappear after the check in qmail-getpw.
That's what I thought, I considered a race attack, but there is none.
qmail-local *defers* on homedir failures. Only qmail-getpw actually
*bounces* on homedir failures.
He's using a *modified* qmail-getpw, not a rewritten one. The homedir
check is probably just still in there.
> Having said all that, qmail-local exit with a *temp* error if it cannot
> stat the home directory, so I'm not sure what the exact problem is. If the
> nfs home is gone, then this stat() should fail at some point and defer
> the delivery.
Yeah, that's because qmail-getpw does the bouncing.
> The only general problem is that the NFS timeouts may clog the concurrencylocal
> limits, but then if you have no homes, there's nothing to delivery anyway.
That depends. Where I work we have homedirs spread over about 40
userservers, which means indeed one can be down while the others are up.
I modified my checkpassword replacements (which uses files in the
homedir) to kill itself after 1 second, just because of broken NFS
stuff.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
