On 2012-09-07 at 11:17 +0100, Oliver Howe wrote: > I have a few servers that I'd like to use a default Exim config file > for. But some of these servers need a few values to be different, > e.g 'server A' will have recipients_max set to 50 and 'server B' will > have it set to 250 . > > I see that I can include another config file > > http://www.exim.org/exim-html-current/doc/html/spec_html/ch06.html > > so if I have a default value for recipients_max=50 in the main > Exim.cong file, but then add another value for it to be 250 in an > included file, which one will take preference? > > Or is there a better way of achieving this?
Lookups for options which take expanded strings help, but won't help with recipients_max. You might use macros; at the start of the file, ".include_if_exists" an overrides file, which defines macros with the values, then have macros to define defaults, guarded by ".ifndef" checks. Then when you set the options, set the value to be the macro. Whether this is acceptable depends upon your workload; every delivery attempt, etc, will fork and exec, re-reading in the config file. Most of the pain should be alleviated by the config files being in the system buffer cache. Myself, my better way would be to recognise that similar configurations are being deployed to multiple machines and to start investing the time in deploying a cluster configuration management system, such as Puppet (or Chef, cfengine, etc). Then let the Exim config file be templatised, so that the values are expanded when the file is written out during deployment. All configuration management systems suck. None of them suck as much as not using a configuration management system. Pick one based on what folks in your technical community use and can provide help with; default to Puppet if nothing else, simply because it has more momentum behind it. Stick the configs into git or subversion or mercurial -- whatever fits best with your local practice. None provide a compelling enough benefit for operational configurations to justify being different from what developers/others are using. If you're not using configuration management right now, that's another pain point to address. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
