Greetings Rune et al: 


>> >>krb5secret: Unknown error -1765328228 getting credentials
>> >
>> >This error code seems to mean
>> > "Cannot contact any KDC for requested realm" 
>> 
>> Good to know.  In the interest of being self-sufficient, where did you
>> find this information? 
> 
> Asked Google for "1765328228 kerberos" :) 
> 
> It is present in the source code of course - but the library we are using
> is built without the strings and it is easier to ask Google than to look
> in the code.

Ah, I didn't think to drop the minus sign. 


>> I scrambled it.  Our realm is the upper-cased domain of the company I'm 
>> working for. 
> 
> (imho there is no reason for a Coda realm to be upper-cased,
> rather not - to avoid confusion with Kerberos)

Realm, with respect to Kerberos authentication realm.  The coda realm (or is 
it cell??) is, in fact, lower case. 

Please feel free to make the assumption that I have false understandings.  
If "KERBEROS.REALM" is stated, but from syntax it should be "coda.realm", 
please correct me. 


>>> http://coda.wikidev.net/Server_Binary_Installer  
>>> 
>>> What is missing?
>> 
>> I know that you don't handle kerberos, per se, and the whole point of
>> this clog adaptation is to permit any random pairing of coda and
>> kerberos possible, but for the experienced/enthusiastic novice, a
>> base-line example is invaluable.  
>> 
>> I would even be more than happy to write it (I could send it via
>> listserv, email, or direct edit of the wiki).  That is, once I figure
>> out the basic kerberos implementation my own self.  :) 
> 
> It would be great if you can share your experience (let us make it
> a success story :) via the wiki.

Will do. 


> I see. Unfortunately the word "server" is heavily overloaded and
> especially in the context where it normally has a certain meaning - "a
> Coda server" it would be advisable to use a different word for a
> different meaning.

Indeed.  "Host" it shall be. 

Around the office, we strictly refer to hardware as "servers" and 
"workstations", and software as "service" and "client" (or, frequently, 
"browser" as much of what we do is, of course, web based).  The key is 
having some kind of understanding, otherwise a strait forward subject can 
become easily confused. 


>> keytab (krb5.keytab):  Can clog use a kerberos keytab as an auth
>> method?  
> 
> Sure: 
> 
> $ clog -method kerberos5 -- -help
> Usage: clog
> [omitted] 
> 
> [Empty keytab name '' should let it look in implicit "standard Kerberos"
> location(s) which is _not_ what I would recommend. Different services
> need different identities, a host-wide /etc/krb5.keytab is bad.]

There are references to kerberos service principals being stored in a keytab 
for coda -- old standard was host/[fqdn]@[KERBEROS.REALM], but this has 
changed to coda/ (don't want confusion/collision with telnet/ssh/etc., I 
guess), and now codaauth/.  I don't really know what these are for, but it 
is said you have to copy the keytab around after you create them. 

On another site I read up on kerberos keytabs being used to store encrypted 
/ cached / reusable kerberos user/pass for transparent semi-permanent (as 
long as the password doesn't change and remains valid) kerberos 
authentication. 

I didn't want to assume for what or to what extent coda [modular clog] used 
a kerberos keytab.  Now I know that keytabs can be used for coda auth 
caching, which is good -- it will likely be how we manage our coda client 
auth. 


>> Related to the kinit question, is it preferred to use clog to refresh 
>> kerberos tickets (if not using keytab for some reason) or some facility
>> of kerberos (such as krenew or k5start)? 
> 
> Clog is definitely a wrong tool for refreshing Kerberos tickets.
> It is a Coda tool and it does not have any relation to Kerberos tgts
> besides the capability to use them. Clog gives you Coda tokens only
> (it creates possibly some very short-lived Kerberos tickets for its own
> use). 
> 
> Did you really mean "refreshing Kerberos credentials" or rather
> "refreshing Coda credentials"?

Probably.  I don't, as yet, understand the distinction.  When using clog for 
"refreshing Coda credentials", does this not mean "refreshing Kerberos 
credentials"?  Isn't a kerberos "credentials" synonymous with a "ticket"?  
And, in the case of user auth, implicitly a tgt ticket? 

To be abundantly clear, when I refer to a "kerberos ticket", or 
authenticating, I am referring to the process by which I fetch a current and 
valid "tgt" ticket as I currently do not understand any other distinction. 


> Note that refreshing Kerberos credentials (say with kinit) will not
> refresh your Coda credentials per se, you would need a separate clog
> command anyway.

[root_at_sandbox3 ~]# k5start --help         2>&1|grep -iE 'afs|KINIT_PROG|-t'
  -t                   Get AFS token via aklog or KINIT_PROG
If the environment variable KINIT_PROG is set to a program (such as aklog)
then this program will be executed when requested by the -t flag.
Otherwise, using -t is an error. 

[root_at_sandbox3 ~]# krenew --help          2>&1|grep -iE 'afs|KINIT_PROG|-t'
  -t                   Get AFS token via aklog or KINIT_PROG
If the environment variable KINIT_PROG is set to a program (such as aklog)
then this program will be executed when requested by the -t flag.
Otherwise, using -t is an error. 

In essence, you are, of course, correct.  It appears, simply, that the 
notion of running clog (or any other app, including a script) is built in to 
the kerberos utilities. 

Regardless, the keytab appears the most elegant to me, unless there is a 
value to having the simplicity of a coda pw file...? 


Many thanks,
 -Don
{void}