Bug 34246 - Could not find a matching UDM module for the LDAP object
Could not find a matching UDM module for the LDAP object
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Domain management (Generic)
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 4.0-0-errata
Assigned To: Drees Dormann
Florian Best
:
: 24620 24742 26977 35281 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-04 16:39 CET by Florian Best
Modified: 2015-10-14 12:27 CEST (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Error handling, External feedback, Usability
Max CVSS v3 score:


Attachments
patch (34.02 KB, patch)
2014-09-09 16:27 CEST, Drees Dormann
Details | Diff
some text changes + typos fixed (1.77 KB, patch)
2014-12-10 19:24 CET, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2014-03-04 16:39:21 CET
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.
Comment 1 Florian Best univentionstaff 2014-03-04 16:55:16 CET
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.
Comment 2 Florian Best univentionstaff 2014-03-05 10:30:30 CET
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.
Comment 3 Dirk Wiesenthal univentionstaff 2014-03-17 10:52:23 CET
(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
Comment 4 Dirk Wiesenthal univentionstaff 2014-04-01 10:33:16 CEST
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
Comment 5 Drees Dormann univentionstaff 2014-05-19 13:25:48 CEST
* Added check for existence of dn in __init__.py/put(), also added error msg
  if dn is missing
Comment 6 Florian Best univentionstaff 2014-05-19 13:40:05 CEST
Maybe the error message should contain a hint for the end user (See comment #4) ?
Comment 7 Alexander Kläser univentionstaff 2014-05-22 23:48:12 CEST
(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.
Comment 8 Alexander Kläser univentionstaff 2014-05-23 10:43:10 CEST
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.
Comment 9 Alexander Kläser univentionstaff 2014-07-08 16:34:43 CEST
*** Bug 35281 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Kläser univentionstaff 2014-07-09 10:56:17 CEST
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
Comment 11 Dirk Wiesenthal univentionstaff 2014-08-13 12:12:05 CEST
Reported again
Comment 12 Florian Best univentionstaff 2014-09-08 09:50:58 CEST
Reported again.
Comment 13 Drees Dormann univentionstaff 2014-09-09 16:27:24 CEST
Created attachment 6104 [details]
patch

This is an attempt to make the error message more understandable
Comment 14 Florian Best univentionstaff 2014-09-15 09:01:59 CEST
Reported again.
Comment 15 Alexander Kläser univentionstaff 2014-10-08 15:19:12 CEST
(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():
Comment 16 Florian Best univentionstaff 2014-12-01 10:02:04 CET
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
Comment 17 Florian Best univentionstaff 2014-12-01 16:10:49 CET
I overtake this bug as I am working on similar things ;)
Comment 18 Florian Best univentionstaff 2014-12-02 10:44:57 CET
(In reply to Florian Best from comment #17)
> I overtake this bug as I am working on similar things ;)
Well, not exactly.
Comment 19 Florian Best univentionstaff 2014-12-03 11:28:57 CET
*** Bug 24620 has been marked as a duplicate of this bug. ***
Comment 20 Florian Best univentionstaff 2014-12-03 11:29:07 CET
*** Bug 24742 has been marked as a duplicate of this bug. ***
Comment 21 Florian Best univentionstaff 2014-12-03 11:29:12 CET
*** Bug 26977 has been marked as a duplicate of this bug. ***
Comment 22 Florian Best univentionstaff 2014-12-08 11:23:20 CET
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
Comment 23 Florian Best univentionstaff 2014-12-08 14:00:04 CET
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 ;)
Comment 24 Florian Best univentionstaff 2014-12-09 16:16:18 CET
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).
Comment 25 Florian Best univentionstaff 2014-12-10 11:26:14 CET
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.
Comment 26 Drees Dormann univentionstaff 2014-12-10 12:43:01 CET
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)
Comment 27 Florian Best univentionstaff 2014-12-10 13:53:37 CET
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".
Comment 28 Drees Dormann univentionstaff 2014-12-10 15:53:06 CET
adjustments have been made, also fixed broken function

( r56656 )
Comment 29 Florian Best univentionstaff 2014-12-10 19:24:12 CET
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"}}]'
Comment 30 Drees Dormann univentionstaff 2014-12-12 11:44:59 CET
this has been fixed
Comment 31 Florian Best univentionstaff 2014-12-15 11:16:47 CET
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
Comment 32 Florian Best univentionstaff 2014-12-15 11:23:25 CET
(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))
Comment 33 Florian Best univentionstaff 2014-12-16 10:03:08 CET
Reported again, 4.0-0 errata10 (Walle)
cn=SERVER.foo.local,cn=dc,cn=computers,dc=foo,dc=local
Comment 34 Drees Dormann univentionstaff 2014-12-16 10:14:47 CET
code has been adapted according to the proposal

(r 56868)
Comment 35 Florian Best univentionstaff 2014-12-18 14:15:26 CET
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.
Comment 36 Drees Dormann univentionstaff 2015-01-05 11:23:17 CET
Multiedit mode will now show an error if one or more objects could not be saved

(r 57021)
Comment 37 Florian Best univentionstaff 2015-01-06 16:22:46 CET
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"
Comment 38 Drees Dormann univentionstaff 2015-01-07 10:14:45 CET
Changed the behaviour so upon an error the DetailPage is closed only if it is in multiedit mode
Comment 39 Florian Best univentionstaff 2015-01-07 17:37:22 CET
OK, (did little adaptions).
Comment 40 Janek Walkenhorst univentionstaff 2015-01-08 13:59:05 CET
http://errata.univention.de/ucs/4.0/18.html
Comment 41 Florian Best univentionstaff 2015-10-14 12:26:58 CEST
Reported again, 3.2-6 errata341 (Borgfeld)

Remark:
Gruppen hinzufügen
Comment 42 Florian Best univentionstaff 2015-10-14 12:27:47 CEST
Reported again, 3.2-7 errata372 (Borgfeld)