There is no such requirement. ~/.codafs/clog/pref is completely
optional.
Clarification: If I don't put those settings in pref along with
codaauth2, I end up having to define the settings on the command
line. I would like
This means that something else in the setup is broken.
Thanks. I thought I was going nuts. I'll see if I can figure out where
this is broken. Probably DNS, I reckon.
clog to pull as much as it can from dns, then codaauth2, then pref, and
finally command line (overrides working in reverse order, or course). If
codaauth2 has the kerberos definitions in it, why does clog need those
same definitions set in pref?
It doesn't. Your authentication advertisement is apparently not working.
Please recheck.
What I don't understand is how to link a coda user to a kerberos service
principal, as the syntax of the principal (displayed, at least) is
different between the two types. For instance, the following is very
The syntax includes realm names which actually refer to the databases'
instances and do not belong to the records in the databases.
strait forward:
coda_u...@coda.realm
coda_u...@kerberos.realm
Exactly.
What I want to do is associate this same coda user to a service instead.
Can this be done by simply creating a kerberos service in the form of:
coda_u...@coda.realm
coda_user/KERBEROS.REALM
Now what do you mean by "a kerberos service"?
Sorry, I can't help this.
Here is an example of a kerberos service principal:
codaauth/coda.re...@kerberos.realm
The question restated is: Can a kerberos service principal (stored in a
kerberos keytab, of course) be used to authenticate a coda user (using clog
-keytab keytab_file, of course)? If so, given the example of:
coda_u...@coda.realm
[what_does_the_service_principal_look_li...@kerberos.realm
If it's not possible, it's not possible.
Thanks,
-Don
{void}
