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
