Exasol V8, installing it step by step ( with RHEL9 on Azure )

[Malte_Wellbrock]

Hello there everyone,

as some of you might have heared at this years ExaXperience I do have
a habit of running Exasol clusters kind of as a hobby - so, coming from a V7 world
where spinning up an Exasol cluster was either as easy a loading an ISO or using the exa-cloud-tools it was a bit of an adjustment with V8.

That being said and dipping my proverbial toes into Azure I wanted to follow along the

Exasol | Administration | Installation (On-prem) | Install Exasol - step by step
src: Install Exasol - On Premise | Exasol DB Documentation

steps , with RHEL on Azure, to see how that goes and maybe my Xperience is of interest to others and this might turn into a community driven installation

So, since provisioning resources in the cloud can be done in a rather straight forward fashion I did spin up a Standard D4as v6 VM with an 256 GB OSDisk and adding a 4GB DataDisk ( as we all know, start small, scale out ).

This was easy enough and so ( after getting our network set up with “as much default as possible” ) we can now start to ssh into the VM.

Create the Exasol user
I´m actually trying for a root-less install here, so I´m not sure the following steps are strictly necessary, but as there was no mention of them being not required ( only that we need additional steps as documented here Rootless Installation
) I did create a user as easy as sudo adduser -m exasol .

After creating the user I kept with the following command:

sudo usermod -aG sudo exasol
→ yielding “usermod: group ‘sudo’ does not exist”

Now this might just be a peculiarity of me using

@eduvm-01 ~]$ hostnamectl | grep Operating
Operating System: Red Hat Enterprise Linux 9.6 (Plow)

and so I went with the adustment to

@eduvm-01 ~]$ sudo usermod -aG root exasol

This did work, but this would not actually do what the “headline” wanted us to achive, being “add the user to the sudoers group” - so, armed with my very rudimentery Linux knowledge
I adjusted the /etc/sudoers.d/ for the new user in the form of an additional file for the new user with the contents

exasol ALL=(ALL) NOPASSWD:ALL

This did seem to do the trick so that
sudo whoami
→ yields root

**Configure SSH
**
Now it´s time to configure our SSH and running ssh-keygen -t rsa as our newly created user is simple enough.
As I currently only have my single VM I went ahead and did
ssh-copy-id exasol@ because I´m assuming ssh against oneself should be possible in any event.

This led to:

[exasol@eduvm-01 ~]$ ssh-copy-id exasol@10.0.0.4
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/home/exasol/.ssh/id_rsa.pub”
The authenticity of host ‘10.0.0.4 (10.0.0.4)’ can’t be established.
ED25519 key fingerprint is -we-don´t-share-fingerprints-on-the-internet.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys
exasol@10.0.0.4: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

I´m assuming this has to do something with sshd config but I´m anthing but a Linux expert.

This will be it for the time being, as they say, even the longest road begins with the first step.

If this topic is at all of interest to you guys give this post a like and I´ll continue to put updates into the replies.

I used to post much more often in the previous incarnation of the Exasol community so if I´ve gotten a bit rusty do bear with me.

In any case, it´s great we have this platform back (consider me a bit late to the party) and I´m looking forward to be more active here - so, as the documentation clearly states:
Happy Exasolling!

Cheers,
-M.

[juergen_albertsen]

Thanks for sharing, Malte! Curious about where your journey will take you. Not exactly a Linux expert myself, I’m not sure about why you’re getting this error but perhaps somebody else can comment? On a different note, we’re working on an making it easier to install Exasol in different cloud providers. First will be AWS but we will hope to add Azure soon. Stay tuned!

[Bogdan_Mihai]

Hi @Malte_Wellbrock ! It’s good to have you back and posting in our newly Exasol Community!

Can you confirm you’ve worked on the “OS Configuration” part from our documentation? You might have SELinux set to enforcing, please double-check that.

You can also do cat /home/exasol/.ssh/id_rsa.pub >> /home/exasol/.ssh/authorized_keys instead of the ssh-copy-id command.

PS: I forgot to mention - If you are working on a rootless installation you don’t need to add the exasol user to the sudoers file.

Looking forward to your reply!

[Malte_Wellbrock]

Hi everyone,

and thank you @juergen_albertsen & @Bogdan_Mihai for your comments.

Definitely looking forward to anything making cloud provisioning of an Exasol easier, I rather did enjoy the exa-cloudtools - maybe there will be an Exasol-provided and maintained Terraform-generator in the future ? Guess I´ll have to wait and see
I do have a similar thread like this one in mind for a Proxmox-based install, but one story at a time

Thanks to Bogdan´s info our story today continues, as indeed using cat /home/exasol/.ssh/id_rsa.pub >> /home/exasol/.ssh/authorized_keys
did the trick and ssh connectivity was now achived.
I also went back as suggested and checked the OS Configuration, SELinux was actually not set to permissive, and also firewalld was still running so those are 2 potential things that got into my way last time.

So the steps taken today were:

[root@eduvm-01 ~]# getenforce
Permissive

[root@eduvm-01 ~]# systemctl status firewalld
○ firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)

[root@eduvm-01 ~]# dnf install iptables-services
Red Hat CodeReady Linux Builder for RHEL 9 x86_64 (RPMs) from RHUI                                                                           44 MB/s |  14 MB     00:00
Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)                                                                           57 MB/s |  71 MB     00:01
Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)                                                                              75 MB/s |  84 MB     00:01
Red Hat Enterprise Linux 9 for x86_64 - Supplementary (RPMs) from RHUI                                                                       26 kB/s | 3.4 kB     00:00
Microsoft Azure RPMs for Red Hat Enterprise Linux 9 (rhel9)                                                                                  31 kB/s | 2.9 kB     00:00
Dependencies resolved.

Package                                   Architecture               Version                               Repository                                                 Size

Installing:
iptables-nft-services                     noarch                     1.8.10-11.el9_5                       rhel-9-for-x86_64-appstream-rhui-rpms                      24 k

[root@eduvm-01 ~]# systemctl enable iptables
Created symlink /etc/systemd/system/multi-user.target.wants/iptables.service → /usr/lib/systemd/system/iptables.service.
[root@eduvm-01 ~]# systemctl start iptables
[root@eduvm-01 ~]# systemctl status iptables
● iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; preset: disabled)
Active: active (exited) since Fri 2025-10-31 13:07:01 UTC; 5s ago
Process: 2334 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=0/SUCCESS)
Main PID: 2334 (code=exited, status=0/SUCCESS)
CPU: 10ms

[exasol@eduvm-01 ~]$ echo “$SHELL”
/bin/bash

After all this came the part with the ssh copy and that does seem to show that even with permissive SELinx and disabled firewalld the ssh-copy-id didn´t want to help out here, but Bogdan´s cat ( the command, not the animal - don´t even know if he has a cat ) manged to do the trick

[exasol@eduvm-01 ~]$ ssh-copy-id exasol@10.0.0.4
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/home/exasol/.ssh/id_rsa.pub”
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys
exasol@10.0.0.4: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
[exasol@eduvm-01 ~]$ cd ~/.ssh/
[exasol@eduvm-01 .ssh]$ ls -ltr
total 12
-rw-r–r–. 1 exasol exasol 569 Oct 22 17:50 id_rsa.pub
-rw-------. 1 exasol exasol 2602 Oct 22 17:50 id_rsa
-rw-r–r–. 1 exasol exasol 272 Oct 22 17:54 known_hosts
[exasol@eduvm-01 .ssh]$ cat /home/exasol/.ssh/id_rsa.pub >> /home/exasol/.ssh/authorized_keys
[exasol@eduvm-01 .ssh]$ ls -ltr
total 16
-rw-r–r–. 1 exasol exasol 569 Oct 22 17:50 id_rsa.pub
-rw-------. 1 exasol exasol 2602 Oct 22 17:50 id_rsa
-rw-r–r–. 1 exasol exasol 272 Oct 22 17:54 known_hosts
-rw-r–r–. 1 exasol exasol 569 Oct 31 13:12 authorized_keys
[exasol@eduvm-01 .ssh]$ ssh exasol@10.0.0.4
Register this system with Red Hat Insights: rhc connect

Example:

rhc connect --activation-key --organization

The rhc client and Red Hat Insights will enable analytics and additional
management capabilities on your system.
View your connected systems at https://console.redhat.com/insights

You can learn more about how to register your system
using rhc at https://red.ht/registration
Last login: Fri Oct 31 13:10:57 2025
[exasol@eduvm-01 ~]$ exit

