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

[Neulinger, Nathan]

What about the idea of adding an fileserver operation "FetchDB" that
would allow a client to fetch the most current cellservdb from wherever
it gets it's root.cell from?

Have the client load it's local CellServDB, which could even be empty if
using AFSDB locally. Then load from the server and overlay over top,
updating any entries present.=20

This could be at boot only, or recurring.=20

Obviously, that would only be effective for new clients and sites with
new servers.

For that matter, you could have the client configured to fall back to
fetching cellservdb from a grand.central.org file server if none
available locally, with a command line switch to disable.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Paul Blackburn [mailto:mpb@est.ibm.com]=20
> Sent: Monday, December 30, 2002 1:05 PM
> To: Ken Hornstein
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] Small suggestion for RH spec file?=20
> (keeping CellServDB up-to-date on *nix clients)
>=20
>=20
> Ken Hornstein wrote:
>=20
> >>Well, no. See that's the whole point of using a crontab process to=20
> >>synchronise a local CellServDB.
> >>It's automagical robot-tastical.
> >>It just works.
> >>   =20
> >>
> >
> >You're assuming that the source of that file synced by cron=20
> is up-to-date.
> >Many times it is not.
> >
> >It's been my experience that when I tell someone, "Hey, you=20
> can get this
> >file out of our AFS cell", about 50% of the time their CellServDB has
> >our old database server IP addresses ... the ones from 10 years ago.
> >In one case this even happened with someone who is now a=20
> regular OpenAFS
> >contributor.  In many cases the CellServDB that these sites used were
> >automatically synced up by cron ... but the source file was=20
> out of date,
> >and the admins who controlled it were too busy/lethargic to=20
> update it.
> >
> >If I was the OpenAFS dictator, I don't think I would distribute a
> >CellServDB file _at all_, and simply tell sites that they should
> >publish AFSDB records if they want to make their cells globally
> >available.  But that's just me.
> >
> >--Ken
> > =20
> >
> Ken,
>=20
> Is it easier or harder to maintain individual client=20
> CellServDB files on=20
> every client
> or one /afs/@cell/common/CellServDB file per site?
>=20
> Even if some AFS cell admins are lazy and lethargic, having=20
> one "master"=20
> CellServDB per cell
> is (IMHO) a better situation than relying on individual owners of=20
> individual client machines
> to keep their own CellServDB up-to-date.
>=20
> AFSDB records in DNS is interesting but really only suitable=20
> for sites=20
> who _want_
> their cell to be publically accessible. Also, there are=20
> situations where=20
> AFSDB records
> would be no use at all such as in DMZs where AFS is providing shared=20
> filespace
> to webservers and the AFS cell is deliberately blocked from=20
> Internet access.
> --
> cheers
> paul                                            http://acm.org/~mpb
>=20
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20