[OpenAFS] OpenAFS in a production environment

[Jeffrey Hutzelman]

On Thursday, September 01, 2005 07:48:16 PM -0700 Lester Barrows 
<barrows@email.arc.nasa.gov> 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) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA