Red Hat Bugzilla – Bug 1254793
Network Server Web Interface Not Able to Register SUT
Last modified: 2017-04-22 22:25:04 EDT
Created attachment 1064506 [details]
screenshot of error
Description of problem:
On the network test server web interface configuration tab not able to successfully register the RHEL7.0 SUT. Error encountered is could not reach sut1.localdomain. Yet from the network test server I can successfully ping sut1.localdomain.
Per Gary Case the network test server is running RHEL7.1 and was installed using the attached kickstart file rhcert-rhel7-kickstart.cfg.
The SUT is running RHEL7.0.
Version-Release number of selected component (if applicable):
Cert kit components on SUT & Network Server:
Also tried redhat-certification-1.0-20150723.el7.noarch
How reproducible: always
Steps to Reproduce:
1. On the network test server install RHEL7.1 using attached kickstart
2. Ensure only one NIC port has an ip address
3. Set a unique hostname
4. Install above cert kit components
5. Disable firewall - systemctl stop firewalld
6. Activate network server - rhcert-backend server start
7. On network server open firefox and enter network server URL, see attached
screenshot which includes error
Actual results: Firefox error - could not reach sut1.localdomain, see attached screenshot. Yet from the network test server I can successfully ping sut1.localdomain. Also from the SUT I can successfully ping the network server markrs.localdomain.
Expected results: Registering the SUT via the network server web interface should work.
Additional info: Only way I have been able to register a SUT is the following:
1. Network server set SELinux to permissive
2. On the SUT run command - rhcert-backend register --server markrs.localdomain
3. Refresh web interface on network server
Created attachment 1064507 [details]
network server kickstart file
Additional details when registering SUT via the alternate method, step 2 above.
When the SUT command rhcert-backend register --server markrs.localdomain is run the SUT output is in the attached screenshot2.jpg.
Once the network server browser is refreshed the system is still listed as localhost.localdomain even though the SUT /etc/hostname is sut1.localdomain, see screenshot3.jpg.
The web interface system field always reporting localhost.localdomain prevents the SUT from downloading the pre-built VMs from the network server and also causes the network test to fail.
Created attachment 1064557 [details]
Created attachment 1064562 [details]
I suspect the SUT isn't configured with the correct hostname. What does the "hostname" command show from the SUT? This would explain why the registration via the CLI from the SUT to the server result shows "localhost.localdomain".
Does registration from the server to the SUT via IP address work? Try entering the IP address of the SUT in the server dialog that asks for hostname.
How is the SUT's hostname configured so that ping from the server translates the name to an IP address - hosts table on the server, or is DNS running? Does ping from the server show IP address of the SUT (10.5.5.123?)?
Can testing proceede based on IP addresses, and avoid this problem alltogether?
At the bottom of the SUT screenshot2.jpg, the hostname command returns sut1.localdomain as expected.
Registration via the SUT IP address fails with the same error... could not reach ip address.
For the hostname resolution I'm using the /etc/hosts file.
From the network server when I ping the SUT hostname it returns the SUT ip 10.5.5.123.
I thought we did away with the need for DNS and hostname registration? Many vendors do not have DNS setup in their labs. This looks like we might have reintroduced that bug?
That's correct, DNS resolution is not required if IP addresses are used.
From screenshot 2, the SUT sees the server as 10.5.5.89
The SUT sees its hostname appears as "sut1.localdomain",
and the server markrs.localdomain.
The server sees the SUT as 10.5.5.125
The registration seems to work.
Screenshot 3 from markrs shows an SUT at 10.5.5.123, which it seems as "localhost.localdomain", which shows as "ready", again, seeming to work.
As a result, I'm not clear on the test setup. Are there two SUT's, or ?
In any case, can we re-try testing based on IP address, just one SUT and a server?
There is only one SUT but it has four ethernet ports, which is why you see multiple ips for the SUT. The network server has one active ethernet port at 10.5.5.89.
The problem is I have not been able to register the SUT via the network server web interface even when server names are resolved vi the /etc/hosts file.
Screenshot 2 is when registering using the SUT command and /etc/hosts name resolution.
I'll provide details when not using the /etc/hosts but rather ip addresses only as this is our prefered method.
Created attachment 1066998 [details]
The attached registerip.jpg error, waiting for connection, occurs when I try to register the DL360 Gen9 SUT at 10.5.5.131 from the network server web interface using ip addressing only. The /etc/hosts is not being used here.
The DL360pGen8 is still listed in the configuration tab b/c I cannot remove it.
The registerip2.jpg is with the network server /etc/hostname as the ip address just to verify same outcome.
Created attachment 1067013 [details]
What does "rhcert-backend server status" show when run on 10.5.5.131?
You could also try running the listener process on 10.5.5.131 in the foreground via "rhcert-backend server listener" and look for logging of requests by the server (10.5.5.89).
How do I remove a registered server with a status of waiting for response when the remove button does not work?
There is not a test plan associated with this particular SUT but I cannot delete it. I would like to start fresh, nothing listed under registered systems.
In reference to comment 12 & 13, the SUT rhcert-backend server service was not running. Started it and set it to start at boot time. This resolved the server registration waiting for connection error, but the registration status remained in a waiting for response state until the SUT rhcert-backend server service was restarted again.
How would you like to proceed next? For debug purposes, should HP try with only one ethernet port connected? Can they get you any other data?
The other issue mentioned in comment #15 is no longer seen with the latest cert kit 20150901.
This bug is a little confusing to me after reading it a couple times and it may be confusing to the assigned engineer as well.
So let's try and get a clear description of what the exact problem at this time is.
Is the originally described issue still persisting with the 20150901 package? Do you guys still have trouble getting the sut to register?
To me, it looks like the remianing problem is that the rhcert-backend server service needs to be restarted multiple times before the SUT can register.
Is this an accurate description of what you are seeing now?
All issues mentioned in this bug have been resolved, the latest official cert kit 20150901 works fine for registering a SUT.