Andy Cobaugh <[email protected]> writes: > Any time openafs-client is upgraded, it would appear the package is > overwriting /etc/openafs/CellServDB with the cell and db servers entered > at initial install time, based on what's stored in > /var/cache/debconf/config.dat.
No, it's not overwriting (that would be a Policy violation, and I was worried there for a moment). It is, however, ensuring that you have a CellServDB entry for your local cell, so if your local cell is missing, it prompts the user for the local VLDB servers and adds an entry for the local cell. If you've already answered that prompt, then of course it uses the stored answer unless you run dpkg-reconfigure openafs-client. > At least for us, this means the one and only db server we started out > with (which has long ago been retired) is entered into a normally empty > CellServDB (we blank these files and use AFSDB instead), resulting in > most afs-related functions to timeout waiting for this old server to > respond, if they timeout at all. Well, having incorrect debconf settings on your clients pointing to the wrong VLDB servers doesn't seem particularly safe. However, the root of the problem is that the packaging scripts don't consider a completely empty CellServDB to be a valid configuration (because, unless you're using afsdb, it's very much not). I would not recommend the configuration method that you're using, but I suppose it works and saves trouble if you have to re-IP your VLDBs. I'm trying to think how to change the package to allow for it. I suppose the simplest thing to do would be to not worry about CellServDB if configured to use afsdb, although I'm not sure if that would cause any problems. I guess I can't think of any off-hand. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
