[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Reading schema via ldap



Title: Reading schema via ldap
Hi Howard,
 
    you are indeed quite correct!  A rereading of the rfc confirms that subschema attributes are operational atts, and therefore need to be explicitly named.  The code now works brilliantly.  I'm now calling:
 
        Attributes rawSchema = ctx.getAttributes(rawSchemaRoot, new String[] {"attributeTypes", "objectClasses", "matchingRules", "ldapSyntaxes", "*" });
// wildcard is for recovering any extra 'public' schema that may be available in some other (non slapd) directories
 
   ... and it works fine. 
 
  Thanks also to Turbo Fredriksson and David Smith for the PHP code examples (which seem to be equivalent to the above, but searching specifically for "objectClasses").
 
One small question though: I haven't been able to get the "+" wild card option working, and I can't find it in the RFC?  Is there any doco on this, or is it a slapd thing?
 
    thanks *very much* to all,
 
       Chris Betts
 
 
 

-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com]
Sent: Saturday, 18 January 2003 1:52 AM
To: Betts, Chris; openldap-software@OpenLDAP.org
Subject: RE: Reading schema via ldap

The attributes you're probably looking for are all operational attributes. You must retrieve them explicitly or use the "+" wildcard in the attribute list to retrieve all of them.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

-----Original Message-----
From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Betts, Chris
Sent: Thursday, January 16, 2003 11:11 PM
To: openldap-software@OpenLDAP.org
Subject: Reading schema via ldap

Hi everyone!

    I'm the primary author of the JXplorer open source ldap browser (http://pegacat.com/jxplorer).  The browser is written in java and uses Sun's jndi to handle it's ldap connections.  In the past I have used jndi 'context.getSchema()' method to read schema from both slapd and other directories.

    Recently I have modified JXplorer to support DSML, and as part of this I needed to do the schema downloading manually.  The steps are:

a) read the subschema subentry from the root context
b) use the read subschema subentry to read the schema entry (which should correspond more or less to RFC 2252).

    Now this works fine for some ldap directories, but seems to fail for slapd (and yet jndi reads it fine, somehow). Since a large number of the users of JXplorer use slapd, this is a problem! When I do the above I get

a) read the subschema subentry from slapd as CN=SCHEMA  (hooray!)
b) attempt to read CN=SCHEMA returns an empty entry (sniff).

   Does anyone have any idea what I am doing wrong?  The code is the equivalent of:

Attributes rawSchema = ctx.getAttributes("CN=SCHEMA");  // Attributes is not null, but empty


and if anyone can read a BER trace, here it is:

-> odlab7:2123

0000: 30 25 02 01 01 63 20 04   00 0A 01 00 0A 01 01 02  0%...c .........
0010: 01 00 02 01 00 01 01 00   87 0B 6F 62 6A 65 63 74  ..........object
0020: 43 6C 61 73 73 30 00                               Class0.


<- odlab7:2123

0000: 30 30 02 01 01 64 2B 04   00 30 27 30 25 04 0B 6F  00...d+..0'0%..o
0010: 62 6A 65 63 74 43 6C 61   73 73 31 16 04 03 74 6F  bjectClass1...to
0020: 70 04 0F 4F 70 65 6E 4C   44 41 50 72 6F 6F 74 44  p..OpenLDAProotD
0030: 53 45                                              SE


<- odlab7:2123

0000: 30 0C 02 01 01 65 07 0A   01 00 04 00 04 00        0....e........


-> odlab7:2123

0000: 30 38 02 01 02 63 33 04   00 0A 01 00 0A 01 01 02  08...c3.........
0010: 01 00 02 01 00 01 01 00   87 0B 6F 62 6A 65 63 74  ..........object
0020: 43 6C 61 73 73 30 13 04   11 73 75 62 73 63 68 65  Class0...subsche
0030: 6D 61 53 75 62 65 6E 74   72 79                    maSubentry


<- odlab7:2123

0000: 30 2B 02 01 02 64 26 04   00 30 22 30 20 04 11 73  0+...d&..0"0 ..s
0010: 75 62 73 63 68 65 6D 61   53 75 62 65 6E 74 72 79  ubschemaSubentry
0020: 31 0B 04 09 43 4E 3D 53   43 48 45 4D 41           1...CN=SCHEMA


<- odlab7:2123

0000: 30 0C 02 01 02 65 07 0A   01 00 04 00 04 00        0....e........


-> odlab7:2123

0000: 30 2E 02 01 03 63 29 04   09 43 4E 3D 53 43 48 45  0....c)..CN=SCHE
0010: 4D 41 0A 01 00 0A 01 01   02 01 00 02 01 00 01 01  MA..............
0020: 00 87 0B 6F 62 6A 65 63   74 43 6C 61 73 73 30 00  ...objectClass0.


<- odlab7:2123

0000: 30 63 02 01 03 64 5E 04   09 43 4E 3D 53 43 48 45  0c...d^..CN=SCHE
0010: 4D 41 30 51 30 3F 04 0B   6F 62 6A 65 63 74 43 6C  MA0Q0?..objectCl
0020: 61 73 73 31 30 04 03 74   6F 70 04 0C 4C 44 41 50  ass10..top..LDAP
0030: 73 75 62 65 6E 74 72 79   04 09 73 75 62 73 63 68  subentry..subsch
0040: 65 6D 61 04 10 65 78 74   65 6E 73 69 62 6C 65 4F  ema..extensibleO
0050: 62 6A 65 63 74 30 0E 04   02 63 6E 31 08 04 06 53  bject0...cn1...S
0060: 43 48 45 4D 41                                     CHEMA


... thanks in advance to anyone who can shed light on what I'm doing wrong here :-).

   cheers,

       Chris


Dr Christopher Betts
Development Manager UDDI
Richmond/Mooroolbark Lab
Melbourne
Australia
ph: +61 3 8416 5646