[OpenAFS] Strange token issues

[Shane Warner]

--089e013d14ca38ed5d04db85890d
Content-Type: text/plain; charset=ISO-8859-1

We are having some strange issues with tokens on our openafs 1.6.2
environment.

There are 3 scenarios that randomly appear on our clients running apache
with mod_waklog:
1) Tokens become invalid and an rxkad error=19270408 appears in dmesg. This
is the least prevalent issue, and has only happened a couple of times.
2) Permission denied errors are seen intermittently while accessing files.
Some file accesses are successful, some fail. No errors in logs on this one.
3) There is no intermittent behavior, just a solid permission denied even
though it would appear that a token has been obtained. Restarting the
openafs-client/httpd resolves it for about a minute before the permission
denied brick wall comes back. No errors in logs on this one.

Only rebooting the entire system resolves the issues for all of the above
situations. Situations 2 and 3 are by far the most common and occur every
3-7 days on clients.

Things we have tried and verified:
1) UserKey is the same across all servers in the cell. Same checksum, same
kvno. Only one kvno is installed in UserCell on all servers.
2) All KDC's (master and slave) have the same kvno that is installed on the
afs servers in UserKey.
3) There are no more than 1 cell configured for the clients.
4) We only have 1 afs principal "afs/cell@DOMAIN.COM". There is no "
afs@DOMAIN.COM" principal.
5) Key is the correct encryption type - des-cbc-crc.
6) Downgraded from a build we made from the stable git branch, to an
official release from the website hoping it might be a bug.
7) Cell and realm are the same value.
8) We're using AFSDB records for the clients, verified multiple times that
these are correct.
9) All servers and clients are running the same version of openafs: 1.6.2

Is there anything we might be missing that could be causing these strange
issues?

Thanks,
Shane

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

<div dir=3D"ltr"><div>We are having some strange issues with tokens on our =
openafs 1.6.2 environment.</div><div><br></div><div>There are 3 scenarios t=
hat randomly appear on our clients running apache with mod_waklog:</div><di=
v>
1) Tokens become invalid and an rxkad error=3D19270408 appears in dmesg. Th=
is is the least prevalent issue, and has only happened a couple of times.</=
div><div>2) Permission denied errors are seen intermittently while accessin=
g files. Some file accesses are successful, some fail. No errors in logs on=
 this one.</div>
<div>3) There is no intermittent behavior, just a solid permission denied e=
ven though it would appear that a token has been obtained. Restarting the o=
penafs-client/httpd resolves it for about a minute before the permission de=
nied brick wall comes back. No errors in logs on this one.</div>
<div><br></div><div>Only rebooting the entire system resolves the issues fo=
r all of the above situations. Situations 2 and 3 are by far the most commo=
n and occur every 3-7 days on clients.</div><div><br></div><div>Things we h=
ave tried and verified:</div>
<div>1) UserKey is the same across all servers in the cell. Same checksum, =
same kvno. Only one kvno is installed in UserCell on all servers.</div><div=
>2) All KDC&#39;s (master and slave) have the same kvno that is installed o=
n the afs servers in UserKey.</div>
<div>3) There are no more than 1 cell configured for the clients.</div><div=
>4) We only have 1 afs principal &quot;afs/<a href=3D"mailto:cell@DOMAIN.CO=
M">cell@DOMAIN.COM</a>&quot;. There is no &quot;<a href=3D"mailto:afs@DOMAI=
N.COM">afs@DOMAIN.COM</a>&quot; principal.</div>
<div>5) Key is the correct encryption type - des-cbc-crc.</div><div>6) Down=
graded from a build we made from the stable git branch, to an official rele=
ase from the website hoping it might be a bug.</div><div>7) Cell and realm =
are the same value.</div>
<div>8) We&#39;re using AFSDB records for the clients, verified multiple ti=
mes that these are correct.</div><div>9) All servers and clients are runnin=
g the same version of openafs: 1.6.2</div><div><br></div><div>Is there anyt=
hing we might be missing that could be causing these strange issues?</div>
<div><br></div><div>Thanks,</div><div>Shane</div></div>

--089e013d14ca38ed5d04db85890d--