[OpenAFS] openafs-1.4.2 RHEL RPM package installs nonempty SuidCells and mangles CellServDB

[Rainer Laatsch]

My recommendation on installing a new host:

Have the own CellServDB installed before the afs rpm by some other means,
If the afs rpm finds an empty or no CellServDB, it should copy
CellServDB.public to CellServDB .

Mangling the own CellServDB isn't that good; we had to wait for one year
before our updated CellServDB was distributed by grand.central.org.
If the afsd does not start because of that, it cant get at our
CellServDB held in AFS space.

Concerning SuidCells: we are not amused.

The mechanism for periodic updating should be treated separately. A naming
convention like the AFS_POST_INIT in etc/sysconfig/afs may be sufficent.

Best regards / Mit freundlichem Gruss
Rainer Laatsch

(sometimes doing admin stuff here ...)
________________________________	______________________
E-mail: Laatsch@Uni-Koeln.DE		Universitaet zu Koeln
					Reg. Rechenzentrum (ZAIK/RRZK)
Fax   : +49 478-5590			Robert-Koch-Str. 10
Tel   : +49 478-5582			D-50931 Koeln

On Wed, 22 Nov 2006, Jeffrey Altman wrote:

> Berthold Cogel wrote:
> > Derrick J Brashear schrieb:
> >>
> >> If we can get a vgaue consensus on what it is that should be sourced,
> >> I'd love to accept and integrate such a contribution... as long as
> >> people who don't have something set still get their DB updated. Having
> >> one set of packages everyone can use, and no one needing to build, is
> >> high on the list of things the project has tried to do.
> >>
> >
> > Perhaps it is possible to include a script in openafs with a mechanism
> > that allows the user to update his CellServDB. It should be called by
> > the init script. This mechanism could be triggered also by local update
> > methods (cfengine) or manualy.
> >
> > What I would like to have is a something like this:
> >
> > - A CellServDB.dist from openafs.org. Provided during installation and
> >   perhaps updated by cronjobs via ftp or http.
> > - A CellServDB.local which I can maintain myself, perhaps with local,
> >   nonpublic cells.
> > - A CellServDB.blacklist to exclude 'broken' cells (perhaps not up2date
> >   in CellServDB.dist) or cells I don't want to be seen by my users on
> >   all or some special clients.
> >
> > These files can be processed by the update mechanism to form a new
> > CellServDB.
>
> Why even bother forming a new CellServDB at all?
>
> The client's could simply contain the code which handles searching for
> cell information from multiple sources.   CellServDB should be the
> equivalent of .local.  CellServDB.public is the version shipped with
> OpenAFS.  I think I would call CellServDB.blacklist CellServDB.force.afsdb.
>
> Algorithm to find cell information:
>
> (1) search CellServDB.
>
> (2) search CellServDB.force.afsdb.
>     if found and DNS AFSDB support is active,
>     then query DNS AFSDB record for cell
>
> (3) if cell not listed in CellServDB.force.afsdb,
>     search CellServDB.public
>
> (4) if DNS AFSDB support is active and a DNS AFSDB
>     query has not been issued, then query DNS AFSDB
>     record
>
> Jeffrey Altman
>
>
>
>
>
>