Ok great response. I believe I now have a "clue" on where OpenAFS is
relating to all my questions.
1. Given the responses I believe we will continue to wait patiently for
1.4.1. I understand that no version will ever be completely bug free, but
we really would like the server side stuff to be as solid as
possible. Using "betas" and "release candidates" on the clients is a less
problematic issue.
I think one issue here is that the OpenAFS.org client "product" doesn't
work like other software "products" in the industry. Usually a software
package is released, then if it has bugs, the customer receives "patches"
that solve a problem. A patch could even be an entirely new client,
however it is still called a patch with some version number (Transarc used
to do this). In OpenAFS.org's case, all we get is a "production release",
then everything after that is just "...on to the next version with unstable
betas and rc's". I understand this has more to do with the nature of open
source in that the "customer" can download a "source patch" and recompile
to fix a particular problem, however it is still kind of irritating that no
official "patches" are issued. Eg, there's no place on the web site under
"downloads" where the patches to fix particular bugs are listed.
2. Regarding the xlock/xscreensaver/KRBCCNAME issue, we are running RHEL3,
so yes, we are using older stuff. We are using the K5 PAM that came from
RedHat. In light of what was stated, a simple upgrade to RHEL4 should fix
this issue. I believe we tried RHEL4 just after it became available and
had some issues with the OpenAFS compile (or applications) so it was
decided to wait for a while until we could examine the problems further.
Thanks,
Rodney
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
