[Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
Rickard Nilsson
rickard.nilsson at telia.com
Tue Apr 23 18:33:44 EEST 2013
Den 2013-04-23 17:20:02 skrev Timo Sirainen <tss at iki.fi>:
> On 23.4.2013, at 17.58, Rickard Nilsson <rickard.nilsson at telia.com>
> wrote:
>
>> The problem is the service and auth modules, that dovecot tries to load
>> from the compile-time set MODULE_DIR/{settings,auth}. This is a problem
>> for me, because I can't set the module path during compilation since
>> that introduces a circular dependency between the dovecot package and
>> the virtual dovecot-plugins package.
>
> Sounds like a rather generic problem in nixos. Maybe there could be
> generic way to handle this for other packages too, like maybe creating a
> whole new directory somewhere (e.g. under /var) that has symlinks to all
> the installed plugins?
Yes, that is possible. I can create the plugin directory as part of the
dovecot service startup, I do not need to build it as a separate package.
Could dovecot maybe be made to search for plugins somewhere under
base_dir? I already make sure the base_dir is created before starting the
service, I could assemble a base_dir/plugins or something, too.
>> I have solved this by hacking dovecot to read an environment variable,
>> DOVECOT_CONFIG_MODULE_DIR, in the config_parse_load_modules function.
>> This way I can inject my module path during runtime. But this only
>> works for the master process, not the config process which seems to
>> reset its environment (I assume it does this when dropping privileges).
>> So I did another hack which lets me pass an argument to the config
>> process which contains the module path. I can then set this argument in
>> dovecot.conf by "service config { executable = config /my/module/path
>> }".
>
> You can preserve environments by adding them to import_environment
> setting.
OK, that's good to know, although I would like to avoid the environment
trickery entirely.
>> These hacks work, and I can now use both the sieve mail plugin and the
>> sieve service. I have attached the patch, but this is not a request to
>> add it to the source. My hack is a hack because I don't know enough
>> about the inner workings of dovecot to solve it in a good way. Rather,
>> I'm asking for some way to configure the module path in dovecot, either
>> as an argument to the master process or as a setting in dovecot.conf. A
>> bonus would be the ability to specify several paths that dovecot would
>> search, then I can do away with my virtual module package.
>
> I'd rather make those plugin dirs configurable, since it only adds new
> settings that just about nobody changes (and perhaps I shouldn't have
> added mail_plugin_dir setting either in the first place).
With configurable, you mean compile-time configurable? I could live with
that. The best would be if the configured paths were relative the
base_dir, as mentioned above. But absolute paths could work too (but it
would make it harder to run several instances side-by-side).
/ Rickard
More information about the dovecot
mailing list