Problem mounting xcpu client

[Don W Rudish]

I'm trying to mount an XCPU client on my local laptop but am having
problems doing so.

ssh-keygen -t rsa -f admin_key
mkdir /etc/xcpu
cp admin_key* /etc/xcpu
xcpufs -d
xgroupset add 127.0.0.1 root 0
xuserset add 127.0.0.1 root 0 root /root/.ssh/id_rsa.pub
xrx 127.0.0.1 /bin/date

That Works

Now I want to mount the client on /mnt/xcpu1/1 so I do:
mount -t 9p 127.0.0.1 /mnt/xcpu/1/ -o uname=root,port=6667

xcpufs reports:
<<< (0x15b42e0) Tversion tag 65535 msize 8192 version '9P2000.u'
>>> (0x15b42e0) Rversion tag 65535 msize 8192 version '9P2000.u'
<<< (0x15b42e0) Tattach tag 0 fid 0 afid -1 uname root aname nuname -1
>>> (0x15b42e0) Rerror tag 0 ename authentication failed ecode 5

When I leave off the uname=root parameter I get:
<<< (0x15b42e0) Tversion tag 65535 msize 8192 version '9P2000.u'
>>> (0x15b42e0) Rversion tag 65535 msize 8192 version '9P2000.u'
<<< (0x15b42e0) Tattach tag 0 fid 0 afid -1 uname nobody aname nuname -1
>>> (0x15b42e0) Rerror tag 0 ename unknown user ecode 5

I'm using a ubuntu 2.6.27-11-generic kernel with xcpu-1.2.3 running all
commands as root. Any ideas?
-Don

[Abhishek Kulkarni]

On a cursory look, I think the issue here  is that the v9fs client tries to attach to the server with afid = NOFID (note: the afid=%u option does not set the afid, a v9fs bug?)
and xcpufs does not support attaching with NOFID. (in other words, xcpufs requires authentication).

[Latchesar Ionkov]

That's correct. You need to authenticate to mount xcpu. We normally
use xcpu without mounting (connecting from user-space 9P clients).
If you have a convincing case for using it mounted, I can probably
write a simple mounter that does the authentication before it handles
the connection to the kernel.

Thanks,
Lucho

[ron minnich]

On Tue, Mar 31, 2009 at 7:19 AM, Latchesar Ionkov <lio...@lanl.gov> wrote:

> If you have a convincing case for using it mounted, I can probably write a
> simple mounter that does the authentication before it handles the connection
> to the kernel.

I think the case is simple: 9p servers should always be mountable from
9p vfs. It's just embarrassing otherwise.

we've talked about a mount helper for years; this may be the time to write it.

ron

[Latchesar Ionkov]

I believe there is a standard mount helper, but we need a special one
for xcpu as it uses non-standard authentication.

Thanks,
Lucho

[Eric Van Hensbergen]

I wonder if there is a more simple approach for local mounts -- it
seems like key exchange shouldn't be required on the local host as we
know who everybody is (at least inside the kernel). Another
alternative would be to export a named pipe for local mounts and just
use standard permission controls -- I suppose the main problem is
nothing prevents a local user with permissions from opening the named
pipe and spoofing the attach message with an alternate identity which
makes the problem the same for named pipes as it does for a tcp
socket.

-eric

[Don W Rudish]

The only case I can think of is that its uses this example in the current documentation under xcpu-1.2.3/doc/xcpu.pdf. ...the ability to mount a compute node over the network to the local file system is a significant departure from the antiquated remote execution...

For my purpose I'd like to see what XCPU is all about and grasp a better understanding on ways to use it.
-Don

[Latchesar Ionkov]

It looks like the support of user authentication was dropped from v9fs
during some of the rewrites and it is going to take some time to put
it back in an official kernel.
I just sent a patch for approval that would allow you to add
unauthenticated users to xcpu so you can mount without the
authentication support. That was supposed to work, but I guess some
changes overlooked the feature and made it almost impossible to add
such users.

So what you should do after creating /etc/xcpu/admin_key is:

xuserset add localhost nobody 4294967295 xcpu-admin
mount -t 9p 127.0.0.1 /mnt/xcpu/1 -o port=6667,access=any

Let me know if it doesn't work. Once I fix v9fs, I'll create an xcpu-
mount utility that does authentication.

Thanks,
Lucho

[Don W Rudish]

Lucho,
Yes this works great.
Thanks,
-Don