Potentially missed a sudo on the ssh-copy-id , but we´re now able to move forward.

Now came the “Prepare storage” step, and our documentation states:

”(…)
How to add physical and logical devices on the hosts is not covered in this documentation. To know how to add and mount disks, refer to the documentation for your operating system.(…)”

Well, ok then - again, not a Linux-aficinado here so the following steps might lack a bit of elegance.

As it was recommended to use the logical volume manager ( lvm ) and check with lsblk -p,
here´s what we start out with in my setup:

[exasol@eduvm-01 ~]$ lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/nvme0n1 259:0 0 256G 0 disk
├─/dev/nvme0n1p1 259:1 0 500M 0 part /boot/efi
├─/dev/nvme0n1p2 259:2 0 1G 0 part /boot
├─/dev/nvme0n1p3 259:3 0 2M 0 part
└─/dev/nvme0n1p4 259:4 0 62.5G 0 part
├─/dev/mapper/rootvg-homelv 253:0 0 19.8G 0 lvm /home
├─/dev/mapper/rootvg-rootlv 253:1 0 2G 0 lvm /
├─/dev/mapper/rootvg-tmplv 253:2 0 2G 0 lvm /tmp
├─/dev/mapper/rootvg-usrlv 253:3 0 10G 0 lvm /usr
└─/dev/mapper/rootvg-varlv 253:4 0 10G 0 lvm /var
/dev/nvme0n2 259:5 0 4G 0 disk
[exasol@eduvm-01 ~]$

The 256G is the OS-disk from Azure, the 4G disk is what some day will become the data disk of this setup ( I do realize this is very much smaller and doesn´t fit with recommendations along the line of “multiple disks” and xyz-Throughput/IOPS - it´s just a start, once I´ve gotten the process right I´ll do this with more Oomph ).

Now, with this we have one rootvg and not much else so I went with:

[exasol@eduvm-01 ~]$ sudo pvcreate /dev/nvme0n2
Physical volume “/dev/nvme0n2” successfully created.
Not creating system devices file due to existing VGs.
[exasol@eduvm-01 ~]$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/nvme0n1p4 rootvg lvm2 a-- 62.50g 18.75g
/dev/nvme0n2 lvm2 — 4.00g 4.00g
[exasol@eduvm-01 ~]$ sudo vgcreate vg_exasol_data /dev/nvme0n2
Not creating system devices file due to existing VGs.
Volume group “vg_exasol_data” successfully created
[exasol@eduvm-01 ~]$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/nvme0n1p4 rootvg lvm2 a-- 62.50g 18.75g
/dev/nvme0n2 vg_exasol_data lvm2 a-- <4.00g <4.00g
[exasol@eduvm-01 ~]$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
rootvg 1 5 0 wz–n- 62.50g 18.75g
vg_exasol_data 1 0 0 wz–n- <4.00g <4.00g

[exasol@eduvm-01 ~]$ sudo lvcreate --name lv_exasol_data --size 3g vg_exasol_data
Logical volume “lv_exasol_data” created.
[exasol@eduvm-01 ~]$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
homelv rootvg -wi-ao---- 19.75g
rootlv rootvg -wi-ao---- 2.00g
tmplv rootvg -wi-ao---- 2.00g
usrlv rootvg -wi-ao---- 10.00g
varlv rootvg -wi-ao---- 10.00g
lv_exasol_data vg_exasol_data -wi-a----- 3.00g
[exasol@eduvm-01 ~]$ lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/nvme0n1 259:0 0 256G 0 disk
├─/dev/nvme0n1p1 259:1 0 500M 0 part /boot/efi
├─/dev/nvme0n1p2 259:2 0 1G 0 part /boot
├─/dev/nvme0n1p3 259:3 0 2M 0 part
└─/dev/nvme0n1p4 259:4 0 62.5G 0 part
├─/dev/mapper/rootvg-homelv 253:0 0 19.8G 0 lvm /home
├─/dev/mapper/rootvg-rootlv 253:1 0 2G 0 lvm /
├─/dev/mapper/rootvg-tmplv 253:2 0 2G 0 lvm /tmp
├─/dev/mapper/rootvg-usrlv 253:3 0 10G 0 lvm /usr
└─/dev/mapper/rootvg-varlv 253:4 0 10G 0 lvm /var
/dev/nvme0n2 259:5 0 4G 0 disk
└─/dev/mapper/vg_exasol_data-lv_exasol_data 253:5 0 3G 0 lvm

