[OpenAFS] rxkad error=19270408

Tue, 21 Apr 2009 17:10:16 -0700

--000e0cd2dda48bddb60468199609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I've installed 1.4.10 on a linux afs server geronimo and linux client ookpik

the client works on geronimo but uses 96% of 8 cpu's on ookpik which also
has a kernel message rxaderrror

An untouched previously working XP client also hangs at 100% CPU but
eventially carps "attempt to compromise security" when the afs shares are
selected.

Some key ot cc file may have been munged on geronimo but /tmp/krb5_cc0
/etc/krb5.keytab appear to be consistent now - checked with
asetkey
klist
kvno

They wern't consistent previously..

Any testing I can do I will..

On Tue, Apr 21, 2009 at 8:32 AM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:

> Mircea Ciocan wrote:
>
> > IMHO, no matter what kerberos key  b..s is happening this should not
> > produce this miserable kernel loop that kills the most powerful machines
> > available today, it either should have some slower cadence so that
> > eventually some could stop the AFS processes or it should give up after
> > some time, I this regard I consider this behavior a bug.
> >
> > Cheers,
> > Mircea
>
> In the good old days when server-A reported "bad kvno" the cache manager
> would discard the token even though it was possible that the token was
> in fact valid and would work on every other server in the cell.  This
> is frequently a problem when a cell contains a mixture of pre-OpenAFS
> 1.2.8 or Transarc/IBM servers and post-OpenAFS 1.2.8 servers.
>
> A few releases ago a modification was made to prevent the token from
> being discarded and in the case of a replicated volume, to permit fail
> over to an alternate copy.
>
> I suspect the issue is somehow related to this because now the afs
> client will return a bad kvno error to the application instead of
> access denied.  If the application repeatedly retries the request
> the kernel module will just ask the file servers again and produce the
> same result.  If the application asks again, ....
>
> It would be helpful to know if the infinite loop is being driven by
> the application or is strictly within the kernel module.
>
> Jeffrey Altman
>

--000e0cd2dda48bddb60468199609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;ve installed 1.4.10 on a linux afs server geronimo and linux client o=
okpik the client works on geronimo but uses 96% of 8 cpu&#39;s on oo=
kpik which also has a kernel message rxaderrror An untouched previou=
sly working XP client also hangs at 100% CPU but eventially carps &quot;att=
empt to compromise security&quot; when the afs shares are selected. 
 Some key ot cc file may have been munged on geronimo but /tmp/krb5_cc0 =
/etc/krb5.keytab appear to be consistent now - checked with asetkey k=
list kvno They wern&#39;t consistent previously.. Any test=
ing I can do I will.. 
 <div class=3D"gmail_quote">On Tue, Apr 21, 2009 at 8:32 AM, Jeffrey Alt=
man &lt;<a href=3D"mailto:jaltman@secure-endpoints.com" t=
arget=3D"_blank">jaltman@secure-endpoints.com</a>&gt; wrote: 
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Mircea Ciocan wrote: 
 
&gt; IMHO, no matter what kerberos key =A0b..s is happening this should not=
 
&gt; produce this miserable kernel loop that kills the most powerful machin=
es 
&gt; available today, it either should have some slower cadence so that 
&gt; eventually some could stop the AFS processes or it should give up afte=
r 
&gt; some time, I this regard I consider this behavior a bug. 
&gt; 
&gt; Cheers, 
&gt; Mircea 
 
</div>In the good old days when server-A reported &quot;bad kvno&quot; the =
cache manager 
would discard the token even though it was possible that the token was 
in fact valid and would work on every other server in the cell. =A0This 
is frequently a problem when a cell contains a mixture of pre-OpenAFS 
1.2.8 or Transarc/IBM servers and post-OpenAFS 1.2.8 servers. 
 
A few releases ago a modification was made to prevent the token from 
being discarded and in the case of a replicated volume, to permit fail 
over to an alternate copy. 
 
I suspect the issue is somehow related to this because now the afs 
client will return a bad kvno error to the application instead of 
access denied. =A0If the application repeatedly retries the request 
the kernel module will just ask the file servers again and produce the 
same result. =A0If the application asks again, .... 
 
It would be helpful to know if the infinite loop is being driven by 
the application or is strictly within the kernel module. 
 
Jeffrey Altman 
</blockquote></div>

--000e0cd2dda48bddb60468199609--