Comment 27 for bug 160862

Revision history for this message
Master5597 (master5597) wrote :

update: it's fixed, read more to find out how.

ok i added those lines right before the return in get() in the /usr/share/system-tools-backends-2.0/scripts/GroupsConfig.pm file. although i had to change them to:

&Utils::File::run ("echo Min: " . $$logindefs{"gmin"});
&Utils::File::run ("echo Max: " . $$logindefs{"gmax"});

also i assume you wanted me to add the following line to the Users/Groups.pm file

&Utils::File::run ("echo " . join(".", @a));

the new printed out lines are below:

file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo Min: 100 2> /dev/null > /dev/null].
file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo Max: 60000 2> /dev/null > /dev/null].

the 100 and 60000 are the values from my /etc/login.defs file on both my problem system and my VM test system. my /etc/group file on my trouble system has 73 lines in it and the VM test machine has 72 lines.

the line in the groups.pm file usually prints out:

file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo 2> /dev/null > /dev/null].

now here's where the fun begins. i was looking at what the @a variable was, and found my problem. What i found out is that one of the lines in my groups file for the 'user_list' parameter was separated by a colon instead of a comma. (the spec says it's group members' usernames, comma-separated) i changed it to a comma and re run my test. this time it worked perfectly. so basically an extra colon on a line caused it to barf hard core and take out my my system. the offending line was:

audio:x:29:pulse:username
it should be
audio:x:29:pulse,username

so my guess there was some bad update sometime that mistakenly put in a colon instead of a comma. since this was the line it could have been a audio update? also this box was running jaunty beta before i upgraded it to jaunty, so it could have been a beta bug that didn't auto-correct it self later. but in any case maybe the perl module for reading that file needs some better error control, or maybe have something that verifies the files are up to spec before it reads them. i dunno.

also i found out that my /etc/gshadow file was also being hosed. fixed that now too. :-)

thanks for all your help, if there's anything i can do to help make sure this doesn't happen to someone else, please let me know.