Обсуждение: ldapi support
After the LDAP code was switched to use ldap_initialize() as part of the ldaps support, ldapi (LDAP over Unix-domain sockets) also works. I noticed an old bug report (#13625) that asked for it. So I suggest this patch to document this and add some tests. One flaw is that this only works when using the URL syntax. Providing a separate option would require coding URL escaping, since ultimately an URL must be composed and passed to ldap_initialize(). But since OpenLDAP apparently now considers URLs to be the preferred form for connection parameters, I'm comfortable just sticking to that format. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
On Fri, Feb 9, 2018 at 4:05 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > After the LDAP code was switched to use ldap_initialize() as part of the > ldaps support, ldapi (LDAP over Unix-domain sockets) also works. I > noticed an old bug report (#13625) that asked for it. So I suggest this > patch to document this and add some tests. > > One flaw is that this only works when using the URL syntax. Providing a > separate option would require coding URL escaping, since ultimately an > URL must be composed and passed to ldap_initialize(). But since > OpenLDAP apparently now considers URLs to be the preferred form for > connection parameters, I'm comfortable just sticking to that format. Nice. The test doesn't actually succeed in reloading the pg_hba.conf file though: 2018-02-09 16:41:15.886 NZDT [24472] LOG: received SIGHUP, reloading configuration files 2018-02-09 16:41:15.893 NZDT [24472] LOG: unsupported LDAP URL scheme: ldapi 2018-02-09 16:41:15.893 NZDT [24472] LOG: pg_hba.conf was not reloaded I think hba.c needs to learn to consider "ldapi" to be acceptable (after it parses the URL). Then I think when InitializeLDAPConnection() reconstitutes the URL with psprintf, it'll probably need to avoid sticking :port on the end. The fact that we take the URL to pieces and then stick it back together again may seem a bit odd, but it is required by the documentation (ldap_initialize() wants a URL "containing only the schema, the host, and the port fields"). I see there is another scheme called "cldap" (which seems to be something like LDAP over UDP). I wonder if anyone cares about that. -- Thomas Munro http://www.enterprisedb.com
On 2/8/18 22:56, Thomas Munro wrote: > The test doesn't actually succeed in reloading the pg_hba.conf > file though: > > 2018-02-09 16:41:15.886 NZDT [24472] LOG: received SIGHUP, reloading > configuration files > 2018-02-09 16:41:15.893 NZDT [24472] LOG: unsupported LDAP URL scheme: ldapi > 2018-02-09 16:41:15.893 NZDT [24472] LOG: pg_hba.conf was not reloaded Hmm. I think the ldap test suite should be changed to use $node->restart instead of $node->reload, so we can be sure that the various pg_hba.conf lines are actually accepted. It appears that doing so wouldn't impact the run time significantly. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Feb 09, 2018 at 08:44:38PM -0500, Peter Eisentraut wrote: > Hmm. I think the ldap test suite should be changed to use > $node->restart instead of $node->reload, so we can be sure that the > various pg_hba.conf lines are actually accepted. It appears that doing > so wouldn't impact the run time significantly. Does this mean that some portion of LDAP cofiguration cannot be reloaded? It seems backwards to me to not test that. -- Michael
Вложения
On 2/10/18 19:46, Michael Paquier wrote: > On Fri, Feb 09, 2018 at 08:44:38PM -0500, Peter Eisentraut wrote: >> Hmm. I think the ldap test suite should be changed to use >> $node->restart instead of $node->reload, so we can be sure that the >> various pg_hba.conf lines are actually accepted. It appears that doing >> so wouldn't impact the run time significantly. > > Does this mean that some portion of LDAP cofiguration cannot be > reloaded? It seems backwards to me to not test that. Well, my mistake was that some part of my newly proposed pg_hba.conf test snippet did not load and the test did not recognize that. What we currently do is effectively something like echo 'xxx' >pg_hba.conf pg_ctl reload test1 try to connect echo 'yyy' >pg_hba.conf pg_ctl reload test2 try to connect But if for some reason 'yyy' is not accepted, the reload will log an error message and leave the 'xxx' configuration in place. So then the test2 will run against a configuration that was not meant for it. My proposal is that we instead write echo 'xxx' >pg_hba.conf pg_ctl restart test1 try to connect echo 'yyy' >pg_hba.conf pg_ctl restart test2 try to connect Here, if 'yyy' is not accepted, the restart will error out, the test run will fail, and we'd know something is wrong. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services