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.
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
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.
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)
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/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
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
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
Please check also via UDM “System diagnostic”. The Warning “Check primary LDAP server” should not appear anymore.
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