dogtagpki

#3043 consumer initialization failed. Error (0) Total update succeeded
Closed: fixed Opened by rcritten.

Closed: fixed
Reopen Issue

Trying to configure freeIPA per https://pagure.io/freeipa/issue/7622 results in a failed installation, apparently because dogtag is not interpreting the end of replication properly.

This is easily reproducible. Logging for all master is available in the freeipa ticket.

Seems to be a regression.

In the IPA ticket it looks like you're using pki-ca-10.6.3-1 on F28. Could you make sure you're using the latest officially released packages? On F28 that would be:

  • pki 10.6.1-3
  • tomcatjss 7.3.0-1
  • jss 4.4.5-1

The pki-ca-10.6.3-1 might have been accidentally released by the pki module that was still in updates testing, but I have unpushed the module now.

Metadata Update from @edewata:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

 
master:
# rpm -q pki-ca tomcatjss jss
pki-ca-10.6.1-3.fc28.noarch
tomcatjss-7.3.0-1.fc28.noarch
jss-4.4.5-1.fc28.x86_64
clone:
# rpm -q pki-ca tomcatjss jss
pki-ca-10.6.1-3.fc28.noarch
tomcatjss-7.3.0-1.fc28.noarch
jss-4.4.5-1.fc28.x86_64

Could you provide the full stack trace? The stack trace in IPA ticket #7622 doesn't match PKI 10.6.1 source code. Thanks.

Hi,
it looks the same issue as described in 7627, happening because pkispawn is failing when configuring the replication for CA.
During repl setup, pkispawn is reading the attribute nsds5replicaLastInitStatus in cn=masterAgreement1-$hostname-pki-tomcat,cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config in order to find the replication status.
The new format (in 389-ds-base-1.3.7) for this attribute is "Error (0) Total update succeeded" but pkispawn is expecting "0 Total update succeeded" (see the code in 10.5 branch or the code in master branch).
The issue has been introduced with 389-ds-base-1.3.7 with the 389-ds patch for 49599.

Thanks @frenaud for finding the code!

Just to confirm, should we update the code in both PKI 10.5 (for F27) and 10.6 (for F28+)?

Nice analysis @frenaud.

@edewata f27 has 398-ds-base-1.3.8.5 and pki-core-10.5.9 so it looks like we need it on the
10.5 branch too. The fix should handle both the old and new string formats (pretty simple
regex).

Strings suck.

Metadata Update from @mharmsen:
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.11-2
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1596629
- Issue set to the milestone: 10.5.11 (was: 0.0 NEEDS_TRIAGE)
- Issue status updated to: Closed (was: Open)

Metadata Update from @mharmsen:
- Issue close_status updated to: fixed

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.12 (was: 10.5.11)

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/3161

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.
Metadata
None
None
None
None
None
None
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.