[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-directory-users
Subject:    =?utf-8?q?=5B389-users=5D?= Re: Instance startup schema issue
From:       William Brown <wibrown () redhat ! com>
Date:       2016-07-20 22:57:56
Message-ID: 1469055476.4428.22.camel () redhat ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


[prev in list] [next in list] [prev in thread] [next in thread]