dovecot - May 2015 - Additional userdb variables in passwd [was Re: Dovecot Replication - Architecture Endianness?]

On 4/05/2015 11:06 PM, Teemu Huovila wrote:
>> Also is there a way to restrict replication users aside from a crude
hack around system first and last UIDs?
> You can set the userdb to return an empty mail_replica variable for users
you want to exclude from replication.
> http://hg.dovecot.org/dovecot-2.2/rev/c1c67bdc8752
>
> br,
> Teemu Huovila
One last question.  Is it possible to achieve this with system users and 
PAM or do I need to basically create a new static userdb for system users?

Could this be done via a per-user LDA setting or sieve?

Thanks,
Reuben

On 06 May 2015, at 13:52, Reuben Farrelly <reuben-dovecot at reub.net>
wrote:
> 
> On 4/05/2015 11:06 PM, Teemu Huovila wrote:
>>> Also is there a way to restrict replication users aside from a
crude hack around system first and last UIDs?
>> You can set the userdb to return an empty mail_replica variable for
users you want to exclude from replication.
>> http://hg.dovecot.org/dovecot-2.2/rev/c1c67bdc8752
>> 
>> br,
>> Teemu Huovila
> 
> One last question.  Is it possible to achieve this with system users and
PAM or do I need to basically create a new static userdb for system users?
You can create a new userdb passwd-file that adds extra fields. So something
like:

userdb {
  driver = passwd
  result_success = continue-ok
}

userdb {
  driver = passwd-file
  args = /etc/dovecot/passwd.extra
  skip = notfound
}
> Could this be done via a per-user LDA setting or sieve?
Replication would happen also with IMAP access.

On 7/05/2015 7:49 AM, Timo Sirainen wrote:
> On 06 May 2015, at 13:52, Reuben Farrelly <reuben-dovecot at
reub.net> wrote:
>>
>> On 4/05/2015 11:06 PM, Teemu Huovila wrote:
>>>> Also is there a way to restrict replication users aside from a
crude hack around system first and last UIDs?
>>> You can set the userdb to return an empty mail_replica variable for
users you want to exclude from replication.
>>> http://hg.dovecot.org/dovecot-2.2/rev/c1c67bdc8752
>>>
>>> br,
>>> Teemu Huovila
>>
>> One last question.  Is it possible to achieve this with system users
and PAM or do I need to basically create a new static userdb for system users?
>
> You can create a new userdb passwd-file that adds extra fields. So
something like:
>
> userdb {
>    driver = passwd
>    result_success = continue-ok
> }
>
> userdb {
>    driver = passwd-file
>    args = /etc/dovecot/passwd.extra
>    skip = notfound
> }
This doesn't seem to work for me and my config has that exact config. 
My password.extra file has just one line for the one account I am 
testing with at the moment:

user1:::::::userdb_mail_replica=tcps:lightning.reub.net:4813,userdb_mail_replica=tcp:pi.x.y:4814

This breaks access for other system users such as my own account which 
do not have entries:

ay  7 21:19:06 tornado.reub.net dovecot: imap-login: Internal login 
failure (pid=22573 id=1) (internal failure, 1 successful auths): 
user=<reuben>, auth-method=PLAIN, remote=2001:44b8:31d4:1311::50, 
local=2001:44b8:31d4:1310::20, TLS

which then starts soon spitting this out 10s of times per second in the 
mail log:

May  7 21:19:32 tornado.reub.net dovecot: auth-worker(23738): Error: 
Auth worker sees different passdbs/userdbs than auth server. Maybe 
config just changed and this goes away automatically?

This is with -hg latest as of now.

This system uses PAM for local users.  Do I need to replicate all of the 
system users including those who do not need any extra settings, in the 
passwd.extra file too?

Is my syntax above for two mail_replica servers correct?

Thanks,
Reuben