SOC Automated Windows Testing Project

Brad Henry j0j0 at
Thu Jun 15 16:20:30 GMT 2006

tridge at wrote:

>I needed to make a couple of trivial mods to the test run script
> - added SMBTORTURE_WORKGROUP var in as I haven't made
>   my existing vmware session use 'SMBTEST' 
> - added a SMBTORTURE_PATH variable in as I am not
>   using /usr/local/bin
>Maybe we should have a win_test.conf file containing just the local
>variable settings and use ". win_test.conf" near the start of the
Will do, thanks. I'll also start working on integrating these scripts 
into the samba4 test script framework at the same time.

>I also hit a bit of a problem with DNS lookups. My w2k3 server did a
>reverse lookup on the IP of my test box when the telnet connection
>started up. That reverse lookup failed, and the telnet connection
>timed out. I worked around it by adding "-timeout 60" to the "expect
>login:" line in common.exp, but perhaps we could make things more
>robust by adding a hosts entry on the windows box for the IP/hostname
>of the client (ideally we would remove it at the end too).
>After I upped the timeout, the test ran (yipee!) but RAW-QFILEINFO
>failed, and I noticed that the script skips the cleanup phase when the
>test fails, so the smbtorture_share share wasn't deleted. That should
>be easy to fix. I'm not worried about the fact that RAW-QFILEINFO
>failed (thats nothing to do with your project), just the error
Adding an entry to the hosts file definately seems like the best option 
here. I'll make sure to add it to the setup and cleanup phases. One 
place that still needs work is making sure that any time a "last resort" 
error exits the setup or test scripts, the cleanup functions run.

>I guess the next major steps are:
> - the vmware snapshot/resume scripts
> - modifying the scripts in samba4/source/script/tests to optionally
>   call this stuff if enabled
>Then we can setup a box in the build farm to start running this on
>each commit.
>I also wonder how we should get your other vbs scripts onto the
>windows box during tests? The two obvious methods are:
> - make them available via a Samba share, and to net use that share
>   then copy the files
> - add a copy_file() function in common.exp which does a 
>   "copy con xxx.vbs" and sends the file down the link, followed by a ^Z. 
>The think the second option might be better, as it has "less moving
>parts" so hopefully it will be less fragile once its working. It won't
>work for binary files, but I don't think we'll need any of those.
>What do you think?
>Cheers, Tridge
I have a vmware server running now, and it seems that vmware has perl 
api access to their C library, which would let us copy files to the 
windows vm and execute commands there. We then should be able to 
automate the initial windows environment setup from the unix side, and 
only require that vmware tools be already installed in windows. I'll 
work on this and the snapshot/resume scripts at the same time.

Once the environment is setup and the test is running, I agree that if 
we need to, the best way to transfer scripts to windows will be to "copy 
con" over telnet as you said.

So, I think the next steps will be to ensure that in the existing scripts:
* The error handling runs the cleanup scripts properly.
* Adding and removing a hosts file entry for the unix host on the 
windows vm is handled.
* Parameters are passed into the shell script from a config file and the 
variables are in line with what the Samba 4 test scripts have.

And to create some new scripts so that we can manage aspects of the 
vmware server itself like powering the host on, automating the initial 
setup/cleanup, and creating/resuming snapshots.

How does this sound?


More information about the samba-technical mailing list