Rootless Installation

This article describes additional configuration steps when Exasol is installed with a non-root user.

This article only describes the additional steps that are required for a rootless installation. For the full installation procedure, see Install Exasol - step by step.

The default method of installation for an on-premises deployment of Exasol requires that the installation user on the host systems has root privileges. You can also install Exasol with a non-root user, which is known as a rootless installation.

Rootless installation requires additional system configuration steps on each host before you start the installation. A script that automatically applies most of these steps is embedded in c4 and can be run with a single command. This article describes how to use this script as well as the manual steps that are required to prepare the hosts for a rootless installation.

Prerequisites

In addition to the general system requirements for an on-prem installation of Exasol, a rootless installation requires that the newuidmap and newgidmap tools are installed on the hosts.

  • In Ubuntu 20.04 and later these tools are provided by the uidmap package. To install them, run apt install uidmap.

  • In Red Hat Enterprise Linux 8 and later these tools are preinstalled.

Host preparation

To prepare the hosts for a rootless installation, use the following c4 command to run the preplay script. You must run the script on all hosts.

The script must be run either with sudo or as root. If you are logged in as root, exclude sudo from the command.

Copy 
sudo ./c4 _ preplay <EXASOL_USER>

Replace EXASOL_USER with the username of the Exasol user.

The preplay script does the following:

  • Enables unprivileged user namespaces (if disabled). This is needed to create the namespaces for the COS (Exasol cluster operating system) container.

  • Increases resource limits for the Exasol user. This includes limits for the number of open files, the number of processes, the stack size, and the amount of locked memory.

  • Disables transparent huge pages to prevent problems with sparse mappings in DB memory.

  • Applies a number of sysctl settings to improve performance and stability. For more information, see the script.

To view the contents of the script without executing it, use the following command:

Copy 
./c4 _ preplay -D

Add configuration parameter

Add the following parameter to the c4 configuration file:

Copy 
CCC_PLAY_ROOTLESS=true

Alternatively, you can add this parameter to the c4 host play command when you start the installation:

Copy 
./c4 --ccc-play-rootless true host play -i config

Configure data disks

The disk device files that are configured as database storage drives must be read-writable by the primary user ID or the group ID of the $exasol_uid user. One way to achieve this is to set the user as the owner of the selected data disks using udev rules. This also ensures that the owner is not reset when the machine is rebooted.

The following examples show how to apply the necessary udev rules for physical disks and logical volumes.

The following steps must be performed either with sudo or as root.

Physical disk setup

Example:

This script creates the file /etc/udev/rules.d/90-exasol.rules which sets the user with id 1001 as the owner of the disks nvme1n1 and nvme2n1. The change will be persistent because the rules are run on system startup.

Copy 
exasol_uid=1001
disks=(/dev/nvme1n1 /dev/nvme2n1)

for disk in "${disks[@]}"; do
  disk_basename="$(basename "$(readlink -f "$disk")")"
  owner="$(getent passwd "$exasol_uid" | cut -d: -f1)"

  echo 'KERNEL=="'"$disk_basename"'", OWNER="'"$owner"'"' >> /etc/udev/rules.d/90-exasol.rules
done
Result:
Copy 
cat /etc/udev/rules.d/90-exasol.rules
KERNEL=="nvme1n1", OWNER="exasol"
KERNEL=="nvme2n1", OWNER="exasol"

To apply the rules immediately without having to reboot, run the following command (with sudo or as root):

Copy 
udevadm control --reload-rules && udevadm trigger

Logical volume setup

Example:

If you have two logical volumes at /dev/mapper/vg_name/lv_name and /dev/mapper/vg_name/lv_name2, create the file /etc/udev/rules.d/90-exasol.rules with the following rules:

Copy 
SUBSYSTEM=="block", ENV{DM_VG_NAME}=="vg_name", ENV{DM_LV_NAME}=="lv_name", OWNER="exasol", MODE="0660"
SUBSYSTEM=="block", ENV{DM_VG_NAME}=="vg_name", ENV{DM_LV_NAME}=="lv_name2", OWNER="exasol", MODE="0660"

To apply the rules immediately without having to reboot, run the following command (with sudo or as root):

Copy 
udevadm control --reload-rules && udevadm trigger

Configure huge pages

To achieve the expected database performance and stability, the amount of memory that should be reserved for huge pages must be configured in the vm.nr_hugepages sysctl parameter on each host. The value can be calculated from the database parameters using this formula: 

(DB RAM / number of nodes) - maxSystemHeapMemory

Default maxSystemHeapMemory = 32 GiB.

The vm.nr_hugepages parameter value is the number of pages, not the memory amount. Each huge page is typically 2 MiB, although this can vary depending on the system configuration. For more information, refer to the documentation for your installation platform.

You must also set the parameter vm.hugetlb_shm_group to the group ID of the installation user. The group ID equals to the the numerical subordinate group ID of the installation user (found in /etc/subgid) plus 55553.

To set the required parameters you can use the following script:

Copy 
EXASOL_USER=exasol
NR_HUGEPAGES=12345

GROUP_ID_SUBGID=$(grep -w $EXASOL_USER /etc/subgid | awk -F ":" '{ print $2 }')
HUGETLB_SHM_GROUP=$((GROUP_ID_SUBGID + 55553))

# Write new parameters in a sysctl conf file.
echo -e "vm.nr_hugepages=$NR_HUGEPAGES\nvm.hugetlb_shm_group=$HUGETLB_SHM_GROUP" | sudo tee /etc/sysctl.d/92-exasol-hugepages.conf

# Apply the new parameters.
sudo sysctl --system

Additional usage notes

Interacting with the c4_cloud_command service

In rootless mode, all systemd services that c4 creates are user services belonging to the $exasol_uid user instead of being system services. This means that you do not have to use sudo with the c4_cloud_command service in rootless mode. Instead, you use the systemd commands directly together with the --user flag:

The following commands must be run as the $exasol_uid user.

Copy 
systemctl --user status c4_cloud_command
Copy 
journalctl --user -u c4_cloud_command

Some systems require that the XDG_RUNTIME_DIR variable is exported, in which case you may get errors when trying to run the systemd commands. A workaround is to export the variable before running the commands:

Copy 
export XDG_RUNTIME_DIR=/run/user/$(id -u "$USER")

You can also set XDG_RUNTIME_DIR persistently by including this export in the .bashrc of the $exasol_uid.

Next steps

Continue with the installation procedure as described in Install Exasol - step by step.