[OpenAFS-devel] Check for CellServDB and AFSDBRR correctness?

[Jeffrey Hutzelman]

On Fri, 6 Jul 2001, Ted McCabe wrote:

> At 4:01 PM -0400 7/6/01, Derek Atkins wrote:
> >Ted McCabe <ted@MIT.EDU> writes:
> >
> >>  I've known of some sites that deliberately only published a subset of
> >>  the actual db servers.  Also, since the check may happen while a site
> >>  is doing maintenance on their db servers, or during an outage, a
> >>  discrepancy may be only be temporary.
> >
> >Question: what happens if the published subset does not include the
> >syncsite?
> 
> Hmm, good question.  The example I'm remembering did include any 
> possible sync site.  IIRC, I believe the non-published db servers 
> were targetted by some special clients.
>
> If the dbservers could be set up to not point clients to the 
> sync-site, then one might also do it so that clients using the 
> published list would have readonly access to the dbs.  That may be 
> desired for clients outside some tightly controlled environment.

This is a bogus argument.  Security through obscurity is worse than no
security at all.  If you don't want clients making changes, then don't
give them the bits.

> Since the dbservers do direct write requests to the sync-site, I 
> expect the client happily uses the pointer it gets.  It might 
> explicitly check against the published list, I've not looked at the 
> code, but there's not much point to check since it has no reason to 
> not trust the forwarding info.

The dbservers don't tell you who the sync site is.  If you try a write
request on not the sync site, you get UNOTSYNC, and it's up to you to find
the sync site.  The Ubik client library will do this for you, but it only
makes a VOTE_GetSyncSite call if there are at least four dbservers;
otherwise it uses simple iteration.

So, if you're going to only publish some dbservers, make sure you publish
at least four, so clients can find your sync site.  OTOH, having very many
more servers than that will start to cause problems, especially during
recovery when the new sync site labels and then tries to propagate a new
database.

You're really better off publishing all possible sync sites all the time.
In theory, that means the lowest-numbered half+1 of the voting dbservers,
but I can't promise that something wierd won't come up that makes some
other server become sync site.

-- Jeff