after using newusers to add 3000 users to our system I then required them to be put into 2 groups one called staff one called users. I generated a list of the usernames to be added to the staff and users groups and did something like for i in `cat userlist` do echo "Processing user $i" usermod -Gstaff,users $i done This should have added all the users in the list to the groups staff and users. what II actually got is shown below (sort of, I'm unable to put the full details in here (........ indicates other userid's on the line) (Sample from /etc/group) users::100:a1000,a1001,a1002........a1678,a1679,a168 0,a1681,a1682,a1683,a1684,a1685...........a2361,a2362,a 2,a999 ,a998 ,a997 ,a996 ,a995 ,a994 ,a993 ,a992 ,a991 ,a990 ,a989 ,a988 ........... and so on for a few hundred lines This obviously breaks the group file. We wish to use linux as a NIS server but if each time we add a user it's going to break the group file we will have to look to an alternate platform as we can't afford for the NIS group file to corrupt each time we add a user. I would guess this is a problem for anyone else who requires large groups so that we can do authentication for groups in samba. This bug was reported for redhat 5.2 as well but I ended up having to write custom scripts of my own that didn't break the group file. It seems as though the passwd and user utilites have some sort of limit (string ?) but when I put all the members of the group onto a single line the system worked fine. Lee
Changing component to shadow-utils as that is where usermod is located. Also forwarding to developer for further action.
*** Bug 3810 has been marked as a duplicate of this bug. *** after using newusers to add 3000 users to our system I then required them to be put into 2 groups one called staff one called users. I generated a list of the usernames to be added to the staff and users groups and did something like for i in `cat userlist` do echo "Processing user $i" usermod -Gstaff,users $i done This should have added all the users in the list to the groups staff and users. what II actually got is shown below (sort of, I'm unable to put the full details in here (........ indicates other userid's on the line) (Sample from /etc/group) users::100:a1000,a1001,a1002........a1678,a1679,a168 0,a1681,a1682,a1683,a1684,a1685...........a2361,a2362,a 2,a999 ,a998 ,a997 ,a996 ,a995 ,a994 ,a993 ,a992 ,a991 ,a990 ,a989 ,a988 ........... and so on for a few hundred lines This obviously breaks the group file. We wish to use linux as a NIS server but if each time we add a user it's going to break the group file we will have to look to an alternate platform as we can't afford for the NIS group file to corrupt each time we add a user. I would guess this is a problem for anyone else who requires large groups so that we can do authentication for groups in samba. This bug was reported for redhat 5.2 as well but I ended up having to write custom scripts of my own that didn't break the group file. It seems as though the passwd and user utilites have some sort of limit (string ?) but when I put all the members of the group onto a single line the system worked fine. Lee
*** Bug 7542 has been marked as a duplicate of this bug. ***
assign to laroche
*** Bug 11930 has been marked as a duplicate of this bug. ***
This is fixed in 19990827-16 (current rawhide). Sorry for the long delay; the bug got assigned to the wrong people for whatever reason.
This is not fixed in 1990827, nor in 20000826. The solution used by the designer was to grow the buffer as needed if the last character inputted by fgets is not a newline. Cool enough. But the patch (hugegroups.patch in the source rpm) assumed that fgets does not put any '\0' at the end when the input buffer limit is reached, which is not the case. The fgets is retried, jumping 8192 bytes in the input buffer. This jumps over the '\0' left by fgets, so information is lost. The fix is available at ftp:/ftp.solucorpqc.ca/pub/misc/shadow-20000826-hugegroups.patch2. This patch works on top of the hugegroups.patch.