Inline...

> -----Original Message-----
> From: [log in to unmask] 
> [mailto:[log in to unmask]] On 
> Behalf Of Stephan Wiesand
> Sent: 03 March 2009 18:24
> To: [log in to unmask]
> Subject: RE: AFS and /usr/vice/etc/CellServDB
> 
> Hi Martin, Graham,
> 
> On Mon, 2 Mar 2009, Bly, MJ (Martin) wrote:
> 
> > AFAIK:
> >
> > The CellServDB file is distributed by the folk at grand.central.org.
> >
> > We notified them of the changes we were making, and made the changes
> > with suitable pauses to allow the new CellServeDB to 
> percolate around.
> > The latest update they have seems to be from November which 
> has all four
> > servers in it (the interim stage) and can be found at
> > /afs/grand.central.org/service/CellServeDB (which is a link to the
> > latest version).  At what frequency they put updates to 
> CellServeDB into
> > the wild and at what frequency it then makes it into the 
> AFS RPMs I do
> > not know.
> 
> I don't know about grand.central.org, but unless we forget we 
> update the 
> CellServDB (to the grand.central.org version, plus additions like 
> hepix.org where required) in the openafs-client RPM whenever 
> we push out a 
> new release - which we try to avoid except upon minor SL 
> releases. Now the 
> current SL4/5 builds are from June 2008, hence the changes regarding 
> the rl.ac.uk DB servers are not yet in.
> 
> I'd gladly provide an SRPM with no change but the corrected 
> entry for your 
> cell for SL5.3 RC2.5 and following SL releases. Please 
> confirm that this 
> would be
> 
> >rl.ac.uk               #Rutherford Appleton Lab, England
> 130.246.183.203                 #afs1.gridpp.rl.ac.uk
> 130.246.183.204                 #afs2.gridpp.rl.ac.uk
> 130.246.183.205                 #afs3.gridpp.rl.ac.uk
> 
> without wallace, no matter what grand.central.org has. 

Yes, correct. 

> NB a notice to 
> this list could also ensure that correct entries for a cell 
> are provided 
> with any default SL installation, independent of the pace at 
> grand.central.

Noted.  We can post any future changes here though we don't expact to
change again in the near future.  

Do you want us to let you know personally, Stephan?

> Of course it's still up to Connie and Troy to accept such 
> changes. Even 
> though they are quite minor, they still mean rebuilding and 
> pushing out a 
> lot of packages.
> 
> > Standard practice is usually to overwrite any RPM supplied 
> CellServeDB
> > with the grand.central.org version, or with one of your own 
> crafting, if
> > the RPM supplied version gets too far out of date.
> 
> Right. I wonder whether the CellServDB (and maybe ThisCell, and maybe 
> more) should be split out into something like 
> openafs-client-config to 
> make it easier for sites to customize the client and for SL to update 
> CellServDB without having to push out a whole set of packages?

We have our own local RPM that overwrites CellServeDB - we update it
various intervals to try and keep it in step, usually when someone
notifies usof a problem.  But thinking about it, the openafs updates may
be more frequent and overwrite our version in turn.  Hmmm.   Needs some
thinking...

> > The old server address is still active at RAL as a virtual 
> address on
> > one of the new servers (the old machine has been retired 
> with prejudice
> > after too many years server - no flowers), so if you use the
> > single-server config, it should still work.  (For a while - 
> I need the
> > i/p address back, so at some point after grandcentral catch up, I'll
> > reclaim it.)
> 
> An advance notice to this list would be much appreciated.

Noted.  I don't expect to have to do this for a month or two at the
present rate of use of IP space.

Regards,
	Martin.
-- 
Martin Bly
RAL Tier1 Fabric Manager 
--
Scanned by iCritical.