Hello.
>
> What happens when those caching servers get out of sync? What happens
> if they crash? ...
That means that if an exim gets HUPped, it does not restart.
Monitoring will catch the crash of the LDAP server before significant
number of exims get down.
After all, LDAP is only one of possible protocols to fetch the configuration data.
I can use HTTP, or MySQL or just about anything else as well if LDAP servers
prove to be unreliable.
>>>Besides, some people don't use LDAP and would have to learn just to make
>>>Exim work. It adds another layer of complexity that no one needs.
>>
>>And I'm not suggesting an unconditional move to LDAP-based config as well.
>
>
> *grin* Good.
I suppose even if i write an absolutely solid patch it would not be merged into
exim source because it's too specific.
>>I'm evaluating whether writing a patch and testing will worth it.
>
>
> I think that it will create more problems than it's worth. But what
> worked/works for me may not do for you.
Be sure that I'm getting into this mess in hopes to get out of a larger one :-)
>>All configuration is read from configure file and stored either in global
>>variables or some lists. The fork() takes care of them.
>
>
> Yes, we agree here...
Except that there are some circuimstances when exim execve()-s itself,
where the config would be re-read. I will dig into sources to clarify this.
> Hum... How about haiving the main configuration in cvs somewhere and
> push it to the servers when you want it?
I think CVS isn't quite applicable here. There is no single main configuration,
there are several thousand different configurations that belong to different users.
And there's little point in storing history of textual files, as all user actions
in the [web] interface are logged anyway.
> I don't really understand why you are parsing the config file. What's
> your setup?
One goal is to simplify administration of all those exims without hampering
the flexibility and keeping possiblity of per-host tweaks of the config.
Another, more distant goal is to provide hosting users with as much flexibility
in configuring their mail server via some kind of [web] interface as possible without
allowing them to create an open relay by mistake. This would be of course their
responsibility, but I need to minimize the probability of it happening.
