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@bgsu.edu<mailto:tffishe@bgsu.edu>
Phone: 419.372.1626
[Description: BGSU]
--
389-users mailing list
389-users(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject...
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane