To me this looks like Dogtag never created its Replication Manager bind users before actual use. Looking at the pki-core code, I don't see how it ever worked in past -- the bind user for replicationdb is never created in IPA workflow. 389-ds does return error 49, e.g. entry does not exist:
[11/Feb/2021:12:53:00.424286315 -0500] conn=102 op=0 RESULT err=49 tag=97 nentries=0 wtime=0.000126054 optime=0.000467697 etime=0.000592407 - Entry does not exist
but while in past it was treated as 'NO_SUCH_USER' in Dogtag, this update causes Dogtag to treat it as 'INVALID_PASSWORD':
Compare this to my F33 setup with 389-ds-base-1.4.4.11-1.fc33.x86_64 and pki-ca-10.11.0-0.1.alpha1.20210204232642UTC.23c3d215.fc33.noarch:
2021-01-26 07:02:26 [main] INFO: CMSEngine: initializing password store for replicationdb
2021-01-26 07:02:26 [main] INFO: CMSEngine: verifying connection to master.ipa.test:389 as cn=Replication Manager masterAgreement1-master.ipa.test-pki-tomcat,cn=config
2021-01-26 07:02:27 [main] WARNING: CMSEngine: password test execution failed for replicationdb with NO_SUCH_USER. This may not be a latest instance. Ignoring ..
sadly, I don't have older 389-ds access logs on that instance to verify what 389-ds did return.
This update has been submitted for testing by tbordaz.
This update's test gating status has been changed to 'ignored'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
As you can see from the Automated Tests tab, this appears to break server deployment. Logs at https://openqa.fedoraproject.org/tests/774965/file/role_deploy_domain_controller-var_log.tar.gz .
This update has been obsoleted.
...or at https://openqa.fedoraproject.org/tests/774968/file/role_deploy_domain_controller-var_log.tar.gz (possibly a bit cleaner as no replica stuff is involved).
To me this looks like Dogtag never created its Replication Manager bind users before actual use. Looking at the pki-core code, I don't see how it ever worked in past -- the bind user for replicationdb is never created in IPA workflow. 389-ds does return error 49, e.g. entry does not exist:
but while in past it was treated as 'NO_SUCH_USER' in Dogtag, this update causes Dogtag to treat it as 'INVALID_PASSWORD':
Compare this to my F33 setup with 389-ds-base-1.4.4.11-1.fc33.x86_64 and pki-ca-10.11.0-0.1.alpha1.20210204232642UTC.23c3d215.fc33.noarch:
sadly, I don't have older 389-ds access logs on that instance to verify what 389-ds did return.
Here's the log tarball from the same test passing on a different F32 update: https://openqa.fedoraproject.org/tests/775367/file/role_deploy_domain_controller_check-var_log.tar.gz