Bug 50481 - store error messages form acl/schema registration on acl/schema LDAP/udm object
store error messages form acl/schema registration on acl/schema LDAP/udm object
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-2-errata
Assigned To: Felix Botner
Dirk Wiesenthal
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-11-11 12:39 CET by Felix Botner
Modified: 2019-11-20 13:26 CET (History)
1 user (show)

See Also:
What kind of report is it?: Development Internal
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:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2019-11-11 12:39:08 CET
* new attribute listenerMessage settings/ldapschema and settings/ldapacl
* listenerMessage is set by python/ldap_extension.py
** to '' at the start of the register
** to stderr/stdout of slaptest in case the test fails
** to OK if registration is successful
* new functions to set/get listenerMessage python/ldap_extension.py
Comment 1 Florian Best univentionstaff 2019-11-11 12:47:57 CET
What if there are 5 failing listeners on 5 different UCS systems?

I don't understand how storing error messages in LDAP helps us?
We see them in the listener.log.
Comment 2 Felix Botner univentionstaff 2019-11-11 12:56:06 CET
(In reply to Florian Best from comment #1)
> What if there are 5 failing listeners on 5 different UCS systems?

It is mainly for the ldapacl/schema registration, and therefore on the master system.

> I don't understand how storing error messages in LDAP helps us?
> We see them in the listener.log.
The registration during the app installation seems to be unstable (at least that is what the data suggests) and we need a way to get more debug messages. For the appcenter team it would be the easiest to ask the ldap object for a possible error message (the content of listenerMessage attribute).
Comment 3 Felix Botner univentionstaff 2019-11-12 16:31:16 CET
univention-ldap 83f5d652f9532954757135fbabc78545412e1b13
added univentionListenerMessage to LDAP schema
Comment 4 Felix Botner univentionstaff 2019-11-12 17:15:59 CET
univention-lib:

added set_handler_message/get_handler_message to get set handler message objects (settings/data with univentionDataType: handlerMessage in cn=handler_messages,cn=univention,dc=four,dc=four) in python/ldap_extension.py

added set_handler_message calls to python/ldap_extension.UniventionLDAPSchema and UniventionLDAPACL

univention-ldap:

reverted 83f5d652f9532954757135fbabc78545412e1b13, we cant change to object that triggers the handler, instead we create a settins/data object 

added set_handler_message calls to listener/ldap_extension.py postrun

univention-appcenter:

TODO
Comment 5 Felix Botner univentionstaff 2019-11-14 16:20:24 CET
e6695e5a8a9a6fd858499b4b5c54362f3e459fb3 - univention-appcenter

* RegisterSchemaFailed / RegisterSchemaFileFailed are now "get_exc_details" 
  exceptions (tracking)
* include get_handler_message('ldap_extension',... message into Register 
  Exceptions
Comment 6 Dirk Wiesenthal univentionstaff 2019-11-18 12:29:13 CET
OK: works with tracking info in appcenter
OK: no registration problems -> no error message
OK: flawed slapd.conf -> meaningful error message
OK: no running listener -> no message at all

~NOT OK: if a message was written once, a new registration of the schema file (e.g., an update of contents) does not reset message
(not critical for a first look)

OK: YAML

VERIFIED