> 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 cpu
> 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
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
> 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 do
// 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/tcp5
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
> 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 t
From: Christian Kellermann <[EMAIL PROTECTED]>
>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
* Brian L. Stuart <[EMAIL PROTECTED]> [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 fo
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 s
11 matches
Mail list logo