For a rootless install the user needs to have device r/w privileges as documented in the “rootless install prerequisites” part of the documentation, so I created the following:

[exasol@eduvm-01 ~]$ sudo vi /etc/udev/rules.d/90-exasol.rules
SUBSYSTEM==“block”, ENV{DM_VG_NAME}==“vg_exasol_data”, ENV{DM_LV_NAME}==“lv_exasol_data”, OWNER=“exasol”, MODE=“0660”
[exasol@eduvm-01 ~]$ sudo udevadm control --reload-rules && udevadm trigger
0006:045E:0621.0001: Failed to write ‘change’ to ‘/sys/devices/0006:045E:0621.0001/uevent’: Permission denied
input1: Failed to write ‘change’ to ‘/sys/devices/0006:045E:0621.0001/input/input1/uevent’: Permission denied
event1: Failed to write ‘change’ to ‘/sys/devices/0006:045E:0621.0001/input/input1/event1/uevent’: Permission denied
js0: Failed to write ‘change’ to ‘/sys/devices/0006:045E:0621.0001/input/input1/js0/uevent’: Permission denied
mouse0: Failed to write ‘change’ to ‘/sys/devices/0006:045E:0621.0001/input/input1/mouse0/uevent’:

There came quite a few lines of errors regarding “Permission denied” , so as I already used the magic word ( i.e. sudo ) I opted for a simple reboot in order to get the udev refreshed.

Now came the time to check if c4 thinks my config is “worthy”:

[exasol@eduvm-01 ~]$ ./c4 host diag -i myconfig
OK check_disks
OK check_external_dependencies
SKIPPED check_internal_rootless_dependencies: root-based deployment enabled
OK check_login_defs_umask
OK check_required_params
OK check_root_umask
OK check_selinux
OK check_sudo
OK check_time_sync
OK check_unprivileged_userns_clone
OK check_user_umask
[exasol@eduvm-01 ~]$ vi myconfig
[exasol@eduvm-01 ~]$ ./c4 host diag -i myconfig
OK check_disks
OK check_external_dependencies
OK check_internal_rootless_dependencies
OK check_login_defs_umask
OK check_required_params
SKIPPED check_root_umask: rootless deployment enabled
SKIPPED check_selinux: rootless deployment enabled
SKIPPED check_sudo: rootless deployment enabled
OK check_time_sync
OK check_unprivileged_userns_clone
OK check_user_umask
[exasol@eduvm-01 ~]$

That did seem promising , but remembering that exasol would like to have a bit of storage left at the location it´s installed ( which if I understand correctly by default would be /home/exasol ) I did enlarge the storage layout to get to:

