>> First, please take a look at these configs.  Why must authmethod and 
>> krb5realm be explicitly defined in both pref and codaauth2 -- did I
>> foul up 
> 
> 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 
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? 


>> a config somewhere, or perhaps dns?  And is there no way to define the 
>> location of the -keytab krb5.conf declaration in a config (pref?), or 
> 
> Sorry, what do you mean exactly? krb5.conf is not used anywhere for
> the client's sake.

Ack!  Miss-type: sed 's/krb5\.conf/krb5.keytab/g'.  Which is to say, I meant 
to type "krb5.keytab", NOT "krb5.conf". 


>> perhaps a default location it looks for the keytab so that I can place
>> the krb5.keytab there and omit the explicit declaration entirely? 
> 
> No, iirc there is no configuration option for use of keytab or its
> location.

That's what I figured, but I wanted to make sure. 


> (It is hardly a usual pattern for human users to authenticate with a help
> of a keytab even though it may make sense sometimes of course. Shouldn't
> be hard to add, patches are welcome)

We have no "users" per se, just services trying to get at files.  For us, 
the keytab is very handy.  Obviously we could pass in the user password to 
clog, but that seems unrefined somehow. ;) 

I will provide patches should I find myself in abundance of the same thing 
you lack for doing the patch.  :p 


>> [root_at_sandbox1]# cat /vice/codaauth2.conf
>> 4 {
>> authorities {
>>   coda.realm {
>>     authmethod = kerberos5
>>     methodopts {
>>       krb5realm = KERBEROS.REALM
>>     }
>>   }
>> }
>> }
>> [root_at_sandbox1]# cat ~/.codafs/clog/pref
>> 5 {
>> loginto = coda.realm
>> identities {
>>   coda.realm {
>>     desc = coda.realm
>>     identity = codaadmin/codaauth_at_coda.realm
>>     authmethod = kerberos5
>>     methodopts {
>>       krb5realm = KERBEROS.REALM
>>     }
>>   }
>> }
>> [root_at_sandbox1]# clog -keytab ~/.codafs/clog/krb5.keytab 
> 
> This looks like you are missing the point with authorities. 
> 
> It should be like: 
> 
> 4 {
>   authorities {
>     xyz {
>       authmethod = kerberos5
>       methodopts {
>         krb5realm = KERBEROS.REALM
>       }
>     }
>   }
> } 
> 
> and then: 
> 
> 5 {
>   loginto = abc
>   identities {
>     abc {
>       desc = Kerberos-based admin login to coda.realm
>       identity = codaadmin/xyz_at_coda.realm
>     }
>   }
> } 
> 
> Note that "xyz" and "abc" are arbitrary strings you choose,
> but it is grossly misleading to choose the authority name
> to coincide with the realm name. 
> 
> I would rather call the authority "krb5" or alike because you _can_
> authenticate in different ways 
> 
> codaadmin/krb5_at_coda.realm
> codaadmin/codaauth_at_coda.realm 
> 
> and so on, krb5 and codaauth are just examples here.

Apologies, this area of the configs themselves are somewhat misleading.  I 
actually use a shortened version of the corp name, not the coda.realm, I 
just didn't want to confuse matters by implicitly defining a new 
substitution (corp_name, I suppose). 

Further, while I understand that it is possible to have arbitrary strings 
linking any coda realm to any kerberos realm, we simply have no need for 
such a feature.  I know it is high in demand amongst the typical coda users 
(especially for clog where a user may be interfacing with several coda 
realms out on the internet), but our environment is simple, simple, simple.  
It has a single kerberos realm, which matches our single coda realm, which 
matches the domain of all the hosts everything is running on (both servers 
and clients), and will only be used within this environment inclusive to 
itself. 

We may expand our use of kerberos to include another kerberos realm for 
internal corporate [IT] use, website auth, vpns, and perhaps a coda 
fileserver to go with it -- you know, what kerberos was actually meant for 
 -- but there will not be any association to this initial environment. 


>> Regarding keytab auth, I found this site referring to kerberos _service_ 
>> principal keytab based afs auth (3rd paragraph from the top, under 
>> "Background" section):
>> http://www.stanford.edu/services/kerberos/sysadmin/keytabs.html 
> 
> I don't think it is appropriate to rely on this document. It is written
> for a very specific environment in mind (AFS). Its wording is chosen for
> brevity and thus creates confusion when the formulations are interpreted
> outside of the context they were written for. 
>
>> Do you know of a way to swap out a kerberos user principal for 
>> a kerberos service principal for the purpose of coda user authentication? 
> 
> A "user principal" and a "service principal" are just different ways
> of using a Kerberos principal. Usually different and sometimes complicated
> conventions are applied to the naming of principals depending on how they
> are to be used, but it is a different matter. 
> 
> For Coda purposes each process which needs to access Coda is to use
> some Coda identity and be authenticated as such. A Coda realm can be
> set up so that knowledge of passwords for certain principals in certain
> Kerberos realms can be used to authenticate as certain Coda identities.
> "Authorities" is a way to map Kerberos realm names and identities
> (or other authentication protocols, database instances and identities) to
> Coda identities. 
> 
> To set this up with Kerberos, the Coda authentication server process
> itself must have a knowledge of the password to a principal in
> the kerberos-realm-it-is-going-to-trust-for-authentication of
> Coda identities.  The name of this principal is arbitrary, but for
> good security- and adminsistration-related reasons it should be
> codaauth/coda.realm[@THAT.KERBEROS.REALM.THAT.IS] The authentication
> server is using a keytab to obtain credentials for this principal. 
> 
> Any processes desiring to authenticate against Coda may then use either
> Kerberos passwords or the corresponding keytabs for suitable Kerberos
> principals to obtain Kerberos credentials usable for authentication
> against Coda. 
> 
> There are no requirements what the Kerberos principals used for this
> purpose must look like, there is only a requirement that they
> must correspond to the names of Coda identities in a certain way.
> A primitive mapping is equality (the only situation for AFS), but
> this makes use of multiple Kerberos realms by one Coda realms hardly
> possible. A more general (and suggested) mapping is 
> 
> <principal>@KREALM.A ->
>    <samestringastheprincipalname>/<"A"authorityname> 
> 
> Note that clog always shows <name>/<authority> but internally in Coda
> user database it may correspond to either "bob" or "bob"/"krbA" depending
> on the setup. Your setup is the simplest and limited one, "bob" -> "bob"

Wow, based on my initial read, I believe you're saying that, yes, this is 
possible.  That would be fantastic. 

The key is linking the coda user (pdbtool) to the kerberos "principal" (user 
or service, being irrelevent). 

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 strait forward:
coda_user_at_coda.realm
coda_user_at_KERBEROS.REALM 

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 


I haven't tried this, but will certainly do so at my first opportunity. 

I also need to read back over what you wrote here again, as I've only had an 
initial [quick] read through of it. 


Thanks for all the information! 


>> Lastly, the following scripts/binaries are annoyingly interactive:
>> *) cocli
>> *) coser
>> *) createvol_rep 
> 
> If it annoys you, let you fight back! :) 
> 
>  yes "" | the-annoyingly-interactive-script >/dev/null 2>&1

