[389-users] Re: Instance startup schema issue

[William Brown]

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:  [e-mail]<mailto:[e-mail]>
>  Phone: [phone]
>  [Description: BGSU]
>  
>  --
>  389-users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/[e-mail]... 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane