The process of adding a user is a bit messy right now (we are working on
much improved handling of this).

First you must add the user to user.coda, and possibly groups.coda (see
user_coda (5) and groups_coda(5).  Then you rebuild the pdb with pwd2pdb.

Finally, you call au as you did to set the password for the new user.

The only thing to remember about this is that Coda has a separate
group/user database (the vice.pdb) which is manually generated from the
user and group file.  A server, called the Yale Protection Server (ala pts
in AFS) is forthcoming. 

The passwords are in another database (auth2.pw) and those are accessible
with a client/server system.  clog and au are our clients, and the server
is auth2. 

The fileserver needs access to the pdb file to check acls but does never
contact the auth2.pw file. 

Thanks for all your inquisitive questions!

- Peter -



On Sat, 18 Jul 1998 bwoodard_at_cisco.com wrote:

> Ok the day has come, I have to let someone else use my coda system but I am
> having trouble adding a user.
> 
> What could be going wrong here:
> 
> [bwoodard_at_trill auth2]$ /usr/sbin/au -h gemini nu
> Your Vice name: bwoodard
> Your password:
> RPC2_Bind() --> RPC2_SUCCESS
> Vice user: nina
> New password: foobar
> New info: Nina Woodard
> AuthNameToId() --> AUTH_FAILED
> 
> The I thought that it might that I was not part of the sysadmin group
> but when I double checked:
> 
> [root_at_k2-test-jdex db]# cat group.coda
> System:Administrators   -204    admin bwoodard
> 
> I even tried doing it as the user admin and it didn't work.
> 
> Where should I look as the next place where the authorization might be
> failing?
> 
> The authlog is adding this informatin:
> 
> 19:25:50 In PWGetKeys()
> 19:25:50        vid = 1001
> 19:25:50 AuthNewConn(0x16, 0, 66, 2, 1001)
> 
> but I don't really know what it means.
> 
> -ben
>