Hi,
I have a problem using back-sql and entries with multiple object classes:
If I add the entry:
dn: cn=testuser2,dc=kmux,dc=de cn: testuser2 sn: test objectClass: top objectClass: person objectClass: posixAccount gidNumber: 514 uidNumber: 4711 uid: test2 homeDirectory: hh
I get in the logs of slapd complains that attr uidNumber in objectClass person is undefined. That's right, but the object has the additional class posixAccount, which has the attribute.
When I look in the logs, I see that the table ldap_entry_objectclasses gets inserted the auxiliary class posixAccount AFTER it tries to set the attribute uidNumber. So ist clear that it doen't find the attribute.
The tables in the database are constructed similar to the objectclasses.
Any hints?
<quote who="Wilhelm Meier">
Hi,
I have a problem using back-sql and entries with multiple object classes:
If I add the entry:
dn: cn=testuser2,dc=kmux,dc=de cn: testuser2 sn: test objectClass: top objectClass: person objectClass: posixAccount gidNumber: 514 uidNumber: 4711 uid: test2 homeDirectory: hh
I get in the logs of slapd complains that attr uidNumber in objectClass person is undefined. That's right, but the object has the additional class posixAccount, which has the attribute.
Can you paste soem logs entries?
When I look in the logs, I see that the table ldap_entry_objectclasses gets inserted the auxiliary class posixAccount AFTER it tries to set the attribute uidNumber. So ist clear that it doen't find the attribute.
The tables in the database are constructed similar to the objectclasses.
Any hints?
Wilhelm
Wilhelm Meier wrote:
Hi,
I have a problem using back-sql and entries with multiple object classes:
If I add the entry:
dn: cn=testuser2,dc=kmux,dc=de cn: testuser2 sn: test objectClass: top objectClass: person objectClass: posixAccount gidNumber: 514 uidNumber: 4711 uid: test2 homeDirectory: hh
I get in the logs of slapd complains that attr uidNumber in objectClass person is undefined. That's right, but the object has the additional class posixAccount, which has the attribute.
When I look in the logs, I see that the table ldap_entry_objectclasses gets inserted the auxiliary class posixAccount AFTER it tries to set the attribute uidNumber. So ist clear that it doen't find the attribute.
When data gets inserted in table should have nothing to do with objectClass consistency.
Schema checking occurs __before__ doing anything else in add. So I assume that if a valid entry is passed, back-sql will not barf. We need to know what exactly slapd complains about. And knowing what version of OpenLDAP is creating trouble would be a good start.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Am Samstag, 30. Juni 2007 17:42 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Hi,
I have a problem using back-sql and entries with multiple object classes:
If I add the entry:
dn: cn=testuser2,dc=kmux,dc=de cn: testuser2 sn: test objectClass: top objectClass: person objectClass: posixAccount gidNumber: 514 uidNumber: 4711 uid: test2 homeDirectory: hh
I get in the logs of slapd complains that attr uidNumber in objectClass person is undefined. That's right, but the object has the additional class posixAccount, which has the attribute.
When I look in the logs, I see that the table ldap_entry_objectclasses gets inserted the auxiliary class posixAccount AFTER it tries to set the attribute uidNumber. So ist clear that it doen't find the attribute.
When data gets inserted in table should have nothing to do with objectClass consistency.
Schema checking occurs __before__ doing anything else in add.
Yes, schema checking succeeds:
Jul 2 06:31:29 kmux-postgres slapd[3578]: do_add: dn (cn=testuser2,dc=kmux,dc=de) Jul 2 06:31:29 kmux-postgres slapd[3578]: conn=1 op=1 ADD dn="cn=testuser2,dc=kmux,dc=de" Jul 2 06:31:29 kmux-postgres slapd[3578]: ==>backsql_add("cn=testuser2,dc=kmux,dc=de") Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_required entry (cn=testuser2,dc=kmux,dc=de), objectClass "posixAccount" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_required entry (cn=testuser2,dc=kmux,dc=de), objectClass "person" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "cn" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "sn" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "objectClass" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "gidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "uidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "uid" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "homeDirectory" Jul 2 06:31:29 kmux-postgres slapd[3578]: oc_check_allowed type "structuralObjectClass" Jul 2 06:31:29 kmux-postgres slapd[3578]: => access_allowed: add access to "cn=testuser2,dc=kmux,dc=de" "entry" requested
So I assume that if a valid entry is passed, back-sql will not barf. We need to know what exactly slapd complains about. And knowing what version of OpenLDAP is creating trouble would be a good start.
The version is:
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
... Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): executing "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (DEFAULT,?,?,?,?)" for dn "cn=testuser2,dc=kmux,dc=de" Jul 2 06:31:29 kmux-postgres slapd[3578]: for oc_map_id=3, p_id=1, keyval=2 Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "cn" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): executing "update person set cn=? where id=?" val[0], id=2 Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "sn" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): executing "update person set sn=? where id=?" val[0], id=2 Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "objectClass" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "gidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "gidNumber" is not registered in objectclass "person" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "uidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uidNumber" is not registered in objectclass "person" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "uid" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uid" is not registered in objectclass "person"
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Wilhelm Meier wrote:
Yes, schema checking succeeds:
OK
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
OK
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
Don't be confised by LDAP vs. SQL. In that case, it is setting uidNumber for the SQL person, which is not related to LDAP. It's your mapping that defines what person contains. In back-sql, in fact, entries are essentially based on a structural class, defined by means of the mappings, which contains all attributes of that type of entry. In your case, the mappings for persons must allow also data related to posixAccount. Then, attributes related to posixAccount will only be allowed if the posixAccount class is present in ldap_entry_objclasses.
Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "uidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uidNumber" is not registered in objectclass "person"
Perhaps the logs should be more explicit?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Am Montag, 2. Juli 2007 09:31 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Yes, schema checking succeeds:
OK
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
OK
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
Don't be confised by LDAP vs. SQL. In that case, it is setting uidNumber for the SQL person, which is not related to LDAP. It's your mapping that defines what person contains. In back-sql, in fact, entries are essentially based on a structural class, defined by means of the mappings, which contains all attributes of that type of entry.
What happens if my object has more than one structural objectclass (proposed that the structural classes share the same inheritance line)? Then back-sql searches the attributes in the mapping of the first(?) structural class? Based on which search strategy (Probably the same as the naming in slapd.conf ?)?
In your case, the mappings for persons must allow also data related to posixAccount.
ok, that is, the mapping must accumulate all attributes?
If I have the structural class (person in my example) in different combinations with different other classes, the mapping of the structural class has to have all attributes of all combinations?
Then, attributes related to posixAccount will only be allowed if the posixAccount class is present in ldap_entry_objclasses.
Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "uidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uidNumber" is not registered in objectclass "person"
Perhaps the logs should be more explicit?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Below are some additional questions. Any hints?
Am Montag, 2. Juli 2007 09:31 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Yes, schema checking succeeds:
OK
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
OK
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
Don't be confised by LDAP vs. SQL. In that case, it is setting uidNumber for the SQL person, which is not related to LDAP. It's your mapping that defines what person contains. In back-sql, in fact, entries are essentially based on a structural class, defined by means of the mappings, which contains all attributes of that type of entry.
What happens if my object has more than one structural objectclass (proposed that the structural classes share the same inheritance line)? Then back-sql searches the attributes in the mapping of the first(?) structural class? Based on which search strategy (Probably the same as the naming in slapd.conf ?)?
In your case, the mappings for persons must allow also data related to posixAccount.
ok, that is, the mapping must accumulate all attributes?
If I have the structural class (person in my example) in different combinations with different other classes, the mapping of the structural class has to have all attributes of all combinations?
Then, attributes related to posixAccount will only be allowed if the posixAccount class is present in ldap_entry_objclasses.
Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add(): adding attribute "uidNumber" Jul 2 06:31:29 kmux-postgres slapd[3578]: backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uidNumber" is not registered in objectclass "person"
Perhaps the logs should be more explicit?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Wilhelm Meier wrote:
Below are some additional questions. Any hints?
Am Montag, 2. Juli 2007 09:31 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Yes, schema checking succeeds:
OK
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
OK
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
Don't be confised by LDAP vs. SQL. In that case, it is setting uidNumber for the SQL person, which is not related to LDAP. It's your mapping that defines what person contains. In back-sql, in fact, entries are essentially based on a structural class, defined by means of the mappings, which contains all attributes of that type of entry.
What happens if my object has more than one structural objectclass (proposed that the structural classes share the same inheritance line)? Then back-sql searches the attributes in the mapping of the first(?) structural class?
I don't have the answer right now; I suggest you read the code (you see, this is the difference between open and closed source). In any case, the more you go along that trail, the more you'll get hurt. Back-sql should be intended the other way round: you've got some tables in SQL, you want to render them nicely in LDAP. If your ambition is to implement full LDAP semantics support in back-sql, well, good luck.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Am Freitag, 6. Juli 2007 07:55 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Below are some additional questions. Any hints?
Am Montag, 2. Juli 2007 09:31 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
Yes, schema checking succeeds:
OK
kmux-postgres:/etc/ldap# dpkg -l slapd ii slapd 2.3.30-5 OpenLDAP server (slapd)
OK
In the log below (some lines after the log above) you see that it tries to set the attribute uidNumber for objectClass person - thats wrong!?!
Don't be confised by LDAP vs. SQL. In that case, it is setting uidNumber for the SQL person, which is not related to LDAP. It's your mapping that defines what person contains. In back-sql, in fact, entries are essentially based on a structural class, defined by means of the mappings, which contains all attributes of that type of entry.
What happens if my object has more than one structural objectclass (proposed that the structural classes share the same inheritance line)? Then back-sql searches the attributes in the mapping of the first(?) structural class?
I don't have the answer right now; I suggest you read the code (you see, this is the difference between open and closed source). In any case, the more you go along that trail, the more you'll get hurt. Back-sql should be intended the other way round: you've got some tables in SQL, you want to render them nicely in LDAP. If your ambition is to implement full LDAP semantics support in back-sql, well, good luck.
thanx
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
openldap-software@openldap.org
-
Gavin Henry -
Pierangelo Masarati -
Wilhelm Meier