On 2010-03-29 at 13:08, Russ Allbery ( [email protected] ) said:
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.
Yes. This is now done in the current packages in unstable.
Cool, thanks.
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.
You need to ensure the right option is set in /etc/openafs/afs.conf.client
and not just command line options set in AFSD_OPTIONS, but afsdb is the
default there.
Yes, we do have AFSDB enabled in afs.conf.client.
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.
Well, from my perspective the correct solution would be to deploy a
CellServDB with the correct database servers, but I realize that you don't
want to do things that way.
Agreed. At least with managed machines on our network relying on dns for
this sort of thing is safe enough, and allows us to not worry about
updating CellServDB everywhere. We rely on dns/ldap for a lot of
"zeroconf"-like configuration.
--andy
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
