Sample LDIF for pg_service.conf no longer works
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+7-7
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=requireThat 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 syntaxuniqueMember 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