Hi Zetas,

On Tue, Aug 03, 2010 at 09:47:17AM -0400, Zetas wrote:
> that i clogin to on the client machines to make changes to the share, this is a
> completely manual process. Is this the best way to do it? Should i make each
> user login to a separate share just for them (i.e. something that automatically

I guess there is some confusion. When you authenticate against Coda, you
actually authenticate a local uid (the uid of the process executing clog)
to a Coda realm - not to any "share".

> happens when they login)? Or should i just create a corresponding user account
> in coda for each real user? Can coda integrate with our existing LDAP
> infrastructure?

It depends on what you mean by integration. Short answer - not.

Coda uses its own account database.
Coda uses its own group database, semantically incompatible with Unix.
Coda may use its own password database or/and some kind of an external
authentication authority. There is good support for using a Kerberos
realm as such authority. There is no support for using any unix-like
database of password hashes (which sometimes can be found in LDAP).

> Right now i just have one user, the default user created during vice-setup, and
> while im trying to copy existing user data to the share the permissions are
> getting all messed up, i have to go back manually and change the permissions for

It is a confusion.

> I feel like i should be able to find this information on my own, i know coda has
> some kind of ACL setup, but i have not been able to find any reliable, fairly

It uses ACLs. You should forget paying attention at the Unix mode bits,
owner and group. They are irrelevant with Coda.

Unfortunately there is in Coda historically some semantics connected
to the first two mode bits but you are better off and your users are
safer ignoring this, trust me :) Just make sure those bits are not zero
(those corressponding to "read and write for the owner" in Unix world).

(Much later you _may_ find a use for those bits but not before you
understand the implementation and the semantical implications well)

> new guides for it or how to create and manage users. I also need to make it so
> the coda share is not readable by anonymous.. but thats less critical right now.

There are acls and you have to [learn to] use them. Hope somebody on
the list will point to a proper documentation piece.

There are no "straightforward" tools for account management in Coda.
You have to rely on several utilities or/and build some
automation around them.

pdbtool is used for manipulation of the account and group database,
au              for manipulation of Coda internal password records,
cfs             for setting and listing ACLs on directories

pdbtool is to be run as the "Coda server user" (presumably root)
on the SCM host.

au can be run on any host (it shall talk to SCM) but needs
the knowledge of the password to a powerful Coda account (a member of
System:Administrators) or to the account to be modified;
the subcommand to be used to create a password record is different from
changing one which is confusing for many;
people often confuse creation/modification of an account record (pdbtool)
and corresponding operations on password records (au) - these commands
modify separate databases! note also that the account must be created
prior to creation of the corresponding password record.

cfs needs a[dministration] privileges on the directories where you modify acls
for the token of the local uid running cfs.

Hmm this informaion actually should go to the Wiki - or is it there somewhere?
If not - feel free to move it there...

As you see, this is far from pretty. On the other side this works, is
fairly scalable for many users and groups and is possible to automate
(which of course we do at Aetey).

Regards,
Rune