With nsvs installed on a system with a large number of groups, some large (more than 15 members), any utility based on getgrent was failing to show the first large group encountered, and the last group. Other group functions are not affected. So, for example, "id <user>", works fine, but "getent group" or "groups user" do not work correctly. The reason for this appears to be iterating the grent record (and/or the grent_rec counter) before returning with an EXHAUSTED_BUFFER/RETRY. To correct this behavior, I had to add a buffer exhaustion check prior to loading the member list, and add code to decrement grent.cur_rec before returning a RETRY error. (There are essentially 2 bugs in the nsvsd getgrent function) Also, the current reconnect behavior didn't seem to have any effect with our old (4.0.x) mysql client libraries, so I've also included a patch to manually attempt a reconnect. I've posted these patches to the fssos-users mailing list, but, given the unmaintained state of this project, I don't know whether they'll get into CVS. If they do not, I wanted to make sure they can be added to the ebuild, as they're fairly important. I've been running these patches on an amd64 gentoo linux test server without any issues for a week or so now. Reproducible: Always Steps to Reproduce: 1. Create a large group with more than 15 members in your SQL backend 2. Run 'getent group' Actual Results: As long as your group was large enough to prompt an "exhausted buffer" when loading the member list, it fails to appear in the output list. Expected Results: All groups defined in the SQL tables should show up in the list of groups
Created attachment 170244 [details, diff] Multiple getgrent fixes
Created attachment 170245 [details, diff] Manual reconnect code
Thanks for submitting your fixes! You're right that upstream seems a little stale to say the least, and the mailing list seems pretty crowded with spam :( Assigning to ebuild maintainer.
Already treecleaned
