Bug 50842 - Hourly cronmail when following article to use random LDAP server
Hourly cronmail when following article to use random LDAP server
Status: NEW
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
Depends on:
  Show dependency treegraph
Reported: 2020-02-19 16:38 CET by Erik Damrose
Modified: 2020-11-08 07:36 CET (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 1: Will affect a very 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.057
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Error handling, Large environments, Troubleshooting, Usability
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2020-02-19 16:38:23 CET
When following the article [1] 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.

[1] https://help.univention.com/t/14138

Reported here: https://help.univention.com/t/14349
Comment 1 Ingo Steuwer univentionstaff 2020-02-19 17:07:37 CET
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>
  ldapFilter: (univentionObjectType=computers/memberserver)
  ldapServer: <DC MASTER FQDN>
  name: default-settings
  requiredObjectClasses: univentionHost

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
Comment 2 Erik Damrose univentionstaff 2020-02-19 17:33:57 CET
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
Comment 3 Lutz Willek 2020-11-08 07:36:49 CET
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:
* https://docs.software-univention.de/manual-4.4.html#introduction:Policy_concept
* https://docs.software-univention.de/manual-4.4.html#central:policies

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 ;-) )