Bug 34341 - Disable listener module processing
Disable listener module processing
Status: RESOLVED WONTFIX
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: 2020-07-03 20:55 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:
Flags outvoted (downgraded) after PO Review:
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.
Comment 4 Ingo Steuwer univentionstaff 2020-07-03 20:55:14 CEST
This issue has been filed against UCS 4.2.

UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.