On Thursday, September 01, 2005 07:48:16 PM -0700 Lester Barrows
<[EMAIL PROTECTED]> wrote:
OpenAFS clients in excess of one system work poorly behind any NAT I've
ever put them behind, be that hardware such as those on Cisco or Foundry
routers, or software such as iptables with the Linux kernel. There may
be a few types of NATs which work properly, and increasing polling
frequency may indeed help, but from an architectural standpoint I
wouldn't recommend placing several AFS clients behind a NAT. It's simply
asking for trouble from my experience, which is the context in which my
response was written.
So tell us about your experience, but please don't spread FUD about AFS by
making blanket statements like "OpenAFS doesn't seem to work very well with
NATs" based solely on your own experiences. I don't care for NAT's but I
do use them from time to time, and it works just fine for me.
If you'd like to describe your setup and symptoms in enough detail that we
can reproduce the problem, I'm sure there are any number of people who
would be interested in helping to try to track it down and build in a
workaround for whatever broken behavior your network hardware has. But
until then, please don't spread FUD about OpenAFS with blanket statements
like "The developers do not seem to be interested in a solution for this".
What is convenient is often chosen over what is
perceived to be correct.
Yes, people often choose to shoot themselves in the foot. I still
recommend against it.
We still have issues with obtaining tokens from a kaserver on
login under amd64, but those will hopefully be sorted by the time 1.4
rolls out.
As I mentioned, the current version is OpenAFS 1.4.0 Release Candidate 2.
I expect that the only changes that will be applied at this point are ones
that fix high-severity "showstopper" bugs, or that fix longstanding known
problems and otherwise have minimal impact.
Lacking a serious new security problem, I doubt the gatekeepers will
consider any problem related to kaserver support to be of that severity.
If you ask around, I expect that most people will tell you that the
solution to your problem is to stop using the kaserver.
That said, feel free to file a bug report. Without one, your problem will
not be fixed, before 1.4 or after. I was unable to reproduce any problem
with getting tokens from a kaserver on an amd64_linux26 box, but then, I
didn't know enough about your environment to try very hard.
PAG support has been available for quite some time. Yes, if you run an
old enough version you won't get PAG support. So don't run something
that old.
PAGs aren't the issue
Well, except to the extent that you said "Older releases of OpenAFS don't
support 2.6 at all with PAGs to my knowledge". So since you brought it up,
I felt obligated to correct this error.
OpenAFS has supported PAG's on 2.6 for as long as it has supported 2.6.
Initially it did not support the technique of trapping the setgroups()
system call to prevent callers of initgroups() from making PAG's go away
(incidentally, well-behaved PAM applications should not ever have this
problem). However, even that support has been available for i386_linux26
and amd64_linux26 since 1.3.78 or so, for all 2.6 kernels (ppc, sparc, and
the like took a few versions longer; the probe code last changed in 1.3.81).
Frankly, I hate the included backup system. However, there are a number
of good alternatives available, depending on your environment.
Agreed, but for some organizations it has to suffice.
Yeah. I just wish we could ship something that didn't suck so much.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
