Jeffrey Hutzelman wrote:
> 
> 
> 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".

There certainly have been issues related to the file server not doing
all it can to track UUIDs and keep appropriate separation between two
clients sharing the same IP address with different UUIDs.   At least
some of these should be fixed in 1.4.0 RC2.   If you are still seeing
problems, file a bug report.

>> 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.

At this point, unless someone submits a fix for a problem in the next
day and that fix is utterly trivial, it will be held back until 1.4.1.
1.4.0 RC3 will be cut very soon and the gatekeepers expect that it will
be the last release candidate.

> 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.

The gatekeepers are unaware of any problems with kaserver.   Please
file a bug report at [EMAIL PROTECTED] including details of how
to reproduce the problem.


Jeffrey Altman
begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:[EMAIL PROTECTED]
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to