I plan to implement support for the "grplist" Hesiod Type, and would like some advice and/or sanity checks. It seems that the best way is to modify getgrouplist() and make it little more than a call to nsdispatch(), similar to getgrent_r(). I would write backend methods such as files_grplist, dns_grplist, etc. to be called from nsdispatch. My *_grplist methods would need to iterate over their respective databases, essentially calling getgrent but without going through nsswitch. The obvious way to do this without duplicating a lot of code is to call the corresponding methods from getgrent.c, such as files_group. The problem is, they are static methods, and not visible from getgrouplist.c. Could they be [renamed and] exported? Could getgrouplist() be moved into getgrent.c? How else could this problem be solved?
Should the group-%d "compatibility" be retained as a fallback in the absence of a grplist RR for the given user? Are there any sites out there using Hesiod /without/ grplist RRs? There is no real need to remove it, but... Using all configured services to find group memberships seems most logical. Otherwise, where would I stop? Stopping on a "first match" doesn't make sense. Opinions? Thanks in advance, Eric -- Eric van Gyzen Sr. Systems Programmer http://www.stat.duke.edu/~vangyzen/ ISDS, Duke University _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
