aliasedObjectName problem

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

 



2009/4/21 Rich Megginson <rmeggins at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20090422/a6bb3604/attachment.html 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux