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.
Russ
On 5/3/05, "Nils O. Sel�sdal" <[EMAIL PROTECTED]> wrote:
> Russ Cox wrote:
> > after the cron job has run, what does cat /mnt/factotum/ctl show?
> >
> As I told Russ, the key gets disabled. I added a flog call to
> factotum/p9sk1.c;
>
> convM2T(tbuf, &s->t, (char*)s->key->priv);
> if(s->t.num != AuthTc){
> disablekey(s->key);
> flog("disabling key. s->t.num=%d",s->t.num);
> if(askforkeys){
>
> (Ok I later realized t.num is a char)
> Which seems to be what is disabling the key.
> /mnt/factotum/log says disabling key. s->t.num=41,
> (on next reboot it said s->t.num=76)
>
> The whole log is;
>
> 2: no key matches proto=p9sk1 role=server dom?
> 2: failure no key matches proto=p9sk1 role=server dom?
> 3: no key matches proto=p9sk1 dom=fiane.intra role=client dom=fiane.intra
> user?
> !password? owner=upas owner=*
> 3: failure no key matches proto=p9sk1 dom=fiane.intra role=client
> dom=fiane.intra user? !password?
> disabling key. s->t.num=76
> 3: failure bad key
> 4: no key matches proto=p9sk1 role=server user? dom?
> 4: failure no key matches proto=p9sk1 role=server user? dom?
>
> --
> Nils O. Sel�sdal
>
