Also, nowadays Lua would be a better way to do custom authentication and we're more careful not to break that.
> On 21. Jun 2022, at 13.47, Timo Sirainen <t...@sirainen.com> wrote: > > Oh, I think your problem is that you've implemented a separate dict-server. > And looks like we forgot to mention in v2.3.17 release notes that the dict > protocol had to be changed due to some improvements. Your dict server should > verify that the VERSION line's major version number is as expected, and error > out if not. That would have made it easier to notice this change. See > https://doc.dovecot.org/developer_manual/design/dict_protocol/ for the new > protocol - the only relevant change I think is that a "<tab><username>" is > appended to each lookup command, and since these are shared/ key lookups it > means there is no username, and you just need to ignore the trailing <tab> at > the end of L-command lines. > >> On 21. Jun 2022, at 0.47, Ralf Becker <r...@egroupware.org> wrote: >> >> Hi Timo, >> >> attached is the log with auth_debug=true from the starting process and >> running "doveadm auth test ralfimapt...@egroupware.org" and one other >> regular passdb lookup. >> >> I replaced passwords and the customer email with XXXXXX. >> >> I also run "doveadm user '*'" to test the iteration, which worked. >> >> Ralf >> >> >> Am 20.06.22 um 13:32 schrieb Ralf Becker: >>> Hi Timo, >>> >>> Am 20.06.22 um 12:17 schrieb Timo Sirainen: >>>> On 20. Jun 2022, at 10.03, Ralf Becker <r...@egroupware.org> wrote: >>>>>> Fixes: Panic: file userdb-blocking.c: line 125 >>>>>> (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL) >>>>> As the above Panic is fixed I tried again (see my attached mail to the >>>>> 2.3.19 release) and I can confirm to no longer get the Panic, BUT >>>>> authentication is NOT working either :( >>>>> >>>>> Reverting back to a container with Dovecot 2.3.16, get's everything >>>>> working again. >>>>> >>>>> We use a hourly updated local SQLight database and a dict for user- and >>>>> passdb. >>>>> >>>>> Is the usage of multiple backends no longer supported, or did something >>>>> in that regard changed between 2.3.16 and 2.3.19.1? >>>> We have lots of tests using multiple backends for authentication, and lots >>>> of people are using many passdbs/userdbs in production. I was only aware >>>> of iteration being broken with multiple userdbs, since that's not used so >>>> much. And we added a test to verify that multiple userdb iteration is >>>> actually returning results from both userdbs, so that shouldn't be >>>> completely broken either. >>>> >>>> So I'd need more details of what exactly goes wrong and how. Is it the >>>> authentication or the iteration that is now broken? >>> >>> I only seen authentication errors in doveadm log errors and our montioring >>> trying to access the backend with user credentials. >>> >>>> Logs with auth_debug=yes would likely help. >>> >>> I will get you the logs tonight, don't want to switch (one leg of) the >>> production system during daytime. >>> I can then also try eg. doveadm user -A to check the iteration. >>> >>>> Also: >>>> >>>>> Here's the relevant part of my config (full doveadm config -n is >>>>> attached): >>>>> >>>>> userdb { >>>>> args = /etc/dovecot/dovecot-sql.conf >>>>> driver = sql >>>>> } >>>>> userdb { >>>>> args = /etc/dovecot/dovecot-dict-auth.conf >>>>> driver = dict >>>>> } >>>>> passdb { >>>>> args = /etc/dovecot/dovecot-dict-master-auth.conf >>>>> driver = dict >>>>> master = yes >>>>> } >>>>> passdb { >>>>> args = /etc/dovecot/dovecot-dict-auth.conf >>>>> driver = dict >>>>> } >>>> What do these external conf files contain? >>> >>> /etc/dovecot/dovecot-sql.conf: >>> >>> driver = sqlite >>> connect = /etc/dovecot/users.sqlite >>> >>> #password_query = SELECT userid AS username, domain, password \ >>> # FROM users WHERE userid = '%n' AND domain = '%d' >>> #user_query = SELECT home, uid, gid FROM users WHERE userid = '%n' AND >>> domain = '%d' >>> # return no userdb, as db contains only user-names >>> #user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE userid = >>> '%n' AND domain = '%d' >>> user_query = SELECT home,NULL AS uid,NULL AS gid, \ >>> '*:bytes='||(quota*1048576) AS quota_rule, \ >>> userid||'@'||domain AS master_user, \ >>> LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS acl_groups \ >>> FROM users WHERE userid = '%n' AND domain = '%d' >>> >>> # For using doveadm -A: >>> iterate_query = SELECT userid AS username, domain FROM users >>> >>> /etc/dovecot/dovecot-dict-auth.conf: >>> >>> uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere >>> #uri = proxy:10.44.99.180:2001:somewhere >>> >>> password_key = passdb/%u/%w >>> user_key = userdb/%u >>> iterate_disable = yes >>> #iterate_disable = no >>> #iterate_prefix = userdb/ >>> default_pass_scheme = md5 >>> >>> /etc/dovecot/dovecot-dict-master-auth.conf: >>> >>> uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere >>> #uri = proxy:10.44.99.180:2001:somewhere >>> >>> #password_key = master/%{login_domain}/%u/%w >>> password_key = master/%{login_user}/%u/%w >>> iterate_disable = yes >>> default_pass_scheme = md5 >>> >>> Thanks :) >>> >>> Ralf >>> >> >> -- >> Ralf Becker >> EGroupware GmbH [www.egroupware.org] >> Handelsregister HRB Kaiserslautern 3587 >> Geschäftsführer Birgit und Ralf Becker >> Leibnizstr. 17, 67663 Kaiserslautern, Germany >> Telefon +49 631 31657-0 >> <dovecot-auth_debug.log.bz2> >
