Russ Cox wrote:
It sure sounds like your auth server (keyfs) and your factotum
do not agree on what the password is. The new factotum that
I said to pull fixed a different problem -- if the server side fails
the auth, it could be because the client lied, so that case doesn't
disable the key anymore. But the case you're running into is that
the tickets coming back from the auth server don't decrypt properly,
and since factotum trusts the auth server, it disables the key.
Ok. I'm not quite sure I follow, You're saying the key(password) in nvram
doesn't match what's stored in /adm/keys ?
(if so I'm pretty sure they're the same, but I'll try to investigate further..)
if you're not using securestore, then yes that's what i'm saying.
(if you're using securestore, then i'm saying that the password
in the secstore file doesn't match what is stored in /adm/keys.)
Well, bootes secstore only holds my key for sources..
I reinitialized nvram (echo asda >/dev/sdC0/nvram, rebooted) and
ran 'passwd' as bootes , ensuring both passwords were the same.
I suspect they already were, else no login/passwd changing would have worked ?
Still, I can only drawterm to it (as bootes, or anyone else) until cron
has run.
*sigh* I'm too new/not any good at this.
--
Nils O. Sel�sdal
