Greg Folkert said:
> --
> I am an admittedly huge zealot for the Debian way of doing things... >
> But, don't let that cloud you judgment here.
>
> I am using exim v4.30 with exiscan compiled in (exim4-daemon-heavy) from
> the debian repositories. Recently Andreas Metzler and Marc Haber made a
> truly remarkable change to the way the Exim Config is handled in Debian.
>
> Instead of having one huge monolithic config file, with which I >
sometimes get corn-fused as to exactly where I am in the file, I have a >
"conf.d" directory with more directories such as:
>
> acl, auth, main, retry, rewrite, router, transport
Kevin Reed said:
>Yuck
>
>Hopefully not... It is way to easy to search around a single file where
>everything is located to make changes. For me anyway.
>
>For a really complex site, I can see moving that direction as the number
>of rules etc increase, but for learning a system like this which already
>can be tough since you are normally replacing something that has to be
>working out of the chute why add all that complexity.
>
>MOHO...
--
I would have to agree with Kevin and most of the other posters on not
makeing this type of thing a 'standard' out of the box.
And just to make a note here, I use one very large commented config
file for multiple boxes with different configs and have a perl script
parse it out when exim starts into an uncommented 'runtime' file
(done not by exim of course).
I have sections global to all, then chunks of data seperated by the
type of machine the config is to run on with html style
'<CONFIG-TYPE> </CONFIG-TYPE>' where they need to be so the flow of the
file is never broken as to when a partcular chunk is to be run. I even
have the file fill-in machine specific information such as hostnames, or
node numbers, etc, with <$CONFIG> statements 'host_name=<$CONFIG>'.
Some, or most would find this terribly confussing but i like it very much
as I have lots of machines that are the same as for OS build, but need
to do different things. This way I can just roll out one master file to
all and not worry about it.
The best part I think is that that actual master config file will not parse
by exim as it is not in 'parsable exim config format' so I do not have to
worry about the full file ever being loaded accidentally. The perl script
(which could also be a bash, etc. script) also supports making seperate
commented machine-files so that I have at least three ways to check a
config file on any one machine.
I keep a running 'change' log in file so that I know what I did since the
last update (serialized and all).
Sometimes you need to look at uncommented files, and sometimes you need
the comments to understand why something was done. Either way, I never see
the reason to make a progam parse a bunch of comments all the time.
Any way.... as you can see, there are many different ways that things can
be done, and we all find them 'easy for us'.
Welcome to the power of text file configuration!!!
Now, just try that with an Exchange server configuration ;)
...since you all probably get tired of me always defending MS...
--EAL--