[exasol@eduvm-01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 3.1G 17M 3.1G 1% /run
/dev/mapper/rootvg-rootlv 2.0G 72M 1.9G 4% /
/dev/mapper/rootvg-usrlv 10G 2.0G 8.1G 20% /usr
/dev/nvme0n1p2 960M 177M 784M 19% /boot
/dev/mapper/rootvg-tmplv 2.0G 47M 1.9G 3% /tmp
/dev/mapper/rootvg-varlv 10G 491M 9.5G 5% /var
/dev/nvme0n1p1 500M 7.1M 493M 2% /boot/efi
/dev/mapper/rootvg-homelv 30G 428M 29G 2% /home
tmpfs 1.6G 0 1.6G 0% /run/user/1000
[exasol@eduvm-01 ~]$

And now for the actual install ( I did scrap the public IP in the following log ) :

[exasol@eduvm-01 ~]$ ./c4 --ccc-play-rootless true host play -i myconfig
INFO[2025-10-31 14:15:54] Creating new host deployment…
INFO[2025-10-31 14:15:54] Done reading configuration.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Exasol installation procedure is about to be started.
During this procedure, Exasol software will be installed to remote hosts.
It will take some time (several minutes).
After the installation is finished, you can connect to the Database or COS.

During the installation, you can login to the hosts via SSH,
and watch the process using:

sudo journalctl -f

After the installation finished, you can connect to COS using:

ssh -p 20002 root@$IP

IP addresses used for the deployment:

* public-ip-redacted

Exasol version: 2025.1.0
Exasol package: @exasol-2025.1.0
SSH username : exasol
SSH keyfile : id_rsa
Data disk(s) : /dev/mapper/vg_exasol_data-lv_exasol_data

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
INFO[2025-10-31 14:15:54] Cleaning up…
Failed to stop c4_cloud_command.service: Unit c4_cloud_command.service not loaded.
INFO[2025-10-31 14:15:55] Done cleaning up.
INFO[2025-10-31 14:15:55] Initial OS preparation
INFO[2025-10-31 14:15:55] Skipping sudoers preparation: rootless installation enabled
WARN[2025-10-31 14:15:55] CCC_HOST_IMAGE_PASSWORD will be ignored: rootless installation enabled
INFO[2025-10-31 14:15:55] Veryfing OS configuration…
INFO[2025-10-31 14:15:55] Skipping sudo check: rootless installation enabled
INFO[2025-10-31 14:15:55] OS on all hosts is configured properly
INFO[2025-10-31 14:15:55] Fetching Exasol packages…
✓ exasol-2025.1.0.tar.gz [==================] 100% 6.9 GiB 12 MiB/s
INFO[2025-10-31 14:28:28] Done fetching Exasol packages.
INFO[2025-10-31 14:28:28] Copying Exasol packages to remote hosts…
INFO[2025-10-31 14:28:29] Done copying Exasol packages to remote hosts.
INFO[2025-10-31 14:28:29] Extracting packages…
INFO[2025-10-31 14:31:28] Done extracting packages.
INFO[2025-10-31 14:31:28] Syncing time…
INFO[2025-10-31 14:31:28] Skipping time syncing (assuming time is already synced): rootless installation enabled
INFO[2025-10-31 14:31:28] Done syncing time.
INFO[2025-10-31 14:31:28] Installing the secret and SSH keys…
INFO[2025-10-31 14:31:29] Done installing the secret and SSH keys
INFO[2025-10-31 14:31:29] Running installation…
INFO[2025-10-31 14:31:29] Creating new host deployment…
INFO[2025-10-31 14:31:29] Done
N PLAY_ID NODE MEDIUM INSTANCE DB_VERSION EXTERNAL_IP INTERNAL_IP STAGE STATE UPTIME TTL
1 ecdde6a6 11 host - - x.yyy.zzz.qq 10.0.0.4 a - 00:00:00 +∞
INFO[2025-10-31 14:31:29] Done running installation.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

The final steps of the Exasol installation procedure were successfully
started on remote hosts now.
It will take yet some time to complete (several minutes).
The installation is finished when every node reaches stage ‘d’ (see ‘c4 ps’).
After the installation is finished, you can connect to the Database or COS.

During the installation, you can login to the hosts via SSH,
and watch the process using:

sudo journalctl -f

After the installation finished, you can connect to COS using:

ssh -p 20002 root@$IP

IP addresses used for the deployment:

* public-ip-redacted

Exasol version: 2025.1.0
Exasol package: @exasol-2025.1.0

Happy Exasolling!

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Now one would expect a functional Exasol database, but it would seem I managed to introduce some misconfiguration yet, because:

[exasol@eduvm-01 ~]$ ./c4 ps
WARN[2025-10-31 14:37:26] in ps.NewLister: in aws.NewConfigFromConfig: credentials file does not exist: /home/exasol/.aws/credentials module=awscf
WARN[2025-10-31 14:37:26] in ps.NewLister: in aws.NewConfigFromConfig: credentials file does not exist: /home/exasol/.aws/credentials module=aws
N PLAY_ID NODE MEDIUM INSTANCE DB_VERSION EXTERNAL_IP INTERNAL_IP STAGE STATE UPTIME TTL
1 ecdde6a6 11 local - 2025.1.0 - 10.0.0.4 a1 - 00:41:07 +∞
[exasol@eduvm-01 ~]$ c4 connect -t 1/cos
ssh: connect to host public-ip-redacted port 20002: Connection timed out

So my “cluster of one” does seem to be stuck in the a1 stage and a c4 connect to the COS doesn´t work ( which might have something to do with my Azure setup ).

I was slightly surprised to see the public IP in the COS connect - need to wrap my head around this one, I guess I´m confusing “public IP” in the Azure-sense with “public IP” in the Exasol sense ( the first leaning more into the “web-exposed” side of things, while the second is more in the direction of “client facing” , which in this setup isn´t really interchangeable ).

So there you have it, we´ve got a running cluster that for now does not want to talk to us - I think we´re getting close

Will update this as soon as I get a chance - all feedback, comments and critique welcome !

Cherrs,
-M.

[juergen_albertsen]

@Malte_Wellbrock We will announce the new cloud installer in this webinar: Product Innovation Summit 2025 | Explore what's new in Exasol . So if you haven’t registered yet, make sure you do! I’d also be interested in beta testers. Like I said, we’re focussing on AWS for the moment, but we’re using Terraform so perhaps you could even bet interested in developing Azure scripts. If you are, DM me and we can talk.

[Bogdan_Mihai]

@Malte_Wellbrock - Thanks for the detailed reply with the included output.

• Please share the output of this command > systemctl --user status c4_cloud_command

• After the installation is complete c4 gets copied into local user’s $PATH (/home/exasol/.local/bin/c4), so you’ll need to use c4 ps instead of ./c4 ps.

• Regarding the public IP, can you check if you added it to the myconfig file as CCC_HOST_EXTERNAL_ADDRS ?

• If I’m not mistaken the default installation creates a persitent volume of 8 GiB. Can you try adding more storage and retry the installation?

Note: I recommend uninstalling Exasol before reinstalling it with more storage.

Looking forward to your response.

[Malte_Wellbrock]

Hello everyone,

sooo, 7 days past and a lot has happend, the culmination of which is that I can now indeed connect to a running EXA8 instance (with certain limitations)

But let´s start where we last left off:

After reading @Bogdan_Mihai input I very much suspected that the missing storage is our culprit, in combination with my confusion about “pubic IP” - in order to get around any uninstall shenanigans I simply restored OS- and DataDisk in Azure from a RestorePoint I set right before I did the c4 based install ( we skip the part where I forgot to enlarge the /home directory leading to many fun “not enough space” messages during install and jump right to the 2nd try ).

With my eduvm-01 now armed with a 16GB DataDisk ( and the necessary lvm actions done ), a secondary network interface attached ( for the external_addr ) and adjusted config-file ( external_addr now carried the seconds NIC instead of the “public IP” assigned through Azure ) I was ready to repeat the install - went right through, and this time, after we were done installing, a call to “c4 ps” yielded a progressively positive progress on our cluster stage up to “d”, meaning “database up and connectable”.
Still don´t quite understand why calling the copied c4 yields a different output than the “original one”, as in:

[exasol@eduvm-01 ~]$ ./c4 ps
WARN[2025-11-10 20:27:53] in ps.NewLister: in aws.NewConfigFromConfig: credentials file does not exist: /home/exasol/.aws/credentials module=awscf
WARN[2025-11-10 20:27:53] in ps.NewLister: in aws.NewConfigFromConfig: credentials file does not exist: /home/exasol/.aws/credentials module=aws
N PLAY_ID NODE MEDIUM INSTANCE DB_VERSION EXTERNAL_IP INTERNAL_IP STAGE STATE UPTIME TTL
1 fb5aed03 11 local - 2025.1.0 - 10.0.0.4 a1 - 00:38:49 +∞
[exasol@eduvm-01 ~]$ c4 ps
N PLAY_ID NODE MEDIUM INSTANCE DB_VERSION EXTERNAL_IP INTERNAL_IP STAGE STATE UPTIME TTL
1 fb5aed03 11 host - 2025.1.0 10.0.100.4 10.0.0.4 d - 00:38:55 +∞
2 fb5aed03 11 local - 2025.1.0 - 10.0.0.4 d - 00:38:54 +∞

As for the systemctl output, that also turned out to be a bit of a conundrum - at the “host” level, we got

[exasol@eduvm-01 ~]$ systemctl --user status c4_cloud_command
Failed to connect to bus: No medium found

Also didn´t change with the “magic word” ( i.e. sudo ).

Within the COS systemctl doesn´t exist:
[exasol@eduvm-01 ~]$ c4 connect -t 1/cos
Last login: Mon Nov 10 21:13:38 2025 from 10.0.100.4
root@n11:~# systemctl --user status c4_cloud_command
-bash: systemctl: command not found

Trying that is more due to my lack of knowledge, if I understand it correctly, then c4 ( and by extension c4_cloud_command ) is kind of an isolation layer so it would only make sense for it to only be present on the actual “host” layer.

With a bit of research work I dug up somthing that at least yielded an output, and presumably attests to the fact that “all is running well”:

[exasol@eduvm-01 ~]$ sudo systemctl --user -M exasol@ status c4
● c4.service - c4 server
Loaded: loaded (/home/exasol/.config/systemd/user/c4.service; enabled; preset: disabled)
Active: active (running) since Mon 2025-11-10 19:49:14 UTC; 46min ago
Main PID: 1724
Tasks: 8 (limit: 100168)
Memory: 82.1M
CPU: 265ms
CGroup: /user.slice/user-1001.slice/user@1001.service/app.slice/c4.service
├─1724 /bin/bash /home/exasol/.ccc/ccc/etc/c4
└─1727 /home/exasol/.ccc/ccc/bin/c4 server --socket /home/exasol/.ccc/ccc/etc/c4_socket
[exasol@eduvm-01 ~]$ sudo systemctl --user -M exasol@ status c4_cloud_command
● c4_cloud_command.service - c4 init service
Loaded: loaded (/home/exasol/.config/systemd/user/c4_cloud_command.service; enabled; preset: disabled)
Active: active (running) since Mon 2025-11-10 19:49:14 UTC; 46min ago
Main PID: 1725
Tasks: 651 (limit: 100168)
Memory: 1.4G
CPU: 41min 367ms
CGroup: /user.slice/user-1001.slice/user@1001.service/app.slice/c4_cloud_command.service
├─ 1725 /bin/bash /home/exasol/.ccc/ccc/etc/c4_cloud_command
├─ 2065 /home/exasol/.ccc/ccc/bin/c4 play @exasol-2025.1.0
├─ 2103 bash -c “main ‘@exasol-2025.1.0’”
├─ 2900 python3 /home/exasol/.ccc/x/u/branchr/saas-650d33b7-64r/.c4/play start
├─ 3073 python3 /home/exasol/.ccc/x/u/branchr/cos+86168de4-95cb568b-64r/.c4/play start
├─ 3254 /home/exasol/.ccc/x/u/branchr/cos+86168de4-95cb568b-64r/install/opt/exasol/cos-8.60.3/sbin/exact mount /home/exasol/.ccc/play/local/fb5aed03-6f45-433e-9b51-e6fbdae2e1b5/main/11/changes /home/exasol/.ccc/play/local/fb5aed03-6f45-433e-9b51-e6fbdae2e1b5/main/11/root /home/exasol/.ccc/play/local/fb5aed03-6f45-433e-9b51-e6fbdae2e1b5/main/11/data init-sc -i 11
├─ 3255 /opt/exasol/cos-8.60.3/libexec/cos_cored -n 11 --auth-sock-dir /var/lock -m 224.0.0.1 -s 10.0.0.4 -t 3250 -l /exa/logs/cored --node-uuid FB5AED036F45433E9B51E6FBDAE2E1B500000011 --default-file-mode 600 --with-strict-node-id --allow-only-same-subnet --canary-timeout=90 --canary-grace-period=300 --random=/exa/etc/cored_random /opt/exasol/cos-8.60.3/bin/exainit stage2
├─ 3264 tail -n0 -q -F /exa/logs/cored/exainit.log /exa/logs/cored/cored.log
├─ 3279 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/libexec/super_cored -d -a
├─ 3512 “sshd: /usr/sbin/sshd -D [listener] 0 of 300-800 startups”
├─ 3515 /usr/sbin/cron -f “-L 15”
├─ 3516 /opt/exasol/cos-8.60.3/libexec/logd --default-log-dir /exa/logs/logd
├─ 3517 /opt/exasol/cos-8.60.3/libexec/lockd
├─ 3563 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/libexec/bucketfsd --config=/exa/etc/bucketfs.cfg_bfsdefault
├─ 3565 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/bin/healthd
├─ 3566 /opt/exasol/cos-8.60.3/libexec/dwad --backupfile /exa/metadata/dwad/dwad.dump --store-config /exa/metadata/dwad/dwad.dump --store-interval 10 --allow-runtime-rename=cluster --upgrade-cluster-uuid-mapping=Exasol:hu5xANVgRoaEPBYEgX-jFg
├─ 3635 /opt/exasol/cos-8.60.3/libexec/cos_storage /exa/etc/cos_storage.conf
├─ 3723 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/bin/confd -v
├─ 3777 /opt/exasol/cos-8.60.3/share/webui_backend/db-restapi start --addr :4444 --disable-redirect --rpc-endpoint ``https://localhost:20003`` tls --certFile /exa/etc/ssl/ssl.crt --keyFile /exa/etc/ssl/ssl.key
├─ 3814 /opt/exasol/db-2025.1.0/bin/controller -dbName Exasol -current_cluster_name MAIN -current_cluster_uid hu5xANVgRoaEPBYEgX-jFg -commMain n11 -commNPROC 1 -port 8563 -mode rw -outputdir /exa/logs/db/Exasol/ -additionalAuthorizedSysPasswordHashes=OhNoYouDon´t -netmask= -auditing_enabled=1 -builtinScriptLanguageName=slc-9.5.2_c4_7_standard_EXASOL_all_r_4.4/Scr>
├─ 3850 /opt/exasol/db-2025.1.0/bin/pddserver -current_process_nr=1
├─ 3946 /opt/exasol/db-2025.1.0/bin/objectserver -current_process_nr=2
├─ 3995 /opt/exasol/db-2025.1.0/bin/exasqllog -current_process_nr=4
├─ 4023 /opt/exasol/db-2025.1.0/bin/loaderd -current_process_nr=5
├─ 4050 /opt/exasol/db-2025.1.0/bin/exaetl -current_process_nr=1024
├─ 4051 /opt/exasol/db-2025.1.0/bin/exacs -current_process_nr=3
├─ 4132 /opt/exasol/db-2025.1.0/bin/exasql -current_process_nr=7
├─ 4171 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/bin/eventd
├─ 4196 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/bin/rapid --wait-init --port 8000 --root-path /api/v1
├─ 4330 /opt/exasol/cos-8.60.3/bin/python3_cos -c “from multiprocessing.resource_tracker import main;main(114)”
├─ 97088 /usr/sbin/anacron -s
├─105193 /bin/sh -c “run-parts --report /etc/cron.daily”
├─105194 run-parts --report /etc/cron.daily
├─105198 /bin/sh /etc/cron.daily/apt-compat
├─105213 sleep 1352
└─106035 /opt/exasol/cos-8.60.3/bin/python3_cos /opt/exasol/cos-8.60.3/bin/confd_client db_list --json --volatile

And with all that, I could finally get some SQL going:

EXA: select substr(cluster_name,1,6) as cluster_name,to_char(measure_time,'…

CLUSTE MEASURE_TIME     EVENT_TYPE                               DBMS_VERSION                   NODES   DB_RAM_SIZE




MAIN   08.11.2025 12:09 STARTUP                                  2025.1.0                             1         11.3
MAIN   08.11.2025 13:40 SHUTDOWN                                 2025.1.0                             1         11.3
MAIN   10.11.2025 20:49 STARTUP                                  2025.1.0                             1         11.3

3 rows in resultset.

Now I just need to figure out why this is only working with an EXAplus on the host itself, but not from a Windows-VM within the same subnet, even though the NetworkSecurityGroup should allow any traffic in the same vnet…oh well, we do have a running “cluster of one” at least, next short-term target is getting a screenshot from the new Admin-UI ( I already see the system listening on the corresponding port, so I can´t be that far off ).

That´s it for now, hope this will help anyone trying anything similar to this, and I´ll keep updates coming.

Cheers,
-M.

[Bogdan_Mihai]

Hi @Malte_Wellbrock . I’m happy to hear you got the installation done in one-go this time around.

When executing the script from the current working directory (./c4), the script expects a config file, something that contains details about the deployment, hence those WARNING messages.

While you execute the script c4 from PATH (/home/exasol/.local/bin/c4), the script looks at the config file $INSTALL_DIR/.ccc/ccc/etc/c4.yaml, and it already has the details about the deployment, hence it will show what it needs to show.

Did you try to connect to the DB using the default port 8563? Does the security group allow communication over that port?

I will happily assist you if you have any further questions

Bye for now!