Univention Bugzilla – Bug 50842
Hourly cronmail when following article to use random LDAP server
Last modified: 2020-11-08 07:36:49 CET
When following the article  introduced by Bug #50191 to configure a different ldap server on memberserves with
ucr set --force ldap/server/name=...
The server will generate hourly cronmails with a warning:
W: ldap/server/name is still set in scope "forced"
This happens because the cronjob univention-directory-policy-cron sets the UCRvs unconditionally (probably to overwrite local changes and apply the configured values in any case) in /usr/lib/univention-directory-policy/univention-set-ldap-server
The warning itself originates in UCR itself, and is a generic warning when setting a UCRv, that informs if the UCRv will not have an effect, because a higher scope will overrule the setting.
Reported here: https://help.univention.com/t/14349
By default we create a policy that defines the default LDAP server for memberservers, for example:
# udm policies/ldapserver list
DN: cn=default-settings,cn=ldap,cn=policies,<LDAP BASE>
ldapServer: <DC MASTER FQDN>
We should update the SDB article, users can
* define the LDAP server using "ucr set" with "--force" but will see the mentioned warning by the CRON job
* modify the LDAP server policy / create additional ones for memberservers where changes are usefull
When adapting the SDB article to create / modify existing policies, we should recheck the policy cronjob algorithm. It has additional logic to set the ldap server UCRvs
Indeed, the article https://help.univention.com/t/changing-the-primary-ldap-server-to-redistribute-the-server-load/14138 should be updated, in a way that the instruction to create a policy is mentioned first in future.
In addition, links to relevant documentation should also be provided there:
I suggest not to alter the existing description on how to set manually via "ucr set --force ...", because it certainly has its justification.
Instead, to indicate that the policy is the preferred way to set things. Furthermore the hint that the manual way has the potentially unwanted side effect that every server sends an hourly warning message about the cron job.
Afterwards all further steps should be accomplished, as checking the logic of the cronjob algorithm. (Erik mentioned it)
The reason why I recommend doing it this way:
In the past few months I have received several calls from befriended UCS admins. Due to the high promotion of this KB article (caused by introduction of the system check which recommends setting ldap to the dc backup) all trapped into the same mail flood, e.g. this bug. They all just tried to follow the KB article. They were all irritated by the fact that the article did not suggest the best solution. Such an experience does not enhance Univention's reputation, and it could be fixed immediately and easily, simply by updating the KB article.
( In addition it would help me to reduce the number of calls I get ;-) )