Issue when changing primary ldap server from dc to backup

Hi guys,

after updating to UCS: 4.4-3 errata443 the system check shows a hint that the primary ldap server in the environment is set to the dc master and recommends setting it to the dc backup. This is the exact text in german:

Der primäre LDAP-Server dieses Systems (UCR ldap/server/name) ist in der Standardkonfiguration auf den DC Master der UCS Umgebung konfiguriert (server01.intern.mydomain.de).
In dieser Umgebung sind weitere LDAP-Server verfügbar, daher empfehlen wir zur Entlastung des DC Masters eine andere Konfiguration.
Siehe Univention Support Database - Änderung des primären LDAP-Server zur Verteilung der Server Last für weiter Hinweise zur Konfiguration.

After following the instructions in the Support Database found here Changing the primary LDAP Server to redistribute the Server load every server sends hourly a warning mail through the cron job:

W: ldap/server/addition is still set in scope "forced"
W: ldap/server/name is still set in scope "forced"

I wish to retain the setting of the master not beeing primary ldap server.
Can anyone help me resolve this situation?

Thanks in advance!

Kind regards
KaBi

Thank you for the report, i created an issue in our bugtracker https://forge.univention.org/bugzilla/show_bug.cgi?id=50842

As mentioned in the Bug report:

Please consider to work with LDAP server policies. My recommendation is to define a new policy and attach it to the memberserver instance.

In case you are new to our LDAP policy concept please have a look at https://docs.software-univention.de/manual-4.4.html#introduction:Policy_concept and https://docs.software-univention.de/manual-4.4.html#central:policies

Unfortunately the KB article is still not updated yet, so still a lot of admins are following the article and it seems they all end up here.

If you are one of those brave admins, and you found this thread because you found yourself in exactly this situation: The following text is for your convenience.
To be fully honest, the following is also for my convenience: I try to avoid that I’m called on Sunday mornings by befriended admins, shouting out for help, because their systems were messed up while trying to repair.

Ok, let’s start. It is relatively easy to escape from this situation. Most likely you need less than one hour to repair. In case you previously worked with policies, the job is done in some minutes.

1.
Please create a new policy named memberservers for your UCS member servers, just by following the really fine Univention documentation provided in the comment above. You may end up with policies very similar to the following one:

root@dc-master:~# udm policies/ldapserver list

DN: cn=default-settings,cn=ldap,cn=policies,dc=myorg,dc=lan
  ldapFilter: (univentionObjectType=computers/memberserver)
  ldapServer: dc-master.myorg.lan
  ldapServer: dc-backup.myorg.lan
  name: default-settings
  requiredObjectClasses: univentionHost

DN: cn=memberservers,cn=ldap,cn=policies,dc=myorg,dc=lan
  ldapFilter: None
  ldapServer: dc-backup.myorg.lan
  ldapServer: dc-master.myorg.lan
  name: memberservers

Basically, the new policy is a copy of the existing one, just the dc-backup server is mentioned first, and the second entry points to the dc-master.
This example scenario has only two servers. In case your environment is more complex, you have to adapt it to your needs of cause. The important aspect is that the dc-master is not longer listed as the first item.

2.
Please make sure that the desired member servers are referencing to the newly created policy memberservers, instead using the default policy default-settings. You can check the resulting policy on each member server by using the command “univention-policy-result”. As example:

root@memberserver:~# univention-policy-result -h $(ucr get ldap/server/name) -D $(ucr get ldap/hostdn) -y /etc/machine.secret $(ucr get ldap/hostdn)

...snip...

Policy: cn=memberservers,cn=ldap,cn=policies,dc=myorg,dc=lan
Attribute: univentionLDAPServer
Value: dc-backup.myorg.lan
Value: dc-master.myorg.lan

3.
The next step is to remove the previously forced settings via ucr, in order to allow the policy to become effective on this machine. Of cause, this needs to be done only on servers which have the forced settings applied as a consequence of following the KB article.
Hint: Sometimes it is unknown for one particular server if the setting was forced or not. Just have a look into the file /etc/univention/base-forced.conf in this case: if the variables ldap/server/name or ldap/server/addition are found there, the setting was previously forced on this particular server and most likely needs to be reverted. The settings can be unforced by using the following commands:

root@memberserver:~# ucr unset --force ldap/server/name
root@memberserver:~# ucr unset --force ldap/server/addition

4.
The policy needs to be applied. Either just wait, usually 5 minutes, because the policy will be applied via cron job, configured in echo "$(ucr get ldap/policy/cron)".
As alternative, manually apply the policy with the help of the following command:

root@memberserver:~# /usr/sbin/univention-ldap-server-available && run-parts /usr/lib/univention-directory-policy

5.
Check the results. It is expected to see ldap/server/name as well as ldap/server/addition configured according to the applied policy:

root@memberserver:~# for key in ldap/server/name ldap/server/addition ; do ucr get $key; done
dc-backup.myorg.lan
dc-master.myorg.lan

Please check also via UDM “System diagnostic”. The Warning “Check primary LDAP server” should not appear anymore.

6.
Lean back, enjoy your tea or coffee, and of cause enjoy less amount of useless and spammy mails in your inbox. Leave me a like if this post helped you - I wrote it for you. Cheers Lutz

Hi Lutz,

it took me some time to get to this again.
I am facing the following issue now: there are no forced ucr variables on the member server, however no matter how I add my pdc/bdc in the policy, their order ist switched automatically. Could this be due to their names: srv10 and srv12?

Kind regards

I ran into the same problem just now, that the policy reset itself using 2 servers with names “p1” and “p2”. I could not save the inverted order of first field “p2” and then “p1”. Fortunately I have one server with a different name.
So I updated the policy to “p2”, “different_name” and saved. Then edited again to “p2”, “p1” and saved and that worked. Hope it helps someone.

Possibly a bug in the policy system.
Plus I think that the article Changing the primary LDAP Server to redistribute the Server load should at least mention the option of using a policy.

Mastodon