Debian - Exim non-split config worried about autogeneration
Not relishing building Exim from scratch on my Debian 6 VPS that I am building, I grabbed the Debian package exim-4-daemon-heavy which seems to have all the elements that I need to use in it already to start dabbling with. I did the auto generation with basic stuff to get it going and chose to go with the non-split config as I am more comfortable with a single config rather than a bunch of split up ones.
One thing I am concerned about is if there would be anything that could cause the auto generation to take place again without my making it do so as I want to change the existing config file pointed to by the exim4 binary located in /var/lib/exim4/config.autogenerated.
Is there anything that would cause this to be auto generated again without me specifically asking for it to be done?
6 Replies
If you selected non-split config in settings, you're supposed to edit /etc/exim4/exim4.conf.template, which's a full, nearly-complete config file, except for a few DEBCONF macros. Leave these intact (and change them via "dpkg-reconfigure exim4-config"), edit rest as you wish.
/etc/init.d/exim4 restart automatically regenerates config.autogenerated from exim4.conf.template (or the split files in /etc/exim4/conf.d if you'd have chosen that option.
If you really, really want to avoid debconf totally, write your own config file in another location, and edit /etc/default/exim4 to add a commandline flag that'll make exim use that file instead of config.autogenerated.
On the command line, you can change where exim looks for the config file, but that opens a can of worms as the same binary is used for a lot of other mail commands.
Changing the start up script will be needed unless I stick to the "standard".
Thanks for the info because I wasn't really sure what was actually doing what before. Searches on this was finding lots of how to change the configuration from within the debian model, but not how it actually worked.
But I've just found something that you should be VERY interested in:
> 2.1.6. Using a completely different configuration scheme
If you are an experienced Exim administrator, you might feel working with our pre-fabricated configuration cumbersome and complex. You might feel right if you need to make more complex changes and do not need to receive updates from us. This section is going to tell about how to use your own configuration.
But, you might profit from keeping the Debian magic. Most files that come with Debian exim4 are conffiles. Debian is going to care about your changes and keeps them around. Additionally, a lot of configuration options can be overridden with a macro, which does not require you to actually change our configuration file. A lot of people are using our configuration scheme, and maybe it is going to save you a lot of time if you decide to spend some time familiarizing yourself with our scheme.
2.1.6.1. Override exim4-config configuration magic
If you are only running a small number of systems and want to completely disable Debian's magic, just take your monolithic configuration file and install it as /etc/exim4/exim4.conf. Exim will use that file verbatim. To have something to start, you can either take /etc/exim4/exim4.conf.template, run update-exim4.conf –keepcomments --output /etc/exim4/exim4.conf, or use upstream's default configuration file that is installed as /usr/share/doc/exim4-base/examples/example.conf.gz. You are going to lose all magic you get from packaging though, so you need to be familiar with Exim to build an actually working config.
/var/lib/exim4/config.autogenerated, the file generated by update-exim4.conf, is ignored as soon as /etc/exim4/exim4.conf is found. You should not edit /etc/exim4/exim4.conf directly when Exim is running, because the forked processes Exim starts for SMTP receiving or queue running would use the new configuration file, while the original main exim-daemon would still use the old configuration file.
G'luck!
I have already made changes using a slightly different method and have my full default Exim system up and running along with all the capabilities that I am used to. From the configuration point of view (single config file) it is almost identical to the rest of the servers that I manage.
I will have to go back and take a look at that info to see if I should adjust what I've done, but so far the changes that I made have worked across reboots and other reconfigurations without any issue.
This is one of the few areas on this server where I have deviated from the normal Debian configuration standard with most of the other services using the standard. It's actually been kind of fun learning the new system as it has been quite a while since I've had to do that with a Unix platform.
Thanks for the info…