On Wednesday, April 26, 2006 05:15:22 PM +0200 Tommie Gannert
<[EMAIL PROTECTED]> wrote:
Hi!
I've been trying to make my behind-NAT AFS-server do backups to
a butc-server behind another NAT.
That didn't work because the vlserver keeps sending the file servers'
first address instead of the one matching the client address. vlnat
is a patch against 1.4.0 which
1) Makes vlserver choose the best fs-address based on the number of
common address-bits of the RX-client.
Huh? The modern vlserver interfaces return _all_ the addresses of a
server, not just one. The decision of which address to use should be up to
the client, which is in a better position to make a decision. It's
possible that the backup system is still using ancient interfaces that
refer to fileservers by a single address instead of by UUID; if so, the
right long-term fix is to make it use the modern interfaces.
Unfortunately, this all gets very complicated when you have clients and
servers on networks with non-globally-routable addresses, because the
vlserver can't always know which such addresses will work for which
clients. I think we're going to have to come up with a general solution to
this issue if we ever hope to support IPv6 in a reasonable way.
Second, 1.4.1 contains a typo in vlserver.c. During command
line processing, instead of argv[index] it says argv[i]. i is
uninitialized. It's the "rxmaxmtu" case.
Yup, that's a bug. You should send it to openafs-bugs. Including a patch
wouldn't hurt, but also shouldn't strictly be necessary in this case, since
the fix is so obvious.
(Isn't anyone else using "-syslog"?)
Yes; we've been using -syslog in production for quite a long time. I bet
not too many people use -rxmaxmtu, though, and this bug should be very
unlikely to affect people who don't.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
