[OpenAFS] Small suggestion for RH spec file? (keeping CellServDB up-to-date on *nix clients)

[Ken Hornstein]

>Is it easier or harder to maintain individual client CellServDB files on 
>every client or one /afs/@cell/common/CellServDB file per site?

There's no argument, one common CellServDB is easier.  But it seems like
that isn't the issue, because in many cases that is not maintained.

>Even if some AFS cell admins are lazy and lethargic, having one "master" 
>CellServDB per cell is (IMHO) a better situation than relying on individual
>owners of individual client machines to keep their own CellServDB up-to-date.

*shrug* at least those people who install a new RedHat RPM have a
reasonable chance to access other cells; if they use a central one at a
site, many times they cannot.

>AFSDB records in DNS is interesting but really only suitable for sites 
>who _want_ their cell to be publically accessible.

I take it you've never heard of a split-horizon DNS?  And I would hope
that anyway if you don't want your cell to be publically accessible,
you're using a IP firewall and not relying on the lack of a CellServDB
entry.

>Also, there are situations where AFSDB records would be no use at all such
>as in DMZs where AFS is providing shared filespace to webservers and the
>AFS cell is deliberately blocked from Internet access.

Hm.  I guess I don't see why AFSDB records wouldn't be useful for even the
local cell in that case.  If you change an IP address of a database server
in DNS, everything works and you don't have to do anything else.

I guess that as I see it, the OpenAFS people want AFS to be a truely
global filesystem, so the distributions that _they_ put together are
set up so that it functions as such.  Now of course there are plenty of
places that use AFS as a local filesystem, and those uses are perfectly
valid.  And those sites that want to use AFS locally are free to put
together their own RPMs ... so what exactly is the problem?

--Ken