Univention Bugzilla – Full Text Bug Listing |
Description
Sönke Schwardt-Krummrich
2010-09-20 10:26:18 CEST
Erneut an Ticket #2012051621002077 gemeldet. UCS 2.4-3 An oben erwähntem Ticket wurde der Benutzer allerdings entfernt, nicht hinzugefügt. Traceback (most recent call last): File "/usr/share/univention-webui/modules/requests.py", line 272, in run_request self.dialog.apply() File "./unidialog.py", line 615, in apply self.mod.apply() File "/usr/share/univention-directory-manager/uniconf/modwizard.py", line 1703, in apply object.remove(remove_childs) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py" , line 430, in remove return self._remove(remove_childs) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py" , line 852, in _remove self._ldap_pre_remove() File "/usr/lib/python2.4/site-packages/univention/admin/handlers/users/user.p y", line 2785, in _ldap_pre_remove self.sid=self.oldattr['sambaSID'][0] KeyError: 'sambaSID' (In reply to comment #2) > An oben erwähntem Ticket wurde der Benutzer allerdings entfernt, nicht > hinzugefügt. Bitte mal prüfen: Der Traceback kommt auch, wenn das zu entfernende Benutzerobjekt im LDAP gar nicht existiert. Tritt das mit UCS 3 noch auf? (In reply to Stefan Gohmann from comment #4) > Tritt das mit UCS 3 noch auf? yes Der Traceback ist an Bug 35759 erneut aufgetreten. Echtes Problem ist hier, dass im Exception-Handler beim Aufräumen wieder eine Exception auftritt. Und das tut sie zuverlässig, wenn das ldap_add nicht funktioniert hat. Damit wird die eigentliche Exception überlagert und man hat keine Ahnung, wo und warum der ursprüngliche Fehler aufgetreten ist. Die remove() Funktion muss noch vor dem Aufruf von pre_remove() prüfen, ob das Objekt überhaupt im LDAP existiert. Ansonsten sollte sie einfach nichts machen. Außerdem sollte der Exception-Handler kein "raise e" sondern ein einfaches "raise" ausführen, um die gefangene Exception nach dem Aufräumen nach oben durchzuwerfen. (In reply to Florian Best from comment #5) > (In reply to Stefan Gohmann from comment #4) > > Tritt das mit UCS 3 noch auf? > yes Also seen with UCS-4 Reported again. Reported again, 3.2-4 errata247 (Borgfeld) Created attachment 6593 [details]
patch
patch:
* raise noObject again when the object does not exists
* log exceptions which occur during reverting the changes
* preserve traceback of original exception
@Sönke: what do you think about the patch?
Enhanced patch has been applied in svn r57502. YAML: 2015-01-22-univention-directory-manager-modules.yaml Package: univention-directory-manager-modules Version: 10.0.29-19.1283.201501221644 Branch: ucs_4.0-0 Scope: errata4.0-0 no cross dependencies. This does not work. Just "raise" seems correct, but it will actually reraise the cancel/remove error (if any). Furthermore, where is this logged? I have totally messed up _ldap_post_create() and cancel(). But I only have Post-Create operation failed: Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 790, in _create self._ldap_post_create() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/users/user.py", line 1878, in _ldap_post_create if 'samba' in self.option: AttributeError: 'object' object has no attribute 'option' in /var/log/univention/directory-manager-cmd.log. I would also doubt that this is the whole stack. UDM itself now reports an error in remove(). Is remove safe to be called when cancel() raised? So far, cancel() is defined to remove allocated objects. If this not work somehow, should the object be removed? Ok, reraising is now fixed (package currently builds). Also the loglevel for the subexceptions have been lowered to be always logged. For the rest: make sure you do 'pkill -f univention-cli-server' after changing files and make sure you don't use objects which have a lock when testing. OK, works as expected. Reported again, 3.2-6 errata344 (Borgfeld) (In reply to Florian Best from comment #16) > Reported again, 3.2-6 errata344 (Borgfeld) same UUID again. |