In article <Pine.SOL.3.96.990610140803.5384M-100000@???>,
Philip Hazel <ph10@???> wrote:
>On 10 Jun 1999 michael@??? wrote:
>
>> > Not sure. This is mainly contributed code which I did not originate.
>> > Presumably the belief is that this is a configuration error, so the
>> > message should be kept and tried again - hopefully when the
>> > configuration has been corrected. This is similar to deferring for a
>> > syntax error in an Exim filter file.
>>
>> Ok, so I vote for fail instead of defer.
>What do other LDAP users on this list think? I do not use LDAP, so I
>don't have a feel for this.
>
As always when the is a valid debate about something like this it is
because both points of view are correct in some context. And probably
means that the decision must be made by the administrators not the implementors.
What is required is:
- ability to specify multiple servers to send the queries to in case of defer
- ability to specify successive queries in case of failure
Or something like:
for (query in query_list) do
{
for (server in server_list) do
{
if (connect(server) {
send_query(server);
break;
}
}
}
This does point out quite nicely the limitation with LDAP URL's. I can't
remember if this has been addressed in the latest URL draft.
I would "vote" to keep the URL format intact. It is used so that (hopefully)
people used to using them elsewhere will feel comfortable.
We also already have the ability to specify multiple queries to use in case
of failure.
So really all we need to do is be able to try additional hosts if we have a
defer situation.
I would suggest either having exim attempt to connect to additional ldap servers
as defined by multiple A records (round robin dns). I.e. pick one at random. If
you can connect continue. If not delete from list and start over. If you end up
with nothing in the list then return defer.
It *might* also be useful to have a global variable which specifies a list of
servers to connect to. The URL format specifically allows for the host portion
to be empty with the choice then being left to the software. This could be further
complicated by having two global variables. One a list of hosts to connect to
in random order (same as round robin dns). One a list of hosts to connect to
in a specific order. Again I can see both being useful in different situations.
>> I don't know if the RFC defines that the protocol://host[:port] part of
>> an URL has to resolve to an A record or if SRV records would be allowed
>> as well. I do know that I need a solution to my problem of a fall-back
>> host urgently and the appended patch appears to provide it. ;)
>
>Again, what do other LDAP users think of this patch? If it is generally
>liked, I have no objection to considering it for inclusion.
--
Stuart Lynne <sl@???> 604-461-7532 <http://edge.fireplug.net>
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 88 EC A3 EE 2D 1C 15 68
--
*** Exim information can be found at
http://www.exim.org/ ***
