Bug 890572

Description of problem:
On a RHEV-H host in a RHEV 3.1 environment the '/etc/vdsm-reg/vdsm-reg.conf' file initially contains "vdc_host_port=443". 

If registration of a RHEV-H host is initiated from the RHEV Manager, the host port that it uses in RHEV 3.1 is 80, and the 'vdc_host_port' value in the '/etc/vdsm-reg/vdsm-reg.conf' file is changed accordingly. However, the line becomes "vdc_host_port = 80". It now has a space before and after the '=' sign. 

If the RHEV-H host is then re-registered from RHEV-H (not from RHEV Manager), then the 'Management Server Port' value on the 'RHEV-M Configuration' menu can no longer be modified.

What happens then is that as long as communication between the host and RHEV-M via port 80 is successful, then there appears to be no issue with this change in format, other than the value can no longer be modified via the'RHEV-M Configuration' menu.


Version-Release number of selected component (if applicable):
RHEV 3.1
RHEV-H 6.3
VDSM, VDSM-REG 4.9.6-x.x.x

However, this also occurs in RHEV 3.0 with VDSM/VDSM-REG 4.9-x.x.


How reproducible:
Every time.


Steps to Reproduce:
1. Register a RHEV-H host from the RHEV Manager.

2. Re-register the RHEV-H host from RHEV-H (via the 'admin' login/'ovirt-config-setup' menus)

3. The 'Management Server Port' value on the 'RHEV-M Configuration' menu can no longer be modified.
  

Actual results:
When a RHEV-H hypervisor is registered the '/etc/vdsm-reg/vdsm-reg.conf' file is initially configured with the host port set as "vdc_host_port=443";

[vars]
# time to wait (in seconds) for the next registration request when registration fails
reg_req_interval = 5
#The location of the vdsm conf file
vdsm_conf_file=/etc/vdsm/vdsm.conf
#The location of the pid file
pidfile=/var/run/vdsm-reg.pid
#The logger conf file
logger_conf=/etc/vdsm-reg/logger.conf
#The hostname of the vdc, should be verified each boot (look for DNS SRV record)
vdc_host_name=None
#The port of the RHEV-M. Allows http or https connections.
vdc_host_port=443	
#The registrtion uri
vdc_reg_uri=/RHEVManagerWeb/VdsAutoRegistration.aspx
#Upgrade settings
upgrade_iso_file=/data/updates/ovirt-node-image.iso
upgrade_mount_point=/live
# registration ticket
ticket=


The 'vdc_host_port' value then gets written by the 'setup' script during the host registration process;

        if engine_port is not None:
            deployUtil._updateFileLine(vdsm_reg_conf_file, "vdc_host_port", str(engine_port), True)


'deployUtil._updateFileLine()' is called, which writes it specifically with no space characters;

        for line in old_file:
            #Note: the line below must not have spaces before or after the '=', since it'll fail bash scripts !
            newLine = re.sub('^[#\s]*%s\s*=.*' % key , '%s=%s' % (key, value), line)
            if re.match('^%s=%s$' % (re.escape(key), re.escape(value)), newLine):
                logging.debug("_updateFileLine: replacing " + str(line) + " with: " + newLine)
                fReplaced = True
                line = newLine

 
However, when 'vdsm-reg-setup' is then executed, it executes the following;

         if ticket:
             if registered or ticketRetries is 0:
                 config.set('vars', 'ticket', '')
                 config.write(file(confFile, 'w+'))
                 deployUtil.ovirtfunctions.ovirt_store_config(confFile)
                 ticket = ""


Prior to the call to 'config.write(), the '/etc/vdsm-reg/vdsm-reg.conf' file remains unchanged. However, inside this routine, which is 
in 'Configparser.py', the file contents are erased and new contents are written;

    380     def write(self, fp):
    381         """Write an .ini-format representation of the configuration state."""
    382         if self._defaults:
    383             fp.write("[%s]\n" % DEFAULTSECT)
    384             for (key, value) in self._defaults.items():
    385                 fp.write("%s = %s\n" % (key, str(value).replace('\n', '\n\t')))
    386             fp.write("\n")
    387         for section in self._sections:
    388             fp.write("[%s]\n" % section)
    389             for (key, value) in self._sections[section].items():
    390                 if key != "__name__":
    391                     fp.write("%s = %s\n" %
    392                              (key, str(value).replace('\n', '\n\t')))
    393             fp.write("\n")


The 'self._sections' array looks like;

{'vars': {'vdc_host_port': '80', 'test_socket_timeout': '10', 'reg_req_interval': '5', 'vdsm_conf_file': '/etc/vdsm/vdsm.conf', 'vdc_reg_uri': '/SolidICE/VdsAutoRegistration.aspx', 'vdc_authkeys_path': '/rhevm.ssh.key.txt', 'vdsm_dir': '/usr/share/vdsm', 'vdc_host_ip': 'None', 'vdc_reg_port': '54321', 'logger_conf': '/etc/vdsm-reg/logger.conf', 'upgrade_iso_file': '/data/updates/ovirt-node-image.iso', 'ticket': '', 'vdc_host_name': 'None', 'pidfile': '/var/run/vdsm-reg.pid'}}


On exit, the file contents have been re-written and all entries contain a space before and after the '=' sign, e.g.

[vars]
vdc_host_port = 80
test_socket_timeout = 10
reg_req_interval = 5
vdsm_conf_file = /etc/vdsm/vdsm.conf
vdc_reg_uri = /SolidICE/VdsAutoRegistration.aspx
vdc_authkeys_path = /rhevm.ssh.key.txt
vdsm_dir = /usr/share/vdsm
vdc_host_ip = None
vdc_reg_port = 54321
logger_conf = /etc/vdsm-reg/logger.conf
upgrade_iso_file = /data/updates/ovirt-node-image.iso
ticket = 
vdc_host_name = None
pidfile = /var/run/vdsm-reg.pid



If the RHEV-H host is then re-registered from RHEV-H (not from RHEV Manager), the 'Management Server Port' value on the 'RHEV-M Configuration' menu cannot be changed.┘


If you enter a new value, e.g. 443, it will revert to 80.

The reason is that the spaces before and after the '=' sign cause 'engine.py' (and 'rhevm.py' in 3.0) not to be able to modify this value in '/etc/vdsm-reg/vdsm-reg.conf';

    if system("ping -c 1 " + engineHost):
        sed_cmd = "sed -i --copy \"s/\(^vdc_host_name=\)\(..*$\)/vdc_host_name=" + engineHost + "/\" " + VDSM_REG_CONFIG
        if system(sed_cmd):
            log("The @ENGINENAME@'s address is set: %s\n" % engineHost)
        if enginePort != "":
            sed_cmd = "sed -i --copy \"s/\(^vdc_host_port=\)\(..*$\)/vdc_host_port=" + str(enginePort) + "/\" " + VDSM_REG_CONFIG
            if system(sed_cmd):
                log("The @ENGINENAME@'s port set: %s\n" % enginePort)
            fWriteConfig=1



Expected results:
The 'Management Server Port' value on the 'RHEV-M Configuration' menu should be able to be modified.


Additional info:
This is a fairly trivial bug, but I have seen customer cases where an initial attempt to register a RHEV-H host failed and follow-up attempts have been required, and in so doing I have seen the the 'vdsm-reg.log' contain something like this, where the HTTPS connection fails, but then the HTTP connection succeeds;

MainThread::DEBUG::2012-11-02 15:02:39,773::vdsm-reg-setup::199::root::execute: after getRhevmCert: True
MainThread::DEBUG::2012-11-02 15:02:39,776::deployUtil::1265::root::getRemoteFile start. IP = 10.16.190.122 port = 8080 fileName = "/rhevm.ssh.key.txt"
MainThread::DEBUG::2012-11-02 15:02:59,790::deployUtil::1285::root::/rhevm.ssh.key.txt failed in HTTPS. Retrying using HTTP.
Traceback (most recent call last):
  File "/usr/share/vdsm-reg/deployUtil.py", line 1280, in getRemoteFile
  File "/usr/share/vdsm-reg/deployUtil.py", line 1124, in getSSLSocket
  File "/usr/lib64/python2.6/ssl.py", line 338, in wrap_socket
  File "/usr/lib64/python2.6/ssl.py", line 120, in __init__
  File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake
SSLError: [Errno 8] _ssl.c:490: EOF occurred in violation of protocol


I can't tie instances of the message sequence above specifically to this bug, and therefore haven't attached any customer cases to this bug, but it is certainly a possibility that this bug is the cause of the message sequence above. However, as long as the subsequent HTTP connection succeeds then the host registration will continue, so this bug does not necessarily cause a blocking problem. It can however potentially result in a misdiagnosis of a host registration failure, if something else in the registration sequence actually were to fail. I digress.