Re: [9front] Problem with authentication on file server

["Özgür Kesim" <oec-9front@kesim.org>]

Hi Tobias,

Thank you for your input, TIL about `history -D`.

But as it turns out, the issue was on the client side:

There was a spurious `factotum` left running from an earlier experiment
with 9pfs on my linux machine, and drawterm tried to retrieve the
(non-existent) key material from /tmp/ns.user.:0/factotum.

Killing the factotum process on linux resolved the issue.  (However,
getting factotum showing a prompt on linux is also worth an experiment
at some point).

Cheers,
oec


Thus spake theinicke@pheist.org (theinicke@pheist.org):

> Hi,
> 
> not really an expert, but usually altering /lib/ndb/local might require to
> execute auth/wrkey again, depending on what has changed...
> 
> Also maybe you want to history -D /lib/ndb/local to see what you changed
> exactly?
> 
> And finally you could remove /adm/keys and recreate them, ex. using
> auth/changeuser (if anything else fails and no one has a better idea :)
> 
> Good luck,
> Tobias Heinicke
> 
> 
> Quoth Özgür Kesim <oec-9front@kesim.org>:
> > Hi,
> > 
> > I have a 9front file+cpu+auth server on my desk that I occasionally use
> > for some experiments.  About a week ago I did a sysupdate on the machine
> > and some changes to ndb/local (IIRC, only adding an authdom to the
> > ipnet).  Now connection to it via drawterm (the 9front version) fails,
> > with the following complaint:
> > 
> > drawterm: can't authenticate: auth_proxy rpc: p9any client ask for keys: unable to find common key
> > 
> > Altering ndb/local didn't help.  Before I dig deeper and try to extract
> > more information from the cpu server -- does anybody have an idea and a
> > hint where I should look?
> > 
> > Cheers,
> > oec
>