yuan.fan wrote at Mon Mar 30 2009 22:14:52 GMT-0700 (PDT): > >> >> Thanks. I was looking at the latest auto_nicdrv_0330.tar.bz2 >> and indeed it downloads the latest version of the test suite. >> That is great. However, as Tom Chen pointed out on the other >> thread, it does appear that the install.ksh script is running >> stf_configure with root permissions. I am not sure why this >> is necessary -- STF should be able to handle stf_configure >> being run as a non-root user (it does, for every other test >> suite). Why is it necessary to run stf_configure as root for >> the nicdrv test suite? >> >> -UVR. > > Hi Ravindra > In the stf_configure process,NICDRV disable/enable some system services > and do some > configuration on the peer machine with rsh. > So nicdrv needs users have the root permission. > thanks > -yuan.fan
I'm sorry, the explanation does not seem to be valid. I am not convinced that stf_configure must be invoked as root. I assume that the script which you are describing is running the remote disable/enable on the peer machine is this: http://cvs.opensolaris.org/source/xref/test/stcnv/usr/src/suites/net/nicdrv/configure.ksh If so, it is already declared as an STF_ROOT_CONFIGURE script: http://cvs.opensolaris.org/source/xref/test/stcnv/usr/src/suites/net/nicdrv/Makefile What this says is that 'stf_configure' should be invoked as non-root. stf_configure will prompt the user for the root password during execution. After that, STF will take care of switching to 'root' user; it will run the configure script on the local host and peer as 'root'. At least, this is what STF is designed to do. If you have tried to run stf_configure as non-root and have experienced failures, that would be reason to report a bug against STF. But the mere fact that the configure script needs to be run as root does not imply that stf_configure should be run as root. In general, stf_configure and stf_execute should NEVER be run as root. -UVR.
