Proposed F19 Feature: NFStest

Paul Wouters pwouters at redhat.com
Tue Jan 29 16:17:28 UTC 2013


On 01/29/2013 09:32 AM, Steve Dickson wrote:

> Ok... that sounds good... but what does that have to do with testing
> the NFS 4.0 and 4.1 protocol? Granted I know nothing about libreswan
> other than I just read in the libreswan-3.0/README, but just don't
> see how libreswan fits in...
>
> Note, NFStest is a set of python scripts that explicitly tests the NFS
> v4.0 and v4.1 protocol by sending packets and then analysing the network
> traffic to make sure the correct protocol is being followed.
>
> So, again, I just don't see how an IPsec implementation would help
> with that.

I just meant, if you have not yet build an infrastructure to launch test cases by firing up KVMs, you could re-use what we have built using KVM, qemu and 
libvirt. The test harness is independent of IPsec, but we share a similar problem. If the test fails, it might mean network connectivity with the test hosts 
might be broken, so you need some other mechanism to get the log files of the failure. We use direct 9p filesystem mounts for that (and years ago, we used UML 
hostfs, but UML is just too broken all the time)

If you look at libreswan, eg in testing/pluto/basic-pluto-01, you will see:

*init.sh files that run when the VMs are launched to prepare them for the test
*run.sh files run on the "initiator" of the test - i.e. the client.
*.console.txt files that are the sanitized outputs
*.pcap/txt files that is a complete log of the entire traffic stream.

We run tcpdump to capture all traffic (we need to see if traffic indeed got encrypted). Then we sanitize ephemeral data and run a diff. The test flags as failed 
if there is a diff in daemon state, network traffic or console output.

But if you already have a system that can run automated tests on different hosts, I guess ignore all I said :)

Paul


More information about the devel mailing list