I think you meant "let yes fight back". 

I'm familiar with yes, but I would much rather quiet or pre-answer 
known/typical questions, not blindly answer "yes" (or in this case, "") to 
any and all prompts which are delivered. 


>> Is there a automation friendly flag I can pass in to make unattended 
>> roll-outs possible?  I don't want to have to resort to expect just to
>> pass through a few [enter] key strokes. 
> 
> Sure! The flag is even implicit :) 
> 
> There is no information you give to the scripts in a different
> way than via the command line options. 
> 
> See above. It is what we do for automated installations (except that we
> log the output for possible troubleshooting), works like a charm :) 
> 
> Otherwise feel free to remove the messages and confirmations
> from the setup script, it is bourne shell and it is open source.
> Please indicate clearly (say by a descriptive suffix) that it is
> a modified version if you are going to publish it.

I would love to modify these scripts to add a backup query flag and 
non-interactive flag, and even provide patches to you, but when I ran file 
against these files, they were reported as binaries:
# file cocli-2.0-20090214-linux-ia32-1.bin
cocli-2.0-20090214-linux-ia32-1.bin: ELF 32-bit LSB executable, Intel 80386, 
version 1 (GNU/Linux), statically linked, stripped
# file coser-1.5-20090214-linux-ia32-3.bin
coser-1.5-20090214-linux-ia32-3.bin: ELF 32-bit LSB executable, Intel 80386, 
version 1 (GNU/Linux), statically linked, stripped 


I do note that createvol_rep is a script, however -- even when one finally 
digs past the several layers of scripts in front of it (something I only now 
checked). 

I will patch in support for a backup cli option and provide the patch.  I 
should have something along shortly for your review. 


Thanks,
 -Don
{void}