File-dictionary based quotas and SETQUOTA

[Ganael Laplanche via dovecot]

Hello,

I am trying to set up file-dictionary based quotas while supporting the 
SETQUOTA IMAP command.

I am using the following configuration :


plugin {
  quota = dict:User quota::file:%h/Maildir/dovecot-quota
  quota_set = dict:file:%h/Maildir/dovecot-quota
}


which enables correct quota accounting + setting through SETQUOTA.

A user's dovecot-quota file ends with the following contents :


priv/quota/limit/storage
5242880
priv/quota/limit/messages
20
priv/quota/messages
1
priv/quota/storage
8506282


which shows a correct accounting (1 mail received, ~8MB used) and correct 
setting after having used the following IMAP command through a master user :

A2 SETQUOTA "User quota" (STORAGE 5242880 MESSAGE 20)

*But* the problem is that I am unable to fetch the limits and consume them 
from userdb (as a consequence, the limits are never applied).

On the consuming side, I am using a dictionary userdb to try to fetch the 
'priv/quota/limit/storage' value from the file but it does not work because 
the key is never found.

Here is my configuration :


userdb {
  driver = dict
  args = /etc/dovecot/dovecot-dict-quota.conf.ext
}


and my dovecot-dict-quota.conf.ext file :


uri = file:%h/Maildir/dovecot-quota
iterate_disable = yes

key quota {
  key = priv/quota/limit/storage
  default_value = 100
}

userdb_fields {
  quota_rule = *:storage=%{dict:quota}
}


If I try to fetch the quota for that user :

# doveadm quota get -u ganael.laplan...@centralesupelec.fr
Quota name TypeValue Limit  

%
User quota STORAGE  8307   100  
 
8307
User quota MESSAGE 1 -  

0

the default rule is returned (100). The logs show :

May 16 12:02:45 mailhost1-saclay dovecot: auth-worker(12899): Debug: 
dict(ganael.laplan...@centralesupelec.fr): Lookup: shared/priv/quota/limit/
storage not found, using default value 100

We can see that the default quota rule has been applied because the key is not 
found. The problem is that a "shared/" prefix is always prepended when looking 
for the key I configured (priv/quota/limit/storage).

If I test the dictionary manually, the key is found :

# doveadm dict get -u ganael.laplan...@centralesupelec.fr "file:/var/vmail/l/
laplanche_gan/Maildir/dovecot-quota" priv/quota/limit/storage
5242880

Does anyone know how to prevent Dovecot from adding that prefix and make it 
fetch the correct value from userdb ?

Best regards,

-- 
Ganael Laplanche 
Unix Systems Engineer @CentraleSupelec Rennes

Re: LDA locking problems - home related

[Ganael Laplanche]

On Thursday 16 March 2017 15:35:08 Ganael Laplanche wrote:

> Hi list,

Of course, the subject of my mail should be :

LDA locking problems - home related

not LDA*P*.

I could have LDAP locking problems but that's another story ;-)

-- 
Ganael Laplanche 
Unix Systems Engineer @CentraleSupelec Rennes

LDAP locking problems - home related

[Ganael Laplanche]

Hi list,

# dovecot --version
2.2.13

We use Dovecot LDA and I've discovered lots of messages stating that lock 
files cannot be written:

Mar 16 12:02:03 mailhost dovecot: lda(someuser): Error: 
file_dotlock_open(/home/sg/someuser/.dovecot.lda-dupes) failed: No such file 
or directory

That user's home directory is fetched from LDAP and does not exist locally on 
our 'mailhost' machine, so those error messages do make sense; I would like to 
fix that situation.

In our current Dovecot configuration, only mail_location is set:
 
mail_location = maildir:/var/mail/%u

I would like to ignore the erroneous 'home' attribute fetched from LDAP and 
specify a common mail_home, i.e. set:

mail_home = /var/mail/%u/home

but if I understand correctly, that global mail_home configuration directive 
would still be overridden by the LDAP 'home' attribute fetched from passdb:

[...]
pass_attrs = supannAliasLogin=user,userPassword=password,\
  homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid
[...]

Can I just remove homeDirectory from pass_attrs to skip fetching 'home' from 
LDAP and then set the global mail_home ?

Also, if that works:

We would switch from a situation where a home is set (but wrong) to one where 
it becomes valid. Can there be any side-effect in that case (apart from fixing 
locking problems) ?

Finally, will mail_home (leaf) directory be created if it does not exist yet 
(parent directory exists) ?

Best regards,

-- 
Ganael Laplanche 
Unix Systems Engineer @CentraleSupelec Rennes