Re: [389-users] csngen_adjust_time: adjustment limit exceeded

[Juan Asensio Sánchez]

OK Rich, thank you very much. I will try this tomorrow, it's evening here in
Spain.

For "replicas" I mean replicated suffixes/databases on each server in my
previous message.

Regards.

2010/8/16 Rich Megginson <rmeggins(a)redhat.com&gt;

>  Juan Asensio Sánchez wrote:
>  > Hi
>  >
>  > Thanks Rich for your answer. Just some questions:
>  >
>  >
>  >     The bug that caused this to happen was fixed, but unfortunately
>  cannot
>  >     fix the bad nsState that already exists.  The problem is that the CSN
>  >     generator attribute (nsState) in the cn=replica entry for the suffx
>  is
>  >     not cleaned up properly when you re-init replication.  In general,
>  you
>  >     can't do this, because you could generate CSNs that you have
>  generated
>  >     before.
>  >
>  >     I think the solution here is to first unconfigure replication,
>  >
>  >
>  > Must I unconfigure all the replicas, or just for the database giving
>  > problems?
>  If by "replicas" you mean "directory servers", then yes, all
> directory
>  servers.  If you mean "one of several replicated suffixes/databases on a
>  server", then no.  The nsState entry is in each cn=replica entry for
>  each suffix, so you only have to fix the one that is causing problems.
>  >
>  >
>  >     then
>  >     shutdown the servers, then dump the database(s) to LDIF,
>  >
>  >
>  > I suppose I must export only the data (with db2lif),
>  correct
>  > not the replica information (with db2ldif.pl <http://db2ldif.pl> -r)
>  correct
>  > because the server has shut down and this last script requires the
>  > server to be running.
>  No, because you do not want to keep the old replication state
>  information (generated by -r) because it is bogus.
>  >
>  >
>  >     then remove the
>  >     nsState attribute.
>  >
>  >
>  > When exporting the data, has any entry that attribute? Or from where
>  > remove that attribute?
>  In dse.ldif, in the cn=replica entry under each suffix under cn=mapping
>  tree,cn=config.
>  >
>  >
>  >     You will have to do this on every server.  Then,
>  >     start up, reconfigure replication, reload the data,
>  >
>  >
>  > What do you want to say with "reload the data" and after "re-init
> the
>  > other replicas"? Import the exported data in one server, and then
>  > re-init the rest of the servers?
>  Yes.  import the exported data on your "primary" master, then use that
>  one to re-init the other servers.
>  >
>  >     and re-init all of
>  >     the other replicas.  Make sure all of your servers are in time sync
>  >     before you begin.
>  >
>  >
>  > Yes of course.
>  >
>  >
>  >     I know this is a pain but I don't know any other way to get rid of
>  the
>  >     bad nsState.
>  >     >
>  >     > Regards and thanks in advance.
>  >     >
>  >
>  >
>  > Regards and thanks in advance (again ;)).
>  > ------------------------------------------------------------------------
>  >
>  > --
>  > 389 users mailing list
>  > 389-users(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users
>