On 2010-03-24 at 13:56, Russ Allbery ( [email protected] ) said:
For the rest, that's something that would need to be addressed upstream.
If you've not already, could you file a bug report with
[email protected] requesting this feature? It seems like a
reasonable thing to implement, although so far as I know you're the first
person who's wanted to do this.
Open a bug with regards to aklog looking in CellServDB directly, or...?
I believe the only thing aklog uses CellServDB for is to try to figure out
what Kerberos realm to use; I'm not sure what it should do instead. You
may want to think about your desired answer to that question and include
it in the bug report.
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?
Well, a completely empty file without afsdb enabled will cause bad things
to happen. I think doing that if afsdb is enabled makes sense, though. I
don't think I see any reason where the package really needs to update the
CellServDB for the local cell if afsdb is enabled. Either the local cell
is missing, in which case the user probably wants to just use afsdb; or
it's present and matches the canonical CellServDB, in which case we were
already assuming everything was fine; or it's present and has been
modified, in which case we preserve the user's modifications.
I think that makes sense. Would you just rely on AFS_AFSDB in
/etc/openafs/afs.conf.client to tell if we're using afsdb? That would work
in our case. Though, we're getting our afsd options from OPTIONS in
/etc/openafs/afs.conf, where we've set OPTIONS directly, since we want to
tweak things, and this makes it easy to keep the same afsd options across
debian and redhat, where the openafs.org rpm packages just use
AFSD_OPTIONS in /etc/sysconfig/openafs.
In any case, I think I'd rather have a client that fails to start, or even
crashes, than a client that starts using old db servers after every
package upgrade.
--andy
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
