Home / Support / Apache Cassandra on Ubuntu 24.04 LTS
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.
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:
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 cassandraFix 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.
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:
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.
| Application ports | 9042 (CQL native transport) |
|---|---|
| Admin credential file | 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 |
| Service(s) | cassandra |
| Configuration | /etc/cassandra/cassandra.yaml; data in /var/lib/cassandra/ |
| Logs | journalctl -u cassandra -f; /var/log/cassandra/system.log |
| Version | Apache Cassandra 4.1.12 (OpenJDK 11) |
| Platform | Ubuntu 24.04 LTS |
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-passwordSign in as dcaadmin-<random> (CASSANDRA_ADMIN_USER in the credential file); the default cassandra/cassandra superuser is DISABLED.
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.
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.