Hi Enrico, On Tue, Jan 17, 2017 at 2:18 PM, Enrico Zini <[email protected]> wrote: > Hello, > > I am exploring ways of managing prosody configuration, and I would like to > deploy in a way that the original prosody.cfg.lua remains unchanged, and I do > everything via conf.d files. > > The first issue I hit is that prosody.cfg.lua defines `VirtualHost > "example.com"`, > and all configuration following that line goes to the example.com virtualhost. > This means that I cannot add a file /etc/prosody/conf.d/local.cfg.lua that > contains global directives like: > > c2s_require_encryption = true > s2s_secure_auth = true > s2s_insecure_domains = { "gmail.com" } > > I should however be able to work around that by redefining VirtualHost to "*", > though I haven't tried yet.
Currently, the VirtualHost is commented out, so this problem is gone, but in fact, you still cannot use global directives in the included files because the order in which they are processed isn't defined. They are included in order lfs.dir() iterates over them. I don't know if setting VirtualHost to "*" can help though (haven't tried myself). > > > The second issue is that I cannot seem to be able to access the configuration > values set so far. I would like this to be able to add modules without > clobbering the default list of modules, as in doing something like this: > > table.insert(modules_enabled, "carbons") > table.insert(modules_enabled, "privacy") > table.insert(modules_enabled, "blocking") > table.insert(modules_enabled, "smacks") > table.insert(modules_enabled, "mam") > table.insert(modules_enabled, "throttle_presence") > table.insert(modules_enabled, "filter_chatstates") This would be very helpful but I think it needs to be coordinated upstream. > > However, because the prosody config loader redefines __newindex for the > configuration code, values that are set are not found in the normal Lua > environment, and I couldn't find a way to access them. > > Also, I didn't find a way to get prosody to dump all the configuration that it > has read, so I am currently not sure that if I set a global option in an > included config file, it actually rewrites its previous value. > > > If these kinds of overrides/updates in included file were possible, I could > have a deployment configuration that maintains maintainer changes on the > original config file, which I feel is a nicely more future-proof way of > managing it. Right, modifying separate subconfigs without touching the main config file would be useful. Cheers! -- Sergei Golovan
