From: Graham B. <gb...@po...> - 2001-03-29 10:44:40
|
----- Forwarded message from Jan Hackel <jh...@rz...> ----- Date: Thu, 29 Mar 2001 10:06:14 +0200 To: <gb...@po...> From: "Jan Hackel" <jh...@rz...> Subject: Net::LDAP and OpenLDAP Schemata X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Hi, I am trying to access an OpenLDAP 2 server with Net::LDAP. Everything fine so far. But when I try to read schema information via the Net::LDAP::schema method it fails. The reason is that the server does not answers operational attributes such as "subschemaentry". Currently I fixed it by explicitly requesting the operational attributes via attrs => ['+', '*'] in both Net::LDAP::root_dse and Net::LDAP::schema. Is there a better way to get the schema information out of the directory? I could not find any hint in the perldocs. Thank you, Jan. P.S. Is some conversion support for attribute values planned in the future, e.g. automatically converting a attribute with syntax '1.3.6.1.4.1.1466.115.121.1.15' to UTF-8 etc? ----- End forwarded message ----- |
From: Chris R. <chr...@me...> - 2001-03-29 11:38:56
|
Graham Barr <gb...@po...> wrote: > ----- Forwarded message from Jan Hackel <jh...@rz...> ----- > > Date: Thu, 29 Mar 2001 10:06:14 +0200 > To: <gb...@po...> > From: "Jan Hackel" <jh...@rz...> > Subject: Net::LDAP and OpenLDAP Schemata > X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > > Hi, > > I am trying to access an OpenLDAP 2 server with Net::LDAP. Everything fine > so far. But when I try to read schema information via the > Net::LDAP::schema method it fails. The reason is that the server does not > answers operational attributes such as "subschemaentry". Currently I > fixed it by explicitly requesting the operational attributes via attrs => > ['+', '*'] in both Net::LDAP::root_dse and Net::LDAP::schema. As far as I know the '+' character is not part of any RFC-defined way of requesting all operational attributes. (There is no RFC-defined way of doing this. Again, AFAIK.) > Is there a better way to get the schema information out of the directory? > I could not find any hint in the perldocs. You should be able to do just: $schema = $ldap->schema(); which gets the schema from one of the places defined in the root DSE, or: $schema = $ldap->schema('some DN'); which gets the schema from the named subschema subentry. The $schema object will be of class Net::LDAP::Schema. However there were some recent changes to Net::LDAP's code to retrieve schema using a more standard (and correct) method. The previous code only worked in (I think) Netscape and Active Directory. These changes are in the CVS repository and haven't yet been released to CPAN - can you try the version of the code in CVS? Instructions for getting Net::LDAP from CVS are at: http://sourceforge.net/cvs/?group_id=5050 > Thank you, > Jan. > > P.S. Is some conversion support for attribute values planned in the > future, e.g. automatically converting a attribute with syntax > '1.3.6.1.4.1.1466.115.121.1.15' to UTF-8 etc? Well that OID is for DirectoryString, and servers must return values using that syntax to LDAPv3 clients using UTF-8 already. I do have some changes implementing syntax handlers in Net::LDAP, which will do things like exploding values using the standard syntaxes into components. For example DNs explode into lists of lists, BER-encoded values can get decoded into UTF-8 strings, etc. Is this what you were after? Cheers, Chris |
From: Kurt D. Z. <Ku...@Op...> - 2001-03-29 14:39:49
|
At 12:38 PM 3/29/01 +0100, Chris Ridd wrote: >> I am trying to access an OpenLDAP 2 server with Net::LDAP. Everything fine >> so far. But when I try to read schema information via the >> Net::LDAP::schema method it fails. The reason is that the server does not >> answers operational attributes such as "subschemaentry". Currently I >> fixed it by explicitly requesting the operational attributes via attrs => >> ['+', '*'] in both Net::LDAP::root_dse and Net::LDAP::schema. > >As far as I know the '+' character is not part of any RFC-defined way of >requesting all operational attributes. (There is no RFC-defined way of >doing this. Again, AFAIK.) Yes, '+' as a means for requesting is only a 'work in progress'. And even when it is published as a RFC, I'd question it's appropriate for read select operational attributes types. The '+' mechanisms is more suited to browsing by humans. An automated application should know what's it after and request it directly. Kurt |
From: Kurt D. Z. <Ku...@Op...> - 2001-03-29 14:53:14
|
BTW, the "+" I-D is available at: http://search.ietf.org/internet-drafts/draft-zeilenga-ldapv3bis-opattrs-05.txt comments are welcomed. (likely best privately or on the LDAPext list). Kurt At 06:41 AM 3/29/01 -0800, Kurt D. Zeilenga wrote: >At 12:38 PM 3/29/01 +0100, Chris Ridd wrote: >>> I am trying to access an OpenLDAP 2 server with Net::LDAP. Everything fine >>> so far. But when I try to read schema information via the >>> Net::LDAP::schema method it fails. The reason is that the server does not >>> answers operational attributes such as "subschemaentry". Currently I >>> fixed it by explicitly requesting the operational attributes via attrs => >>> ['+', '*'] in both Net::LDAP::root_dse and Net::LDAP::schema. >> >>As far as I know the '+' character is not part of any RFC-defined way of >>requesting all operational attributes. (There is no RFC-defined way of >>doing this. Again, AFAIK.) > >Yes, '+' as a means for requesting is only a 'work in progress'. >And even when it is published as a RFC, I'd question it's >appropriate for read select operational attributes types. The >'+' mechanisms is more suited to browsing by humans. An >automated application should know what's it after and request >it directly. > >Kurt |