Red Hat Bugzilla – Bug 983295
Unable to bypass FQDN requirement for rhevm-setup
Last modified: 2015-09-22 09:09 EDT
Description of problem: When installing RHEV-M 3.2 in a lab or test environment where a FQDN might not always be available, the rhevm-setup script does not allow the user to bypass the FQDN requirement. While I agree that forcing FQDN for an enterprise product is the way to go, there should be a --flag to bypass this for certain instances if the user is made aware of the risks. Version-Release number of selected component (if applicable): rhevm-setup-3.2.0-11.33 How reproducible: Very Steps to Reproduce: 1. Configure a RHEL system without a FQDN such as an internal dynamic DNS environment in a lab 2. yum install rhevm 3. rhevm-setup Actual results: Install fails with error "Host fully qualified domain name. Note: this name should be fully resolvable [quimby] : quimby.usersys.redhat.com" The IP XX.XX.XX.XX does not hold a PTR record for the FQDN: quimby.usersys.redhat.com Expected results: The installer should have a --flag to allow the user to bypass the FQDN requirement and alert them of the risks and possibly require an additional Y/N answer. Additional info: This is necessary for setting up many of our internal Red Hat test environments.
This is in place because of these reasons: 1. libvirt requirement, as far as we know it tries to resolve the name and reverse resolve name when performing migration, so in aio configuration this is important. 2. ovirt-node/rhev-h require to access the engine via ssl, and host name must be resolvable. 3. users require to access the engine via ssl, and in order to avoid errors regarding host name mismatch there should be proper naming services. But manual bypassing is important, and we have just had a discussion about this[1] And in new installer we limited the reverse resolve to the aio configuration. [1] http://gerrit.ovirt.org/#/c/16543/
Moran, This should be closed as CANTFIX or NOTBUG or anything... Thanks,
(In reply to Alon Bar-Lev from comment #2) > But manual bypassing is important, and we have just had a discussion about > this[1] > > And in new installer we limited the reverse resolve to the aio configuration. > > [1] http://gerrit.ovirt.org/#/c/16543/ Can we fix this in the next RHEV 3.2.z installer? Upping priority to high. This severely limits our ability to install RHEV in a lab environment that might not have DNS but where we could fake it with /etc/hosts entry. Also, think about the customers... what if a customer wants to do a POC of RHEV but they don't have DNS for that environment? They will be dead in the water unless they install RHEV 3.1 first.
Forcing the RHEVM FQDN to forward/reverse resolve during rhevm-setup also breaks the procedure we are using for RHEV-M on HA cluster (https://access.redhat.com/site/node/216973). We don't set the IP address for the RHEV-M until we set up the cluster some time after rhevm-setup. That's because that IP address needs to move among different cluster nodes.
This should be resolved in 3.3.
This is not resolved yet on current formal release sf20.1 (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4.
(In reply to Ilanit Stein from comment #8) > This is not resolved yet on current formal release sf20.1 > (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4. This is not cloned bug for 3.2.z, it is the bug for 3.3.0.
Verified on is12: invalid fqdn in non interactive mode indeed allowed.
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
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. http://rhn.redhat.com/errata/RHSA-2014-0038.html