Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / Apache Cassandra on Ubuntu 24.04 LTS

Apache Cassandra on Ubuntu 24.04 LTS — Support & Quick Start

Apache Cassandra on Ubuntu 24.04 LTS — Apache Cassandra is a distributed wide-column NoSQL database built for high write throughput and no single point of failure. Published by Derek Coleman & Associates Inc on the Azure Marketplace, deployed in your own Azure subscription.

Known issue on the current image (as of 2026-10-11)

CQL listens on 127.0.0.1 only, so clients on other machines cannot connect: the image leaves Cassandra's `rpc_address` at its upstream default (localhost), even though first boot opens 9042 in the VM firewall and this page tells you to connect to <VM-IP>:9042. (image build tested: 2026.916.1343 (the version the Marketplace publishes today; checked on a deployed VM on 2026-10-11))

What you will see: `cqlsh -u <user> -p <password> <VM-IP> 9042` from another machine fails with connection refused, and `sudo ss -lnt | grep 9042` on the VM shows only 127.0.0.1:9042. Local connections (`cqlsh … 127.0.0.1 9042`) work, and the default cassandra/cassandra account is refused.

Workaround:

  1. This is the change the fixed image makes at first boot; applied by hand on a VM from this image on 2026-10-11, the generated superuser then signed in over the VM's private IP and cassandra/cassandra was refused there. In /etc/cassandra/cassandra.yaml set `rpc_address: 0.0.0.0` and add `broadcast_rpc_address:` with the VM's private IP (Cassandra requires it when rpc_address is 0.0.0.0 — it is the address drivers are told), then restart Cassandra (commands below). If the VM's private IP ever changes, update broadcast_rpc_address.
  2. CQL is not encrypted (client_encryption_options is off): allow 9042 in the NSG only from your client addresses, never from the internet.
PRIV_IP=$(hostname -I | awk '{print $1}')
sudo sed -i -E 's/^rpc_address:.*/rpc_address: 0.0.0.0/' /etc/cassandra/cassandra.yaml
sudo sed -i -E '/^broadcast_rpc_address:/d' /etc/cassandra/cassandra.yaml
echo "broadcast_rpc_address: ${PRIV_IP}" | sudo tee -a /etc/cassandra/cassandra.yaml
sudo systemctl restart cassandra

Fix status: Fixed in image-factory PR #504 (merged 2026-10-11), proven on build 2026.1011.2219: first boot binds CQL to every interface with password authentication only after the default superuser is disabled, keeps broadcast_rpc_address on the VM's private IP at every start, and proves the generated superuser signs in on the VM's private address while cassandra/cassandra is refused there (also confirmed from a second VM in the same virtual network). That image also pins Cassandra 4.1.12 exactly. It is not on the Marketplace yet; until it is, the image you deploy today behaves as described above. Track the fix.

Source: our 2026-10-11 image sweep of the newest published build. This notice is removed when a build that passes the same test is live on the Marketplace.

Fixed on image version 2026.916.1343 (published 2026-09-16)

The image ships a cqlsh that runs on Ubuntu 24.04 / Python 3.12 (the bundled one died with `No module named 'six.moves'`), so first boot can do its job: it creates the per-VM superuser, writes it to /var/lib/cassandra/admin-password, then disables the upstream default `cassandra`/`cassandra` superuser and fails loudly — rather than silently — if any of that does not take.

If you deployed this VM before 2026-09-16, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. SECURITY: on a VM from an earlier image the rotation never ran, so the upstream default `cassandra`/`cassandra` superuser is very likely still active. It listens on loopback only (9042 is not open in the NSG by default) — keep it that way until you have rotated it.
  2. That image's cqlsh cannot connect, so use a current one: `python3 -m venv ~/cql && ~/cql/bin/pip install cqlsh`, then `~/cql/bin/cqlsh -u cassandra -p cassandra 127.0.0.1 9042` and `ALTER ROLE cassandra WITH PASSWORD = '<strong password>';`. Redeploying from the current Marketplace version gives you the rotation done properly.

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-16. New deployments take the newest version by default.

At a glance

Application ports9042 (CQL native transport)
Admin credential filesudo cat /var/lib/cassandra/admin-password
Sign in asdcaadmin-<random> (CASSANDRA_ADMIN_USER in the credential file); the default cassandra/cassandra superuser is DISABLED
Service(s)cassandra
Configuration/etc/cassandra/cassandra.yaml; data in /var/lib/cassandra/
Logsjournalctl -u cassandra -f; /var/log/cassandra/system.log
VersionApache Cassandra 4.1.12 (OpenJDK 11)
PlatformUbuntu 24.04 LTS

Quick start

  1. Deploy from the Azure Marketplace (Get It Now → Create), choosing your SSH key at the Administration step.
  2. Allow inbound SSH (22) for yourself plus the application port(s): 9042 (CQL) — to your application subnets only — restrict to your own IP where possible. The in-image firewall already allows them; only the Network Security Group (NSG) keeps them closed.
  3. Connect with cqlsh using the generated superuser (see First login below), create a keyspace and your application roles.
  4. For a multi-node cluster set seeds / listen_address in /etc/cassandra/cassandra.yaml on each node and restart.

First login / credentials

This image generates its admin credential on the VM at first boot — nothing is pre-set. SSH into the VM with the username + key you chose at deploy, then print the generated credential:

ssh <your-username>@<VM-IP>
sudo cat /var/lib/cassandra/admin-password

Sign in as dcaadmin-<random> (CASSANDRA_ADMIN_USER in the credential file); the default cassandra/cassandra superuser is DISABLED.

  1. Print the credential file: CASSANDRA_ADMIN_USER (per-VM superuser name) and CASSANDRA_ADMIN_PASSWORD.
  2. Connect: cqlsh -u <user> -p <password> <VM-IP> 9042 (locally: cqlsh -u <user> -p <password> 127.0.0.1 9042).
  3. Create application roles with least privilege, then rotate the superuser password (ALTER ROLE … WITH PASSWORD) and delete the file.

The default cassandra/cassandra account is disabled on this image; use the per-VM superuser in the file. Create scoped roles for applications and rotate the superuser password.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.