Univention Bugzilla – Bug 43633
replace python-notifier and UMCP by unifying UMC-Server and UMC-Webserver with Tornado
Last modified: 2023-07-06 09:27:19 CEST
Python-Notifier is the event based framework we use in UMC (and other components). It is not actively further developed. It has some problems: * Bug #29582 → causing using a lot of unnecessary hardware resources * It crashes the whole process in various situations, e.g. if exceptions occur in thread-finished callbacks and event-notify callbacks Better alternatives are some other well known tested event driven frameworks such as: http://www.tornadoweb.org/en/stable/ https://twistedmatrix.com/trac/ http://circuitsframework.com/ … (https://wiki.python.org/moin/WebFrameworks) Maybe we can replace python-notifier with one of them. Maybe we could also unify the UMC-Server and the UMC-Webserver to one component which uses HTTP as the overall protocol and replaces UMCP. I already implemented a PoC once, doing this using twisted: https://github.com/spaceone/univention-management-console (but I would say tornado is better than twisted).
https://blog.signifai.io/not-your-fathers-python-amazing-powerful-frameworks/
or maybe just use a readymade framework. Nameko comes to mind, or a task queue like celery.
... twisted has racked up quite a bit of a following, ldap & radius implementations are available. Pretty handy to have a python ldap server for testing... https://twistedmatrix.com/trac/wiki/ProjectsUsingTwisted
Why use a general event framework, if the intention is to create a HTTP API server? For that there are framework with more advanced features, resulting in less boilerplate and better upstream support: Falcon, Flask, FastAPI. As this is for UCS 5 we should go with a Python 3 framework that supports asyncio, validation, type annotations and a variety of authentication and authorization methods.
Well, choosing an async implementation sort of leads to choosing a frontend / api framework I guess. There's http/api frameworks for all of them, Twisted works with Klein or Flask, Celery works with Flask, Cyclone combines Tornado and Twisted, ... And since UCS is heavy on async operations it seems sensible to focus on that point. Async implementations delivered with python have traditionally been quite bad, asyncio seems to be the first decent one. The others are more mature, have more features and backwards compability. I'm new to ucs and not familiar with all common async implementations, so I can't really make a recommendation.
*** Bug 52655 has been marked as a duplicate of this bug. ***
*** Bug 28043 has been marked as a duplicate of this bug. ***
*** Bug 41795 has been marked as a duplicate of this bug. ***
*** Bug 29582 has been marked as a duplicate of this bug. ***
*** Bug 31923 has been marked as a duplicate of this bug. ***
*** Bug 32586 has been marked as a duplicate of this bug. ***
*** Bug 37487 has been marked as a duplicate of this bug. ***
*** Bug 47239 has been marked as a duplicate of this bug. ***
*** Bug 50290 has been marked as a duplicate of this bug. ***
*** Bug 50604 has been marked as a duplicate of this bug. ***
*** Bug 50942 has been marked as a duplicate of this bug. ***
*** Bug 54727 has been marked as a duplicate of this bug. ***
*** Bug 56087 has been marked as a duplicate of this bug. ***
*** Bug 54874 has been marked as a duplicate of this bug. ***
*** Bug 56136 has been marked as a duplicate of this bug. ***
*** Bug 55577 has been marked as a duplicate of this bug. ***
Copy from the epic: Introduction ============ `UMCP` is a self defined proprietary Binary+JSON-RPC protocol. The UMC-Webserver is a service based on `python-cherrypy` speaking `HTTP` and transforming it into `UMCP` - forwarding everything to the UMC-Server. UMC-Webserver implements the session handling, connections to UMC-Server and SAML. The UMC-Server is a service speaking only `UMCP` which manages UMC-Module processes, handles authentication via PAM and provide some core endpoints (e.g. the list of available modules). All three of them (UMC-Server, UMC-Web-Server, UMC-ModuleProcesses) are using the asynchronous `python-notifier` framework. [python-notifier](https://github.com/univention/python-notifier) is not maintained anymore, the ownership has been transfered to Univention. The goal of this epic is to: - unify both services into one - drop `UMCP` and only speak `HTTP` - keep current external HTTP-API - keep internal architecture (long running process, asynchronicity, ...) - reduce the dependency on `python-notifier` and make it possible to drop it in a short while The new service uses [Tornado](https://www.tornadoweb.org/en/stable/) - a Python web framework and asynchronous networking library. The implementation adds a `Tornado` main-loop implementation to `python-notifier` - because this is currently a API for module processes which can't be replaced if features of `python-notifier` are used. This implementation is the second approach. The first approach was done 2014 as PoC using the Twisted framework: - https://github.com/univention/univention-management-console-twisted Reasoning ========= * There should only be one service with one protocol (`HTTP`)! * increase **maintainability** * No `UMCP` protocol maintenance necessary, standardized HTTP is already fully defined * No use of 2 different frameworks (`cherrypy` and `python-notifier`) necessary, when `Tornado` is capable of both functionalities * `python-notifier` is not maintained anymore (since 2011) - Univention took over the ownership. * We should drop it. * we migrated it to Python 3 but it still cannot cannot use modern Python technologies like async functions. * There is no need for this extra complexity and proprietary protocol `UMCP` * Every programming language has a `HTTP` client, none have a `UMCP` one * decrease **error-proneness** * less code causes less bugs, less time on reading, etc. * **simplification** * less code required * it simplifies the dockerization of UMC * currently 3 large containers with much duplication exists * We can then drop one container (time saving every time a change to UMC is done only one container needs to be updated) * increase **testability** * only one path would need to be tested * `Tornado` also provides a test suite (not sure if we should use it though) * more **flexibility** for **further developments** * `HTTP` (and maybe `WebSockets` in the future) provide all technologies we need * support easier implementation of OpenID-Connect in UMC-Server (through `tornado.auth`) * currently missing functionality: * we currently cannot use the full features of `HTTP` but are limited to binary-data without metadata or JSON data transmitted via `UMCP`. * there were difficulties and workarounds in the 2-factor-auth-privacy-idea module * currently no or barely use of HTTPs methods, caching, compression, authentication possible * Tornado allows to use modern `async def` functions/patterns. * less **debug effort** * We still have memory leaks, which aren't easy to test/debug with those 2 components - which can be fixed more easily then. * If there were bugs in `Tornado` upstream maintainers might fix them instead of us * Developer don't need to trace down in which component a bug occurred (e.g. during transformation into `UMCP`, or just during processing of a command, etc.) * **Saving development time** through * more flexibility * less debug effort * we can link to external documentation instead to our (barely) self written documentation * less dependency on my knowledge about the internals, other developers can participate in development * improve **stability** / **robustness** * with `python-notifier` it is/was possible that the process crashes - not so with `Tornado` - e.g. if unhandled exceptions occur in thread-finished callbacks or event-notify callbacks * **separation of concerns** * the current logic (e.g. for authentication) is strongly coupled with the `python-notifier` logic * chance for better **scalability** * easier multiprocessing * one process can't be the bottle-neck for the other anymore * UMC-Webserver thread-size is not the bottle-neck for parallel connections anymore * **reduce misunderstanding** (management of 2 services) * customers don't need to understand the differences between those 2 components anymore * e.g. when to restart which service, which log level needs to be increased, which log file needs to be watched * reduce **power consumption** * UMC-Webserver needs to use the `python-notifier` `dispatcher` function which is called every 100ms (in large environments even more often) - while `Tornado` only uses time-based or `select()` based wake-ups * decrease **memory usage** * We only need to load the python-libraries into one process - saves a little bit memory usage (but the major memory usage are the module processes itself) * **security** enhancement * a self written protocol doesn't follow security considerations, best practices and known vulnerabilities as standardized protocols specify in their RFCs * more **future proof** - long term re-orientation * (current) `RPC` style is not `HTTP` conform and harder to understand * we probably want to implement API's (e.g. `REST APIs`) in the future; used by machines and JavaScript frontends at once * **basic work is already done** * One PoC's exists since 2014, another since 2019. * **reduce dependency** on me * I have the most overview about the complex undocumented components. With another framework this could change. Scope/focus of this RFC: ======================== - [x] Merge UMC-Server with UMC-Webserver into one service - [x] Drop `UMCP` - [x] run with `systemd` instead of `python-daemon` + init script (univention/ucs!137) - [x] get rid of `python-notifier` in the main process - [x] be backwards compatible for all existing UMC modules (i.e. still support python-notifier, still use same JSON-RPC responses) - [x] use Tornado as basis - [x] implement, release and use the Tornado implementation of python-notifier - [ ] use a systemd alias for (univention-managment-console-web-server to univention-management-console-server) - [x] backport `umc-client` and other scripts using the UMCP interface, so it uses HTTP - [x] compare performance and memory usage - [ ] support multiprocessing Risk ==== * There could be **regressions**: e.g. due tue Python Tornado handling connections differently; UMC modules not implemented by ourselves, or even internal teething troubles (e.g. regarding session, module or connection handling). After reading the source code of Tornado I feel comfortable about the change. * Dropping `UMCP` sound like a **major API change** - and of course if it would be used from the outside it would be one - but `UMCP` is barely to not at all documented, `UMCP` changed in the past and we didn't get complains about this and I never saw any customer or professional service employee ever using or asking how to use it. `UMCP 2.0` was introduced in UCS 3.0 - so since I am working here. I see `UMCP` more as an internal implementation detail which we can change also in a minor version - as long as the scripts which are using it keep compatible. * There could be **performance, memory usage or scalability degradation**. In my basic tests I couldn't see any. * `Tornado` could be the **wrong choice**: In the first step we don't expose any `Tornado` APIs (e.g. to module processes) - so a later change would always be possible. Even if, changing from a `Tornado` definition is easy and more easy than changing from our self defined APIs. It is definitely a improvement compared to the current situation. Discussion points ================= - [ ] Store sessions not in memory so that the service can be restarted without logging out all users? Known Issues and TODOs ====================== - [ ] don't perform check_saml_session_validity() during authentication requests but during all other protected and unprotected resources? - [ ] check if all restarts of UMC-Server are still necessary or if a reload is satisfying - [ ] provide a generic thread-finished callback for progressbars in UMC modules - to replace the need of notifier.threads - [ ] move file upload handling from module processes into UMC server - save bandwith between the two components. Earlier security checks. - [ ] already create future proof resources which respect the correct HTTP methods? e.g. combine UserPreferences - [ ] when a long running request (e.g. appcenter/keep_alive) is canceled due to an timeout by umc-server the module process doesn't detect the request is aborted - [ ] "Add flavor:" log messages occur when a module process was killed. why? unneded __del__() logic executed? - [ ] duplicated error messages can be shown; maybe due to title and message being equal?
I consider this finished now
I consider this finished now - grr, my smileys here caused the rest of the message to be stripped: (at least if there aren't some small things in the next test runs). Note: the Jenkins tests currently run with outdated versions (something seems broken with announcement?) and therefore have many failures due to not running UMC-server processes or AttributeErrors. The required version: Package: univention-management-console Version: 12.0.29-1 So, what can I say? The UMC-Server and UMC-Webserver has been unified into one service "univention-management-console-server". "univention-management-console-web-server" has been removed. The systemd service for it is now an empty stub. I planned to define it as Alias for univention-management-console-server but systemd has a bug which prevents that the service cannot be restarted when it is masked. And that is required for upgrades via UMC. The service now uses the asynchronous web framework python-tornado (tornadoweb.org/), which has some similar concepts than python-notifier but in modern and good quality. The service tries to have the very same architecture as before to reduce possible side effect e.g. ineffective module processes per session are forked, but not preserving the memory leaks ;-) and not preserving the power-consuming notifier dispatcher, … etc. The HTTP interface keeps being the same with small exceptions for set/ requests to provide different urls for different concepts/resources). The programming API for UMC modules is kept, except for some removed UMCP details. Many things are marked as deprecated. We should make a cleanup of existing modules in UCS 5.1. I did it already for some modules. A python-notifier notifier.TORNADO main loop has been implemented, which is used in the umc module processes to support notifier.threads, notifier.popen and notifier.signals functionality for modules which still use that. I tried to make the git commit easier to read by moving some files before, so that a diff is generated. During the years of rebasing I had to squash many commits, which were clean in traceable. So the main commit for the most changes is: f65f51cd0c3327b174e7e0d72d59e924baed503d The Python API doc has been adjusted. The architecture documentation has been adjusted. The manual did not contain any information regarding UMC-Server or UMC-Webserver. Multiprocessing is still possible via apache load balancer module with sticky sessions. I tried getting it to work natively with Tornado but that did not succeed because UMC frontend sends e.g. two direct requests (authentication and module process query) in the same HTTP/1.1 pipeline request, which the apache gateway forwards to the tornado-server, where the kernel put those 2 requests to 2 different processes and tornado handles them parallel. but the second request of course must wait for the first authentication to succeed to make it work. using some SyncManager.Event() could realize this maybe. Also the UNIX socket of UMC module processes would have to be replaces with TCP socket so that multiple processes can connect to it. Not worth the effort now. We performed the UMC and UDM product tests with large environments of multiple thousands users, make large data transfers. We tested using two parallel UMC's behind a gateway, e.g. http://fqdn:9000/ and http://fqdn/ still allows to use two different UMC sessions. We upgraded a UCS 1, UCS 2 VM to UCS 5.0-4 and tested using basic UMC features like appcenter, users module. The diagnostic checks have been adjusted and are ok. TODO: We are not yet finished running and analyzing the locust performance tests with many parallel requests/sessions. This is tracked in another issue. We have to support ways/documentation for the support department how to revert to the old UMC in UCS 5.0-4 when after the upgrade failures are detected. univention-web (4.0.4-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests univention-updater (15.0.9-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 717323cb41b7 | fix(updater): stop left over univention-management-console-server when upgrading to UCS 5.0-4 via UMC univention-updater (15.0.8-1) 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service f65f51cd0c33 | refactor(umc): Unify UMC-Server and UMC-Webserver via Tornado service 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-updater (15.0.10-1) ee874eb6342e | feat(updater): kill also UMC-Webserver in postup.sh univention-system-setup (13.0.9-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service univention-system-setup (13.0.8-1) 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-self-service (5.0.7-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests univention-quota (14.0.5-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 1e3901f0ee46 | refactor(quota): replace notifier.popen with tornado 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-python (13.0.4-1) 9b24bebb8552 | feat(logging): decrease loglevel from INFO(3) to DEBUG/ALL(4) univention-portal (4.0.12-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests univention-network-manager (12.0.5-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service univention-management-console-module-udm (10.0.8-1) b216531f58c8 | Bug #43633: fix typo univention-management-console-module-udm (10.0.7-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 f65f51cd0c33 | refactor(umc): Unify UMC-Server and UMC-Webserver via Tornado service univention-management-console-module-udm (10.0.6-1) 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-management-console-module-services (9.0.3-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service univention-management-console-module-services (9.0.2-1) 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-management-console-module-passwordchange (5.0.2-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests univention-management-console-module-lib (9.0.4-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service univention-management-console-module-lib (9.0.3-1) f65f51cd0c33 | refactor(umc): Unify UMC-Server and UMC-Webserver via Tornado service a3424b562627 | style(js-umc-lib): adjust wording of restarting UMC univention-management-console-module-diagnostic (6.0.6-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 86719cb786eb | fix(diagnostic): Adjust file permissions for new UMC server UNIX sockets univention-management-console-module-adtakeover (7.0.6-1) 27a6e0a9f6db | fix(adtakeover): respond to HTTP requests in main thread univention-management-console-module-adtakeover (7.0.5-1) 25ea6568d6eb | refactor(umc-ad-takeover): don't use UMCP internals univention-management-console (12.0.29-1) ded86ba58e34 | feat(umc): reimplement multiprocessing via apache load balancing with sticky sessions univention-management-console (12.0.28-1) 73d02f46d621 | refactor(umc): enhance Session interface 9cc91f348de4 | feat(umc): include module name in UNIX sockets 5edcce385b97 | fixup! refactor(umc): improve debugability of module processes 78200d9dd1b5 | Bug #43633: fix fuzzy 9b24bebb8552 | feat(logging): decrease loglevel from INFO(3) to DEBUG/ALL(4) 4172ceb39127 | refactor(umc): improve debugability of module processes 3922c70b8b65 | fix(umc): make responding in non-main-thread thread safe univention-management-console (12.0.27-1) 6a46723cc51f | fix(umc): execute `super().prepare()` coroutine c3e5ecefaa1e | Bug #43633: fix typo univention-management-console (12.0.26-1) 1034aa214365 | fix(umc): set stdin,stdout,stderr file descriptors inheritable univention-management-console (12.0.25-1) acf34db6585c | fix(umc): restore Python 2 compatibility c78d392c5bfd | fix(umc-client): show error message instead of traceback on failed authentication in umc-command univention-management-console (12.0.24-1) 5dcf2901ae16 | fix(umc): allow flavor to be given in file uploads univention-management-console (12.0.23-1) fd57da7852df | fix(umc): allow to run self.finished() inside of non main thread univention-management-console (12.0.22-1) 1c9697dd5367 | fix(umc): handle unset username on reauthentication 20c64d44508d | feat(umc): make tornado access log level configurable d1703793dfd4 | feat(umc): use new API to get user information univention-management-console (12.0.21-3) 0d92b7c0a0f1 | feat(umc): add error handling for threads trying to write the HTTP response 893a95494854 | fix(umc): fix SAML logout for POST binding e.g. used by Keycloak 45a2d9685e66 | refactor(umc): move _client into parent class c8a1a38cff9e | fix(umc): fix ability to assign self.{username,password,userdn,auth_type} b0e428420ccd | Bug #43633: fix typo univention-management-console (12.0.21-2) d3fdf0787449 | Bug #43633: stop UMC-Web-Server also on interim upgrades (not coming from univention-management-console (12.0.21-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 8e80af12b59b | fix(umc): prevent duplicated restart on upgrade fc4a608a0dbc | fix(umc): fix blocking of UMC restart when services are masked during UMC upgradres 95c3727fb088 | feat(umc): make it configurable to allow certain IP networks to overtake sessions a21786130104 | fix(umc): fix memory/LDAP-Connection leak in UMC-Server ACLs 0040ba7bfa21 | fix(umc): drop UMCP port from firewall rules b52856d1fb26 | docs(umc): adjust UCS-Python-API docs for unified UMC f65f51cd0c33 | refactor(umc): Unify UMC-Server and UMC-Webserver via Tornado service univention-management-console (12.0.20-1) 88c61f921b32 | chore(umc): rename files to preserve diff in next commit 75ca3771e0d8 | chore(umc): rename files to preserve diff in next commits 8859c35b75e5 | fix(umc): use TLS 1.2 instead of 1.0 for communication 1f76b3c5dacb | feat(umc-modules): add @threaded decorator univention-management-console (12.0.18-1) c475050ba649 | build(umc): change to pybuild and replace distutils with setuptools univention-management-console (12.0.17-14) 800d30b4a4cd | fix(umc): Fix HTML decoding of single quotes in tracebacks univention-lib (9.0.16-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests univention-lib (9.0.15-1) f65f51cd0c33 | refactor(umc): Unify UMC-Server and UMC-Webserver via Tornado service univention-ldap (10.0.10-19) r43633 | install settings_ldapacl (Bug #32411) univention-appcenter (9.0.8-1) ef9300db9938 | Bug #43633: add missing changelog entry univention-appcenter (9.0.7-10) 355552b70cdf | chore(umc-modules): adjust dependencies on UMC version 956eb427a6af | refactor(umc-modules): replace direct use of notifier.threads with UMC @threaded decorator univention-ad-connector (14.0.16-1) 54e7208fae74 | fix(ad-connector): request.options access with simple_response threaded d ecorator univention-ad-connector (14.0.14-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 5f37cfc5f2fd | refactor(ad-connector): replace notifier.popen with tornado ucs-test (10.0.13-2) 34d73ffe553e | Bug #43633: fix readability of selenium test ucs-test (10.0.13-1) d7276ea5a10c | Bug #43633: Merge branch 'fbest/43633-unify-umc-server' into 5.0-4 7c4874127f47 | refactor(umc): adjust UMCP set/ HTTP requests 48930e88eae3 | fix(umc): remove obsolete references to univention-management-console-web-server systemd service 9615928da439 | test(umc): adjust test cases for unified UMC ucs-test (10.0.12-1) 275e947bae50 | test(umc): refactor logrotate test NONE f27c79f29ec9 | docs(architecture): Update ArchiMate views about UMC be18513b3b94 | docs(umc-manual): Remove UMCP from UCS architecture and developer documentation
Already tested by the apprentices: * Updating an old environment to 5.0-4 * Running behind a reverse proxy * Changing IP of Master in UMC * Simultaneous SAML/Plain login * Using modules that ask for password and do plain login when using SAML auth (appcenter, Computer room, ...) * Test computer room module with 3 windows PCs * DVD Installation * DVD Installation as DC Slave * Testing huge environment (multiple thousand users, groups, printers, computers) * Updating from 5.0-3 to 5.0-4 via UMC * Updating UCS@School from 5.0-3 to 5.0-4 via UMC * French translation * Open-Xchange license manager
Verified: * The packages have been build: OK * A changelog entry has been added: OK * Installation works: OK * Update works:OK * Login works: OK * UMC modules can be opened: OK
*** Bug 52361 has been marked as a duplicate of this bug. ***
*** Bug 55481 has been marked as a duplicate of this bug. ***
*** Bug 52940 has been marked as a duplicate of this bug. ***
*** Bug 55755 has been marked as a duplicate of this bug. ***
*** Bug 37716 has been marked as a duplicate of this bug. ***
*** Bug 38735 has been marked as a duplicate of this bug. ***
UCS 5.0-4 has been released: https://docs.software-univention.de/release-notes/5.0-4/en/ If this error occurs again, please use the 'Clone This Bug' option.
*** Bug 55978 has been marked as a duplicate of this bug. ***