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, runapt 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.
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:
./c4 _ preplay -D
Add configuration parameter
Add the following parameter to the c4 configuration file:
CCC_PLAY_ROOTLESS=true
Alternatively, you can add this parameter to the c4 host play
command when you start the installation:
./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.
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:
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):
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:
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):
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:
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.
systemctl --user status c4_cloud_command
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:
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.