Bug 1506550

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?

(Originally by Ryan Barry)

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
> /usr/share/rpm
> 
> 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. 

~~~
/etc/sysconfig/rhn/up2date
/etc/sysconfig/rhn/systemid
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
~~~

So, here the concern is only with the certificate file which is missing after the upgrade. Others are available with the configuration.

(Originally by Ulhas Surse)

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.

(Originally by Sachin Raje)

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.

Test version:
# imgbase layout
rhvh-4.1-0.20170925.0
 +- rhvh-4.1-0.20170925.0+1
rhvh-4.1-0.20171002.0
 +- rhvh-4.1-0.20171002.0+1

Test steps:
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

Actual results:
After step 2.4, there is no file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.

Expected results:
After step 2.4, there should be file /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.

(Originally by Huijuan Zhao)

I was positive I posted a comment about this on Friday.

The missing changes in network files seem to be due to a misunderstanding in the test scenario.

The changes in /etc/resolv.conf do NOT survive a restart of NetworkManager.service (resolv.conf itself tells you it is managed by NetworkManager, not "network.service")

The changes in /etc/sysconfig/network-scripts/ifcfg-* must be done in the engine, as the files are managed by vdsm. Please ensure that files in /var/lib/vdsm/persistence match the expected configuration. These files also tell you they are managed by vdsm. It is the reboot which is overwriting these, which will happen with or without an upgrade.

I made some trivial changes and upgraded, then mounted the new LV:

[root@localhost imgbased]# mount /dev/mapper/rhvh-rhvh--4.1--0.20171025.0+1 /tmp/a
[root@localhost imgbased]# cat /tmp/a/etc/resolv.conf 
# Generated by NetworkManager
search nested
nameserver 192.168.122.1

#test comment
[root@localhost imgbased]# cat /tmp/a/etc/sysconfig/network-scripts/ifcfg-ens3 
# Generated by dracut initrd
# test comment
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="74cf2f12-4819-4bdf-882e-49b7a9bb6822"
IPV6INIT=yes
BOOTPROTO=static
IPADDR=192.168.122.237
DNS1=192.168.122.1
GATEWAY=192.168.122.1
TYPE=Ethernet
[root@localhost imgbased]#

The changes made it.

/usr/share/rhn/... requires the posted patch, but this is not a blocker IMO (this has existed since RHVH 4.0). I'm happy to backport the patch.

However, please retest the changes to /etc

Huijuan, a test from Virt QE would also be appreciated.

1. Other files changes in /etc (I tested /etc/aliases, and touched new file /etc/test) can be persisted after upgrade.

2. But for the /etc/resolv.conf, after register rhvh to rhvm, when change the /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt manually, the /etc/resolv.conf can not be changed according to ifcfg-ovirtmgmt, even if restart service network or restart service NetworkManager. 
Just as Ryan said in comment 10: The changes in /etc/sysconfig/network-scripts/ifcfg-* must be done in the engine, as the files are managed by vdsm.

But I am not sure how to change the ifcfg-ovirtmgmt by vdsm ?

I reproduced according to comment 9 steps, the results are not exactly same as comment 9.

Test version:
From: rhvh-4.1-0.20170925.0
To:   rhvh-4.1-0.20171002.0

Test steps:
1. Install rhvh-4.1-0.20170925.0, and register rhvh to rhvm

2. Check the files:
# cat /etc/sysconfig/network-scripts/ifcfg-em1
# Generated by VDSM version 4.19.31-1.el7ev
DEVICE=em1
BRIDGE=ovirtmgmt
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

# cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
# Generated by VDSM version 4.19.31-1.el7ev
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
DNS1=10.72.17.5
DNS2=10.68.5.26

# cat /etc/resolv.conf 
; generated by /usr/sbin/dhclient-script
search nay.redhat.com. redhat.com.
nameserver 10.72.17.5
nameserver 10.68.5.26

3. Manually change ifcfg-ovirtmgmt(add 2 lines: DNS3=10.72.18.6 and PEERDNS=no), and then restart service network and NetworkManager, check files.

# cat /etc/sysconfig/network-scripts/ifcfg-em1
# Generated by VDSM version 4.19.31-1.el7ev
DEVICE=em1
BRIDGE=ovirtmgmt
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

# cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
# Generated by VDSM version 4.19.31-1.el7ev
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
DNS1=10.72.17.5
DNS2=10.68.5.26
DNS3=10.72.18.6
PEERDNS=no

# cat /etc/resolv.conf 
; generated by /usr/sbin/dhclient-script
search nay.redhat.com. redhat.com.
nameserver 10.72.17.5
nameserver 10.68.5.26

# cat /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt 
{
    "ipv6autoconf": true, 
    "nameservers": [
        "10.72.17.5", 
        "10.68.5.26"
    ], 
    "nic": "em1", 
    "mtu": 1500, 
    "switch": "legacy", 
    "dhcpv6": false, 
    "stp": false, 
    "bridged": true, 
    "defaultRoute": true, 
    "bootproto": "dhcp"
}

Please note: /etc/resolv.conf is NOT changed according to ifcfg-ovirtmgmt.

4. Upgrade rhvh to rhvh-4.1-0.20171002.0, check above files.
Same as step3.


So the main problem here is how to change /etc/resolv.conf after register rhvh to rhvm(Obviously the above method is not suitable).

oVirt Node (or RHV-H node) as far as I was aware, allows installation of addiotin RPMs.  I've installed the RPM for the monitoring system we use (Xymon).

The xymon-client needs the file /etc/sysconfig/xymon-client to persist.  From memory it does not persist a RHV-H upgrade (when done via the RHV-M webUI).  I'm not in a position to double check this though.

Colin -

Node does allow installation of RPMs, which are persisted after a reinstall as long as yum is used (including 'yum localinstall')

However, no matter whether this is done or not, everything in /etc should make it across to the new system. The problem here is /usr

Ryan, shouldn't this be ON_QA?

We need to wait for a secalert waive for the errata tool to move this.

Test version:
From: rhvh-4.1-0.20170808.0
To:   rhvh-4.1-0.20171101.0

Test steps:
1. Install old build rhvh-4.1-0.20170808.0, and register to rhvm
2. Touch new file /usr/share/rhn/test1
3. Upgrade rhvh to new version rhvh-4.1-0.20171101.0
4. Reboot and login new build rhvh-4.1-0.20171101.0
5. Check /usr/share/rhn/test1

Test results:
After step5, the file /usr/share/rhn/test1 created in step2 are persisted.


So this bug is fixed in rhvh-4.1-0.20171101.0, 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.

https://access.redhat.com/errata/RHBA-2017:3140