Sample LDIF for pg_service.conf no longer works

Started by Noah Mischover 11 years ago2 messages

noah@leadboat.com

over 11 years ago

1 attachment(s)

When using pg_service.conf with LDAP, we document[1]http://www.postgresql.org/docs/devel/static/libpq-ldap.html the following sample LDIF
for populating the LDAP server:

version:1
dn:cn=mydatabase,dc=mycompany,dc=com
changetype:add
objectclass:top
objectclass:groupOfUniqueNames
cn:mydatabase
uniqueMember:host=dbserver.mycompany.com
uniqueMember:port=5439
uniqueMember:dbname=mydb
uniqueMember:user=mydb_user
uniqueMember:sslmode=require

That presumably worked at one point, but OpenLDAP 2.4.23 and OpenLDAP 2.4.39
both reject it cryptically:

ldap_add: Invalid syntax (21)
additional info: uniqueMember: value #0 invalid per syntax

uniqueMember is specified to bear a distinguished name. While OpenLDAP does
not verify that uniqueMember values correspond to known DNs, it does verify
that the value syntactically could be a DN. To give examples, "o=foobar" is
always accepted, but "xyz=foobar" is always rejected: "xyz" is not an LDAP DN
attribute type. Amid the LDAP core schema, "device" is the best-fitting
objectClass having the generality required. Let's convert to that, as
attached. I have verified that this works end-to-end.

Thanks,
nm

[1]: http://www.postgresql.org/docs/devel/static/libpq-ldap.html

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

Attachments:

ldif-sample-device-v1.patchtext/plain; charset=us-asciiDownload

commit 957b58f (HEAD)
Author:     Noah Misch <noah@leadboat.com>
AuthorDate: Mon Aug 4 00:03:21 2014 -0400
Commit:     Noah Misch <noah@leadboat.com>
CommitDate: Mon Aug 4 00:03:21 2014 -0400

    Make pg_service.conf sample LDIF more portable.
    
    The aboriginal sample placed connection parameters in
    groupOfUniqueNames/uniqueMember.  OpenLDAP, at least as early as version
    2.4.23, rejects uniqueMember entries that do not conform to the syntax
    for a distinguished name.  Use device/description, which is free-form.
    Back-patch to 9.4 for web site visibility.

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index db634a8..ef45fbf 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -7043,17 +7043,17 @@ version:1
 dn:cn=mydatabase,dc=mycompany,dc=com
 changetype:add
 objectclass:top
-objectclass:groupOfUniqueNames
+objectclass:device
 cn:mydatabase
-uniqueMember:host=dbserver.mycompany.com
-uniqueMember:port=5439
-uniqueMember:dbname=mydb
-uniqueMember:user=mydb_user
-uniqueMember:sslmode=require
+description:host=dbserver.mycompany.com
+description:port=5439
+description:dbname=mydb
+description:user=mydb_user
+description:sslmode=require
 </programlisting>
    might be queried with the following LDAP URL:
 <programlisting>
-ldap://ldap.mycompany.com/dc=mycompany,dc=com?uniqueMember?one?(cn=mydatabase)
+ldap://ldap.mycompany.com/dc=mycompany,dc=com?description?one?(cn=mydatabase)
 </programlisting>
   </para>

Magnus Hagander

magnus@hagander.net

over 11 years ago

In reply to: Noah Misch (#1)

Re: Sample LDIF for pg_service.conf no longer works

On Sat, Aug 16, 2014 at 5:31 AM, Noah Misch <noah@leadboat.com> wrote:

When using pg_service.conf with LDAP, we document[1] the following sample LDIF
for populating the LDAP server:

version:1
dn:cn=mydatabase,dc=mycompany,dc=com
changetype:add
objectclass:top
objectclass:groupOfUniqueNames
cn:mydatabase
uniqueMember:host=dbserver.mycompany.com
uniqueMember:port=5439
uniqueMember:dbname=mydb
uniqueMember:user=mydb_user
uniqueMember:sslmode=require

That presumably worked at one point, but OpenLDAP 2.4.23 and OpenLDAP 2.4.39
both reject it cryptically:

ldap_add: Invalid syntax (21)
additional info: uniqueMember: value #0 invalid per syntax

uniqueMember is specified to bear a distinguished name. While OpenLDAP does
not verify that uniqueMember values correspond to known DNs, it does verify
that the value syntactically could be a DN. To give examples, "o=foobar" is
always accepted, but "xyz=foobar" is always rejected: "xyz" is not an LDAP DN
attribute type. Amid the LDAP core schema, "device" is the best-fitting
objectClass having the generality required. Let's convert to that, as
attached. I have verified that this works end-to-end.

+1.

I've run into that problem as wel,l just not had time to prepare a
proper example in the core schema :)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers