From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <25638d2949fca1a94387ae1ab3e10fbb@9netics.com>
To: 9fans@9fans.net
Date: Fri, 22 Jan 2010 15:27:22 -0800
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <126b0b011076c61e000be785dae74079@9netics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] mysterious auth
Topicbox-Message-UUID: c42e32a2-ead5-11e9-9d60-3106f5b1d025

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