directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Difference between the following ldif files
Date Sat, 21 Jul 2007 16:58:20 GMT
Hi Markus,

On 7/21/07, Markus Pohle <apacheds.users@webunity.de> wrote:
>
> Hi list,
>
> I used a ApacheDS in version 1.5.0 (officially released version
> downloaded from directory website) on my server and created my on
> partition with the following ldap structure:
>
> dn: dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: extensibleObject
> objectClass: top
> dc: douglasholding
>
> dn: dc=VERWALTUNG,dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: top
> 0.9.2342.19200300.100.1.25: verwaltung
> dc: VERWALTUNG
>
> dn: cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> objectClass: organizationalRole
> objectClass: top
> 2.5.4.3: users
> cn: users
>
> dn: dc=APPLICATIONS,dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: top
> 0.9.2342.19200300.100.1.25: applications
> dc: APPLICATIONS
>
> dn: cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING
> objectClass: organizationalRole
> objectClass: top
> 2.5.4.3: cms
> cn: cms
>
> Then I needed to switch to apacheds-1.5.1-snapshot release that Alex
> Karasulu due to apacheds-tools problems with version 1.5.0 build for me.
>
> And what I found out browsing the ldap schema using LDAP Studio on the
> apacheds-1.5.1-snapshot is the following:
>
> dn: dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: extensibleObject
> objectClass: top
> dc: douglasholding
>
> dn: dc=VERWALTUNG,dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: top
> dc: VERWALTUNG
>
> dn: cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> objectClass: organizationalRole
> objectClass: top
> cn: users
>
> dn: dc=APPLICATIONS,dc=DOUGLASHOLDING
> objectClass: domain
> objectClass: top
> dc: APPLICATIONS
>
> dn: cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING
> objectClass: organizationalRole
> objectClass: top
> cn: cms
>
> And here comes the question:
> What are these additional objectclasses for that can be seen in the
> upper example of the ldap structure, e.g.:
>
> 0.9.2342.19200300.100.1.25: applications
> 2.5.4.3: cms


These are the normalized representations of attributes dc and cn
respectively. These
numbers are their OIDs.

Looks to me like your LDIF export contained them and so ApacheDS preserved
them as
you loaded them into the server.  ApacheDS is required to return entries as
you entered
them without modifying the entries attribute names.  BTW in LDAP you can use
OID, or
an alias like cn, or even commonName.  What ever you choose on the import or
add
operation should be returned back to you as it was imported/added.

Now this leads us to the question of why the export from ApacheDS resulted
in returning
these canonical representations instead of the attribute aliases which you
probably
originally provided like cn and dc instead.  I presume before the LDIF
export you took, you
initially added these entries to the first ADS instance using dc and cn
correct?

If this is happening the server may be reverting indexed attribute
identifiers to their OID.
If so this is a bug we need to fix.  However there was a switch in the
server that forces denormalization which I had thought was enabled by
default.

I recommend performing a little test to see what is going on.  Just delete
the structure you
loaded and massage your export file to just use the alias names dc and cn
instead of using
their OIDs.  Then load it into the server again and see if in studio the OID
appears instead.

Let us know if the server is changing these attribute identifiers back into
their OID.  Also
take an export to LDIF again and see if that export has replaced cn and dc
with their OID.

HTH,
Alex

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message