On 2010-03-24 at 13:25, Russ Allbery ( [email protected] ) said:
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.
I generally dislike having to tell the package management system what I
want put in my config files. I think I did run dpkg-reconfigure once on a
different machine after realizing what was going on, but it was still
populating CellServDB.
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.
What else are supposed to do if we *only* want to use afsdb? Even with
-afsdb, tools like aklog, and it would seem pam-afs-session as well, seem
to look in the csdb directly for db servers to contact before falling back
to afsdb.
Indeed, having no CellServDB file at all is a mis-configuration, but
having one that's totally blank isn't if one is using afsdb as you said,
and perhaps if there is a csdb file but it has no contents, maybe we can
assume the user knows what they're doing? At least with the openafs.org
RPMs, having an empty CellServDB file prevents any overwriting when
openafs-client gets updated, as any new CellServDB file will get created
as CellServDB.rpmnew.
My personal preference is to just not touch CellServDB at all, but that's
just me.
--andy
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
