Greetings Rune: 

Thank you for your thorough and expedient reply.  My comments are in-line: 


>> Password for admin/admin_at_KERBEROS.REALM:
>> 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? 


> I guess the problem is that you rely on your client-side ~/.codafs/clog/pref
> which is totally unnecessary for testing, nor for regular use as long as
> you supply the Coda account name and the Coda realm name on the command
> line.

Understood.  I will attempt some clog commands with various options. 


> Your file (and possibly the corresponding advertisement from the server)
> seems to point to a non-existing Coda realm (named for some reason
> "KERBEROS.REALM"!) 

I scrambled it.  Our realm is the upper-cased domain of the company I'm 
working for. 


> and to an authentication authority called "admin" which
> looks confusing. The authentication authority is a name for a certain
> way to authenticate against the given Coda realm. You may have several
> authorities designating e.g. several Kerberos realms usable with one Coda
> realm, or authorities to refer to different authentication means. If you
> are using a single Kerberos realm as the main means of authentication,
> call the corresponding authority "krb" or "common" (but why "admin"? -
> it is really you private matter of choice - I just want to make sure
> you know the semantics). 
> 
> I would suggest to begin with manually supplying all the parameters
> on clog command line and removing ~/.codafs/clog/pref to avoid
> extra confusion.

Ok!  Now this is good to know.  I thought perhaps that was what it was, but 
I couldn't quite give-over from the "classic" coda method of having coda 
user / kerberos user semantics.  So this is the key to modular clog's full 
abstraction from kerberos. 

I still need better understanding of what the "authorities" declarations do 
in codaauth2.conf and what the "identities" declarations do in 
.codafs/clog/pref.  They are clearly two sides of the same coin (or perhaps 
similar coins at different points in the auth process). 

However, the point is still clear regarding my next step.  Shutdown/remove 
these configurations and try again with explicit clog options.  I will post 
back the command and results (hopefully success). 


>> NOTE:  It is quite possible that I simply have not created the kerberos 
>> principal/user or the coda user correctly -- or, perhaps I simply haven't 
>> configured .codafs/clog/pref
> 
> This is client side and is totally optional. 
> 
>> or TCP 370 "codaauth" service correctly for 
> 
> This is server side and is optional too but crucial for _transparent_
> authentication. Otherwise you can always manually supply all options
> (like kdc addresses etc) on clog command line.

I'll need more info on this, but before I consume needless resources, I will 
get clog to work exclusively with options.  It is not unusual for 
understanding to crystalize upon finally hitting the magic combination for 
success. 


>> this user/principal pair.  This part of the configuration is largely 
>> undocumented.  While I have spent considerable time adding all manner of 
> 
> Well, I think I made a reasonable effort in
>  http://coda.wikidev.net/Server_Binary_Installer 
> 
> It would help if you ask more explicit questions with reference to
> certain statements from that page, then I may fix/add it there.
> What is missing?

First, allow me to say that these instructions were clear and precise for 
their purpose.  Permitting basic authentication.  And with respect to 
initial coda install, both the packages and the nitty/gritty configuration 
primer allowed for several insights I had not yet understood. 

However, unfortunately for me, I was already able to get coda working with 
basic auth from default packages.  What I couldn't do is get kerberos auth 
working with coda. 

It's a cruel joke that I can find countless references in search engines of 
people with kerberos auth issues getting directed to aetey.se, only to end 
up right back where I was:  Coda auth, no kerberos auth -- albeit, 
presumably now with a coda client capable of "better" kerberos auth. 

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.  :) 


>>  However, if needed, I also have a second server only running the 
>> client. 
> 
> This looks contradictory :) You mean, you have another host running a
> client?

At your preference.  I call it a server, because it is a mostly headless, 
rack mount "server" providing services to other servers and workstations.  
Services for which it will depend on a /coda filesystem.  I.E.:  A server 
[hardware] running a coda client only [software].  I can just as easiy use 
"host" here if that is a more accepted convention. 


> A client on the server host may be more confusing for the beginning, in
> case you have Kerberos-related things lying in /etc and alike and expect
> the client to pick things from there. 
> 
> For simplicity use a plain Aetey client on a different host, there
> shouldn't be any Kerberos-related configuration present there, really,
> to avoid possible confusion. You do not need any "kinit" or similar.

Noted.  Should be easily done. 


> Similarly for the server - put it preferably on a "Kerberos-agnostic" host
> without any traditional Kerberos configuration files and libraries. Those
> are ignored by the server but may confuse yourself. 
> 
> When you have Coda authentication with Kerberos working, with all
> parameters given on the clog command line, then set up the advertisement
> service on the server and make clog work with <account>@<codarealm> only.
> When it is working and you feel adventurous, proceed wiht setting up
> .codafs/clog/pref...

Will do, though the server, being the krb/kadmin in this test environment, 
will always have krb files laying about. 


> Good luck Don,
> don't hesitate to come back and ask.

Thanks, I will. 


A few burning questions raised from the wiki's and your comments above: 

keytab (krb5.keytab):  Can clog use a kerberos keytab as an auth method?  
The implementation appears very similar to the ssh authorized_keys file, 
though the keytab is obviously obtained in a much more complicated way and 
is attached to a given auth user/password. 

kinit:  Assuming kinit is laying about on the coda client host, will clog 
auth transparently off of a kinit fetched tgt? 

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)? 


Regards,
 -Don
{void}