Bug 34341 - Disable listener module processing
Disable listener module processing
Status: NEW
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 4.2
All Linux
: P5 enhancement with 1 vote (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-13 15:11 CET by Philipp Hahn
Modified: 2018-04-14 14:01 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.046
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number: 2012050221003422, 2013052921001364
Bug group (optional): Error handling, Troubleshooting, Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2014-03-13 15:11:20 CET
Sometimes a listener module needs to be disabled, either because some required configuration is not yet done or because of some temporary problem.
1. Currently modules either ignore this and crash (Bug #34108), which leads to changes not being processed until a manual "univention-directory-listener-ctrl resync" is done.
2. Or modules implement their own log to persistently store the changes for later processing (Ticket #2012050221003422, Ticket #2013052921001364).

The first case could be solved by allowing handler_initialize() to return an error code, which would leave the modules as !HANDLER_READY.
On the next restart of the Listener if module would then be tried again.

For the second case see handler_exec(), which can return !=0, but its return-value is ignored everywhere.

PS: handlers_initialize_all() is unused.
Comment 1 Stefan Gohmann univentionstaff 2016-11-28 08:04:13 CET
Re-setting the bug classification. As far as I understand it is more a general improvement.
Comment 2 Stefan Gohmann univentionstaff 2017-06-16 20:37:57 CEST
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4.

If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Comment 3 Daniel Tröder univentionstaff 2017-06-19 15:32:09 CEST
One scenario which I have encountered is, that something external to the listener module ("environmental") is not ready. For example missing data, because a wizard has not run yet: gapps- and office365-connectors have this.

Those two deal with it, by simply ignoring all requests, until they have all necessary data. Thus they may miss an activated user. → 1.

The OX-listeners do 2.

a) It would be nice if the listener could queue jobs for deactivated listener modules.
b) The proposed API of Bug #44786 offers ListenerModuleConfiguration.get_active() → bool (should be is_active...) which by default maps to !ucr.is_true(listener/module/<name>/deactivate). The gapps- and office365-connectors would overwrite this method to instead check their api-token-state.