Hide Forgot
Description of problem: bind package is not automatically updated during ipa-server upgrade process from Rhel 7.3.z to RHEL 7.4 Version-Release number of selected component (if applicable): ipa-server-4.5.0.20 How reproducible: Always Steps to Reproduce: 1. Setup IPA-server at RHEL 7.3.z. 2. Use the latest repo links for RHEL 7.4 3. Update the ipa server by executing commands: # yum -y update 'ipa*' sssd 4. Restart ipa service "ipactl restart" Actual results: 1. After step3, the upgrade process completes successfully. 2. After step4, the ipactl command fails to restart ( The named-pkcs11 service fails to restart) 3. the bind package is not updated :: [ PASS ] :: Command 'yum -y update 'ipa*' sssd 'python*'' (Expected 0, got 0) :: [ BEGIN ] :: Running 'tail -1 /var/log/ipaupgrade.log | grep 'The ipa-server-upgrade command was successful'' :: [ BEGIN ] :: Running 'ipactl restart' Failed to start named Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl Starting Directory Service debugging enabled, suppressing output. Starting krb5kdc Service Starting kadmin Service Starting named Service :: [ FAIL ] :: Command 'ipactl restart' (Expected 0, got 1) :: [ BEGIN ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-ca sssd' ipa-server-4.5.0-20.el7.x86_64 389-ds-base-1.3.6.1-16.el7.x86_64 bind-9.9.4-50.el7_3.1.x86_64 <--- (RHEL 7.3.z) bind-dyndb-ldap-11.1-3.el7.x86_64 pki-ca-10.4.1-10.el7.noarch sssd-1.15.2-50.el7.x86_64 Expected results: The ipactl restart command should run successfully. Additional info: The upgrade is successful and ipactl restart command run correctly for following paths: 1. 7.1.z > 7.4 2. 7.2.z > 7.4 3. 7.3 > 7.4
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