I've just started to look at this LDAP problem.
On 10 Jun 1999 michael@??? wrote:
> > > Are there any objections against extending the LDAP URLs for exim? If not,
> > > I might send a patch later.
> >
> > I believe the LDAP URLs follow some RFC. I do not know if it would allow
> > for such an extension.
The RFC is 2255. It refers to RFC 1738 for the definition of [hostport]
which is defined as a single host name, followed optionally by :port.
> The RFC would certainly not allow such an extension, but we don't lose
> much by doing something very useful compared to letting a syntactically
> false lookup fail (in the context of a config file!).
That is true, and I have discovered something significant (see below).
> 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. ;)
On this host, a Solaris 2.5.1 machine, using the University of Michigan
LDAP library, I don't appear even to need a patch to get some of the
behaviour you want. I checked out the function that opens a connection
to an LDAP server, ldap_open(), and the specification defines the first
argument as a *list* of blank-separated hosts, to be tried in turn. The
ldap_parse_url() function, which is used to extract the host from the
URL, doesn't seem to mind blanks in the string, so I did some
experiments. Sure enough, if the first host is down, it goes on to the
second one. What is more, I'm pretty sure it tries all the IP addresses
if the host has more than one. (I tried it on a domain with two
addresses pointing to two different hosts, and it always found the one
on which I was listening, however many times I tried.)
So: It appears that the facility is already present, at least at the
ldap_open() level, though strictly this breaks the rules for the URL.
However: there are other circumstances that cause deferment, namely
1. failure to bind to the host after setting up the connection
2. some kind of syntax error
3. timeout on the query
4. too many entries returned
I don't think you't want to try another server for 2 and 4, so the
question is: are 1 and 3 cases that are going to happen often enough in
practice to make it worth putting in special code for them?
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
