Bug 1801791
| Summary: | Compatibility Schema difference in functionality for systems following RHEL 7.5 -> 7.6 upgrade path as opposed to new RHEL 7.6 systems | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Dave <dsimes> |
| Component: | ipa | Assignee: | Florence Blanc-Renaud <frenaud> |
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.6 | CC: | abokovoy, aheverle, arajendr, cheimes, myusuf, pasik, pcech, rcritten, ssidhaye, tscherf |
| Target Milestone: | rc | Keywords: | Reopened, TestCaseProvided |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ipa-4.6.6-12.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-29 19:58:31 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: | |||
|
Description
Dave
2020-02-11 16:11:16 UTC
This looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1585020. What matters is that you created a new replica, not the upgrade path. *** This bug has been marked as a duplicate of bug 1585020 *** We do not agree this is a duplicate of 1585020, as our compat data is generated only for Posix groups, and we have zero AD related info under cn=groups,cn=compat There are two parts here.
1. ipaExternalGroup is only handled for trust to AD configurations. The compat tree configuration for that is only set up when you run ipa-adtrust-install --enable-compat on the specific master (turning the master into a trust controller). When you have no external group members configured for some external groups (this is a concept in IPA, 'ipa group-add --external' and 'ipa group-add-member --external'), and these groups aren't included into some POSIX groups, you should not see any of AD groups pulled in.
2. Second part is actual addition of the 'objectclass: ipaExternalGroup' into the entries under cn=groups,cn=compat,$BASEDN. This happens after /usr/share/ipa/updates/50-externalmembers.update file is automatically imported on IPA upgrade. The file content is:
$ cat install/updates/50-externalmembers.update
dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
addifexist: schema-compat-entry-attribute: ipaexternalmember=%deref_r("member","ipaexternalmember")
addifexist: schema-compat-entry-attribute: objectclass=ipaexternalgroup
The upgrade should happen during replica deployment as one of last steps before enabling optional services. You can see that in the replica installation log with 'Applying LDAP updates'. But I think there might be an ordering discrepancy because the base compat tree configuration is in install/updates/80-schema_compat.update so it is ran after 50-externalmembers.update. And since at that point cn=groups,cn=Schema ... does not exist yet, it is not applied.
You can re-run ipa-server-upgrade manually once to see if objectclass=ipaexternalgroup would be added. Please report if that fixes your observed difference.
this did in fact create objectclass=ipaexternalgroup for all our Posix groups, our data now matches on new replicas vs existing servers I'm going to reuse this bug to move the update file around. Upstream ticket: https://pagure.io/freeipa/issue/8193 Upstream PR: https://github.com/freeipa/freeipa/pull/4229 QE: in order to verify this change, set up a replica and see if 'cn=groups,cn=Schema Compatibility,cn=plugins,cn=config' on the replica contains 'schema-compat-entry-attribute: objectclass=ipaexternalgroup' attribute. Fixed upstream master: https://pagure.io/freeipa/c/ff547a2777d63609faba42101e9802f5e988fa00 Fixed upstream ipa-4-8: https://pagure.io/freeipa/c/14dbf04148c6284b176eca34aa70df4bef09b857 ipa-4-7: https://pagure.io/freeipa/c/9db61a51f4cfcaae5e51d10c9ce2ed751cce4c49 ipa-4-6: https://pagure.io/freeipa/c/a5a201fc008b19841f98bb70d44ede7d04ef1126 Test case added to upstream master: https://pagure.io/freeipa/c/9120d65e881e582cc37ee8445fb66a54f6fb4d75 https://pagure.io/freeipa/c/312d00df90fc40c1c4c934945c3c73053b6ea18a ipa-4-8: https://pagure.io/freeipa/c/210619a98f0d8a042a181bab5891bdd595aa5351 https://pagure.io/freeipa/c/3f3fa403a944035cf5531939fe3a2e338da99612 Fixed upstream ipa-4-6: https://pagure.io/freeipa/c/e6960b7af2e8d8e4746245d8ba82a46225174529 https://pagure.io/freeipa/c/b739bc2089774cea0437347283c821ac86f8251d ipa-4-7: https://pagure.io/freeipa/c/405363baa62c7a2e875aae516abc8080031094f2 https://pagure.io/freeipa/c/651d97a47d1f60875648ae72c2c0e6fe6ffabe04 Both the automation passed. Hence marking the bug as verified. *** Bug 1860262 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: ipa security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3936 |