Hello, We manage a mail server using Dovecot under Debian. Since a long time, we run nightly a script permitting to display the storage usage of each user on the webmail, using internal calls. The usage on each mailbox is stored in a Mysql database. For several reasons, we would now want to use the IMAP quota feature, not only to let users have the quota displayed from their Mail clients. But testing that features, I encounter two problems : 1) It seems that when we use the sql dict, a map contaning the patern "priv/quota/limit/messages" is mandatory. Not specifying it in dovecot-dict-sql.conf.ext issues an error. As we are interested only by the storage size and don't want to process the number of messages, how to get rid of it ? 2) We store the storage value in kilobytes. But the plugin seems to only accept storage in bytes, Is there any way to let know to dovecot that the value stored in the database is in kilobytes ? (of course, I tried to put "size/1024" in the value_field field of the map. It works, but generate a lot of error lines in the dovecot log as it create a syntaxly incorrect MySQL uodate request...) Jacques. -- The last man connected to the Interet was browsing some old WebSites. "You have new mail" appeared on the screen... --------------------------- adapted from a short Fredric Brown's story
Am 08.09.2017 um 14:42 schrieb Jacques Belin:> > Hello, > > We manage a mail server using Dovecot under Debian. > Since a long time, we run nightly a script permitting to display the > storage usage of each user on the webmail, using internal calls. The > usage on each mailbox is stored in a Mysql database. > > For several reasons, we would now want to use the IMAP quota feature, > not only to let users have the quota displayed from their Mail clients. > > But testing that features, I encounter two problems : > > 1) It seems that when we use the sql dict, a map contaning the patern > "priv/quota/limit/messages" is mandatory. Not specifying it in > dovecot-dict-sql.conf.ext issues an error. As we are interested only by > the storage size and don't want to process the number of messages, how > to get rid of it ?Set it to unlimited?> 2) We store the storage value in kilobytes. > But the plugin seems to only accept storage in bytes, Is there any way > to let know to dovecot that the value stored in the database is in > kilobytes ? (of course, I tried to put "size/1024" in the value_field > field of the map. It works, but generate a lot of error lines in the > dovecot log as it create a syntaxly incorrect MySQL uodate request...)Using 'storage' instead of 'bytes' should provide limits as kilobytes. See Wiki: https://wiki2.dovecot.org/Quota/Configuration#Limit_configuration -- Alex JOST
Le dimanche 10 septembre 2017 14:35:16, Alex JOST <jost+lists at dimejo.at> a ?crit:> > 1) It seems that when we use the sql dict, a map contaning the patern > > "priv/quota/limit/messages" is mandatory. Not specifying it in > > dovecot-dict-sql.conf.ext issues an error. As we are interested only by > > the storage size and don't want to process the number of messages, how > > to get rid of it ? > > Set it to unlimited?It is not the point. I don't want to have to manage the number of messages, only the storage size. If the IMAP QUOTA RFCs, the number of messages is given only as an example of resources that can be accessible by IMAP QUOTA. So why dovecot made it mandatory ?> > 2) We store the storage value in kilobytes. > > But the plugin seems to only accept storage in bytes, Is there any way > > to let know to dovecot that the value stored in the database is in > > kilobytes ? (of course, I tried to put "size/1024" in the value_field > > field of the map. It works, but generate a lot of error lines in the > > dovecot log as it create a syntaxly incorrect MySQL uodate request...) > > Using 'storage' instead of 'bytes' should provide limits as kilobytes.It is what I have already done, from the begnining. But that word deals about how the limit is defined in the quota rule definition, not about the values stored in the database. In the database we use, the sizes are stored in kilobytes, but dovecot wants bytes (strange choice BTW, as when we deal about disk storage we talk only in terms of sectors size, clusters, etc... which are now always defined as multiples of kilobytes...)... Jacques. -- The last man connected to the Interet was browsing some old WebSites. "You have new mail" appeared on the screen... --------------------------- adapted from a short Fredric Brown's story
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 8 Sep 2017, Jacques Belin wrote:> 1) It seems that when we use the sql dict, a map contaning the patern > "priv/quota/limit/messages" is mandatory. Not specifying it in > dovecot-dict-sql.conf.ext issues an error. As we are interested only by > the storage size and don't want to process the number of messages, how > to get rid of it ?No, not that I know of. The value is calculated and storred.> 2) We store the storage value in kilobytes. > But the plugin seems to only accept storage in bytes, Is there any way > to let know to dovecot that the value stored in the database is in > kilobytes ? (of course, I tried to put "size/1024" in the value_field > field of the map. It works, but generate a lot of error lines in the > dovecot log as it create a syntaxly incorrect MySQL uodate request...)The plugin maintains an internal value in a dict. Don't change it and keep your hands off. If you need to access the current values from the DB, use a view, which transforms the internal value into what you need. The limits can be expressed in any way, have your userdb query calculate bytes from whatever value you have in the userdb. For:> We manage a mail server using Dovecot under Debian. > Since a long time, we run nightly a script permitting to display the > storage usage of each user on the webmail, using internal calls. The > usage on each mailbox is stored in a Mysql database.use doveadm to get the values and modify them. If the VIEW does not fit. - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWbkvoHz1H7kL/d9rAQLQCQf/c11sxz+iDZM7K5Sj4aNb/jLwewXcijRX LsnOkqfH422Ranue3EA4zBROPHrkTd+82txYQ4NlmJc8QN2Fp+td5Ksz0Jz64X9O 41l8JBIQmQ45F9wA1X4Eu8pIAxJ841DTq5AeAVh5MNlTtcIc1svnLWxPVuqlxd1B Yt6XpkEHwoTJEt9G/kFKjzuuLLpJJn3r/y2O7BtdBbWRT5DGm5NafwxxRoUpWv94 jxcY7SlifFH7prvehUqnYU4cJiyzGMt+vetYOjM0IFhMbKSM3Y0cFuF/wNUFa/Vv +/jCciVmw0LLPlhKpBnVaF3HMV+lqoTgRYgA6nV0tlfLPh4SmEjGFA==rqXt -----END PGP SIGNATURE-----