Note: Cool Solutions are articles documenting additional functionality based on Univention products. Not all of the shown steps in the article are covered by Univention Support. For questions about your support coverage contact your contact person at Univention before you want to implement one of the shown steps.
This article gives some additional information and recommendations about the “Backup to Master” process. The process irreversibly replaces the DC Master of a UCS Domain, in case of failure.
This article extends the information given in the Backup to Master section in the UCS documentation, where also an excellent introduction for the use cases of the “Backup to Master” process can be found. Please note that the documentation may be more up-to-date than this article, so doubt, please follow the documentation.
The primary goal of the “backup2master” process included in the product is to enable a Backup Domain Controller instance to offer the standard UCS services. So the process includes automated reconfiguration of standard services including OpenLDAP, Samba 4 and the SSL certification authority. To ensure that this process is possible even if the “old” DC Master is down, UCS synchronizes all information needed for these services between the DC Master and all DC Backup instances.
The following sections focus on additional services, which are optionally installed on a Domain Controller Master but not covered in the standard “backup2master” process.
This list is not complete, so please assume individual steps also needed for those App/Service not included here.
The backup2master process includes all necessary steps for the Samba 4 Domain Controller to continue working. In most scenarios, the “Samba 4 Connector” is active on the DC Master. The backup2master process detects that the Connector was on the previous master and automatically configures and starts it on the new DC Master.
The recommendation is to have Samba 4 installed on all DC Backup instances that might become DC Master in the future to ease the process.
As the first step, install the google-apps app on the new DC Master. Then, the directory /etc/univention-google-apps has to be copied from the DC master or restored from a backup to the same directory.
To restore the synchronization, the google-apps listener must be enabled on the DC master:
chown listener:root /etc/univention-google-apps/* service univention-directory-listener restart
For testing the connector connection, print all known users and groups by calling
Single Sign-On works out of the box after installing the app.
As the first step, you have to install the office365 app on the new DC Master. Then, the directory /etc/univention-office365 has to be copied from the DC master or restored from a backup to the same directory.
To restore the synchronization, the office365 listener must be enabled on the DC master:
chown listener:root /etc/univention-office365/* service univention-directory-listener restart
To test the connector connection, a simple test is to print all known users and groups by calling /usr/share/univention-office365/scripts/print_users_and_groups
Single Sign-On works after installing the app.
Typically setups are migrated automatically as the LDAP stores all relevant information. Only if a failover peer configuration was in place on the old DC Master attention might be needed.
You can install the Radius App on other UCS Domaincontroller instances. Thus manual configuration changes are only needed if you installed Radius solely on the DC Master. A switch to a different Radius Server typically needs manual reconfiguration of Radius Clients (i.e., WLAN Access Points). Some Radius clients even support multiple servers for a smooth failover.
In case the Password Self Service App is installed on a new Domain controller, end users can directly use it. The LDAP stores all needed information for the default configuration. However, the App can be configured to use alternative messaging services like SMS gateways. You need to restore these additional configurations manually, after completing the failover.
However, users who started the password reset process on the old DC Master, need to retrieve a new token or link as the old one becomes invalid in the process.
These Services also need additional attention, but currently, no step-by-step guide is available.
The service isn’t migrated automatically during a backup2master. It should be possible to ease migration by restoring the local configuration (UCR, mapping definition files in /etc.) and cache files, but this is not yet documented.
The most common scenario is to sync the two directories. It this case it is possible to install and configure the Connector App on the new DC Master after the backup2master. The initialization starts a full re-sync.
It is perfectly fine to install these services on a Domain controller Master. This setup is most common in smaller UCS Domains. In case of unrecoverable failures of the DC Master with these services, we recommend to restore from a recent backup instead of the “Backup 2 Master” process - otherwise App/Service-specific data needs to be restored from a recent backup of the old DC Master instance on the new server including App/Service specific restore procedures.
The following Services should not be installed on a Domain Controller Master to avoid unnecessary complexities in case of a backup2master:
- Mail & Groupware Services: We recommend a Domain Controller Slave for all Mail and Groupware services.
- File- and Printservices: Recommended are Memberserver or Domain controller Slave instances
- Business Applications: Typically these Applications include a Database backend and additional service processes. Examples are ERP, CRM or project management solutions. The recommendation is to install these services on Memberserver instances.
You should configure a UCS domain with redundant services, to reduce the risks in case of outages of an individual UCS instance. You can find further information in the “Fault-tolerant domain setup” section in the UCS documentation.