* Brian L. Stuart [080505 20:50]:
> 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
>
> Factotum is running in both cases. What am I doing
> wrong? I'm trying to mount the server's file system
> and authenticate in. I must be missing something
> fundamental.

You did set up a user in fossil with fossilcons(8) right?

Kind regards,

Christian

--
You may use my gpg key for replies:
pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (OpenBSD)

iD8DBQFIH1vDXYob3Uf3l4gRAhI5AJ41fsRxvM+YcbYfHw1WfR Yt9dcq3ACdE0uJ
Dv2gPZlKRHT1yKhHfnKhelI=
=hKFQ
-----END PGP SIGNATURE-----

From: Christian Kellermann
>You did set up a user in fossil with fossilcons(8) right?

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

> Once again, I find myself in the unhappy, but familiar,
> place of being befuddled by security/authentication.
> ...

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?

Thanks,
BLS

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

> 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

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.

As long as I'm at it, though, I've got a question about listen.
It's filling a rather large logfile with lots of address in
use errors. As I look into things, it appears that I'm starting
listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
latter specifying the -t option. That definitely seems to
be one too many. It looks from what I've got that I should
comment out the one in /bin/cpurc. What is the convention
on that?

Thanks for all the suggestions,
BLS

> As long as I'm at it, though, I've got a question about listen.
> It's filling a rather large logfile with lots of address in
> use errors. As I look into things, it appears that I'm starting
> listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
> latter specifying the -t option. That definitely seems to
> be one too many. It looks from what I've got that I should
> comment out the one in /bin/cpurc. What is the convention
> on that?

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

> As long as I'm at it, though, I've got a question about listen.
> It's filling a rather large logfile with lots of address in
> use errors. As I look into things, it appears that I'm starting
> listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
> latter specifying the -t option. That definitely seems to
> be one too many. It looks from what I've got that I should
> comment out the one in /bin/cpurc. What is the convention
> on that?

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

fn external{
bind -b '#l1' /net.alt
bind -b '#I1' /net.alt
ip/ipconfig -x /net.alt -g 12.51.113.1 ether /net.alt/ether1 $1 /123
ndb/cs -x /net.alt -f /lib/ndb/external
switch($2){
case recursive
ndb/dns -sx /net.alt -f /lib/ndb/external
case notrecursive
ndb/dns -Rrsx/net.alt -f /lib/ndb/external
}
}

echo cpurc $sysname
switch ($sysname) {
case tyty
timesync $time

ndb/dns -s
ip/dhcpd
ip/tftpd

auth/keyfs -wp
auth/secstored >/dev/null >[2=1]
auth/cron >>/sys/log/cron >[2=1] &
aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service il
aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service tcp

external 12.51.113.2 none
aux/listen -q -t /rc/bin/service.extauth -d /rc/bin/service.ext /net.alt/tcp

[...]

> 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.

Sounds like there are several ways people handle this.
For now at least, I'm going to go with my initial
instinct and leave the listens commented out in cpurc
and use the ones in cpustart. Doing that has stopped
the issue reported in the logging.

BLS