[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