Beautiful! It all seems to work now! Thanks!
Daniel On 11/5/08, Abhishek Kulkarni <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-11-05 at 11:15 -0500, Daniel Gruner wrote: > > Hi Abhishek, > > > > Things are much better now, thanks! There are still some glitches (see > below): > > > Great! > > > > > > > > On 11/4/08, Abhishek Kulkarni <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, 2008-11-04 at 18:20 -0500, Daniel Gruner wrote: > > > > Hey Ab, great stuff! > > > > > > > > With some caveats, though... > > > > > > > > Single user addition now appears to work properly. > > > > > > > > Adding all groups also appears to work, for those groups in the > > > > /etc/group file, as well as the groups available from NIS. > > > > > > > > Adding all users only partly works. I suspect there is an issue with > > > > parsing the passwd file. Also, apparently the software does get the > > > > NIS passwd info in addition to /etc/passwd, but only some of the users > > > > get added and some not. > > > > > > > > > the /etc/passwd file is not parsed directly, the entries are obtained > > > from the passwd database using getpwent(). the users should be added if > > > the user has a key at $PWDIR/.ssh/id_rsa.pub which has read permissions > > > for root. if the home dir for the user is NFS-mounted check if root can > > > read from the key in the user's home dir. > > > > > > > > > > In fact, I got users to add even though their > > > > group was not in the node database (as checked with "xgetent group > > > > n0000"). > > > > > > > > > can you paste the output for > > > xgetent passwd n0000 > > > > > > xgetent group n0000 > > > > Sorry, this was my mistake (things just flew off the screen). > > > > > > > > > > > > > In addition, the "flush" options to xgroupset and xuserset return > errors: > > > > > > > > [EMAIL PROTECTED] sxcpu]# xuserset flush n0000 > > > > xp_user_flush: n0000: Error 5: unknown command > > > > Error: unknown command > > > > > > > > [EMAIL PROTECTED] sxcpu]# xgroupset flush n0000 > > > > xp_group_flush: n0000: Error 5: unknown command > > > > Error: unknown command > > > > > > > > > > > > > no, this works fine. > > > did you update the xcpu module that perceus uses for the slave nodes? > > > It should be in /var/lib/perceus/modules/xcpu, IIRC. > > > > > > > I did now. > > > > It works. > > > > > > > > > Furthermore: xuserset delete n0000 -u appears to work. However, > > > > after doing that, re-adding the root user, showing with xgetent passwd > > > > n0000 that only root and the admin user are there, when I tried > > > > "xgroupset delete n0000 -u" I got a pile of error messages saying that > > > > the groups in question were not empty: > > > > xp_group_del: n0000: Error 5: jockusch:group not empty > > > > xp_group_del: n0000: Error 5: segal:group not empty > > > > > > > > > > > > > yes that looks like a bug. i'll look into this. > > > > This is still giving me an error when I try to delete a single group. > > I was under the impression that if you decide to delete a group it > > would delete all its users too. Did this change? > > > No, it didn't change. It's been like this since long. A group is not > deleted if it has users associated with it. > > > > Regardless, even > > when I delete all the users in a group, manually, when I try to delete > > the individual group I still get the error message that the group is > > not empty. I guess it is just a book-keeping bug that doesn't clean > > up the database when empty... > > > > > this has been fixed in the trunk now. > > > > > > > > > > > > > > > > One more: is it possible to avoid adding the admin-type groups and > > > > users (like lp, nobody, etc)? > > > > > > > > > > > > > the -u switch adds all the groups in the group database. it does not > > > differentiate between admin-type groups and groups you would want. at > > > the most, groups with gids < 500 (maybe 1000?) could be skipped but i am > > > not sure if it would be worth it. > > > > > > thanks again! > > > > > > > I have one more suggestion about filtering users to be added with -u: > > Those users that do not log in, i.e. whose shell is specified as > > /bin/nologin, should not be added. For instance, I got the user > > "operator" added because its passwd entry is: > > > > operator:x:11:0:operator:/root:/sbin/nologin > > > > so it did find a .ssh/id_rsa.pub (the one for root), and so the > > operator user got added. > > > > > > > > > Daniel > > > > > > > > > > > > > > > > > > > > On Tue, Nov 4, 2008 at 4:45 PM, Abhishek Kulkarni <[EMAIL PROTECTED]> > wrote: > > > > > after a few off-the-list exchanges with Daniel, i caught two bugs > with > > > > > xuserset. > > > > > > > > > > 1) the supplied arguments were not parsed properly when trying to > add a > > > > > single user with xuserset. > > > > > > > > > > 2) to add all the users from /etc/passwd, xuserset made a looping > call > > > > > over getpwent() but xp_user_add did a getpwnam() to find the uid for > > > > > xcpu-admin which reset the passwd database causing it to go in an > > > > > infinite loop. > > > > > > > > > > few more structural changes in xuserset & xgroupset. > > > > > > > > > > -- > > > > > Signed-off-by: Abhishek Kulkarni <[EMAIL PROTECTED]> > > > > > > > > > > > > >
