In December we will open the beta release of UCS 5.0 to the public. For users who have been using UCS for a longer period of time, the renaming of the system roles in particular will bring a significant change, which will be visible in the beta release. In addition to the removal of known terms of discrimination (“master” and “slave”), we would like to use new names in order to reflect the central functionality of our new system in the respective names. In the following, I will introduce the new naming for the system roles and explain the goals we are pursuing with it.
Origin of the previous names
In environments with many entities, the system roles in UCS allow to distribute components of the UCS management system such as the directory service in a meaningful way: Depending on the selected system role, a complete management system, a replica of the directory service or even no directory service at all is installed.
The descriptions of the system roles used up to UCS 4.4, such as “domain controller master”, are derived from terms that have their origins in the NT domains Microsoft introduced in the 1990s. About 15 years ago we made a conscious decision to use these terms because they were common – and because at that time, UCS’ goal was to provide services compatible with NT domains.
Reasons for the changes
At Univention, the discussion about the names of the system roles goes back at least to the year 2016 – but we only wanted to implement such a fundamental change in a major release (like now with UCS 5.0). The reasons for the discussion come from at least two areas:
1. Self-explanatory descriptions
With the switch to Active Directory-compatible domain services for clients, the terms “Master” and “Backup”, derived from the NT world, are misleading: Every system on which a Samba 4 DC is rolled out as an app is a writeable copy of the Samba4 directory service (a “Master”). But there is no need to install it on the “UCS Domain Controller Master” system role, which means only OpenLDAP is installed there – so it is not a “domain controller” in the sense of an Active Directory compatible domain. We want to strip away the terms from the “Microsoft world” to avoid misunderstandings and to make it clearer what the actual goals of the system roles are.
2. Non-discriminating terms
The terms “master” and “slave”, which were used in the previous names of the system roles, are inseparably linked to the suffering of countless people through injustice such as enslavement and racial segregation – and are thus in clear conflict with the values we represent at Univention.
Approach to the new terms
The name of a system role shall stand for the core functionality of the role. Here we want to resolve the binding of services to a system role in future – not all with UCS 5.0, but later – by outsourcing further services in apps from the UCS App Center. The first example is the UCS portal, which has already been provided as a preview for UCS 4.4 in form of an app, but also services such as DNS or the PKI integrated in UCS.
The primary task of an UCS instance as a centrally managed enterprise operating system is to be a platform for various services. We find that this is optimally represented by the term “node”, i.e. a node in an infrastructure.
The most important separation between the system roles in the next step is whether or not an OpenLDAP is rolled out on the system as a directory service. This decision is also defined in the long term via the system role. Systems with a directory service are then called “Directory Node”, those without are a “Managed Node”.
Finally, there is a distinction in the tasks of the directory service: “Primary Directory Node” is a writeable, leading entity, “Backup Directory Node” is an entity that can take over the writeable role of the “Primary Directory Node” as a fallback, and “Replica Directory Node” is a permanent, read-only copy.
|Previous name||New name||Core function|
|Domain Controller Master||Primary Directory Node||Writeable, leading entity of the directory service|
|Domain Controller Backup||Backup Directory Node||Copy of the directory service and all information to take over the role of the Primary Directory Node as a fallback|
|Domain Controller Slave||Replica Directory Node||„Read-Only“ replica of the directory service for load distribution and locations as well as hosting of services with high workload of the directory service|
|Memberserver||Managed Node||Centrally managed system for hosting services|
|Base-system||–||The role is omitted because the added value is too small compared to a pure Debian.|
Adjustment of other computer objects in the management system
UCS 4 introduced the “IP Managed Client”, which serves as an object for managing IP information (address, DHCP, DNS). We saw a risk of confusion here with the new role of the “Managed Node”. At the same time, the term “Managed Client” is misleading, since the client itself is not managed by UCS, but only its information in the UCS services DNS and DHCP. The client will therefore be called “IP Client” in future.
Some older objects in the management system, which go back to products that have been discontinued for some time, have been removed from UCS 5. These include objects such as the “Univention Thin Client” and “Univention Corporate Client”.
By renaming the system roles, we are taking an important step towards greater clarity in the use of UCS and laying the foundation for greater flexibility with future releases.
Of course, these changes are not the only ones we will be releasing with UCS 5.0. In upcoming articles as we continue to develop, I will discuss changes to the installation, updates of the base system, revision of the look & feel and other new features.
With each article we also welcome your feedback on the changes here in the blog!