replication troubles

[Natxo Asenjo]

hi,

we are having some trouble with our rhel 7 to rhel 8 migration and after
checking some things, it became apparent the replication is mostly broken
among the idm servers

I see in the errors:
agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d). The
consumer may need to be reinitialized
According to this:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

Reason: Most likely the changelog was recreated because of the disk is full
or the server ungracefully shutdown.

/var/log on this hosts was full recently, so this could have caused this
indeed.

I also see:

ERR - NSMMReplicationPlugin - send_updates - .... : data required to update
replica has been purged from the changelog, if the error persists the
replica must be reinitialized.

This is pretty clear.

So this server is the ca master.

The domain level is 1.

The rhel version is right now 7.9.

If I reinitialize this server with the ca role (master), with other server,
will it overwrite the CA?

[Mark Reynolds]

What version of 389-ds-base is installed?  There were bugs around csn 
location that were fixed in the very latest version of the LDAP server 
on RHEL 7.9.  So make sure you are running the latest version of 
389-ds-base.

As for replication being broken, you can confirm this by making a 
"dummy" change somewhere and checking if that change is present on the 
other replicas (give it some time to replicate of course, but it 
shouldn't take more than a few seconds).

As for re-initializing just make sure you are initing from the most 
current/accurate replica.

HTH,

Mark

On 2/8/24 9:06 AM, Natxo Asenjo via FreeIPA-users wrote:
> hi,
>
> we are having some trouble with our rhel 7 to rhel 8 migration and 
> after checking some things, it became apparent the replication is 
> mostly broken among the idm servers
>
> I see in the errors:
>     |agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB
>     rc=%d). The consumer may need to be reinitialized|
>
> According to this:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...
>
> Reason: Most likely the changelog was recreated because of the disk is 
> full or the server ungracefully shutdown.
>
> /var/log on this hosts was full recently, so this could have caused 
> this indeed.
>
> I also see:
>
> ERR - NSMMReplicationPlugin - send_updates - .... : data required to 
> update replica has been purged from the changelog, if the error 
> persists the replica must be reinitialized.
>
> This is pretty clear.
>
> So this server is the ca master.
>
> The domain level is 1.
>
> The rhel version is right now 7.9.
>
> If I reinitialize this server with the ca role (master), with other 
> server, will it overwrite the CA?
>
> -- 
> Regards,
> natxo
>
> --
> _______________________________________________
> FreeIPA-users mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[Natxo Asenjo]

On Thu, Feb 8, 2024 at 3:56 PM Mark Reynolds  wrote:
> What version of 389-ds-base is installed?  There were bugs around csn
> location that were fixed in the very latest version of the LDAP server on
> RHEL 7.9.  So make sure you are running the latest version of 389-ds-base.

this is 1.3.10.2-12.el7_9

so not the latest one. And I cannot update right now because of other
issues. Does this version have this csn problem?

As for replication being broken, you can confirm this by making a "dummy"
> change somewhere and checking if that change is present on the other
> replicas (give it some time to replicate of course, but it shouldn't take
> more than a few seconds).
>
> As for re-initializing just make sure you are initing from the most
> current/accurate replica.

yes, I saw we can use ipa topologysegent-reinitialize with just the domain
suffix, so this should avoid overwriting the CA suffix (phew).

Thanks.

[Mark Reynolds]

On 2/8/24 10:14 AM, Natxo Asenjo wrote:
> On Thu, Feb 8, 2024 at 3:56 PM Mark Reynolds  wrote:
> What version of 389-ds-base is installed?  There were bugs around
> csn location that were fixed in the very latest version of the
> LDAP server on RHEL 7.9.  So make sure you are running the latest
> version of 389-ds-base.
>
>
> this is 1.3.10.2-12.el7_9
>
> so not the latest one. And I cannot update right now because of other 
> issues. Does this version have this csn problem?

Yes it does.  It was fixed in:  1.3.10.2-17

Regards,

Mark
> As for replication being broken, you can confirm this by making a
> "dummy" change somewhere and checking if that change is present on
> the other replicas (give it some time to replicate of course, but
> it shouldn't take more than a few seconds).
>
> As for re-initializing just make sure you are initing from the
> most current/accurate replica.
>
>
> yes, I saw we can use ipa topologysegent-reinitialize with just the 
> domain suffix, so this should avoid overwriting the CA suffix (phew).
>
> Thanks.