Re: aliasedObjectName problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



tamarin p wrote:

2009/4/21 Rich Megginson <rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>>

    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.
------------------------------------------------------------------------

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

<<attachment: smime.p7s>>

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux