Hide Forgot
Description of problem: rhel6.1 cert test inconsistent about SELINUX policies Version-Release number of selected component (if applicable): v7 v1.3 release 46 How reproducible: unknown Steps to Reproduce: 1. execute v7 server -n ipaddr v7 responds with: Warning: SELinux is in enforcing mode - it must be set to "permissive" for certification testing. 2. execute setenfore 0 3. execute v7 run -t reboot v7 responds with: Actual results: Error: SELinux is in permissive mode - it must be set to "enforcing" for certification testing. Reboot test for nfs failed verification: No test server was set. Expected results: I'm not sure. This my first experience running v7 but I would think the SELINUX policies would be consistent. Additional info:
I think there's some confusion about setting the test server vs. running the test server. Prior to running the test, the test server must be set up on another system (other than the System Under Test). Due to BZ 524983 selinux must be permissive on the test server: myTestServer> setenforce 0 myTestServer> v7 server start To run the reboot test the test server must be set up and running and its host name supplied via --server: systemUnderTest> v7 run --test reboot --server myTestServer The system under test must be running selinux in enforcing mode. The inconsistency in these two policies (SUT vs. the test server) is BZ 524983. Does this clarify the issue?
That's helps some. This time I ran this on the test server: [root@roadking ~]# setenforce 0 [root@roadking ~]# v7 server start Checking installed rpms: fence-agents-3.0.12-23.el6.x86_64 python-lxml-2.2.3-1.1.el6.x86_64 All required rpms installed make server RUNMODE=start python network.py server start Starting lmbench services... done. Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [ OK ] Starting NFS mountd: [ OK ] Starting httpd: [ OK ] Starting v7 daemon That looks like it went OK. Now on the system under test I did: [root@spike ~]# setenforce 1 [root@spike ~]# v7 server -n 10.10.19.187 and I get: Checking installed rpms: fence-agents-3.0.12-23.el6.x86_64 python-lxml-2.2.3-1.1.el6.x86_64 All required rpms installed make server RUNMODE=start python network.py server start Warning: SELinux is in enforcing mode - it must be set to "permissive" for certification testing. Starting lmbench services... done. bind: Address already in use Starting httpd: The v7 server daemon is already started ~~~~~~~~~~~~ Notice I still get a warning message. ~~~~~~~~~~~~ [root@spike ~]# v7 run -t reboot loaded results /var/v7/results.xml the controller /org/freedesktop/Hal/devices/pci_103c_323a_scsi_host is already in testplan, will skip the block device /dev/sda saved test plan to /var/v7/results.xml Running the following tests: info reboot nfs reboot local Reboot test for nfs failed verification: No test server was set. [root@spike ~]# v7 run -t reboot loaded results /var/v7/results.xml the controller /org/freedesktop/Hal/devices/pci_103c_323a_scsi_host is already in testplan, will skip the block device /dev/sda saved test plan to /var/v7/results.xml Running the following tests: info reboot nfs reboot local Reboot test for nfs failed verification: No test server was set. ~~~~~~~~~~~~~~~~~ The nfs test fails saying no server was set, but it was... ~~~~~~~~~~~~~~~~~ 1 Tests Failed Verification Verification failed, would you like to continue testing? (y|n) y response: y info reboot nfs reboot local running info on sh: kudzu: command not found installing test from /usr/share/v7/tests/info into /tmp/v7-info-k7PgXK mkdir -p /tmp/v7-info-k7PgXK cp -a runtest.sh info.py Makefile /tmp/v7-info-k7PgXK chmod a+x ./runtest.sh ./info.py Test Parameters: OUTPUTFILE=/var/log/v7/runs/3/info/output.log DEVICE= TESTSERVER=unknown RUNMODE=normal DEBUG=off UDI= Subtest: Log versions - Log v7 and OS version and release Tested OS: Red Hat Enterprise Linux Server 6.1 (Santiago) Kernel RPM: kernel-2.6.32-131.0.15.el6 v7 version 1.3, release 46 PASS Subtest: Verify v7 - Verify the v7 installation PASS Subtest: Kernel - Check OS kernel build, version + rpm -ql kernel-2.6.32-131.0.15.el6 Boot Parameters: ro root=UUID=0cfc832d-67ba-4326-a4cc-19ff3ebe9665 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=us SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=128M 3 nomodeset PASS Subtest: Modules - Check kernel modules checking modules... ~~~~~~~~~~~~~~~~~~~~~~~~ bunch of dmidecode output and unicode warnings ~~~~~~~~~~~~~~~~~~~~~~~~ saveOutput: /var/log/v7/runs/3/info/output.log Return value was 0 saved to /var/v7/results.xml running reboot on sh: kudzu: command not found installing test from /usr/share/v7/tests/reboot into /tmp/v7-reboot-s0N4XE mkdir -p /tmp/v7-reboot-s0N4XE cp -a runtest.sh reboot.py Makefile /tmp/v7-reboot-s0N4XE chmod a+x ./runtest.sh ./reboot.py Test Parameters: OUTPUTFILE=/var/log/v7/runs/3/reboot/output.log DEVICE=nfs TESTSERVER=unknown RUNMODE=normal DEBUG=off UDI= Subtest initialize: Checking kdump configuration kexec-tools installed: kexec-tools-2.0.0-188.el6.x86_64 Found crashkernel=128M boot parameter Kernel panic reboot timeout is 0 Setting to 1 sec. core_collector currently set to "makedumpfile -d 31" Error: v7 test server not set for network dump The system must be restarted for this test Ready to restart? (y|n) I respond with a "y" to restart the system. After reboot the system may lock up immediately and I have to power cycle to recover. When this occurs there is no core file collected. Is the core file file collected after the reboot? If so, that may explain why there is no core when the system locks up. Have there been any other reports of lockups? I also occasionally see NMIs. But I doubt those are test related.
(In reply to comment #2) >[...] > > That looks like it went OK. Now on the system under test I did: > > [root@spike ~]# setenforce 1 > [root@spike ~]# v7 server -n 10.10.19.187 > This doesn't set the server for spike, it runs the server on spike, which is not what you want. To set the server on spike use the --server option, as in: [root@spike ~]# v7 run --test reboot --server 10.10.19.187 > [...] > > I respond with a "y" to restart the system. After reboot the system may lock up > immediately and I have to power cycle to recover. When this occurs there is no > core file collected. > Is the core file file collected after the reboot? If so, that may explain why > there is no core when the system locks up. Have there been any other reports of > lockups? > I also occasionally see NMIs. But I doubt those are test related. The reboot test causes a kernel panic to exercise kdump. The system should time out (via /proc/sys/kernel/panic setting) and restart, dumping the image.
reading through the bug, the correct use of --server parameter is doing v7 run -t XXXX --server <SERVER_IP> on SUT (server under test, i.e. the machine you want to run v7 and get certified), instead of the test server (i.e. the machine you deploy and run `v7 server` command) So I'm going to close this bug as NOTABUG. any objections?
closing... feel free to reopen if it is still a problem.