[Date Prev][Date Next]
Re: back-sql and multiple objectclasses
Below are some additional questions. Any hints?
Am Montag, 2. Juli 2007 09:31 schrieb Pierangelo Masarati:
> Wilhelm Meier wrote:
> > Yes, schema checking succeeds:
> > 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!?!
> 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
> your case, the mappings for persons must allow also data related to
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: backsql_add(): adding
> > attribute "uidNumber"
> > Jul 2 06:31:29 kmux-postgres slapd:
> > backsql_add_attr("cn=testuser2,dc=kmux,dc=de"): attribute "uidNumber" is
> > not registered in objectclass "person"
> Perhaps the logs should be more explicit?
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: email@example.com