1. System configuration#

This section covers the differences of UCS in the area of system configuration. The term system configuration in the context of this section refers to controlling the behavior of a system and its services through configuration files.

Administrators typically configure Linux operating systems using text-based configuration files. Debian GNU/Linux and Ubuntu are no exception to this principle. The advantage of a text-based configuration format is that it requires no extra tools or knowledge other than a text editor and a documentation of the configuration syntax. Text-based configuration is also useful for configuration management and infrastructure as code software such as Ansible, Puppet, or Terraform that allow administrators to configure multiple systems.

UCS, being a derivative of Debian GNU/Linux and thus a Linux operating system, is no exception to this principle. The services on a UCS system use their familiar text-based configuration files. As an administrator with Linux know-how, it’s natural to manually edit the configuration with a text editor and adapt the settings of a service to the needs of their environment.

1.1. Template system for configuration files#

When it comes to manually editing configuration files, UCS is different from other Linux distributions. UCS automatically generates most configuration files from text-based file templates and a key-value-based variable store. Univention calls this capability Univention Configuration Registry (UCR).

The registry contains various variables and their values, for example the hostname of the central LDAP server. Configuration files that need this particular value, refer to the variable. Changes to the variable trigger the UCR mechanism to recreate all affected configuration files.

See also

For a detailed elaboration, see the following sections in Univention Corporate Server 5.0 Architecture [1]:

UCS uses UCR for the following non exhaustive list of benefits:

  • Single setting values can apply to multiple configuration files.

  • UCR ensures configuration consistency for services affected on a system.

  • The majority of software packages on UCS use UCR for their configuration.

  • Avoid configuration errors resulting from an invalid configuration setting syntax.

  • Apply logic to values and write the result in the configuration file.

  • Logging of changes to UCR variables.

  • Applying settings to configuration files of upgraded software.

UCR does not restart a service. Operators must do that manually.

You can recognize configuration files controlled by UCR by the presence of a header at the beginning of the file, as shown in Listing 1.1. The header lists the template file used to generate the configuration file:

Listing 1.1 Header in configuration files under control of UCR#
# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:

See also

For detailed information about how to use UCR, see the following sections in Univention Corporate Server - Manual for users and administrators [2]:

1.2. Listener modules writing configuration files#

As an operating system utilizing a Domain concept and a Replication concept, the so-called Listener-/Notifier mechanism also generates configuration files based on configuration data in the domain database and UCR.

Changes to UCR don’t trigger a regeneration of those files. Changes to related objects in the domain database, so-called UDM objects, trigger a regeneration, as well as, the command to re-synchronize a listener module.

Important

Unfortunately, listener modules that generate configuration files don’t add a header with a warning to configuration files. For a status, see Bug #56790.

See also

For more information, see the following resources in Univention Corporate Server - Manual for users and administrators [2]:

For more information about the concepts, see the following resources in Univention Corporate Server 5.0 Architecture [1]:

1.3. Consequences of manually editing configuration files#

Editing configuration files manually, as you practice it for other Linux distributions, may bring you closer to your goal. At first glance, you have a good feeling, because the configuration works as expected. The feeling can turn into frustration when the carefully handmade configuration vanished. Software package updates and installation of additional software trigger UCR to regenerate configuration files and therefore overwriting custom changes. Restarting the service, or rebooting the system, activates the changes in the configuration files.

Sometimes the causes of problems are hard to find. Each run of UCR can affect the configuration, overwrite manual changes, and require additional analysis and repair.

The negative consequences range from small effects, such as a service reverting to its default behavior, to key services not running at all. For example, the LDAP server refuses to start, preventing users from signing in their environment and preventing them from doing their daily work.

This brief overview introduces the first principle. Applying it can save you a lot of frustration, effort, and headaches.

Principle #1

Don’t manually edit configuration files that are under control of UCR or listener modules.

1.4. Customize configuration#

Nevertheless, UCS is an open system and wants to enable administrators to customize it to their needs. To avoid problems caused by ignoring UCR, use it to your advantage.

  1. Take existing UCR variables and the UCR mechanism to customize a UCS system to your needs.

To add a custom configuration, not covered by existing UCR variables, use one of the following possibilities:

  1. Modifying UCR templates and customize them to your needs.

    However, keep in mind that the template file is under the control of a software package. After a package update you may need to manually merge your customization with the update that Univention provides for the package. As long as the merge isn’t resolved, the affected service may not work at all.

  2. Use local configuration possibilities such as local.conf files or local configuration directories.

    The local configuration possibilities strongly depend on the service you have in mind and what configuration options it offers.

    Examples:

See also

See the following resources in Univention Corporate Server - Manual for users and administrators [2]