Bug 1981334

Summary:	CSN not found, we aren't as up to date, or we purged
Product:	Red Hat Enterprise Linux 7	Reporter:	cilmar <cilmar>
Component:	389-ds-base	Assignee:	LDAP Maintainers <ldap-maint>
Status:	CLOSED DUPLICATE	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.9	CC:	bsmejkal, dsimes, ldap-maint, mreynolds, mrhodes, tbordaz, tmihinto, vvanhaft
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-10-12 15:45:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 4 mreynolds 2021-07-13 02:40:29 UTC

Can the customer please run cl-dump.pl ?  We see this type of error pop up now and then, and I want to confirm if the CSN is actually in the replication changelog or not.  

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/shell_scripts#cl_dump_Dump_and_decode_changelog

Then just grep the output file for that CSN.  


Now if this problem happens again, what would be very useful is getting the RUV's as soon as possible, using something like this, but replacing the parameters values as needed:

# ldapsearch -xLLL -D "cn=directory manager" -W -b dc=example,dc=com \
  '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))

And also running cl-dump.pl to confirm if that CSN is present or not.

Comment 5 mreynolds 2021-09-09 13:51:26 UTC

Please, if anyone sees this issue again, please get a replication change log dump (cl-dump.pl), and get the RUV's, as described in Comment #4.

Thanks!

Comment 18 Dave 2021-12-15 12:55:31 UTC

(In reply to mreynolds from comment #4)
> Can the customer please run cl-dump.pl ?  We see this type of error pop up
> now and then, and I want to confirm if the CSN is actually in the
> replication changelog or not.  
> 
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/
> html/configuration_command_and_file_reference/
> shell_scripts#cl_dump_Dump_and_decode_changelog
> 
> Then just grep the output file for that CSN.  

the link is no longer valid, but it seems we can find old DS 10 docs here as pdf (which also means we can't get a link to a specific section):
https://access.redhat.com/sites/default/files/attachments/red_hat_directory_server-10-configuration_command_and_file_reference-en-us.pdf

and under this section:
10.4.2. cl-dump.pl (Dumps and Decodes the Changelog)

however, cl-dump.pl has many options, what is an example syntax?


> Now if this problem happens again, what would be very useful is getting the
> RUV's as soon as possible, using something like this, but replacing the
> parameters values as needed:
> 
> # ldapsearch -xLLL -D "cn=directory manager" -W -b dc=example,dc=com \
> '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))

is this the correct nsuniqueid or how do we derive the nsuniqueid to use?

Comment 21 Dave 2021-12-15 14:03:26 UTC

(In reply to mreynolds from comment #4)
> however, cl-dump.pl has many options, what is an example syntax?

we simply tried:
# cl-dump.pl -w (hidden) | grep (our long CSN #)
is this OK?


>> # ldapsearch -xLLL -D "cn=directory manager" -W -b dc=example,dc=com \
>> '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))

> is this the correct nsuniqueid or how do we derive the nsuniqueid to use?

I see we use nsuniqueid from the cl-dump.pl output..

(lol, answering my own questions..)

Comment 28 mreynolds 2022-10-12 15:45:32 UTC

Closing bug as a duplicate of 2113056

*** This bug has been marked as a duplicate of bug 2113056 ***