This article is written for UCS 4. It uses the old UCS Role Names (Master, Backup, Slave, Member). The general steps should be the same when used for UCS 5, but they might differ in some places.
There might come a time when you want to replace the UCS Master server for another one. It might be that the old Master is still using the 32bit architecture or it might broke in some way. Whatever the reason, we can setup a UCS Backup to take over its role in the domain.
The most distinguishing feature of a UCS Master is that it is solely allowed to write to the LDAP and has a complete copy of the LDAP. UCS Backups also hold a full copy of the LDAP but are not allowed to write to it directly. The UCS Master also serves in the domain as a DNS server and might have other roles as well.
This article is partitioned into 3 phases.
- The preparation phase can be performed at any time. I would even advise you to always keep a backup at hand where the preparation phase has been performed on. This UCS backup can then take the master role in case of an unexpected failure of the old UCS Master.
- The execution phase is when you perform the backup2master mechanism. It is when the role of the UCS backup changes to that of UCS Master.
- The finalization phase contains some steps you should perform afterwards to ensure that no references to the old UCS Master exist any more and all systems in the domain recognize the new UCS Master.
Preparation
By writing to the LDAP, the UCS Master performs one of the most essential operations in any domain, and there is no other system that can take some of this load. For this reason we advise to keep the UCS Master as free as possible from other services and obligations as possible.
To prepare the UCS backup you decided to become the standby for the UCS Master you have to reduce the difference between the UCS Master and the UCS backup as much as possible. For this first take a listing of the installed packages on both systems and compare them.
$ COLUMNS=200 dpkg --list
Some differences are okay, but check if there are any packages you might be missing once the backup2master mechanism is finished. One special case are the packages univention-server-backup and univention-server-master. univention-server-backup will be replaces by univention-server-master during the execution phase.
Now also check if the installed apps from the app center are the same on both systems. You can get a listing of all apps and where they are installed with
$ univention-app info
Since you want to keep the UCS Master as free as possible from other obligations you should think about moving any service away from both the Master and its standby backup system to some other VM in the domain. This might not be possible or practical with all apps.
Having the same programs running on both servers is a great but they also have to be configured in the same way. For this you have to compare the UCR variables on both systems. Run
$ ucr dump
to get a full listing of all UCR variables. There are some variables that should stay different from each other. This has to be evaluated on a case by case basis.
Now you have the same programs running with the same configuration on both systems. The next step is to ensure that the LDAP Server will also run correctly once the backup2master is finished. For this you have to check that all LDAP schema files are installed on the UCS backup system.
Background information: LDAP schema files
The schema files describe how certain types of object classes and attributes can look and are evaluated in the LDAP. If you are missing a schema file for an attribute, but it is used in your LDAP directory then LDAP will have no idea of how to parse or handle this. It will give an error and exit.
In UCS schema files are installed on the UCS Master. On the Master they are combined and replicated to all other UCS systems in the domain with a copy of the LDAP (backups and slaves).
To get a list of the schema files on the UCS Master take a look into the /etc/ldap/slapd.conf. There all schema files get imported. You can directly get a list of the packages the schema files were installed with by running
$ awk '/^include/{print $2}' /etc/ldap/slapd.conf | xargs dpkg -S
slapd: /etc/ldap/schema/core.schema
slapd: /etc/ldap/schema/cosine.schema
slapd: /etc/ldap/schema/nis.schema
slapd: /etc/ldap/schema/inetorgperson.schema
slapd: /etc/ldap/schema/ppolicy.schema
univention-ldap-config: /usr/share/univention-ldap/schema/samba.schema
univention-ldap-config: /usr/share/univention-ldap/schema/mail.schema
...
univention-ldap-config: /usr/share/univention-ldap/schema/univention-data.schema
univention-saml-schema: /usr/share/univention-ldap/schema/univention-saml.schema
univention-virtual-machine-manager-schema: /usr/share/univention-ldap/schema/univention-virtual-machine-manager.schema
dpkg-query: Kein Pfad gefunden, der auf Muster /var/lib/univention-ldap/local-schema/univention-app.schema passt
You can see that the schema were installed with the packages slapd, univention-ldap-config, univention-saml-schema, and univention-virtual-machine-manager-schema. For one of the schema files however the package manager had no idea where it came from. In this case it is easy to see that it is part of univention-appcenter.
Make sure that all of the schema files are installed on the UCS Backup as well. As long as it has the role UCS Backup it will not use these schema files but rely on the copy it got from the Master, so there is no risk in this.
Execution
Before you start the backup2master process make sure the old UCS Master is shut down. It should never be turned on again to prevent confusion in the domain. So use this last chance to backup any data from the old UCS Master server.
Now you can run the backup2master process on the UCS Backup you want to become the new UCS Master.
$ /usr/lib/univention-ldap/univention-backup2master -v
The option -v gives you a bit more output, which is great if anything goes wrong. During the process you will get some output and maybe even be asked some questions (for example about DNS entries and if they should be changed to the new Masters IP or domainname). Answer those questions. In most cases the default should be the right choice. The script also logs to the file /var/log/univention/backup2master.log. It is advisable to have it open in another terminal.
$ tail -f /var/log/univention/backup2master.log
The Process should only take a couple minutes.
As one of its last steps the script replaces the package univention-server-backup with univention-server-master. Use
$ dpkg -l univention-server-master
to see if it is correctly installed.
Now your former UCS Backup system has taken the role UCS Master.
Finalization
Now you have to perform some cleanup tasks. These serve to make sure any reference to the old UCS Master is replaced with a reference to the new UCS Master.
First we need to check the UCR variables on all systems in the domain. On every UCS system in the domain run
$ ucr search --brief --non-empty --value "$oldMasterHostname" "$oldMasterIP"
If anything is found change the occurrences of the hostname of the old Master with the hostname of the new Master. Do the same for the IP addresses.
Next you need to check the DNS host entries are correct in the LDAP. For this run
$ udm dns/host_record list --superordinate zoneName="$(ucr get domainname),cn=dns,$(ucr get ldap/base)"
Also test all our other DNS domains is you have multiple. You should try to find any reference to the old Master and replace it with one to the new Master instead.
Lastly you have to check the policies. For this it is easiest to use the UMC.
Open the policies modules in the UMC and use the search field to search for the old UCS Masters hostname and IP. If any entries are found change them accordingly. Any reference to the old Master should be replaced by a reference to the new Master.
Now everything should work as normal again. Please perform some basic and regular operations in your domain to ensure everything works as intended. If it does you can remove the old UCS Master for good.