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
