On Wednesday, April 26, 2006 09:30:59 PM +0200 Tommie Gannert
<[EMAIL PROTECTED]> wrote:
Unfortunately, you can't get 'vos listvldb' to directly show you server
UUID's or more than one address per server. However, any given address
can only be assigned to one server, so you can take the server names or
addresses reported by 'vos listvldb' and feed them to 'vos listaddrs' to
find out the UUID and/or other addresses assigned to that server.
Makes sense.
Is an extension of listvldb a possibility? (For
consistency, deprecating the old RPCs.)
I don't see why listvldb could not be made to use the new interfaces.
So, now my question is... Is buserver in use? Do people use tapes or
can it be safely converted to file based storage?
I don't use it, but recent mailing list traffic suggests that some people
do, and that people are doing backup to tape. File-based storage is nice
for handling recent-timeframe restore requests, but doesn't do so well with
things like "get me back this file I deleted 5 years ago", or with some
kinds of disaster recovery.
> I'm not sure if the clients are better off making the decision,
> though. If they are behind NAT with the same subnet as the server,
> things will get messy. The idea of using common address bits means
> it will resort to global address space pretty easily. However, it's
> a hack, yes.
Well, it's got to resort to a global address if it's not on the same
private network as the server. However, since the vlserver never gets to
see the client's private address, it's not really in a position to make
the right decision.
The Thesis:
The address which the server sees, is in the same subnet the server
is on, as seen from the client.
Suppose you have a server and client that are behind the same NAT, and so
share private address space. But at least one vlserver is outside the NAT,
and has a routable address. In that configuration, that vlserver will not
know the client and server share a private subnet.
-- 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
