Univention Bugzilla – Bug 50253
Handle reloading of extended attributes better
Last modified: 2023-10-13 12:34:53 CEST
Currently extended attributes are only reloaded in certain requests like .../users/user/add. We should add a mechanism which automatically reloads extended attributes and extended options when there are changes. This can be achieved by: * changes of extended-* objects can trigger the reload directly * a listener can cause a "service ... reload" call. * ... There are several dis/advantages for each way. We should find a good combination which suits for most cases.
Proposition: * UDM REST API implements a way to trigger a reload by a client (with sufficient priviledges) * a listener plugin on systems where the UDM REST API is installed sends this trigger in case Extended Attribute objects in LDAP have been changed in a postrun method
IMHO a change to any of the following modules require a restart of the UDM REST server: * settings/extended_attribute * settings/extended_options * settings/udm_module * settings/udm_syntax
There should be a way for clients to know _when_ the UDM REST server has restarted the last time. That way they can wait for it. Scenario: 1. create an object of one of the four above modules via join script 2. wait for UDM REST server to restart 3. use UDM REST server An entry in the UDM REST APIs root or a dedicated resource could hold that kind of metadata information (and possibly other "about this system" data in the future like the UCS version, patch level etc).
I installed OX with its UDM modules, registered by registerLDAPExtension. While the UDM CLI worked, my REST API Python client did not. I did not expect the service to be reloaded and had to search for the reason. I second an automated solution for this.
I search one hour of DL (!) time yesterday in two apps that use the UDM REST API for strange errors, only to find out that I didn't restart the UDM REST API after creating a few extended attributes.
I created a patch in git:fbest/50253-udm-rest-api-reload-extended-attributes which reloads the service via an listener if any extended attribute/option was changed. The UDM-Server is then reloading all currently loaded extended attributes/UDM modules. Additionally the listener is triggered for settings/udm_{module,syntax,hook} object changes. This depends of course on the order of listeners being executed: udm_extension.py udm_rest_reload.py → So the filename is important.