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

[Juan Asensio Sánchez <okelet@xxxxxxxxx>]

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@xxxxxxxxxx>

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

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users