[9fans] mysterious auth

[9fans] mysterious auth

[Skip Tavakkolian]

on a new network and standalone auth+fs (built from CD image of Jan
7th), auth is refusing to concur.  i've used Russ' message from a
while back [1] as a checklist.  auth/debug reports:

	cannot decrypt ticket1 from auth server (bad t.num=0x...)
	auth server and you do not agree on key for bootes@bta.somedomainx.org

factotum debug output says "no key matches"; factotum has the right
key and i've zero'ed nvram a couple of times to be sure.  it's
interesting that reading /mnt/factotum/ctl also gives "no key
matches/failure no key matches" message along with the key.  key looks
like this:

key proto=p9sk1 dom=bta.somedomainx.org user=bootes !password?

i've tried logging in from a term (pxeloaded from the same auth+fs)
with similar results.  in that case factotum debug says "no key
matches proto=p9sk1 role=server dom?".  this last message looked a bit
weird and when i check /dev/hostdomain, it is empty.

any ideas?

[1] http://groups.google.com/group/comp.os.plan9/browse_thread/thread/797bce6a973b84e8/0941aa4593f9dc73?lnk=gst&q=factotum+nvram#0941aa4593f9dc73

Re: [9fans] mysterious auth

[erik quanstrom]

> with similar results.  in that case factotum debug says "no key
> matches proto=p9sk1 role=server dom?".  this last message looked a bit
> weird and when i check /dev/hostdomain, it is empty.

/dev/hostdomain empty here, too.

- erik

Re: [9fans] mysterious auth

[Federico G. Benavento]

are you sure that the passwords in nvram and auth/changeuser do match
for bootes?

On Mon, Jan 11, 2010 at 8:22 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
> on a new network and standalone auth+fs (built from CD image of Jan
> 7th), auth is refusing to concur.  i've used Russ' message from a
> while back [1] as a checklist.  auth/debug reports:
>
>        cannot decrypt ticket1 from auth server (bad t.num=0x...)
>        auth server and you do not agree on key for bootes@bta.somedomainx.org
>
> factotum debug output says "no key matches"; factotum has the right
> key and i've zero'ed nvram a couple of times to be sure.  it's
> interesting that reading /mnt/factotum/ctl also gives "no key
> matches/failure no key matches" message along with the key.  key looks
> like this:
>
> key proto=p9sk1 dom=bta.somedomainx.org user=bootes !password?
>
> i've tried logging in from a term (pxeloaded from the same auth+fs)
> with similar results.  in that case factotum debug says "no key
> matches proto=p9sk1 role=server dom?".  this last message looked a bit
> weird and when i check /dev/hostdomain, it is empty.
>
> any ideas?
>
> [1] http://groups.google.com/group/comp.os.plan9/browse_thread/thread/797bce6a973b84e8/0941aa4593f9dc73?lnk=gst&q=factotum+nvram#0941aa4593f9dc73
>
>
>



-- 
Federico G. Benavento

Re: [9fans] mysterious auth

[Skip Tavakkolian]

responding to feedback from multiple 9fans:

Federico said:
> are you sure that the passwords in nvram and auth/changeuser do match
> for bootes?

pretty sure.  i've zero'ed the nvram and re-entered it. i went so far as
stopping keyfs, zero'ing /adm/keys and /adm/keys.who and reinstalling
bootes from scratch and restarting.  it is very puzzling.

Lucio said:
> Should you not add a "role=server" to whatever the chosen entry is?
> It will at minimum help with debugging.

i did, but the result changed only slightly; trying to connect to
auth from another system now results in the same behavior as
auth/debug exhibits: "no key matches".

Re: [9fans] mysterious auth

[Skip Tavakkolian]

in case anyone's wondering, my problem was due to the fact that keyfs
was started after aux/listen for trusted services; /mnt/keys/* wasn't
in authsrv's namespace.  in my case, i put the trusted services in
/cfg/bootes/cpurc, while keyfs was started later in the sequence of
/rc/bin/cpurc.

the default config in the distro CD could lead others to do the
same.  given that only auth needs to run keyfs and trusted services,
it would be better to create a /cfg/example.auth/cpurc that includes
keyfs and trusted services in it and remove them from /rc/bin/cpurc,
since they come after /cfg/$sysname/cpurc is run.

>> are you sure that the passwords in nvram and auth/changeuser do match
>> for bootes?
>
> pretty sure.  i've zero'ed the nvram and re-entered it. i went so far as
> stopping keyfs, zero'ing /adm/keys and /adm/keys.who and reinstalling
> bootes from scratch and restarting.  it is very puzzling.
>
> Lucio said:
>> Should you not add a "role=server" to whatever the chosen entry is?
>> It will at minimum help with debugging.
>
> i did, but the result changed only slightly; trying to connect to
> auth from another system now results in the same behavior as
> auth/debug exhibits: "no key matches".

Re: [9fans] mysterious auth

[erik quanstrom]

On Fri Jan 22 18:29:45 EST 2010, 9nut@9netics.com wrote:
> in case anyone's wondering, my problem was due to the fact that keyfs
> was started after aux/listen for trusted services; /mnt/keys/* wasn't
> in authsrv's namespace.  in my case, i put the trusted services in
> /cfg/bootes/cpurc, while keyfs was started later in the sequence of
> /rc/bin/cpurc.
>
> the default config in the distro CD could lead others to do the
> same.  given that only auth needs to run keyfs and trusted services,
> it would be better to create a /cfg/example.auth/cpurc that includes
> keyfs and trusted services in it and remove them from /rc/bin/cpurc,
> since they come after /cfg/$sysname/cpurc is run.

i was wondering.  thanks for the explaination.

- erik

Re: [9fans] mysterious auth

[lucio]

> it would be better to create a /cfg/example.auth/cpurc that includes
> keyfs and trusted services in it and remove them from /rc/bin/cpurc,
> since they come after /cfg/$sysname/cpurc is run.

You could submit a patch...

I have a feeling that the philosophy is for /cfg to be entirely
optional, so putting examples in there is not encouraged.  But what
about (late in /rc/bin/cpurc):

	# cpu-specific late startup
	if(test -e /cfg/$sysname/cpustart)
		. /cfg/$sysname/cpustart

?

++L