Univention Bugzilla – Bug 34246
Could not find a matching UDM module for the LDAP object
Last modified: 2015-10-14 12:27:47 CEST
we received the following Traceback on 3.2-1 errata66 (Borgfeld): File "/usr/lib/pymodules/python2.6/notifier/threads.py", line 82, in _run tmp = self._function() File "/usr/lib/pymodules/python2.6/notifier/__init__.py", line 104, in __call__ return self._function( *tmp, **self._kwargs ) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py", line 372, in _thread raise UMC_OptionTypeError( _( 'Could not find a matching UDM module for the LDAP object %s' ) % ldap_dn ) UMC_OptionTypeError: Could not find a matching UDM module for the LDAP object uid=****,cn=users,dc=****,dc=eu The error happens when saving a object. I could not reproduce this. When removing all necessary object classes from a object it is not anymore visible in UMC.
A system with the same UCS version reported the following traceback: Traceback: File "/usr/lib/pymodules/python2.6/notifier/threads.py", line 82, in _run tmp = self._function() File "/usr/lib/pymodules/python2.6/notifier/__init__.py", line 104, in __call__ return self._function( *tmp, **self._kwargs ) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py", line 491, in _thread result = module.search( request.options.get( 'container' ), request.options[ 'objectProperty' ], request.options[ 'objectPropertyValue' ], superordinate, scope = request.options.get( 'scope', 'sub' ), hidden=request.options.get('hidden') ) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/udm_ldap.py", line 155, in wrapper_func ret = func( *args, **kwargs ) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/udm_ldap.py", line 440, in search result = self.module.lookup( None, ldap_connection, filter_s, base = container, superordinate = superordinate, scope = scope, sizelimit = sizelimit ) AttributeError: 'NoneType' object has no attribute 'lookup' If there is a object which cannot be identified as UDM object this traceback will occur along with the search query. Such a request can also be triggered by a request with a not-existing flavor.
I could reproduce the first traceback: Save an object which has been deleted e.g. on CLI → maybe we should first check if the object still exists before saving it. I could also reproduce the second traceback: Open the LDAP-directory and enter a invalid value into the LDAP-objecttype field and press search. → The form validation is missing Both aren't critical bugs and shouldn't occur often.
(In reply to Florian Best from comment #2) > I could also reproduce the second traceback: > Open the LDAP-directory and enter a invalid value into the LDAP-objecttype > field and press search. > → The form validation is missing > Bug#28383
First traceback raise UMC_OptionTypeError( _( 'Could not find a matching UDM module for the LDAP object %s' ) % ldap_dn ) reported again. Remark: eine Gruppe hinzugefügt We need to check the existance of the DN and give a meaningful error message. Could be caused by: Renaming the object (e.g. username) Moving the object into another container Deleting the object
* Added check for existence of dn in __init__.py/put(), also added error msg if dn is missing
Maybe the error message should contain a hint for the end user (See comment #4) ?
(In reply to Florian Best from comment #6) > Maybe the error message should contain a hint for the end user (See comment > #4) ? Instead of: > Could not find LDAP object: %s We could say: > LDAP object %s could not be found. This may be caused by the object having been > renamed, moved or deleted. Please update the list view and try to re-open the > object. Similarly: > LDAP object exists, but cannot be opened: %s We could say something like: > LDAP object %s exists, but cannot be opened. This may be caused by an > unsupported UDM object type. In case new software components have been > installed recently, please make sure that all necessary packages have been > installed correctly. I am not sure which other cases could trigger this error (i.e., the object exists with the given DN, yet a corresponding UDM module cannot be found). Otherwise, the error handling works fine. (I needed to build the package.) YAML file is missing.
Could you have a look at the following behaviour: I can rename a user via the CLI and when opening it in UMC (still with its old name), no error is shown and an empty detail page is opened.
*** Bug 35281 has been marked as a duplicate of this bug. ***
In order not to block the release of Bug 34200, Bug 34092, Bug 34093, I reverted the last svn commit. univention-management-console-module-udm (4.0.97-28): * Bug #34246: reverted commit r50381
Reported again
Reported again.
Created attachment 6104 [details] patch This is an attempt to make the error message more understandable
(In reply to Drees Dormann from comment #13) > Created attachment 6104 [details] > patch > > This is an attempt to make the error message more understandable Could you please check the following points: * DetailPage.loadedDeferred is referenced in NewObjectDialog and CreateWizard. I guess that a call to DetailPage.ready() should do it there, as well. Have you checked creating a new object with theses changes? * What happens when you try to remove an object that does not exist anymore? * AFAIS, there is no need to pass the reference to the request object and call self.finished() in report_dn_error(). Throwing an exception (e.g., of the type UMC_OptionTypeError) should be a more consistent with the rest of the code. * As for the changes in udm_ldap.py, one if-statement should be fine, à la: > if mod and self.name == mod.name and self.is_policy_module():
UCS 4.0-0: UMC_OptionTypeError: Could not find a matching UDM module for the LDAP object cn=mail,cn=dc,cn=computers,dc=netqa,dc=local
I overtake this bug as I am working on similar things ;)
(In reply to Florian Best from comment #17) > I overtake this bug as I am working on similar things ;) Well, not exactly.
*** Bug 24620 has been marked as a duplicate of this bug. ***
*** Bug 24742 has been marked as a duplicate of this bug. ***
*** Bug 26977 has been marked as a duplicate of this bug. ***
4.0-0 errata0 (Walle) UMC_OptionTypeError: Es konnte kein UDM-Modul für das übergeordnete Objekt zoneName=****.***.com,cn=dns,dc=office,dc=****,dc=com gefunden werden
Drees: instead of using the function report_dn_error you can define a Exception which does that job and implement __str__() there and just raise it ;)
svn r56601 broke some things: ./udm/__init__.py:399: undefined name 'ObjectDoesNotExists' ./udm/__init__.py:581: redefinition of unused 'reports_query' from line 568 ./udm/__init__.py:585: redefinition of unused 'sanitize_reports_create' from line 572 Some functions were duplicated. The method _error_msg() in the class LDAP_AuthenticationFailed was removed. ObjectDoesNotExists was renamed to ObjectDoesNotExist → please rename back to "ObjectDoesNotExists" (with trailing s). The LDAP search does not work in this way. It searches for cn=name of the ldap dn part. but cn=name can exists more often than once in the LDAP. At least you have to change the search scope of the ldap search to one and the search position to the rest of the exploded dn. (maybe there is a better solution to check if a LDAP dn exists).
Please also fix the following comment: (In reply to Alexander Kramer from Bug #29231 comment #12) > (In reply to Florian Best from comment #10) > > If no UDM module for the LDAP DN can be detected the function does not raise > > this exception anymore. > > That is true, there isn't a traceback anymore. But I would expect a dialog > box that would please me to relead the view, because the object wasn't found > or something like this. Instead I got a blank ldap page (see screenshot) > which is quit confusing.
opening a nonexistent object will now trigger an error message explaining the situation instead of raising an exception. The user will then be returned to the orignating page instead of opening a blank Detail Page. Also searching for an invalid object type will not raise an exception anymore. (r56634)
Please make the following adjustments: * Instead of suggesting a reload of UMC(-server) adjust to relogin into UMC. * Move the above mentioned sentence to the "Could not identify the LDAP object type for %s." sentence. As it belongs there. * Currently for superordinate objects the message is not detailed, like the own for "object not found".
adjustments have been made, also fixed broken function ( r56656 )
Created attachment 6522 [details] some text changes + typos fixed Some little changes are required, see the attached patch. The german translation also contains some typos (missing spaces and dots): Das LDAP-Objekt cn=blub,dc=ucs,dc=dev konnte nicht geöffnet werden Es wurde vermutlich gelöscht oder verschoben. Bitte erneuern Sie ihreSuchergebnisse und versuchen Sie das Objekt erneut zu öffnen. Wenn das Problem bestehen bleibt versuchen Sie bitte die Univention Management Console neuzustarten. umc-command -U Administrator -P univention udm/get -f navigation -e -o '["cn=blub,dc=ucs,dc=dev"]' umc-command -U Administrator -P univention udm/put -f navigation -e -o '[{"object":{"$dn$": "cn=blub,dc=ucs,dc=dev"}}]'
this has been fixed
The search for the object of the LDAP DN is error prone. It can raise a bad search filter exception if the name contains an invalid character (e.g. '('). It is better to use this code snipped: exists = True try: ldap_connection.get(self.ldap_dn, required=True) except udm_errors.noObject: exists = False
(In reply to Florian Best from comment #31) > The search for the object of the LDAP DN is error prone. It can raise a bad > search filter exception if the name contains an invalid character (e.g. '('). > > It is better to use this code snipped: > > exists = True > try: > ldap_connection.get(self.ldap_dn, required=True) > except udm_errors.noObject: > exists = False → err, the exception is ldap.NO_SUCH_OBJECT. Maybe better: exists = bool(ldap_connection.get(self.ldap_dn))
Reported again, 4.0-0 errata10 (Walle) cn=SERVER.foo.local,cn=dc,cn=computers,dc=foo,dc=local
code has been adapted according to the proposal (r 56868)
This looks nice now. OK: moving not existing objects. OK: opening not existing objects. OK: removal of not existing objects. OK: objects which exists as LDAP object but not with an univentionObjectType. REOPEN: when editing multiple objects at once with one object which does not exists this does not work.
Multiedit mode will now show an error if one or more objects could not be saved (r 57021)
The detail page is now closed in any error failure. e.g.: "The LDAP object could not be saved: IP address is already in use. 10.200.27.3"
Changed the behaviour so upon an error the DetailPage is closed only if it is in multiedit mode
OK, (did little adaptions).
http://errata.univention.de/ucs/4.0/18.html
Reported again, 3.2-6 errata341 (Borgfeld) Remark: Gruppen hinzufügen
Reported again, 3.2-7 errata372 (Borgfeld)