Disabling of userdb/passdb modules using config statements
Hola,
Debian (and possibly other distros) use the /etc/dovecot/conf.d/* setup where default config files are stuffed and then one can just add a 99-myconfig.conf et voila, variables are overruled.
This allows the distro to supply updates to the files at package upgrade time without any/much user intervention.
The problem (for me ;) is that the system comes provided with:
auth-system.conf.ext containing:
passdb { driver = pam } userdb { driver = passwd }
Hence pam & /etc/passwd based are always enabled. This while I don't have any local users.
Replication seems to then always pick up the local users, which are vmail + nobody (65536).
doveadm user '*' thus reports vmail, nobody + virtual users
Setting: first_valid_uid = 5000 last_valid_uid = 5000
only keeps vmail in there, but apparently some module (guess replication) is still able to figure out that 'nobody' exists:
Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: Mail access for users with UID 65534 not permitted (see first_valid_uid in config file, uid from userdb lookup). Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: dsync-server: User init failed Apr 10 09:49:38 mail dovecot: doveadm(nobody): Error: sync: Failed to start remote dsync-server command: Remote exit_code=75
and on the other side: Apr 10 09:54:38 mail dovecot: doveadm(nobody): Error: sync: Unknown user in remote
This can be resolved by commenting out the entries in auth-system.conf.ext but then I'll have to do that again at package upgrade time.
Hence, would it be a cool option to be able (in the 99-myconfig.conf) file to put:
passdb { driver = pam enabled = false } userdb { driver = passwd enabled = false }
And thereby disabling those modules completely? Thus avoiding upgrade conflicts etc.
Greets, Jeroen
On 04/10/2015 05:59 AM, Jeroen Massar wrote:
This can be resolved by commenting out the entries in auth-system.conf.ext but then I'll have to do that again at package upgrade time.
Comment out the !include auth-system.conf.ext line in 10-auth.conf.
Hence, would it be a cool option to be able (in the 99-myconfig.conf) file to put:
Actually you mean local.conf. See the master dovecont.conf file, it's included last.
passdb { driver = pam enabled = false } userdb { driver = passwd enabled = false }
And thereby disabling those modules completely? Thus avoiding upgrade conflicts etc.
That's an interesting idea actually. My first thought is that it could be helpful to use *named* passdb / userdb sections to facilitate this.
Greets, Jeroen
On 2015-04-10 12:16, Gedalya wrote:
On 04/10/2015 05:59 AM, Jeroen Massar wrote:
This can be resolved by commenting out the entries in auth-system.conf.ext but then I'll have to do that again at package upgrade time.
Comment out the !include auth-system.conf.ext line in 10-auth.conf.
Though indeed simpler than commenting out multiple lines, that file also gets replaced by a package upgrade.
Hence does not solve the 'can just upgrade silently' issue.
Hence, would it be a cool option to be able (in the 99-myconfig.conf) file to put: Actually you mean local.conf. See the master dovecont.conf file, it's included last.
Only when it exists, one can use both.
from dovecot.conf: 8<------------- # Most of the actual configuration gets included below. The filenames are # first sorted by their ASCII value and parsed in that order. The 00-prefixes # in filenames are intended to make it easier to understand the ordering. !include conf.d/*.conf
# A config file can also tried to be included without giving an error if # it's not found: !include_try local.conf --------------------------->8
Both conf.d/99-myconfig.conf and local.conf can work for this.
I prefer 99- as that is what other daemons also use.
passdb { driver = pam enabled = false } userdb { driver = passwd enabled = false }
And thereby disabling those modules completely? Thus avoiding upgrade conflicts etc.
That's an interesting idea actually. My first thought is that it could be helpful to use *named* passdb / userdb sections to facilitate this.
That would require a default system, which now works out of the box with pam/etc to be properly named and then renamed...
Greets, Jeroen
On Sex, 10 Abr 2015, Jeroen Massar wrote:
Though indeed simpler than commenting out multiple lines, that file also gets replaced by a package upgrade.
Hence does not solve the 'can just upgrade silently' issue.
If the file is unchanged then, yes, it gets replaced on upgrades. If
it has local changes, however, you'll get a prompt asking what you
want to do (keep your changes or use the package version). So while it
fails you "upgrade silently" requirement, you'll not automatically
loose the changes you've made.
Eduardo M KALINOWSKI eduardo@kalinowski.com.br
On 2015-04-10 14:23, Eduardo M KALINOWSKI wrote:
On Sex, 10 Abr 2015, Jeroen Massar wrote:
Though indeed simpler than commenting out multiple lines, that file also gets replaced by a package upgrade.
Hence does not solve the 'can just upgrade silently' issue.
If the file is unchanged then, yes, it gets replaced on upgrades. If it has local changes, however, you'll get a prompt asking what you want to do (keep your changes or use the package version). So while it fails you "upgrade silently" requirement, you'll not automatically loose the changes you've made.
That is correct, though as I don't want to ever be asked about such things, I am looking for a nicer solution and suggested the 'enabled = false' option for these kind of situations.
One does not want to manually approve such changes on every box one runs, can be quite a few of them ;)
Greets, Jeroen
On 04/10/2015 08:28 AM, Jeroen Massar wrote:
That is correct, though as I don't want to ever be asked about such things, I am looking for a nicer solution and suggested the 'enabled = false' option for these kind of situations.
If you have many boxes then I'll assume you have already tested your upgrade path and you have some solid reasons to assume the new version will upgrade smoothly and you have already done the necessary preparations, and you're only missing the information about how to manage these prompts.
http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-mana...
Once again, a config file only needs to be replaced if it has actually changed upstream, and most of the changes upstream are commented out because 90% of dovecot config files is commented out, either actual comments or commented-out settings that serve only to document the defaults.
If upgrading from e.g. 2.2.15 to 2.2.16, chances are you can totally skip all config file changes. If upgrading from 2.1, you have bigger problems than this. Keep things in perspective :-)
On 04/10/2015 08:23 AM, Eduardo M KALINOWSKI wrote:
On Sex, 10 Abr 2015, Jeroen Massar wrote:
Though indeed simpler than commenting out multiple lines, that file also gets replaced by a package upgrade.
Hence does not solve the 'can just upgrade silently' issue.
If the file is unchanged then, yes, it gets replaced on upgrades. If it has local changes, however, you'll get a prompt asking what you want to do (keep your changes or use the package version). So while it fails you "upgrade silently" requirement, you'll not automatically loose the changes you've made.
Actually, a config file in Debian is replaced if it has _not_ been changed locally, and it _has_ been changed upstream. If it has been changed on both sides, you get prompted. If the new package is just a security update, which in most cases means changes to the binaries and not to the default config, then it will just install without prompts, and not touch your config files. If it's an entirely new version, then the desire to just upgrade silently is sort of inappropriate anyway - you will need some preparation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 10 Apr 2015, Jeroen Massar wrote:
Debian (and possibly other distros) use the /etc/dovecot/conf.d/* setup where default config files are stuffed and then one can just add a 99-myconfig.conf et voila, variables are overruled.
This allows the distro to supply updates to the files at package upgrade time without any/much user intervention.
The problem (for me ;) is that the system comes provided with:
auth-system.conf.ext containing:
passdb { driver = pam } userdb { driver = passwd }
Hence pam & /etc/passwd based are always enabled. This while I don't have any local users.
Isn't that a packaging problem then? Debian should use DEBCONF to ask you while installation, which db to enable by default. You should file a bug with Debian to let the admin choose, which (if at all) db to enable by default. There are no config files installed by Dovecot, if compiled by source.
Replication seems to then always pick up the local users, which are vmail + nobody (65536).
doveadm user '*' thus reports vmail, nobody + virtual users
Setting: first_valid_uid = 5000 last_valid_uid = 5000
only keeps vmail in there, but apparently some module (guess replication) is still able to figure out that 'nobody' exists:
Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: Mail access for users with UID 65534 not permitted (see first_valid_uid in config file, uid from userdb lookup). Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: dsync-server: User init failed Apr 10 09:49:38 mail dovecot: doveadm(nobody): Error: sync: Failed to start remote dsync-server command: Remote exit_code=75
and on the other side: Apr 10 09:54:38 mail dovecot: doveadm(nobody): Error: sync: Unknown user in remote
This can be resolved by commenting out the entries in auth-system.conf.ext but then I'll have to do that again at package upgrade time.
Hence, would it be a cool option to be able (in the 99-myconfig.conf) file to put:
passdb { driver = pam enabled = false } userdb { driver = passwd enabled = false }
And thereby disabling those modules completely? Thus avoiding upgrade conflicts etc.
Greets, Jeroen
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEVAwUBVSvDzHz1H7kL/d9rAQJybAgAyOmtGbDyp6nzR0IqK2RUTWTHtjkbcmrN G6MNxMCzsByp7JCCKaKZy4Ec9//4ua5+29zwsF4f/EjdyxOtCdZkOA2TRuw3Zbns nuECm4h03HsjkGIi216mMHP3z2QjqTuZNWFj0MppBuiBqSuNrNFfxQ0pac3xEeAo IYnKl1Oq4SKfwr351iF94NSHzCbR7CJDe5Q7TqkK8OB7PuASFIbYX9R6CYZc1jsR euLRHKssX7Brw44PkQGLjHEOBG8xWP4/cAVf4bApskSiW8q1IZWhMR7Z4rbUgxRY 3RInqI/rJ8azOjZWd8Us25eCJl3f30bFkdbmOlL6LlUkzPAjMPx/3A== =MZqU -----END PGP SIGNATURE-----
participants (4)
-
Eduardo M KALINOWSKI
-
Gedalya
-
Jeroen Massar
-
Steffen Kaiser