Description of problem: system-config-users crashes with non-helpful error message. Version-Release number of selected component (if applicable): system-config-users-1.2.58-1.fc7.src.rpm How reproducible: For me, it is 100% reproducable. Steps to Reproduce: 1. type system-config-users<cr> Actual results: [root@ancho ~]# system-config-users Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/usr/share/system-config-users/mainWindow.py", line 238, in __init__ self.userWin = userWindow.userWindow(self, self.userStore, self.groupTreeView, xml, selinuxEnabled) File "/usr/share/system-config-users/userWindow.py", line 68, in __init__ uidNumber, gidNumber = userGroupFind.find_uid_gid (self.parent.ADMIN, self.parent.preferences) File "/usr/share/system-config-users/userGroupFind.py", line 48, in find_uid_gid uidNumbers = map (lambda x: x[libuser.UIDNUMBER][0], filter (lambda x: x[libuser.USERNAME][0] not in high_uid_ignore, lu_admin.enumerateUsersFull ())) File "/usr/share/system-config-users/userGroupFind.py", line 48, in <lambda> uidNumbers = map (lambda x: x[libuser.UIDNUMBER][0], filter (lambda x: x[libuser.USERNAME][0] not in high_uid_ignore, lu_admin.enumerateUsersFull ())) KeyError: 'no such attribute defined for this entity' Expected results: I expected a gui window to pop up. Additional info: Someone that understands what this code is trying to say might want to send me a version with extra printf's around the failing code that prints the bad line from the password file. I'd expect this code not to exit even if some password file entries are empty. This is a bit of an over-reaction. If it does need to exit it would hopefully print a more meaningful error message that includes the failing data from the file it was parsing.
The problem with that line is that it deals with the whole number of users at once. The KeyError above probably means that either the username or uid number is missing from a user's entry. I've checked in a slightly changed version of the above code to make debugging easier into upstream CVS. You can check out the CVS version like this: cvs -z4 -d :pserver:anonymous.com:/usr/local/CVS co system-config-users It'd be helpful if you could run that version (change to the src/ directory, run ./system-config-users.py as root) and post the traceback which should show better what exactly fails. If you could attach a sanitized version of your /etc/passwd and /etc/shadow (e.g. replace password with "<password>", mark the attachment as "private"), that would be great as well.
NB: that command is one line
root@ancho src]# pwd /root/system-config-users/src [root@ancho src]# ./system-config-users.py (system-config-users.py:4115): libglade-WARNING **: Couldn't find image file: user_add.png (system-config-users.py:4115): libglade-WARNING **: Couldn't find image file: group_add.png (system-config-users.py:4115): libglade-WARNING **: Couldn't find image file: user_conf.png (system-config-users.py:4115): libglade-WARNING **: Couldn't find image file: user_del.png Traceback (most recent call last): File "./system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/root/system-config-users/src/mainWindow.py", line 238, in __init__ self.userWin = userWindow.userWindow(self, self.userStore, self.groupTreeView, xml, selinuxEnabled) File "/root/system-config-users/src/userWindow.py", line 68, in __init__ uidNumber, gidNumber = userGroupFind.find_uid_gid (self.parent.ADMIN, self.parent.preferences) File "/root/system-config-users/src/userGroupFind.py", line 53, in find_uid_gid uidNumbers = map (lambda x: x[libuser.UIDNUMBER][0], usersNotHidden) File "/root/system-config-users/src/userGroupFind.py", line 53, in <lambda> uidNumbers = map (lambda x: x[libuser.UIDNUMBER][0], usersNotHidden) KeyError: 'no such attribute defined for this entity' [root@ancho src]# I've tried to attached sanitized versions of the passwrd,group,shadow files. I'm pretty sure the password file was a mistakenly restored file from the fc6 filesystem. I was just trying to use system-config-users to have a peek before blowing it away and getting the clean fc7 password files from a twin system that has had all the same packages installed in the same order. I didn't immediately see how to mark the attachments as secret. It shouldn't matter much. Only ssh with RSA passwords is allowed here.
I've marked the attachments as "private" now.
Line #4 in the shadow file has no counterpart in /etc/passwd, you might want to remove it as a workaround. I still plan to do something about the robustness of system-config-users, though.
Thanks for the workaround. Reverting to a clean password file did the trick. I'm now seeing a different problem on my other x86_64 fc7 machine. This problem is also shared by yum, which also errors out with a similar cryptic error msg pointing to a problem with a lock error. This problem seems to occur on the main server when it is up for more than 6 hours. Selinux is set to "permissive". As a work around I'll try to set it to disabled. [root@arbol ~]# system-config-users rpmdb: Lock table is out of available locker entries rpmdb: Unknown locker ID: 7db error: db4 error(22) from db->close: Invalid argument error: cannot open Packages index using db3 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/usr/share/system-config-users/mainWindow.py", line 236, in __init__ selinuxEnabled = self.isSELinuxEnabled() File "/usr/share/system-config-users/mainWindow.py", line 869, in isSELinuxEnabled if self.isSELinuxInstalled(): File "/usr/share/system-config-users/mainWindow.py", line 863, in isSELinuxInstalled mi = ts.dbMatch('name', 'policy-sources') TypeError: rpmdb open failed [root@arbol ~]#
At that point, system-config-users tries to check if the policy-sources package is installed. Apparently there is a problem with your RPM DB -- you might want to try rebuilding it ("rpm --rebuilddb").
I have a similar problem (error messages are slightly different, problem here seems to be GID-related): # system-config-users Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/usr/share/system-config-users/mainWindow.py", line 238, in __init__ self.userWin = userWindow.userWindow(self, self.userStore, self.groupTreeView, xml, selinuxEnabled) File "/usr/share/system-config-users/userWindow.py", line 68, in __init__ uidNumber, gidNumber = userGroupFind.find_uid_gid (self.parent.ADMIN, self.parent.preferences) File "/usr/share/system-config-users/userGroupFind.py", line 61, in find_uid_gid gidNumber = find_gid (lu_admin, preferences, preferences['PREFER_SAME_UID_GID'] and uidNumber or None) File "/usr/share/system-config-users/userGroupFind.py", line 77, in find_gid gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) File "/usr/share/system-config-users/userGroupFind.py", line 77, in <lambda> gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) KeyError: 'no such attribute defined for this entity'
(In reply to comment #11) > I have a similar problem (error messages are slightly different, problem here > seems to be GID-related): I encountered the same bug as Andre. It is the exact problem above, but this time the extra entry was in /etc/gshadow. I located that entry, removed it and the problem was gone. However, system-config-users crashing everytime it finds an unmatched entry is /etc/shadow and /etc/gshadow is still an annoying bug, specially if you edit these files manually.
Version 1.2.59 is building right now in Rawhide which should contain fixes for your problem. As it's a noarch package, it shoud be no problem to install it on an F7 system for testing.
Version 1.2.60 is building for F7 updates-testing, please test it once it hits the mirrors.
(In reply to comment #13) > Version 1.2.59 is building right now in Rawhide which should contain fixes for > your problem. As it's a noarch package, it shoud be no problem to install it on > an F7 system for testing. I just checked back and the mirrors now had the ystem-config-users-1.2.59-1.fc8.src.rpm version. Here are the results for that: [root@arbol ~]# system-config-users Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/usr/share/system-config-users/mainWindow.py", line 238, in __init__ self.userWin = userWindow.userWindow(self, self.userStore, self.groupTreeView, xml, selinuxEnabled) File "/usr/share/system-config-users/userWindow.py", line 68, in __init__ uidNumber, gidNumber = userGroupFind.find_uid_gid (self.parent.ADMIN, self.parent.preferences) File "/usr/share/system-config-users/userGroupFind.py", line 72, in find_uid_gid gidNumber = find_gid (lu_admin, preferences, preferences['PREFER_SAME_UID_GID'] and uidNumber or None) File "/usr/share/system-config-users/userGroupFind.py", line 88, in find_gid gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) File "/usr/share/system-config-users/userGroupFind.py", line 88, in <lambda> gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) KeyError: 'no such attribute defined for this entity' [root@arbol ~]# rpm -qi system-config-users Name : system-config-users Relocations: (not relocatable) Version : 1.2.59 Vendor: Fedora Project Release : 1.fc8 Build Date: Wed 27 Jun 2007 02:00:03 AM PDT Install Date: Mon 02 Jul 2007 08:40:45 AM PDT Build Host: xenbuilder2.fedora.redhat.com Group : Applications/System Source RPM: system-config-users-1.2.59-1.fc8.src.rpm Size : 1456143 License: GPL Signature : (none) Packager : Fedora Project URL : http://fedoraproject.org/wiki/SystemConfig/users Summary : A graphical interface for administering users and groups Description : system-config-users is a graphical utility for administrating users and groups. It depends on the libuser library. [root@arbol ~]# I can't find the updates-testing version yet.
system-config-users-1.2.60-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #16) > system-config-users-1.2.60-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. "yum --enablerepo=updates-testing list system-config-users" doesn't show it. Am I using the command? Its been a few days so I'm wondering if I'm not understanding where it is supposed to show up.
I see 1.2.60 in updates-testing with the command you tried. Perhaps your mirror is a bite late with synchronizing the repositories? If all else fails, you can comment out the "mirrorlist" directive for updates-testing and enable ("comment in"?) the "baseurl" directive, but ensure to undo that change as you don't want to always pull from the master.
system-config-users-1.2.60-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
I just tested it after the yum update and I still see some bail-outs without a good indication as to why it bailed. from rpm -qi: system-config-users-1.2.60-1.fc7 [root@arbol ~]# system-config-users Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/usr/share/system-config-users/mainWindow.py", line 238, in __init__ self.userWin = userWindow.userWindow(self, self.userStore, self.groupTreeView, xml, selinuxEnabled) File "/usr/share/system-config-users/userWindow.py", line 68, in __init__ uidNumber, gidNumber = userGroupFind.find_uid_gid (self.parent.ADMIN, self.parent.preferences) File "/usr/share/system-config-users/userGroupFind.py", line 72, in find_uid_gid gidNumber = find_gid (lu_admin, preferences, preferences['PREFER_SAME_UID_GID'] and uidNumber or None) File "/usr/share/system-config-users/userGroupFind.py", line 88, in find_gid gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) File "/usr/share/system-config-users/userGroupFind.py", line 88, in <lambda> gidNumbers = map (lambda x: x[libuser.GIDNUMBER][0], filter (lambda x: x[libuser.GROUPNAME][0] not in high_gid_ignore, lu_admin.enumerateGroupsFull ())) KeyError: 'no such attribute defined for this entity' [root@arbol ~]#
Hmm, would have been good if we caught this in updates-testing...
updates-testing must be the worlds slowest build system. I checked for the update on 2007-7-2 and several times after that. There was never anything there to test. After several iterations of that I decided if redhat wants me to test it they will send me mail *after* the program actually is available for testing.
Wolfgang, I guess you blame the wrong party... If you pull from mirrors (which is done with the usual configuration), you always have a lag between when the files are published on the master and when the mirrors syncs. Sometimes mirrors even sync from other mirrors which makes this even worse. However, neither Red Hat nor the Fedora Project as a whole has any influence on that. In the case of updates-testing, directly pulling from the master as I described in comment #18 should have worked for you as the files were definitely published on the master at that point. If it wouldn't have worked you could have pinged me and I would have tried my best to help you. That's water down the bridge, though ;-). I've (hopefully) come up with a fix and to verify this one, please pull the source directly from the upstream repo (you need to have mercurial installed for that): hg clone http://hg.fedoraproject.org/hg/hosted/system-config-users Then change into the system-config-users/src directory and run "./system-config-users.py" as root. Please report back whether this fixes things.
Wolfgang, have you already had a chance to test the fix? Or do you feel more comfortable testing whole packages -- in this case I would bake one for updates-testing and post a link to it here.
The current version (system-config-users-1.2.60-1.fc7) handles spurious entries in /etc/shadow perfectly, with a very informative message. But it barfs on spurious entries in /etc/gshadow. Also, the version in the upstream repo still barfs for me: [root@hamlet src]# ./system-config-users.py ... can't find image errors removed ... Traceback (most recent call last): File "./system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 269, in __init__ self.refresh() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 436, in refresh consistent = self.refresh_users() and self.refresh_groups() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 357, in refresh_groups gidNumber = group.get (libuser.GIDNUMBER)[0] IndexError: list index out of range
Here is the result from running the most current *.py file from mercurial (of a few seconds ago.) ./system-config-users.py (system-config-users.py:19324): libglade-WARNING **: Couldn't find image file: user_add.png (system-config-users.py:19324): libglade-WARNING **: Couldn't find image file: group_add.png (system-config-users.py:19324): libglade-WARNING **: Couldn't find image file: user_conf.png (system-config-users.py:19324): libglade-WARNING **: Couldn't find image file: user_del.png Traceback (most recent call last): File "./system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 269, in __init__ self.refresh() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 436, in refresh consistent = self.refresh_users() and self.refresh_groups() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 357, in refresh_groups gidNumber = group.get (libuser.GIDNUMBER)[0] IndexError: list index out of range
I've committed a fix that catches IndexError in these situations to Hg, would you please try it again? Thanks.
$ hg up 0 files updated, 0 files merged, 0 files removed, 0 files unresolved This is in a directory crated via: hg clone http://hg.fedoraproject.org/hg/hosted/system-config-users
Strange. The exception should have been caught, but I still get: [root@hamlet src]# ./system-config-users.py Traceback (most recent call last): File "./system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 269, in __init__ self.refresh() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 436, in refresh consistent = self.refresh_users() and self.refresh_groups() File "/home/gdvieira/devel/system-config-users/src/mainWindow.py", line 357, in refresh_groups gidNumber = group.get (libuser.GIDNUMBER)[0] IndexError: list index out of range
(In reply to comment #28) > $ hg up > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved You have to run: $ hg pull $ hg up
Nils, I did this and it worked (its not a fix, just an experiment): --- a/src/mainWindow.py Thu Jul 19 18:14:24 2007 +0200 +++ b/src/mainWindow.py Thu Jul 19 13:30:53 2007 -0300 @@ -355,7 +355,7 @@ class mainWindow: # /etc/group <-> /etc/gshadow inconsistency canary try: gidNumber = group.get (libuser.GIDNUMBER)[0] - except KeyError, IndexError: + except IndexError: consistent = False self.group_dict[groupName] = group
Created attachment 159595 [details] Fix for Hg tip. *Here* is the fix. Seems like confusing Python syntax.
ok, using both hg pull and hg up got me two new files. Running system-config-users.py I still get errors that don't include the datum that it is objecting to. ./system-config-users.py (system-config-users.py:20599): libglade-WARNING **: Couldn't find image file: user_add.png (system-config-users.py:20599): libglade-WARNING **: Couldn't find image file: group_add.png (system-config-users.py:20599): libglade-WARNING **: Couldn't find image file: user_conf.png (system-config-users.py:20599): libglade-WARNING **: Couldn't find image file: user_del.png Traceback (most recent call last): File "./system-config-users.py", line 46, in <module> mainWindow.mainWindow() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 269, in __init__ self.refresh() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 436, in refresh consistent = self.refresh_users() and self.refresh_groups() File "/u/src/system-config-users/system-config-users/src/mainWindow.py", line 357, in refresh_groups gidNumber = group.get (libuser.GIDNUMBER)[0] IndexError: list index out of range
Wolfgang, You can pull & update in one go with "hg pull -u". The libglade warnings are to be expected when running out of the source tree. Gustavo, thanks for spotting this, I really forgot the parentheses around the list of exception types to catch. I think I only need to catch IndexError in these instances and I've done this in the repo. Pleas try if this fixes the problem.
Better. It now starts up and presents the add/del user and add/del groups screens. One minor wart, it doesn't print the name or ID-number that it is objecting to. That makes the reequest to "please fix" a bit challenging without writing a different homegrown script. "I couldn't figure out the numerical ID for one or more users or groups. In most cases this is caused by inconsistencies in the user or group database, e.g. between the files /etc/passwd, /etc/group and their respective shadow files /etc/shadow and /etc/gshadow. I will try to ignore these entries and continue for now, but please fix these inconsistencies as soon as possible."
Please check the current repo code, it should list the offending users and/or groups if it find inconsistencies.
"finds" even...
Looking good! It finds and reports valid inconsistencies. The inconsistencies are benign, so I'll leave them for a while in case you want me to do more testing. In my case there were a few extra entries left in /etc/gshadow that had been removed from /etc/group.
Building system-config-users-1.2.61 which should hit updates-testing shortly. Please test this one.
system-config-users-1.2.61-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
Fixed for me in system-config-users-1.2.61, both for /etc/shadow and /etc/gshadow. Thanks!
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping