On Wed, 2016-07-20 at 20:44 +0000, Ted Fisher wrote: > I have two new RH7 servers each running 389ds and each with a test ldap instance and a test master. > I set up replication from our old ldap servers (iPlanet 5 on Solaris) to these new instances so they keep up to date with everything until we are ready to switch the VIPs to point to these new ones both both updates to the masters and queries to the ldap instances. > Everything was working fine until I set up replication between the config directories on these new servers (not sure if that was the cause, but timing is that the issue occurred just after this). When I went to restart one of the query directorsies it failed with this logged: When you say "replication between config directories" can you please say what suffix you added to replicate? > dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-ldaptest1/schema/99user.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - > I thought it might have been caused by the replication of config. So, I blew away one of the directory instances then rebuilt it and configured consumer replication again. From the primary supplier I re-initialized it which succeeded. But, when I tried a restart it failed again with the same error. The time stamp on 99user.ldif was the same as when the total update started. > > Any suggestions how I can find out what is getting messed up in the schema? Do I need to turn up more logging to try to get info more than what the unhelpful message above tells me? The content of schema/* is not changed in a replication BESIDEs 99user.ldif which is where any incoming replicated changes land. So that will likely show you where the issue is. I'll point out, the sun schema differs from the RH one, but I have seen them merged into RHDS in the past. When you have a replication agreement, that will automatically cause the cn=schema to be replicated also. Given the error you are seeing, I wonder if what's happening is that the SUN DS is seeing "ohh some attribute X schema doesn't match, I'll replicate it to RHDS", then RHDS is rejecting it from the schema because we already have it, is a possibility. In the past when i have done Sun -> RHDS migrations, we have always done db2ldif then ldif2db, with data-manipulation in between. During early migration this was a nightly cron, and as we moved applications over I think we did this hourly, and eventually we picked a day to cut over the write / vips from sun to RHDS, and decommed sun. > > Thanks. > > Ted F. Fisher > Server Administrator > Information Technology Services > Email: tffishe@xxxxxxxx<mailto:tffishe@xxxxxxxx> > Phone: 419.372.1626 > [Description: BGSU] > > -- > 389-users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389-users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
