Once again, I find myself in the unhappy, but familiar,
place of being befuddled by security/authentication.
Backstory: After fighting with flaky disk drives and
scary RAID controllers, I have a system set up as a
CPU server running fossil+venti, and I want to play
around with it acting as a file server in a mixed
environment. I've got authentication set up enough
so that I can drawterm in. But:

If /bin/service/tcp564 has exec /bin/exportfs -s
On the cpu server: 9fs tcp!127.1 works as if
I am none--can't write.
Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
reports rx: exportfs: authentication not required
and upon mounting it behaves as if I'm none

If /bin/service/tcp564 has exec /bin/exportfs -s -a
On the cpu server: 9fs tcp!127.1 reports:
srv tcp!127.1: mount failed: EOF receiving fversion reply
Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
reports: srv: Tversion: bad length in 9P2000 message header

* Brian L. Stuart bellsouth.net> [080505 20:50]:

From: Christian Kellermann nefkom.net>

Yes. That's the user I'm drawterm'd in as and the
one I'm using as the uname option when mounting
using P9P.

Thanks,
BLS

I know it's bad form to reply to your own question,
but I've gotten a bit farther. I realized that
/bin/service/tcp564 isn't the right way to go about
it. After a good slap on the forehead, I am now
starting listen from fscons. I'm now able to 9fs
on the server and it works like I expect. However,
I still have no joy from P9P. The command:

9 srv -a xxx.xxx.xxx.xxx test

triggers factotum to prompt for the user and password
but then gives the error:

authdial: Connection refused
srv: authproxy: auth_proxy rpc: p9any client get tickets: p9sk1: gettickets:
Connection refused

Obviously, I've still got something not right in the
authentication world. Any ideas?

try some debug in factotum perhaps (-d)?

I have had great success debugging auth problems between plan9 servers
using auth/debug - however I don't know if this exists on p9p.

-Steve

// authdial: Connection refused
// srv: authproxy: auth_proxy rpc: p9any client get tickets: p9sk1: gettickets:
// Connection refused

are you sure that both your auth server is running (look for results
from 'ps | grep keyfs') and that you're running the network listener
for it (service.auth/tcp567)? the "connection refused" says it's just
not getting in, most likely because you're not listening on tcp567.
note that the trusted listeners are started separately from the
others, and not in the default config. see the -t argument to
listen(8) and the comments in /bin/cpurc.
anthony

They are. As it turns out, it was a combination of operator
error and misleading documentation. I had not put an appropriate
entry in /usr/local/plan9/ndb/local. Instead, I had specified
the auth server's IP address in a -a argument to factotum.
It looked from the man page that would work, but it doesn't.
In fact the authaddr variable set to that argument doesn't
appear to ever get used anywhere. Anyway, the moral of the
story is to put the entry in ndb/local and not rely on the
-a option to factotum.

One of these days, I'm going to get this right...
I meant to say /cfg/phantom/cpustart which gets run after
listen is started in /bin/cpurc. What is the usual way
to do this?

Thanks,
BLS

I'm not sure about the "usual" way, but I've got the
listens in cpurc commented out and rely only on
entries in /cfg/whatever/cpustart.

Does your cpustart listen specify -d as well as -t?
It looks like giving only -t should make it not try
(or re-try in your case) the non-trusted ones.
Anthony

you need to use a different directory if you're starting a second
listen with the -t option. e.g. /rc/bin/service.auth. there shouldn't
be any duplication in scripts (save one starting in !) between the
normal and the -t directories.

not sure if this helps, but i perfer the old style bit switch statement.
i tacked on a bit of our cpurc for reference.

- erik