Bug 1892114 - FreeIPA server deployment fails with 389-ds-base-1.4.4.6-1 (and 1.4.3.14-1)
Summary: FreeIPA server deployment fails with 389-ds-base-1.4.4.6-1 (and 1.4.3.14-1)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: mreynolds
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F34BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-10-27 23:04 UTC by Adam Williamson
Modified: 2020-10-28 22:43 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.4.4.7-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-28 22:06:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2020-10-27 23:04:57 UTC
Since 389-ds-base-1.4.4.6-1 landed in Rawhide, and when testing it as an update for F33 (and when testing 1.4.3.14-1 as an update for F32), FreeIPA server deployment fails with dirsrv errors like this:

Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.768558537 -0400] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=domain,dc=local--no CoS Templates found, which should be added before the CoS Definition.
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.786357047 -0400] - ERR - DSRetroclPlugin - retrocl_select_backend - Mapping tree select failed (0) .
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.787199031 -0400] - ERR - mapping_tree_entry_add - The subtree cn=changelog does not match any existing backends, and will not be created.
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.787757028 -0400] - ERR - DSRetroclPlugin - cn="cn=changelog",cn=mapping tree,cn=config could not be created (53)
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.788169343 -0400] - ERR - plugin_dependency_startall - Failed to start object plugin Retro Changelog Plugin
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.790994356 -0400] - ERR - DSRetroclPlugin - retrocl_select_backend - Mapping tree select failed (0) .
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.791707028 -0400] - ERR - mapping_tree_entry_add - The subtree cn=changelog does not match any existing backends, and will not be created.
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.792241268 -0400] - ERR - DSRetroclPlugin - cn="cn=changelog",cn=mapping tree,cn=config could not be created (53)
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.792793731 -0400] - ERR - plugin_dependency_startall - Failed to start object plugin Retro Changelog Plugin
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.793324812 -0400] - ERR - DSRetroclPlugin - retrocl_select_backend - Mapping tree select failed (0) .
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.794228853 -0400] - ERR - mapping_tree_entry_add - The subtree cn=changelog does not match any existing backends, and will not be created.
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.794876337 -0400] - ERR - DSRetroclPlugin - cn="cn=changelog",cn=mapping tree,cn=config could not be created (53)
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.795329668 -0400] - ERR - plugin_dependency_startall - Failed to start object plugin Retro Changelog Plugin
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.795811542 -0400] - ERR - plugin_dependency_startall - Failed to resolve plugin dependencies
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.796265024 -0400] - ERR - plugin_dependency_startall - object plugin Content Synchronization is not started
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.796690181 -0400] - ERR - plugin_dependency_startall - object plugin Retro Changelog Plugin is not started
Oct 27 04:35:35 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:35.797901274 -0400] - INFO - bdb_pre_close - Waiting for 4 database threads to stop
Oct 27 04:35:38 ipa002.domain.local ns-slapd[32241]: [27/Oct/2020:07:35:38.139435361 -0400] - INFO - bdb_pre_close - All database threads now stopped
Oct 27 04:35:38 ipa002.domain.local systemd[1]: dirsrv: Main process exited, code=exited, status=1/FAILURE
Oct 27 04:35:38 ipa002.domain.local systemd[1]: dirsrv: Failed with result 'exit-code'.
Oct 27 04:35:38 ipa002.domain.local systemd[1]: Failed to start 389 Directory Server DOMAIN-LOCAL..

mreynolds says he knows what this is, but I'm filing a bug for tracking. I believe from context that https://github.com/389ds/389-ds-base/commit/67c8b8702a249cb0ef1ebf49b6e87056cd5339f6 is intended to fix this; I'm currently testing an F33 scratch build with that fix backported. So far it seems like it may fix server deployment, but there is still a problem with replica deployment. ipa-replica-install fails with this error:

2020-10-27T22:54:42Z DEBUG Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
2020-10-27T22:54:42Z DEBUG   [1/30]: creating certificate server db
2020-10-27T22:54:42Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/ipapython/ipaldap.py", line 1078, in error_handler
    yield
  File "/usr/lib/python3.9/site-packages/ipapython/ipaldap.py", line 1650, in add_entry
    self.conn.add_s(str(entry.dn), list(attrs.items()))
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 428, in add_s
    return self.add_ext_s(dn,modlist,None,None)
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 414, in add_ext_s
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 746, in result3
    resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4(
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 756, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 329, in _ldap_call
    reraise(exc_type, exc_value, exc_traceback)
  File "/usr/lib64/python3.9/site-packages/ldap/compat.py", line 44, in reraise
    raise exc_value
  File "/usr/lib64/python3.9/site-packages/ldap/ldapobject.py", line 313, in _ldap_call
    result = func(*args,**kwargs)
ldap.UNWILLING_TO_PERFORM: {'desc': 'Server is unwilling to perform'}

and the dirsrv logs show this error around the same time:

[27/Oct/2020:18:54:42.583707102 -0400] - ERR - mapping_tree_entry_add - The subtree o=ipaca does not match any existing backends, and will not be created.

Comment 1 Adam Williamson 2020-10-27 23:05:43 UTC
Proposing the initial form of the bug (FreeIPA server deployment fails) as a Beta blocker per "It must be possible to configure a Fedora Server system installed according to the above criteria as a FreeIPA domain controller, using the official deployment tools provided in the distribution FreeIPA packages" - https://fedoraproject.org/wiki/Basic_Release_Criteria#FreeIPA_server_requirements .

Comment 2 Adam Williamson 2020-10-27 23:18:06 UTC
Okay, so...maybe the problem after the 389-ds-base fix is that FreeIPA is making the same mistake (trying to create a mappingtree entry in backend 'ipaca' before that backend is created) on the replica install path, and that needs fixing FreeIPA side?

Since the 389-ds-base fix does seem to improve things at least, I'm going to do an official Rawhide build with the backport. Will leave f32 and f33 for mreynolds since they're not as urgent thanks to Bodhi.

Comment 3 mreynolds 2020-10-28 22:02:21 UTC
I already filed a PR with freeipa to fix this:

https://github.com/freeipa/freeipa/pull/5212

The latest 389-ds-base-1.4.5.0 is good.  There is no bug here, this is all on IPA now...

Comment 4 mreynolds 2020-10-28 22:06:09 UTC
(In reply to mreynolds from comment #3)
> I already filed a PR with freeipa to fix this:
> 
> https://github.com/freeipa/freeipa/pull/5212
> 
> The latest 389-ds-base-1.4.5.0 is good.  There is no bug here, this is all
> on IPA now...

Also, I did a respin of 1.4.4.7 & 1.4.3.15 which reverted the the failure on FreeIPA.  I'm going to close this out...

Comment 5 Adam Williamson 2020-10-28 22:43:05 UTC
yeah, that seems fine to me. I've backported the PR to Rawhide's freeipa package because I want the fix in so we can hopefully see if a *different* replica deployment bug is fixed.


Note You need to log in before you can comment on or make changes to this bug.