(Illustration by Gaich Muramatsu)
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 >Received on 1998-07-19 00:20:11