Den 2013-04-23 17:20:02 skrev Timo Sirainen <[email protected]>:
On 23.4.2013, at 17.58, Rickard Nilsson <[email protected]>
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
