Univention Bugzilla – Bug 43446
Changes should be logged in 'config-registry.replog' by showing the invoker
Last modified: 2020-06-12 12:21:03 CEST
In some cases it might help a lot when knowing not only what or when something in the UCR has changes but also what caused the change. Sometimes changes were made by manual editing a variable but sometimes it's done by a script, exactly in this cases it will help to know.
It happens now in a paedML Environment, and this feature would have helped here much, because samba4/autostart was set to "manually" and after reboot samba was not started. Now it would be nice to know, if it was a daemon or an administrator, who changed the value. Or can i look it up an other way?
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
This tiny feature would still be very helpful in several support situations so I reopened it against UCS 4.4.
It is always USER=root as only that user can change things locally. ucr might get invoked by - directly by an interactive user from a $SHELL - indirectly by a script invoked from the command line - remotely via ssh - from a Debian package maintainer script - UMC - by some background daemon, e.g. cron → ucr cron entry → script → ucr set - … The call chains can be very long, so what is considered the "what" here? (walk the process chain upward until you reach PID 1 and print all process names)
Looking at this from a users perspective one wants to determine if the change was triggered automatically or manually. By that means the "What?" is either the script's name, that changed the value, or 'manually'. From the perspective of security monitoring one surely wants to know who changed the value. This seems to be easy to find out as long as the umc is used to trigger that change. So in an ideal scenario the config-replog shows either the script or the username of the Issuer.