Re: new feature: LDAP database name resolution

I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:

- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
- Before pg_services.conf is examined, the LDAP servers are contacted
in order until a connection can be established.
- The server is queried for an entry whose distinguished name is
the value of 'service'. A certain attribute is retrieved.
- The resulting string is parsed for options.
- If that fails, pg_services.conf is read as fallback.

I have added a configure option --with-openldap to enable the code.

Does that make sense to you?

Should I try to polish and test the code and submit it as a patch
or is this a lost effort?

Do you have ideas for improvement?

>>> Thank you also for drawing my attention to pg_service.conf - I have
not
>>> been aware of it.
>>> There are two 'shortcomings':
>>> - It still means that you have to change the config file on every
client.
>>
>> Well yes. However, you could generate the config file automatically
>> from another source, either LDAP or something else.
>
> this is definitely the best way of doing it. in fact some folks out
> there use similar configurations to manager large scale systems
> efficiently.

Having to update configuration files on all clients is always a hassle.
Of course it can be done, but isn't it much nicer to have the client
query a configuration server at connection time?

Yours,
Laurenz Albe

Albe Laurenz wrote:
> I am now in the process of writing a patch against CVS HEAD that
> changes fe-connect.c as follows:
>
> - If there is a 'service' option or PGSERVICE is set,

A little off-topic, but related: PeterE recently complained about an
option in pgAdmin which is called "service". Its name originates from
Windows where service is commonly a process running under control of the
service control manager (SCM), comparable to the init process; so for
win32 the naming is accurate. On *ix, pgAdmin accepts a path to pg_ctl
or a script used to control the local postmaster as in /etc/init.d.

It's probably a Good Thing (tm) if new features try to avoid possible
name conflicts with common terms.

Regards,
Andreas

Albe Laurenz wrote:

>I am now in the process of writing a patch against CVS HEAD that
>changes fe-connect.c as follows:
>
>- If there is a 'service' option or PGSERVICE is set, AND the
>environment
> PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
> LDAP name resolution cuts in.
>- Before pg_services.conf is examined, the LDAP servers are contacted
> in order until a connection can be established.
>- The server is queried for an entry whose distinguished name is
> the value of 'service'. A certain attribute is retrieved.
>- The resulting string is parsed for options.
>- If that fails, pg_services.conf is read as fallback.
>
>I have added a configure option --with-openldap to enable the code.
>
>Does that make sense to you?
>
>Should I try to polish and test the code and submit it as a patch
>or is this a lost effort?
>
>Do you have ideas for improvement?
>
>

I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just fine if openldap
is available). Then we could fetch the config from a variety of sources,
not just ldap. Libcurl uses a modified MIT license, so we should not
have any problems on that score. And with luck it would involve less
postgres code maintenance.

The blurb on the libcurl page at http://curl.haxx.se/libcurl/ says:

libcurl is a free <http://curl.haxx.se/docs/copyright.html> and
easy-to-use client-side URL transfer library, supporting FTP, FTPS,
TFTP, HTTP, HTTPS, TELNET, DICT, FILE and LDAP. libcurl supports
HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form
based upload, proxies, cookies, user+password authentication (Basic,
Digest, NTLM, Negotiate, Kerberos4), file transfer resume, http
proxy tunneling and more!

libcurl is highly portable, it builds and works identically on
numerous platforms, including Solaris, NetBSD, FreeBSD, OpenBSD,
Darwin, HPUX, IRIX, AIX, Tru64, Linux, UnixWare, HURD, Windows,
Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, OpenVMS, RISC OS, Novell
NetWare, DOS and more...

cheers

andrew

"Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> writes:
> I am now in the process of writing a patch against CVS HEAD that
> changes fe-connect.c as follows:

> - If there is a 'service' option or PGSERVICE is set, AND the
> environment
> PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
> LDAP name resolution cuts in.
> - Before pg_services.conf is examined, the LDAP servers are contacted
> in order until a connection can be established.
> - The server is queried for an entry whose distinguished name is
> the value of 'service'. A certain attribute is retrieved.
> - The resulting string is parsed for options.
> - If that fails, pg_services.conf is read as fallback.

Uh, why is it a good idea to overload the "service" option like that?
ISTM it'd be less confusing to use a separate option. Further I suggest
that pg_service ought to be handled first, ie, it makes sense to me to
be able to put both the LDAP name and the LDAP server address(es) into a
pg_service.conf entry. The other way (LDAP pointing to pg_service.conf)
is clearly nonsensical, but that doesn't mean that they aren't useful
together.

regards, tom lane

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I would still much prefer to see remote config fetching done in a more
> general way, using say libcurl (which handles ldap just fine if openldap
> is available). Then we could fetch the config from a variety of sources,
> not just ldap.

What other cases are actually interesting? How much code do we save
if we use libcurl instead of homegrown LDAP-accessing code? Does
libcurl bring in any secondary dependencies, or have limitations of
its own (thread safety is one obvious point to ask about)?

Depending on an outside library isn't free, so I think the tradeoff
has to be considered carefully.

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>I would still much prefer to see remote config fetching done in a more
>>general way, using say libcurl (which handles ldap just fine if openldap
>>is available). Then we could fetch the config from a variety of sources,
>>not just ldap.
>>
>>
>
>What other cases are actually interesting? How much code do we save
>if we use libcurl instead of homegrown LDAP-accessing code? Does
>libcurl bring in any secondary dependencies, or have limitations of
>its own (thread safety is one obvious point to ask about)?
>
>Depending on an outside library isn't free, so I think the tradeoff
>has to be considered carefully.
>
>
>
>

It claims to be thread-safe. It has both synch and asynch APIs -
fetching something synchronously involves literally a handful of lines
of code.

There are no dependencies that should bother us - for all our uses they
would be things we normally use anyway, like openssl and zlib. Plus for
this purpose openldap, of course. These are all optional.

As for uses, I could well imagine hosting a service map on an internal
web server, for example. If you want it by property it could even be
done with a CGI script that gives you just the bit you want.

I'm not hugely dogmatic about it, but it seemed to me that for about the
same amount of trouble we could provide a much more general mechanism.

cheers

andrew