On Thu, Jan 07, 2010 at 09:18:32AM -0500, Jeff Layton wrote: > On Wed, 6 Jan 2010 15:33:13 -0500 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > On Wed, Jan 06, 2010 at 03:22:55PM -0500, Chuck Lever wrote: > > > My original idea was that this facility would be a set of smaller unit > > > tests. Since some of statd/sm-notify is now broken out into libraries, I > > > think that makes it a little easier to craft targeted tests that don't > > > require a full-blown statd running to carry out (Of course, that's > > > speculation; I could be wrong, and Jeff has kindly set up the code for us > > > to test this theory!). > > > > > > The old code has a statd simulator that doesn't require root, and uses > > > its own RPC program number. It might be reasonable to adopt that > > > approach instead of using the real statd, for some test cases. > > > > Like I say, it might be nice to be able to add even more intrusive tests > > (e.g. that modify the exports and then test the results over "lo" with > > the kernel client), so I'm actually happy Jeff says he's not bending > > over backwards to make the tests unprivileged. > > > > The root privs problem is definitely a valid concern. > > After thinking about this problem I think the thing to do is > probably to create a "run as root" script that starts up statd (for > now) and other daemons (eventually). make check can then prompt the > user to inspect and run that script as root and then hit return when > it's ok to proceed. > > That should allow someone to run most of the actual test code as an > unprivileged user. I'll plan to incorporate something like this in the > next respin. That sounds complicated. And, as I said above, we might some day like to include tests where the privileged stuff makes up the body of the test. Why not just "the tests you are about to run need root privileges, and will start and stop statd; continue (y/n)?" --b. > > > > Another way to set this up might be to use a container, or run it under a > > > lightweight kvm. > > > > Sounds ambitious for now. > > > > Agreed. That would be hard to implement across different distros (at > least until the virt stuff is more standardized). > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
