Node Customization

This section describes the customization options/tools for the configuration of Qlustar cluster-nodes.

Dynamic Configuration Settings

As explained above, a number of configuration options are configured dynamically by the QluMan execution server when a node boots. These settings will be stored either in the file /etc/qlustar/options or in a separate file in the directory /etc/qlustar/options.d of the nodes root filesystem. Usual BASH shell syntax is used for the options.

The settings in /etc/qlustar/options as well as the config files generated in /etc/qlustar/options.d should usually not be edited manually. However, when a node has trouble starting certain services or configuring some system components, it can make sense to inspect and possibly change the settings in these files to see whether that solves the problem. Please report such a situation as a bug, so that it can be fixed in a future release.

DHCP-Client

The dhclient process started during the boot process of compute-nodes will configure the IP addresses and other parameters given. By default, only the network interface from which the node boots is managed by DHCP.

Cluster-wide Configuration Directory

The directory /etc/qlustar/common contains cluster-wide configuration files for the nodes. At an early stage of the boot process, this directory is mounted via NFS from the head-node. If required, the path on the head-node this directory is exported from, can be customized with QluMan.

NFS boot scripts

To allow for flexible configuration of compute-nodes, a specific NFS directory (/etc/qlustar/common/rc.boot) is searched for executable scripts in a late phase of the boot process (after unionFS is fully initialized, so that you can use programs from the chroot here as well). The scripts found are then executed one by one. You can use this mechanism to perform arbitrary modifications/customization of the compute node OS.

The scripts placed into /etc/qlustar/common/rc.boot must be executable and conform to the naming standard that the command run-parts defines (see man run-parts on the head-node).

The script /lib/qlustar/copy-files, which is also executed at boot, consults a configuration file /etc/qlustar/common/image-files/destinations, where each line describes a directory to be created, a file to be copied from an NFS path to a local path, or a link that needs to be created in the RAMdisk. Example:

# remotefile is a path relative to /etc/qlustar/common/image-files
# and destdir is the absolute path of the directory where remotefile
# should be copied to. mode is used as input to chmod.
# Example:
# authorized_keys   /root/.ssh    root:root   600

# Directories
/etc/ldap

# remotefile            destdir         owner           permissions
ssh/authorized_keys     /root/.ssh      root:root       644
etc/nsswitch.conf       /etc            root:root       644
etc/ldap.conf           /etc            root:root       644
etc/timezone            /etc            root:root       644

# Symbolic links
# Source                target
/l/home                 /home

This mechanism also allows to specify additional files to be processed by adding an #include line like this:

#include ldapfiles

In this example, the file ldapfile will be consulted just like the destinations file.

Furthermore, if the file /etc/qlustar/common/softgroups exists, it may specify a group name directly (without white-space) followed by a colon, followed by a hostlist. An example softgroups file may look like this:

version2: beo-[01-04]
version3: beo-[05-08]

This will make hosts beo-[01-04] additionally consult the file /etc/qlustar/common/image-files/destinations.version2 and hosts beo-[05-08] the file /etc/qlustar/common/image-files/destinations.version3. The group name defined in the softgroups is the extension to the destinations file. The files could look like this:

# destinations.version2 - use version2 of the program:
/apps/local/bin/program.version2 /usr/bin/program
# destinations.version3 - use version3 of the program:
/apps/local/bin/program.version3 /usr/bin/program

Hence, with this mechanism, you can e.g. have parts of your cluster use different versions of the same program.

Mail Transport Agent

By default the compute-nodes do not send mail. You can however activate the simple MTA ssmtp by assigning the QluMan generic property _Activate Mail to cluster nodes.

The configuration of ssmtp needs to be done in the directory /etc/qlustar/common/ssmtp and consists of two files, ssmtp.conf and revaliases. In ssmtp.conf you should set the following parameters:

Root

The address to send mail to for users with id less than 1000.

Mailhub

The host to send all mail to.

RewriteDomain

Make all mail look like originating from this domain.

FromLineOverride

Allow users to override the domain, must be “yes” or “no”.

Hostname

The fully qualified name of this host

An example configuration file would be:

Root=user@domain.com
Mailhub=relayhost
RewriteDomain=domain.com
FromLineOverride=Yes
Hostname=thishost.domain.com

In the file revaliases, you can specify how mails to local accounts should be forwarded to outgoing addresses and which mail server to use. Example:

user:user@mailprovider.com:mailserver.mailprovider.com

LDAP integration with sssd

The sssd daemon is used if LDAP integration is required for the cluster. The sssd config file /etc/sssd/sssd.conf of the head-node is automatically imported into generated Qlustar images, if one is found. So all you have to do is configure sssd correctly for the head-node, then all other nodes will have a functioning configuration as well, provided they can reach the LDAP server specified in the sssd configuration file.

If a different sssd.conf is needed on cluster nodes, this can be achieved as follows: Assuming the nodes are configured to boot the image named <img1>, you can put the custom sssd.conf for these nodes in the directory /etc/qlustar/images/img1/etc/sssd. This can be done using the qlustar-image-edit tool (see Static node OS image customization/modification for details).