Ways to establish a fail-safe domain setup and to increase reliability
UCS can be used for single server environments as well as for a domain with hundreds of UCS servers. So, the default configuration does not match every scenario. The following sections will describe how to configure the different services in order to increase reliability.
Most settings are either configurable with UCR (at each system at local shell) or via domain wide policies in UMC. For general instructions on how to work with policies please see the manual section on policies.
If domain wide policies are already in use, you won’t be able to override such settings via UCR - for example:
root@member:/# ucr set ldap/server/addition="backup1.domain.com"
Setting ldap/server/addition
W: ldap/server/addition is overridden by scope "ldap"
You can adjust the existing policy via UMC then (see manual link above).
LDAP
The use of additional LDAP servers if the primary LDAP server is unreachable, is configurable via UCR:
root@master:~# ucr search ldap/server/addition
ldap/server/addition: Several LDAP servers can be operated in a UCS domain. The primary one is specified with 'ldap/server/name'. Further servers are automatically managed by a Listener module through this variable.
To increase reliability additional servers can be configured, which will automatically be used if the primary LDAP server breaks:
root@master:~# ucr set ldap/server/addition='backup1.domain.com backup2.domain.com slave1.domain.com'
The list should contain space separated fully qualified domain names.
The use of additional LDAP servers is also configurable via a LDAP server policy (see manual section on LDAP servers).
Kerberos
The server which replies to kerberos requests (so called kdc) is also configurable via UCR:
root@master:~# ucr search kerberos/kdc
kerberos/kdc: 127.0.0.1
A list of Kerberos KDC servers can be configured here. The host names should be specified in FQDN form. Multiple values need to be separated by a blank. If the variable is unset, the KDC is queried from DNS service records (see 'kerberos/defaults/dns_lookup_kdc').
root@master:~# ucr search kerberos/defaults/dns_lookup_kdc
kerberos/defaults/dns_lookup_kdc: empty
If this variable is set to 'true' or unset, the KDC(s) used by the system are read from DNS service records. This can be disabled by setting the variable to 'false', is which case the KDC(s) must be set through the variable 'kerberos/kdc'.
You can set the variables like this to use DNS lookup:
root@master:~# ucr set kerberos/defaults/dns_lookup_kdc=true
root@master:~# ucr unset kerberos/kdc
DNS
Different name servers can be configured via UCR:
root@master:~# ucr search nameserver
nameserver1: 10.200.11.240 The first DNS server to be used.
nameserver2: 10.200.11.1 The second DNS server to be used.
nameserver3: empty The third DNS server to be used.
To improve reliability additional name servers in the domain can be used - for example:
root@master:~# ucr set nameserver1=ip of master nameserver2=ip of backup1 nameserver3=ip of backup2
UCS systems with the roles Master, Backup or Slave run their own instance of the BIND nameserver. It is recommended to use this local instance of the BIND namserver as nameserver1 on these systems.
UCS Memberserver do not have their own BIND nameserver, therefore nameserver1-3 need to point to UCS systems with the roles Master, Backup or Slave.
UCR settings can also be applied domain wide via UCR policies.
If a DHCP server is in use, it should be configured to send its clients the list of all available DNS servers.
Active Directory-compatible Domain Controller
Overall reliability can be improved by adding multiple Active Directory-compatible Domain Controllers. This can be accomplished by installing additional UCS systems with a system role of “Domain Controller Backup” or “Domain Controller Slave” (see manual section on system roles) with the “Active Directory-compatible Domain Controller” software component (see manual section on selecting software components). Existing UCS backup or slave domain controllers just have to install the app from the App Center (see manual section on installing Samba4 app).
Samba 4 domain controllers replicate their data automatically by DRS (see SDB#1235 for further information).
DHCP
Clients, Access Points and other devices are often dependent on the availability of a DHCP service to receive a network configuration. If the service were down due to an error or maintenance, they would not work properly. Raising the availability of the DHCP service is simple in a UCS domain. All it takes is another UCS system in the same subnet on which to install the “DHCP server” app.
During installation, the new DHCP server will automatically be added to the DHCP service entry for its domain. When the installation has finished, the DCHP module should be visited to verify that (see manual section on DHCP service). If the app was installed on a domain controller slave or backup, the join script has to be run manually (see manual section on running join scripts).