On 5/3/2010 8:23 AM, Atro Tossavainen wrote: > Hello all, > > I am pleased(?) to say that the SPARC Solaris 8 hosts running IBM AFS > are gone and all @ our place is now on x86_64 Solaris 10 hosts running > OpenAFS 1.4.12. > > I am still experiencing kaserver database issues of the same kind as > before, with one of the boxes reporting unknown key version number. > I can't reproduce this at will. At present, it seems to be all right, > but only on Friday one of our users couldn't change their password > because of this.
Unfortunately, kaserver is a service that has been deprecated within OpenAFS since the release of 1.4. http://www.openafs.org/no-more-des.html As described, in the upcoming 1.6 release kaserver will become an optional build component and in 1.8 kserver will be off by default. If the 1.4 kaserver is unreliable in your environment I would recommend continuing to use the IBM kaserver on the platforms where it is supported or you can try the OpenAFS 1.2 kaserver on the platforms where it is supported. Another option that you can try is to use the 1.5.74 kaserver. I mention this because although there has been no kaserver specific work over the last five years, the src/kauth directory has not been ignored by the efforts to prototype all functions and remove all warnings. However, the kaserver code is plagued with warnings from the DES library (particularly on 64-bit systems) and no efforts have been made to correct them. Migrating to krb5 is the preferred option of the community. OpenAFS will accept patches to kaserver that fix functionality. The challenge is going to be finding someone to identify the bug(s) and develop and test the patch. We have not had anyone since the creation of OpenAFS be interested in spending significant effort on the kaserver source code. > I am also experiencing new issues with clients reporting connection > timing out on AFS files, with the servers NOT going missing at any > stage as far as I can see. In addition, the FileLog of the server > that was changed first does contain an awful lot of "VL_RegisterAddrs > rpc failed" messages: > > Mon May 3 15:18:31 2010 VL_RegisterAddrs rpc failed; The IP address exists > on a different server; repair it > Mon May 3 15:18:31 2010 VL_RegisterAddrs rpc failed; See VLLog for details > > (It's now 15.22 as I write this.) > > VLLog contains nothing. > > All help appreciated, as always. Did you examine the VLLog log on the VLDB server that is currently the sync site? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
