2009/4/21 Rich Megginson rmeggins@redhat.com

tamarin p wrote:

...

I'm running into some problems when trying to add some alias entries and importing with ldapmodify or ldif2db. I'm using the directory server version 1.2.0.

Example of LDIF dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com changetype: add aliasedObjectName: ou=foo,dc=test,dc=com objectClass: top objectClass: alias

When I run this I get: ldapmodify: Object class violation (65) additional info: single-valued attribute "aliasedObjectName" has multiple values

Same when I use ldif2db.. What am I doing wrong?

The application running on top of the ldap uses aliases as pointers and the objectclass exists in the schemata for FDS, so there isnt a requirement that the aliases get dereferenced by the ldap. In any case it currently uses an older fedorads version.

I discovered that that if I changed dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com in the LDIF to dn: aliasedobjectname=ou=foo,dc=test,dc=com,ou=bar,ou=test,dc=com (escape the commas instead of surrounding "" for the alias part in the dn), then I could add the entry and it seems to look ok in an ldap browser and satisfy whatever it is the application uses it for. Should the two be considered equivalent?

Then, when I dump the database to ldif with db2ldif, the entry is represented the same way: escaped comma for the alias part. One Strange thing is I could have sworn I added the same ldif with ""-aliases in FDS 1.1.3 and not only that: The ldif itself is actually dumped from a FDS 7.x server (which has schema checking off, if that could explain how they the entries were added in the first place). Were there any changes between 1.1.3 and 1.2.0 that could explain this? Also it does not appear to have broken replication of those aliases (tested with a quick replica initialize that I didn't run long enough to finish more than 20% of the db, I'll run the whole init tonight) between the 7.x and 1.2.0 server so maybe it's just tools issue.. but if so it happened with both ldif2db and ldapmodify from openldap-clients.

2009/4/22 Rich Megginson rmeggins@redhat.com

tamarin p wrote:

...

2009/4/21 Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com

...

...

tamarin p wrote:

   I'm running into some problems when trying to add some alias
   entries and importing with ldapmodify or ldif2db. I'm using
   the directory server version 1.2.0.

   Example of LDIF
   dn:
   aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com
   changetype: add
   aliasedObjectName: ou=foo,dc=test,dc=com
   objectClass: top
   objectClass: alias

   When I run this I get:
   ldapmodify: Object class violation (65)
          additional info: single-valued attribute
   "aliasedObjectName" has multiple values

   Same when I use ldif2db.. What am I doing wrong?

The application running on top of the ldap uses aliases as pointers and the objectclass exists in the schemata for FDS, so there isnt a requirement that the aliases get dereferenced by the ldap. In any case it currently uses an older fedorads version.

I discovered that that if I changed dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com in the LDIF to dn: aliasedobjectname=ou=foo,dc=test,dc=com,ou=bar,ou=test,dc=com (escape the commas instead of surrounding "" for the alias part in the dn), then I could add the entry and it seems to look ok in an ldap browser and satisfy whatever it is the application uses it for. Should the two be considered equivalent?

Yes. The double quoted style is deprecated - the \ escapes should be used instead.

...

Then, when I dump the database to ldif with db2ldif, the entry is represented the same way: escaped comma for the alias part. One Strange thing is I could have sworn I added the same ldif with ""-aliases in FDS 1.1.3 and not only that: The ldif itself is actually dumped from a FDS 7.x server (which has schema checking off, if that could explain how they the entries were added in the first place).

I don't believe it has anything to do with schema checking.

...

Were there any changes between 1.1.3 and 1.2.0 that could explain this?

Not that I am aware of. I think we did fix some bugs in DN parsing and normalization - it's possible we broke the double quote behavior.

...

Also it does not appear to have broken replication of those aliases (tested with a quick replica initialize that I didn't run long enough to finish more than 20% of the db, I'll run the whole init tonight) between the 7.x and 1.2.0 server so maybe it's just tools issue.. but if so it happened with both ldif2db and ldapmodify from openldap-clients.

Resurrecting another old thread here, but I ran into something i shouldve thought of much sooner.

Basically we were hoping to use replication to migrate the data from an old ldap. the reason is that the directory is big and a regular ldif import would require the site to be offline (or read-only) for several hours. But with replication we could just let it "run in the background" until we're ready to swap the servers and downtime would be minimal. Trouble is we have thousands of entries like the one here: dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com

These can't be added with ldap (ldapadd, ldif2db etc) anymore, but for some reason they replicate/initialize over without a problem. So for a while it seemed possible to take this migration path with FDS 1.2.0 as desired. But then I ran into a problem when testing a backup scripts: It seems an entry maintains the syntax it was "added with" instead of being dumped later with "canonical" syntax. Using replication to copy the data then, we of get a fully consistent directory that works perfectly, but alias entries keep their deprecated syntax when ldif exported which means: running db2ldif on the NEW server will print ldif aliasedobjectname entries that cannot be re-added with ldif2db later because they're in the "broken" syntax. This makes it impossible to restore from that ldif backup later without first converting these to the , escaped commas syntax. running ldif2db on it unmodified just gives errors like this: Entry "aliasedobjectname=\22ou=foo,dc=test,dc=com\22,ou=bar,ou=test,dc=com" single-valued attribute "aliasedObjectName" has multiple values import userRoot: WARNING: skipping entry "aliasedobjectname=\22ou=foo,dc=test,dc=com\22,ou=bar,ou=test,dc=com" which violates schema, ending line 123 of file /tmp/myldif.ldif.

I did some testing with ldapmodify with the following entry. dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=comaliasedObjectName: ou=foo,dc=test,dc=com objectClass: top objectClass: alias

If I add that entry after disabling schema checking, the entry can be added and the result in the directory is this. Note two aliasedObjectName attrs, one is wrong.: dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com aliasedObjectName: ou=foo,dc=test,dc=com aliasedObjectName: "ou=foo,dc=test,dc=com" objectClass: top objectClass: alias

I then tried adding this entry again with no aliasedObjectName attribute. This will work also with schema checking on: dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com objectClass: top objectClass: alias

And the result is this, which works even with schema checking on but yields the wrong aliaseObjectName attr (the "" shouldn't be there): dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com aliasedObjectName: "ou=foo,dc=test,dc=com" objectClass: top objectClass: alias

For some reason, it's perfectly fine from the directory point of view when you replicate instead of ldifimport (until you try to import/export to ldif) so I assume there's some difference in how entries are parsed and added for the two methods there. Don't know if any of this tells you anything, just thought I should mention my findings.

I'm now searching for a workaround that would allow me to still use replication for the migration step. is there f.ex. a way to make the server normalize either on input or output when doing ldif import/export? can you see a better option than to fall back on ldif processing/converting?. So far the only alternative to ldif processing I see is a script to walk the whole directory and modify the aliasedObjectName after replica initialization is complete at some point and the replication agreement is removed.