diff options
Diffstat (limited to 'source4/script/tests/win')
-rw-r--r-- | source4/script/tests/win/README | 121 |
1 files changed, 121 insertions, 0 deletions
diff --git a/source4/script/tests/win/README b/source4/script/tests/win/README new file mode 100644 index 0000000000..06b64e5b02 --- /dev/null +++ b/source4/script/tests/win/README @@ -0,0 +1,121 @@ +This framework uses a VMware Server hosted Windows guest VM to test the +behaviour of Windows -> Samba and Samba -> Windows interactions. To setup a +Windows host for testing, vm_setup.tar.gz contain some scripts which create +an administrative user account, and enable and start the installed telnet +service on the Windows host. Optionally, the hostname and workgroup name can +also be set. vm_setup.tar.gz is currently located in the SOC/bnh branch of +Samba's SVN repository. + +PREREQUISITES + +To use these scripts, VMware Server needs to be running with a Windows guest +VM installed, IP addressed, and VMware tools needs to be installed and running +on the guest VM. The Windows OS I used to test with was Windows Server 2003, +but I think this should work with any version of Windows that has the +Microsoft telnet service installed. The VMware Server versions I used for +testing was 1.0.0 build-27828, and 1.0.0 build-28343. + +PLEASE NOTE: Due to problems with my original revert_snapshot() code, the initial +setup now requires that the VM configuration setting 'When Powering Off' is +manually set to 'Revert to snapshot' (snapshot.action="autoRevert" in the +guest's .vmx file). This should not be a permanent change, but the original +revert_snapshot() code I wrote no longer works and i'm not sure why. + +On the machine that these scripts are running on (this need not be the same +machine as the VMware host), the VMware perl scripting api needs to be +installed, as well as the vix-perl api. These come with the VMware Server +console package. + +After unzipping this file, the libraries are installed by extracting the +VMware-vix-e.x.p-<revision number>.tar.gz and +VMware-VmPerlAPI-e.x.p-<revision number>.tar.gz archives, and running the +vmware-install.pl scripts inside their respective directories. + +On Slackware 10.2, I encountered a problem in that when I tried to use the vix +api libraries, I would get the following error: + +SSLLoadSharedLibrary: Failed to load library /<client program directory>/libcrypto.so.0.9.7:/<client program directory>/libcrypto.so.0.9.7: cannot open a shared object file: No such file or directory. + +The fix found on the VMware knowledge base (search http://kb.vmware.com for +Doc ID: 1837104) states that it's a known problem with the scripting libraries, +and can be resolved by installing VMware Server on the host, which properly +sets up the SSL module loader. This is what I would suggest if you encounter +this, as it solved the problem for me (I don't have VMware Server actually +running on that host though). + +INSTALLATION + +To use these scripts, modify initial_setup.conf to match your environment. The +GUEST_HOSTNAME, GUEST_WORKGROUP, HOST_SERVER_NAME, HOST_SERVER_PORT, +HOST_USERNAME, and HOST_PASSWORD variables are optional, and are commented out +in this release. + +Running initial_setup.sh will: +* Get the IP address of the Windows guest VM. +* Take a snapshot of the pristine Windows guest. +* Copy the windows scripts from the windows-scripts directory on the unix host + to the directory on the Windows guest specified by the + GUEST_SCRIPT_PATH option. This path will be created on the guest if + it does not already exist. +* Execute win_setup.wsf on the Windows guest in order to create the + administrator account specified by GUEST_USERNAME and GUEST_PASSWORD, + enable and start the telnet service, and set the GUEST_HOSTNAME and + GUEST_WORKGROUP if configured. +* If these operations are successful so far, another snapshot is taken at this + point. This is the snapshot which is restored if the tests encounter + problems they are unable to recover from. + +These operations leave the Windows guest in a state such that it can be +remotely administered with telnet. Specifically, this will allow us to use +'make wintest' in Samba 4 to perform smbtorture tests against a Windows host, +and perform tests from a Windows client to a Samba server. + +INTEGRATING WITH THE BUILD FARM + +Follow the standard steps to add a host to the build farm. The major +difference is that we will need to run these tests as root. To run the +Windows tests in the build farm, a .fns file will need to be created for +your new host that exports a WINTESTCONF environment variable pointing to a +config file used by 'make wintest'. An example of this config file can be +found at source/script/tests/win/test_win.conf in the Samba 4 source tree. + +I've also included the bnhtest.fns file that I'm using for my build farm host +below, as an example. It was modified from generic.fns. + +action_test_windows() { + do_make wintest + w_status=$? + echo "WINTEST STATUS: $w_status" + return $w_status; +} + +per_run_hook + +system=`uname` + +export WINTESTCONF="/home/build/win/test_win.conf" + +for compiler in gcc cc icc; do + + # arrgh, "which" gives no err code on solaris + path=`which $compiler` + if [ -x "$path" ]; then + + if $compiler -v 2>&1 | grep gcc.version > /dev/null; then + isgcc=1 + CFLAGS="-Wall" + export CFLAGS + else + CFLAGS="" + export CFLAGS + isgcc=0 + fi + if [ $compiler = gcc -o $isgcc = 0 ]; then + + # only attempt samba4 if we have perl + if which perl > /dev/null; then + test_tree samba4 source $compiler configure build install test_windows test + fi + fi + fi +done |