Description of problem: Installed one machine with RHEL5.4 sever and v7 to be the test server for v7 tests. Issued 'v7 server start' and yes, everything sems to run. When I try to do a "v7 plan --server 192.168.2.2" I get a warning that the server 192.168.2.2 is not running. Version-Release number of selected component (if applicable): v7-1.0-15.el5.noarch.rpm How reproducible: Always Steps to Reproduce: 1. Install v7 test server 2. v7 server start 3. on another machine "v7 plan --server <ipofserver>" Actual results: Get a warining message from v7 plan when its verifying the server. Expected results: No warning message should occur.
The problem with the current implementation is that when v7 tries to validate the v7 server, it invokes the "v7 server status" command on the server via the server's cgi http://<hostname>/v7/cgi/v7web.py?command=status This causes numerous SELinux errors on the server, as the "v7 server status" command is invoked by the httpd via cgi. The resulting broken response is not parsed by the v7 client, causing the validation to fail. The problems are due to the v7 server implementation. There is no v7 server process. The start, stop, and status commands are merely scripts that invoke the necessary lmbench, nfs, and httpd services. At this point, there are two possible paths to a solution: 1) implement the v7 server as a separate process. This is already implemented as the "v7 server daemon" command, which launches v7 in a simple polling loop that reads a task file. The web cgi could simply write to a task file, then read the response of the v7 daemon, eliminating the SELunix errors in the current implementation. 2) simplify the cgi status response v7's web cgi could have a simpler response that did not check the actual server status (running state of httpd, lmbench and nfs), but had a simple response that basically indicated that v7 was installed on the server, and httpd was running. So, should we consider the full solution 1), or the expedient solution 1)? Or perhaps some other idea?
Option one seems like it makes the most sense presuming the polling method doesn't consume too many resources on the server, if so an interrupt or other communication method would need to be used. While this should be fixed as it's obvious bad user experience I'm not thinking this is blocker material if fixing it right with option 1) will take us past the 1.1 dates (and presuming the only impact is the incorrect reporting).
Created attachment 473933 [details] hardwaretest.patch updating server verification This patch updates server verification to allow verification of any v7 server, removing an erroneous version/release comparison, and improves some output. This patch is not a complete fix, as the v7 server reports an error on checkinging export of /var/v7/export that does not appear when running v7 on the server directly.
*** Bug 640351 has been marked as a duplicate of this bug. ***
Created attachment 512696 [details] server status patch to network and kdump tests This patch moves nfs out of the network test (which no longer uses nfs) into the kdump test (uses nfs for network image dumps). Also, the status checking for server status by kdump of nfs is changed to check the /usr/lib/nfs/etab file directly, as this file is readable by everyone, rather than the exportfs command, only usable by root. The server status command is run via httpd/cgi, so it needs to be able to run as a non-root user.
Created attachment 512698 [details] server status patch to network and kdump tests
Created attachment 512700 [details] patch to change server minimum version to 1.4 This patch changes the server minimum version used by clients (SUTs) to 1.4. This is checked when supplying a server hostname via "v7 plan --server <host>".
Created attachment 512702 [details] server status patch to network and kdump tests One added change to fix hard-coded nfs mount point used by SUT.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: In v7 1.3 and previous versions, v7 plan --server command reported server was not running even if v7 server was actually launched correctly. The bogus warning message has been fixed in v7 1.4. Now v7 server running status verification from SUT side is more reliable and no more bogus warning message is printed.
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/RHBA-2011-1436.html