Can you retry this on FC3? FC2 is officially end-of-life as of March 15th, with
FC4 test1. You might have some luck if you install gnome-python2 and its
dependencies, though -- s-c-users had some dependencies there which I removed in
version 1.2.32 (so it should run properly without GNOME installed).

OK, trying on my other FC3 box gives exactly same error (w/o libgnome.so
warning). Trying FC4t1 is unfortunately out of question: I have no third box and
FC4t1 is way too alpha to replace older releases (ranting here about fedora
updates QA is here is unproductive so I better stop).

Which version of libuser do you have installed?

libuser-0.52.5-1 - the one that comes with FC3.

Created attachment 112621 [details]
debugging version of userProperties.py

Please try with this debugging version of userProperties.py, as root do this:

- "cd /usr/share/system-config-users"
- make a backup: "mv userProperties.py userProperties.py.orig"
- "cp /path/to/debuggingversion/userProerties.py ."
- "./system-config-users.py"
- double click on a user

min: [] max: [] warning: [] inactive: []
Traceback (most recent call last):
  File "/usr/share/system-config-users/mainWindow.py", line 848, in rowActivated
   self.on_properties_activate()
  File "/usr/share/system-config-users/mainWindow.py", line 747, in
on_properties_activate
    self.user_properties()
  File "/usr/share/system-config-users/mainWindow.py", line 756, in user_properties
    self.userProperties.showUserProperties(userEnt)
  File "/usr/share/system-config-users/userProperties.py", line 232, in
showUserProperties
    if int(min[0]) == 0 and int(max[0]) == 99999 and int(warning[0]) == 7 and
int(inactive[0]) == -1:
IndexError: list index out of range

I found an interesting thing: if an user was added with luseradd, everything is
fine. If the user was added by other means (this is a department-wide user
database), system-config-users fails. When clicking on luser-added user, s-c-u
displays:
min: [0L] max: [99999L] warning: [7L] inactive: [-1L]

Comparing LDAP records for the accounts in question, luseradd creates accounts
with shadowAccount objectClass set while it seems to be unable to handle
ordinary posixAccount ones (i.e. without shadow data supplied).

Should be fixed in system-config-users-1.2.34-0.fc3.1 which should hit
updates-testing shortly. Please verify.

I am confirming that system-config-users-1.2.34-0.fc3.1 can handle
plain "posixAccount"s. BTW, I see that trying to lock a LDAP account
(does not matter whether it is a full shadowAccount or a plain
posixAccount) gives another stacktrace:
Traceback (most recent call last):
  File "/usr/share/system-config-users/userProperties.py", line 524,
in on_ok_button_clicked
    self.parent.ADMIN.modifyUser(self.userEnt)
RuntimeError: error modifying LDAP directory entry: Invalid syntax

BTW, I checked and it is not a problem with libuser because lusermod
can lock and unlock accounts just fine.

Well, I don't know if I concur with your assessment here -- I'm just
calling libuser in the call shown in the trace, so if it fails only on
LDAP and apparently with an (LDAP?) syntax error, the error is likely
in libuser, possibly in the python wrapper.

Miloslav, what do you think?

Created attachment 112717 [details]
debugging version of userProperties.py

Pleasy try with this debugging version of userProperties.py (as described
above). It should dump the relevant user object when opening its dialog and
when saving (i.e. click on OK). Please report back with what it gives on such
an account.

showUserProperties: userEnt.keys (): ['dn', 'pw_name', 'pw_passwd',
'pw_uid', 'pw_gid', 'pw_gecos', 'pw_dir', 'pw_shell', 'sp_lstchg',
'sp_min', 'sp_max', 'sp_warn', 'sp_inact', 'sp_expire', 'sp_flag', 'cn']
on_ok_button_clicked: userEnt.keys (): ['dn', 'pw_passwd', 'pw_uid',
'sp_lstchg', 'sp_flag', 'cn', 'pw_name', 'pw_gecos', 'pw_dir',
'pw_shell', 'pw_gid', 'sp_expire', 'sp_min', 'sp_max', 'sp_warn',
'sp_inact']
Traceback (most recent call last):
  File "/usr/share/system-config-users/userProperties.py", line 527,
in on_ok_button_clicked
    self.parent.ADMIN.modifyUser(self.userEnt)
RuntimeError: error modifying LDAP directory entry: Invalid syntax

(I agree, the problem may be in the python bindings, I just had no
idea the bindings were part of libuser).

OK, there are two separate bugs:
* s-c-users in userProperties.py around line 522 is setting SHADOWINACTIVE to '',
  which is an invalid integer value; it should be set to '-1'.
  (This should make no difference to other cases, the 'files' module automatically
  uses an empty field if the vlaue is -1).
* libuser is incorrectly adding the 'account' objectClass in modify requests
  if any objectClass must be added and the entry doesn't already have an
  'inetOrgPerson' objectClass. This will be fixed in rawhide libuser-0.53.4-1.

I've corrected that error in comment #15 in system-config-users-1.2.35 which
should hit Rawhide and updates-testing soon. I'll change the component to
libuser for the remaining stuff.

libuser-0.53.4-1 should already be in rawhide.
Nils, I understand you'll want it as an FC3 update too?

Pawel's problem is on FC3, so an update there would be good, yes. I'll also do
an update for my part (s-c-users).

Looking at it again...

This would mean updating the FC-3 libuser from 0.52.5 to 0.53.4, which is rather
risky for a bug fix update:
- the private libuser interfaces changed, which would break third-party modules
  (if there are any)
- the public C libuser interface was extended in an ABI-preserving, but not
  failure-mode-preserving way (for ID values >= 2**31).
- the utilities got many bug fixes which change behavior, potentially breaking
  existing scripts.

So, I don't think updating to 0.53.4 for FC-3 would be a good idea.
Backporting the changes is possible, but I think working on fixing bugs
in FC-4 is a better use of the available time. Sorry.

Anyway... I am running 0.53.4 on FC-3 with no apparent issues.
Pawel, if you think none of the above incompatibilies apply to you (no
third-party modules, no {UG}ID values >= 2**31, no bugs in scripts), please use
the rawhide package. This will probably fix the LDAP problem without the
other changes affecting anything - but the risk will be on you as the LDAP
user instead of on all FC-3 users who have s-c-users installed.

Rawhide in this case is fine for me: I think this bug affects limited group of
people and pushing an global update that risks breaking more fundamental
functions is nothing I would like to accept responsibility for.