Full_Name: Paul Cunningham Version: openldap-2_0-alpha3 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.126.24.200) If I try to read the schema from the LDAP V3 server using: ldapsearch -h scofix -b "cn=schema" -s base "objectclass=*" it only returns the following: CN=SCHEMA cn=SCHEMA objectclass=top objectclass=LDAPsubentry objectclass=subschema objectclass=extensibleObject shouldn't it return the full schema definition (netscapeDS & IBMSecureWay do). Is this a bug or am I doing something wrong. Thanks.
At 01:02 PM 4/11/00 GMT, paulcun@sco.com wrote: >Full_Name: Paul Cunningham >Version: openldap-2_0-alpha3 >OS: Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (150.126.24.200) > > >If I try to read the schema from the LDAP V3 server using: > > ldapsearch -h scofix -b "cn=schema" -s base "objectclass=*" > >it only returns the following: > > CN=SCHEMA > cn=SCHEMA > objectclass=top > objectclass=LDAPsubentry > objectclass=subschema > objectclass=extensibleObject > >shouldn't it return the full schema definition (netscapeDS & IBMSecureWay >do). > >Is this a bug or am I doing something wrong. You did not specify which attribute types to return. As they are operational, you must explicitly list them.
paulcun@sco.com wrote: > > If I try to read the schema from the LDAP V3 server using: > > ldapsearch -h scofix -b "cn=schema" -s base "objectclass=*" > > it only returns the following: > > CN=SCHEMA > cn=SCHEMA > objectclass=top > objectclass=LDAPsubentry > objectclass=subschema > objectclass=extensibleObject > > shouldn't it return the full schema definition (netscapeDS & IBMSecureWay > do). Why do you set -b to "cn=schema" ? Why not -b "" ? Beside in the RFC : Clients MUST only retrieve attributes from a subschema entry by requesting a base object search of the entry, where the search filter is "(objectClass=subschema)". (This will allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested.) So your "(objectClass=*)" must be "(objectClass=subschema)". -- Yohann F.
changed notes changed state Open to Closed
At 04:52 PM 4/11/00 GMT, yohann.fourteau@webmotion.net wrote: >paulcun@sco.com wrote: >> >> If I try to read the schema from the LDAP V3 server using: >> >> ldapsearch -h scofix -b "cn=schema" -s base "objectclass=*" >> >> it only returns the following: >> >> CN=SCHEMA >> cn=SCHEMA >> objectclass=top >> objectclass=LDAPsubentry >> objectclass=subschema >> objectclass=extensibleObject >> >> shouldn't it return the full schema definition (netscapeDS & IBMSecureWay >> do). > >Why do you set -b to "cn=schema" ? Why not -b "" ? The base should be the DN of the desired subschema subentry as determined by reading the subschemasubentry attribute of the entry to be access (or, if adding an entry, the entry at the root of the namingContext). As hinted to in RFC 2251 (and clarified in IETF LDAPext WG discussion), clients cannot rely on the value(s) subschemasubentry attribute of the RootDSE to apply a particular naming context. [In fact, the subschemasubentry of the RootDSE *should* be the subschema controlling the RootDSE itself which may be quite different than that controlling a particular naming context]. I hope to get this and related issues clarified in RFC2251bis documents (when they are drafted). Kurt
devel issue