Andy Cobaugh <[email protected]> writes: > On 2010-03-24 at 13:25, Russ Allbery ( [email protected] ) said:
>> 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. If you had changed the settings for your local cell directly in CellServDB, the package upgrade would have left them untouched. You're only having trouble because your desired configuration is one that was never anticipated by the package (and, indeed, has only become possible relatively recently). It believed that not having an entry for your local cell is a fatal error, and historically it would have prevented afsd from starting. >> 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? Well, that's what I'm saying. I would not recommend doing that. > 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. pam-afs-session just runs aklog. 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. 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. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
