Hi,

On Wed, Feb 10, 2010 at 08:38:08AM -0800, root wrote:
> 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.

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

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

> [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.

> 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"

> 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

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

Regards,
Rune