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.