The NFS tests we employ at Connectathon are available as a tarball at NFS Testsuite. And they are all read-only. Someone somewhere has a SCCS repository for it.

All of this was setup some time ago, way before git, Mercurial, etc. We should be able to do better than this for managing this code. As the source tree is lost, we've had a problem updating changes. The last official change occurred in 2004.

So I created a Mercurial tree on hg.opensolaris.org. You can grab a copy of the source via:

hg clone ssh://anon@hg.opensolaris.org/hg/nfsv41/cthon

which does not assume you have an OpenSolaris account. You could update the tree with something along the lines of:

hg push -R /home/nfs4hg/src/cthon04 \
-e "ssh -q -F /home/nfs4hg/opensolaris/config"

which assumes you do have an OpenSolaris account and that in this case you have setup a secure and passwordless ssh key. (I'm not sure those last two really belong together.)

So one of the minor things which went wrong for our booth was I forgot that we needed to integrate code here at Connectathon 2009. We had a gate (thanks to Rick Mesta) working, but the new Mercurial gate had been put in place since our last event (a Fall Bakeathon) and we just forgot about it. I.e., we did have a Mercurial gate in place, but not one that mimicked the ON gate. We did a couple of integrations the old way (mainly need to remember 'hg push -u'), but there is additional sanity checking which needed to go on.

So I dragged out my notes from Setting up a Development Project Gate and went to work. I cheated in that I already had most of the configuration changes I had made. But I still had to get the system running.

One thing I have to say about my colleague Rick is that he was very thorough in setting up our build machine. But he did things differently than I would have done them. I'm not saying he did them wrong, just differently. He also did more than I thought I asked him to do for the setup. For example, he set the build server up to be a NIS server - which actually saved us several hours when we started to use the machine.

Anyway, I get the gate up and running without any major modifications to the instructions. And it is easy for me to get a clone of the gate either via ssh or local file access. But for the life of me, I can't get the gate to respond to 'hd pbchk':

[th199096@build nfs]> vi bootparam_xdr.c
[th199096@build nfs]> hg reparent ssh://nfs4hg@build//ws/nfs41-gate
[th199096@build nfs]> hg commit
[th199096@build nfs]> hg pbchk
Warning: Parent workspace ssh://nfs4hg@build//ws/nfs41-gate is not accessible
active list will be incomplete

A little backstory - I said Rick configured the machine to be a NIS server and he also configured the gate to be accessible over NFS via the automounter as /ws/nfs41-gate. I had taken a clone of that and changed the automounter mount points to be:

[th199096@build ~]> ypcat -k auto.ws | grep nfs41
nfs41-clone build:/export/gate/nfs41-clone
nfs41-orig build:/export/gate/nfs41-gate
nfs41-gate build:/export/gate/nfs41-gate

But in the Austin lab, we don't export our gate, the only access is via ssh. And that means I use the fully qualified path to the zfs filesystem that has the gate. In this case, I configured everything to reference /export/gate/foo. And since I could get a clone of nfs41-clone, I thought that was sufficient.

This hosed me and it wasn't until I tried the following:

[th199096@build nfs41-clone]> hg reparent ssh://nfs4hg@build//export/gate/nfs41-gate
[th199096@build nfs41-clone]> hg pbchk
CDDL block check:
Error: Invalid line in CDDL block in file usr/src/uts/common/fs/nfs/bootparam_xdr.c

that things started to work. The issue here is that there are no restrictions on getting things out of the read-only clone. But to access the gate, there are restrictions in that you have to be the 'nfs4hg' user and the paths in the config files have to match those passed in by the script that runs when the ssh command is issued.

There are two ways to fix this problem - either change the paths in the config files or teach everyone to use the '/export/gate/nfs41-gate' path. Each has its own advantage, if it were just me, I'd use the full path because it removes a dependency on the automounter. But for this event, everyone is already trained to using the other path.

The other issue here is that as the build machine is also the NIS server, we can not easily have a local account for 'nfs4hg'. With a development gate and a level of personal responsibility (i.e., you know who it is who will be ragging you if you make a mistake), I'm willing to live with that. I'm not sure I could make that same call with the ON gate.