Bug 1469480
Summary: | bind package is not automatically updated during ipa-server upgrade process | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Nikhil Dehadrai <ndehadra> | ||||
Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> | ||||
Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.4 | CC: | enewland, jreznik, ksiddiqu, mkosek, pasik, pemensik, pvoborni, rcritten, salmy, thozza, tscherf | ||||
Target Milestone: | rc | Keywords: | Regression, TestBlocker, ZStream | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | ipa-4.5.0-21.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: |
Prior to this update, the bind packages were missing certain patches required by the bind-dyndb-ldap system plug-in. Consequently, the "named" service failed. To fix this bug, correct version of the bind packages has been used when installing bind-dyndb-ldap. As a result, correct bind package is installed.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 1469978 1469980 (view as bug list) | Environment: | |||||
Last Closed: | 2018-04-10 16:42:04 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1469978, 1469980 | ||||||
Attachments: |
|
Description
Nikhil Dehadrai
2017-07-11 11:11:49 UTC
This issue seems to be caused by the bind-9.9.4-50.el7_3.1 package. bind-dyndb-ldap requires bind >= 9.9.4-44, which adds the patches for the dyndb API. This version is in RHEL 7.4. What's the reason bind version was bumped to bind-9.9.4-50 in RHEL 7.3? It doesn't contain the dyndb patches, yet it meets the requirement for the new version required by bind-dyndb-ldap, which causes the new bind to not be installed. The bind version was bumped to bind-9.9.4-50 in RHEL 7.3 to avoid creating a security regression. We had to fix https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3143 in RHEL 7.3.z due to customer demand, and also due to the Important security impact of the bug. We had to release this fix when 7.4 Y-stream was frozen. Without this version bump, this situation would have resulted in a security regression (bind in 7.3.z fixed, bind in 7.4 GA affected, bind in 7.4.z fixed). This option to bump versions (which we used) is mentioned in the https://mojo.redhat.com/docs/DOC-1048823 document. Another possible option might be to backport the "dyndb patches" to the BIND version in RHEL 7.3. Once this is done, a RHBA for BIND in RHEL 7.3 could be released prior to the 7.4 GA release. The IPA 0-day erratum sounds like a better solution though. dyndb patches *can not* be backported to 7.3, since it would break all existing bind-dyndb-ldap installations on 7.3. The new API is not compatible with older versions of bind-dyndb-ldap. Created attachment 1296759 [details]
patch for dist-git
IPA-SERVER-VERSION: ipa-server-4.5.4-4.el7.x86_64 BIND: bind-9.9.4-58.el7.x86_64 bind-dyndb-ldap-11.1-4.el7.x86_64 Verified the bug on the basis of following observations: 1) Verified that IPA-server/replica is upgrade successfully. 2) Verified that bind package is updated successfully. 3) Verified that ipactl services are restarted correctly after the upgrade. 4) Verified the same for following upgrade paths: - 7.4.3 > 7.5 - 7.4-0day > 7.5 - 7.3.z > 7.5 - 7.2.z > 7.5 - 7.1.z > 7.5 - 7.0 > 7.5 - FAILS (Known issue bz#1482776) Details as below: :: [ BEGIN ] :: Running 'tail -1 /var/log/ipaupgrade.log | grep 'The ipa-server-upgrade command was successful'' 2017-11-29T07:25:36Z INFO The ipa-server-upgrade command was successful :: [ PASS ] :: Command 'tail -1 /var/log/ipaupgrade.log | grep 'The ipa-server-upgrade command was successful'' (Expected 0, got 0) :: [ BEGIN ] :: Running 'sleep 60' :: [ PASS ] :: Command 'sleep 60' (Expected 0, got 0) :: [ BEGIN ] :: Running 'ipactl restart' ipa: INFO: The ipactl command was successful Stopping pki-tomcatd Service Restarting Directory Service debugging enabled, suppressing output. Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Restarting smb Service Restarting winbind Service Restarting ipa-otpd Service Restarting ipa-dnskeysyncd Service :: [ PASS ] :: Command 'ipactl restart' (Expected 0, got 0) :: [ BEGIN ] :: Running 'ipactl status' ipa: INFO: The ipactl command was successful Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING ntpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING :: [ PASS ] :: Command 'ipactl status' (Expected 0, got 0) :: [ BEGIN ] :: Running 'service sssd status' Redirecting to /bin/systemctl status sssd.service ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-11-29 02:25:29 EST; 5min ago Main PID: 16878 (sssd) CGroup: /system.slice/sssd.service ├─16878 /usr/sbin/sssd -i --logger=files ├─16879 /usr/libexec/sssd/sssd_be --domain am2911.test --uid 0 --gid 0 --logger=files ├─16880 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files ├─16881 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --logger=files ├─16883 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files ├─16884 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files └─16885 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files Nov 29 02:25:29 ipaqavmg.am2911.test systemd[1]: Started System Security Services Daemon. Nov 29 02:25:29 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 2 Nov 29 02:26:00 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:26:00 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:26:00 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:26:00 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 2 Nov 29 02:30:17 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:30:17 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:30:17 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 1 Nov 29 02:30:17 ipaqavmg.am2911.test sssd_be[16879]: GSSAPI client step 2 :: [ PASS ] :: Command 'service sssd status' (Expected 0, got 0) :: [ BEGIN ] :: Running 'service sssd restart' Redirecting to /bin/systemctl restart sssd.service :: [ PASS ] :: Command 'service sssd restart' (Expected 0, got 0) :: [ BEGIN ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-ca sssd' ipa-server-4.5.4-4.el7.x86_64 389-ds-base-1.3.7.5-10.el7.x86_64 bind-9.9.4-58.el7.x86_64 bind-dyndb-ldap-11.1-4.el7.x86_64 pki-ca-10.5.1-4.el7.noarch sssd-1.16.0-7.el7.x86_64 :: [ PASS ] :: Command 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-ca sssd' (Expected 0, got 0) Thus on the basis of above observations, marking the status of bug to "VERIFIED" 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, 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/RHBA-2018:0918 |