[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapcat output from 2.0.21 to slapadd to openldap-2.3.24
Aaron, thanks for your input.
Replication has been setup between these servers, but running
"ldapsearch -x -b 'o=HotCoco,c=US' '(objectclass=*)' " on both of the
servers return different results.
I thought slurpd would keep the data consistent, but apparently on the
Master server, the line: "o: HotCoco.com" didn't modify the slave's
record (It's "o:HotCoco")
I've inherited an existing ldap database, so I can't ask the admin who
created this.
My question is: If "o: HotCoco.com" is wrong, then why was it used?
The question might seem like it's on the level of "Why do people make
spelling errors?", but it seems like many others who are running older
openldap servers migrating to newer servers also have had this
problem. Did the standards change?
From your reply, it appears that "o: HotCoco" is correct for: "dn:
o=HotCoco, c=US", but I am hesitant to make that change on the
production Redhat7 server.
I guess the best approach is to make sure I have legit data on the new
server and then cutover and pray that applications that use the ldap
server continue on working. If not, then revert back to the old ldap
server and regroup.. Any feedback is greatly appreciated!
thanks,
Dmisc
------ ldapsearch output from the Redhat7 (openldap-2.0.21) master
------------------
version: 2
#
# filter: (objectclass=*)
# requesting: ALL
#
# HotCoco, US
dn: o=HotCoco, c=US
o: HotCoco.com
objectClass: organization
# root, HotCoco, US
dn: cn=root, o=HotCoco, c=US
cn: root
sn: root
objectClass: person
# bob, HotCoco, US
dn: uid=bob, o=HotCoco, c=US
uid: bob
.
.
------ END From the Redhat7 (openldap-2.0.21) master ------------------
------ ldapsearch output from the Fedora Core 5 (openldap-2.3.24)
master -------------
# extended LDIF
#
# LDAPv3
# base <o=HotCoco,c=US> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# HotCoco, US
dn: o=HotCoco,c=US
o: HotCoco
objectClass: organization
# mike, HotCoco, US
dn: uid=mike,o=HotCoco,c=US
uid: mike
.
.
------ END From the Fedora Core 5 (openldap-2.3.24) master ------------------
On 7/19/06, Aaron Richton <richton@nbcs.rutgers.edu> wrote:
> dn: o=HotCoco, c=US
> o: HotCoco.com
> objectClass: organization
> When I changed the "o: HotCoco.com" to "o: HotCoco", the error (value
> of naming attribute 'o' is not present in entry) went away, and
> ldapadd worked.
>
> Can you please explain why this is the case?
Well, they have to match. If you want to have
o: HotCoco.com then you need dn: o=HotCoco.com, c=US
Given your dn: o=HotCoco, c=US you need o: HotCoco. because they match.
Personally, I'd recommend cleaning up the data on your RH7 box (i.e.
ldapmodify your bogus entry above) to the point where you can slapadd to
2.3.24 cleanly. Once you've got sane data, cut over to the new server,
which will also more strictly enforce the relevant standards and not let
an entry like that in again. This would be a lot safer than continuing to
run with 2.0.21 and letting users get away with more bogus entries.