Description of problem:
Upgrading the host from version RHVH-4.1-20170925.0 is losing the satellite certificate file from the location /usr/share/rhn/
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1) Install RHV-H 7.4 node (Usig ISO image: RHVH-4.1-20170925.0-RHVH-x86_64-dvd1.iso)
2) Register with Satellite v5.x (Using version: satellite v5.7)
3) Confirm existence of /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
4) From RHEV-M host, put newly built host into maintenance mode
5) From RHEV-M host, check for upgrades (will always come back with "updates available")
6) From RHEV-M host, upgrade newly built host.
7) When the newly built host comes back up, the file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT will no longer exist
The file "/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" does not exist.
The file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT should be available.
Current observation is for this file only. Not sure about any other configuration missing.
This will also be true for any other volatile data stored in /usr
We made a strong effort in RHV to move all volatile data to /var, as /usr on RHVH is per-image.
For the rpmdb, we've done the reverse by symlinking /var/lib/rpm to /usr/share/rpm
We can easily do this for /usr/share/rhn. Does Satellite keep any other volatile data in /usr?
F(In reply to Ryan Barry from comment #2)
> This will also be true for any other volatile data stored in /usr
> We made a strong effort in RHV to move all volatile data to /var, as /usr on
> RHVH is per-image.
> For the rpmdb, we've done the reverse by symlinking /var/lib/rpm to
> We can easily do this for /usr/share/rhn. Does Satellite keep any other
> volatile data in /usr?
For the satellite to communicate with the client, these following three files should be available with the configuration intact.
So, here the concern is only with the certificate file which is missing after the upgrade. Others are available with the configuration.
The similar issue found with "/etc/resolv.conf" file.
The changes made in 'resolv.conf' with image 'rhvh-4.1-0.20170925.0' missing after update to newer image 'rhvh-4.1-0.20171002.0'.
Steps to reproduce :
1) Build RHV-H host using RHVH-4.1-20170925.0-RHVH-x86_64-dvd1.iso
2) Join to RHEV-M DC and cluster
3) Make changes to "/etc/resolv.conf"
3) Put newly build host into maintenance mode
4) In RHEV-M webUI, check for upgrades
5) In RHEV-M webUI, upgrade newly built host
6) After newly built host has rebooted, check /etc/resolv.conf, note the modified settings line is missing.
QE can reproduce this issue, but not exactly according to the customer's steps due to no suitable satellite server.
1. For the file "/etc/resolv.conf"(configuration file for DNS resolvers), if modify this file directly, the modification will missing when restart network service, so this issue is not related to upgrade, as the method of modify the file is not suitable.
1.1 I tried to modify /etc/sysconfig/network-scripts/ifcfg-$NIC(such as add: DNS1=10.72.17.6),
1.2 Run "#service network restart", then "/etc/resolv.conf" is modified automately(add: nameserver 10.72.17.6)
1.3 Upgrade rhvh from rhvh-4.1-0.20170925.0 to rhvh-4.1-0.20171002.0 , the changes made in 'resolv.conf' in step 1.2 are persisted.
2. For the file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT, it is not exit after upgrade.
# imgbase layout
2.1 Install rhvh-4.1-0.20170925.0
2.2 Touch new file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
2.3 Upgrade rhvh from rhvh-4.1-0.20170925.0 to rhvh-4.1-0.20171002.0
2.4 Check file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
After step 2.4, there is no file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.
After step 2.4, there should be file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.
# imgbase layout
1 Install rhvh-4.1-0.20171205.0
2 Touch new file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
3 Upgrade rhvh from rhvh-4.1-0.20171205.0 to rhvh-184.108.40.206-0.20171207.0
4 Check file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
After step 4, there is file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.
So this issue is fixed in rhvh-220.127.116.11-0.20171207.0, change the status to verified.
According to comment 13, change the status 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.