Univention Bugzilla – Bug 26013
samba4-idmap.py Traceback beim Anlegen/Löschen eines Benutzers
Last modified: 2012-12-13 17:30:29 CET
Ich hatte zu Testzwecken einen Benutzer immer wieder angelegt und gelöscht. Irgendwann gab es dann beim Anlegen folgenden Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 210, in handler rename_or_modify_idmap_entry(old_sambaSID, new_sambaSID, new_xid, xid_type) File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 82, in rename_or_modify_idmap_entry record = res.msgs[0] IndexError: list index out of range und beim Löschen folgenden Traceback: Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 230, in handler remove_idmap_entry(old[sidAttribute][0], old_xid, xid_type) File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 175, in remove_idmap_entry record = res.msgs[0] IndexError: list index out of range Auffällig hier, obwohl der Benutzer nach dem Löschen im LDAP nicht mehr existiert, ist er noch im Listener Cache.
Created attachment 4144 [details] listener cache
Created attachment 4145 [details] listener log
Der Benutzer was uid=fb1.
Created attachment 4732 [details] Patch gegen UCS 3.0-2
Es lag Nahe, das im Zuge von Bug 28643 mit zu fixen. Fehler beim idmap-Handling können schwer erkennbare Fehlersituationen verursachen.
OK, funktioniert.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".
Ich hatte das gerade an Ticket#: 2012121221000591 auf einem UCS@school 3.0-2 singlemaster. Dort waren die mappings diverser (aller?) importierten Schüler falsch. Ein vermutlich in einem extra Schritt importierter Testbenutzer (evtl. über die UMC angelegt) hatte ein korrektes Mapping. Aufgefallen war dass da die Benutzer nicht auf ihre Homes zugreifen konnten: root@server-01:~# smbclient -Ux.y%12345 //server-01/x.y -c dir NT_STATUS_ACCESS_DENIED listing \* 1373227556 blocks of size 1024. 1296049548 blocks available Mit Samba Debuglevel 9 sieht man dann: --- log.samba set_conn_connectpath: service x.y, connectpath = /home/x.y [2012/12/13 16:43:08.769653, 1, pid=29349] ../source3/smbd/service.c:881(make_connection_snum) 10.16.1.2 (ipv4:10.16.1.2:41589) signed connect to service x.y initially as user SCHULE+x.y (uid=3000048, gid=5050) (pid 29349) --- root@server-01:~# univention-ldapsearch -xLLL uid=x.y sambaSid uidNumber dn: uid=x.y,cn=schueler,cn=users,ou=asr,dc=schule,dc=local uidNumber: 3340 sambaSID: S-1-5-21-1308044329-1928286745-2719287728-7680 root@server-01:~# ldbsearch -H /var/lib/samba/private/idmap.ldb cn=S-1-5-21-1308044329-1928286745-2719287728-7680 xidNumber # record 1 dn: CN=S-1-5-21-1308044329-1928286745-2719287728-7680 xidNumber: 3000048 # returned 1 records # 1 entries # 0 referrals Workaround: cp /var/lib/samba/private/idmap.ldb /var/lib/samba/private/idmap.ldb_univention-support-20121213 /etc/init.d/univention-directory-listener stop /usr/lib/univention-directory-listener/system/samba4-idmap.py --direct-resync /etc/init.d/univention-directory-listener start