Re: [Dovecot] Ambiguous behavior with prefetch database?
Le 12 juil. 2013 à 22:18, Axel Luttgens a écrit : [...] I hope I'll have the opportunity to try it tomorrow. [...] I've applied changesets 9091d0f2d971 and 2be295a0b64f (both were needed) to a clean 2.2.4 source, and it seems to yield the expected results now. Nice to be able to keep configs clean thanks to an enhanced consistency. Thank you very much, Axel
Re: [Dovecot] Ambiguous behavior with prefetch database?
Le 12 juil. 2013 à 01:44, Timo Sirainen a écrit : [...] Here: http://hg.dovecot.org/dovecot-2.2/rev/2be295a0b64f Hello Timo, I hope I'll have the opportunity to try it tomorrow. In the meantime, thanks again for your care, Axel
Re: [Dovecot] Ambiguous behavior with prefetch database?
On Wed, 2013-07-10 at 11:38 +0200, Axel Luttgens wrote: Le 10 juil. 2013 à 04:37, Timo Sirainen a écrit : Fixed: http://hg.dovecot.org/dovecot-2.2/rev/9091d0f2d971 And for LDAP: http://hg.dovecot.org/dovecot-2.2/rev/939aa051e3f1 Hello Timo, Many thanks for having taken the pain to have a look at this. (BTW, when do you sleep?) I've tried the patch for sql, on an otherwise unpatched 2.2.4. And it unfortunately doesn't seem to yield the expected results: I still need the AS userdb_uid workaround. May I somehow be useful by trying something else here? Here: http://hg.dovecot.org/dovecot-2.2/rev/2be295a0b64f
Re: [Dovecot] Ambiguous behavior with prefetch database?
Le 10 juil. 2013 à 04:37, Timo Sirainen a écrit : Fixed: http://hg.dovecot.org/dovecot-2.2/rev/9091d0f2d971 And for LDAP: http://hg.dovecot.org/dovecot-2.2/rev/939aa051e3f1 Hello Timo, Many thanks for having taken the pain to have a look at this. (BTW, when do you sleep?) I've tried the patch for sql, on an otherwise unpatched 2.2.4. And it unfortunately doesn't seem to yield the expected results: I still need the AS userdb_uid workaround. May I somehow be useful by trying something else here? Best Regards, Axel
Re: [Dovecot] Ambiguous behavior with prefetch database?
Fixed: http://hg.dovecot.org/dovecot-2.2/rev/9091d0f2d971 And for LDAP: http://hg.dovecot.org/dovecot-2.2/rev/939aa051e3f1 On 6.7.2013, at 1.18, Axel Luttgens axelluttg...@swing.be wrote: Hello, Let's say dovecot.conf contains: mail_uid= dovemailer mail_gid= dovemailer mail_home = /some/path/%n mail_location = mbox:~/mboxes:INBOX=~/mboxes/inbox and that the password database query is of the form: password_query = \ SELECT \ passwd AS password, \ nickname AS user, \ mail_home AS userdb_home, \ mail_location AS userdb_mail, \ WHERE \ ... The database initially comes with NULL for both mail_home and mail_location, the goal being to be able to progressively replace legacy settings. With the above, one gets such entries in the logs upon a pop or imap connection: auth-worker(11262): Debug: auth(u12345678,127.0.0.1): username changed u12345678 - john.doe auth: Debug: auth(u12345678,127.0.0.1,dsNsasbgRQB/AAAB): username changed u12345678 - john.doe [...] auth: Debug: prefetch(john.doe,127.0.0.1,dsNsasbgRQB/AAAB): passdb didn't return userdb entries, trying the next userdb and, of course, the userdb_query fails since it isn't supposed to be invoked under such circumstances. Of course, the userdb_query could be adapted so as to handle pop/imap connections in addition to say, lmtp or doveadm connections, but this would anyway raise the question: why bother with a prefetch database setup? In fact, it seems that the problem comes from the fact that the password_query returns NULL values (i.e. do not override dovecot.conf settings) for all userdb_xxx settings even if, technically speaking, it returns such columns. A slight yet somewhat silly modification of the password_query, such as this one: password_query = \ SELECT \ passwd AS password, \ nickname AS user, \ 'dovemailer' AS userdb_uid, \ mail_home AS userdb_home, \ mail_location AS userdb_mail, \ WHERE \ ... indeed seems to bring back all the expected behavior: now, the passdb returns userdb entries and, for example, the config's mail_home expands to the expected value /some/path/john.doe. Could it be that the case userdb_xxx columns returned, even if all with NULL values has been somehow overlooked in the code? Or am I erring with my interpetation of all those matters? TIA, Axel
[Dovecot] Ambiguous behavior with prefetch database?
Hello, Let's say dovecot.conf contains: mail_uid= dovemailer mail_gid= dovemailer mail_home = /some/path/%n mail_location = mbox:~/mboxes:INBOX=~/mboxes/inbox and that the password database query is of the form: password_query = \ SELECT \ passwd AS password, \ nickname AS user, \ mail_home AS userdb_home, \ mail_location AS userdb_mail, \ WHERE \ ... The database initially comes with NULL for both mail_home and mail_location, the goal being to be able to progressively replace legacy settings. With the above, one gets such entries in the logs upon a pop or imap connection: auth-worker(11262): Debug: auth(u12345678,127.0.0.1): username changed u12345678 - john.doe auth: Debug: auth(u12345678,127.0.0.1,dsNsasbgRQB/AAAB): username changed u12345678 - john.doe [...] auth: Debug: prefetch(john.doe,127.0.0.1,dsNsasbgRQB/AAAB): passdb didn't return userdb entries, trying the next userdb and, of course, the userdb_query fails since it isn't supposed to be invoked under such circumstances. Of course, the userdb_query could be adapted so as to handle pop/imap connections in addition to say, lmtp or doveadm connections, but this would anyway raise the question: why bother with a prefetch database setup? In fact, it seems that the problem comes from the fact that the password_query returns NULL values (i.e. do not override dovecot.conf settings) for all userdb_xxx settings even if, technically speaking, it returns such columns. A slight yet somewhat silly modification of the password_query, such as this one: password_query = \ SELECT \ passwd AS password, \ nickname AS user, \ 'dovemailer' AS userdb_uid, \ mail_home AS userdb_home, \ mail_location AS userdb_mail, \ WHERE \ ... indeed seems to bring back all the expected behavior: now, the passdb returns userdb entries and, for example, the config's mail_home expands to the expected value /some/path/john.doe. Could it be that the case userdb_xxx columns returned, even if all with NULL values has been somehow overlooked in the code? Or am I erring with my interpetation of all those matters? TIA, Axel
