>>> 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_user_at_coda.realm
>> coda_user_at_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_user_at_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.realm_at_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_user_at_coda.realm
[what_does_the_service_principal_look_like]@KERBEROS.REALM 


If it's not possible, it's not possible. 


Thanks,
 -Don
{void}