It seems mod_edir is having possible issues relating to the caching of identities in the back end. When you go, say, here it takes "riedesg" and caches the location of where the user-directory can be found. Right now it seems to be throwing a 404 the very first time the resource is accessed and is OK (200) afterwards. At least until the entry ages long enough to be purged from the internal cache, at which point the cycle starts over again.
I think.
Since mod_edir is an an open-source project I'll be downloading the latest source and try to trace down where in the code the error is occuring. If a miracle strikes, I might be able to identify where it could be fixed!
UPDATE:
On parsing the debug output of this here module, I've found the flow goes something like this:
[1st connection attempt]
- Username is checked
- It comes back as good
- Check cache for existing entry
- No entry, so query LDAP for userdir
- Gets it, adds to cache
- Craps out on "invalid home directory"
[2nd connection attempt]
- Username is checked
- It comes back as good
- Check cache for existing entry
- Finds entry
- Checks cache for entry for the volume the directory is on
- No entry, so it creates a connection to the volume, adds info to cache
- Connects to resource
- Returns data to requester
[3+ connection attempt, up to the cache-expire time]
- Username is checked
- It comes back as good
- Check cache for existing entry
- Finds entry
- Checks cache for entry for the volume the directory is on
- Finds entry
- Connects to resource
- Returns data to requster
Once the cache-expire time rolls over, timed from the first access not last access, the process starts all over again. Also, this is the request for the VOLUME not the USER in this case. So for heavilly used resources (of which I have none so far) one user per volume per cache-expire period will get an unexpected 404.
I think.
Since mod_edir is an an open-source project I'll be downloading the latest source and try to trace down where in the code the error is occuring. If a miracle strikes, I might be able to identify where it could be fixed!
UPDATE:
On parsing the debug output of this here module, I've found the flow goes something like this:
[1st connection attempt]
- Username is checked
- It comes back as good
- Check cache for existing entry
- No entry, so query LDAP for userdir
- Gets it, adds to cache
- Craps out on "invalid home directory"
[2nd connection attempt]
- Username is checked
- It comes back as good
- Check cache for existing entry
- Finds entry
- Checks cache for entry for the volume the directory is on
- No entry, so it creates a connection to the volume, adds info to cache
- Connects to resource
- Returns data to requester
[3+ connection attempt, up to the cache-expire time]
- Username is checked
- It comes back as good
- Check cache for existing entry
- Finds entry
- Checks cache for entry for the volume the directory is on
- Finds entry
- Connects to resource
- Returns data to requster
Once the cache-expire time rolls over, timed from the first access not last access, the process starts all over again. Also, this is the request for the VOLUME not the USER in this case. So for heavilly used resources (of which I have none so far) one user per volume per cache-expire period will get an unexpected 404.