Обсуждение: Sample LDIF for pg_service.conf no longer works

Поиск
Список
Период
Сортировка

Sample LDIF for pg_service.conf no longer works

От
Noah Misch
Дата:
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.

Thanks,
nm

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

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

Вложения

Re: Sample LDIF for pg_service.conf no longer works

От
Magnus Hagander
Дата:
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/