Applications Azure

Wavelog Amateur Radio Logbook on Ubuntu 24.04 on Azure User Guide

| Product: Wavelog Amateur Radio Logbook on Ubuntu 24.04 LTS on Azure

Overview

Wavelog is the open source, self hosted amateur radio logbook used by radio amateurs worldwide to log their contacts from any web browser. An enhanced fork of Cloudlog, it lets you log QSOs by hand or straight from your rig over CAT, import and export ADIF and ADX, track DXCC entities, awards and gridsquares, upload to and download from LoTW, eQSL, QRZ and Clublog, run multiple station logbooks, and view band activity, map and statistics dashboards, as well as log contests. The cloudimg image ships Wavelog 3.0.2 served by Apache with PHP 8.3 on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete and useful on its own. The installation wizard is pre completed and locked away, so the logbook is ready the moment the instance boots. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and is never exposed to the network. A unique administrator password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

  • Wavelog 3.0.2 served by Apache with PHP 8.3 and mod_php, managed by systemd
  • A bundled MariaDB server holding the Wavelog database, already installed and ready
  • DXCC reference data pre populated (over 300 entities) and a sample station logbook so the app is usable immediately
  • The installation wizard pre completed and locked away, so no setup wizard is ever exposed (/install returns 403)
  • A per VM administrator password generated on first boot and recorded in a root only file
  • No shipped default login: the administrator password ships rotated to a discarded random and the real per VM password is set on first boot
  • MariaDB bound to 127.0.0.1 only, never exposed to the network
  • A base URL derived from the request, so the site answers correctly on the public IP, the private IP or any DNS name you point at it
  • apache2.service, mariadb.service, wavelog-firstboot.service and cron.service as enabled systemd units
  • A cron entry that runs Wavelog's background tasks (cluster, LoTW and eQSL sync, DXCC refresh) every minute
  • An unauthenticated /healthz endpoint for Azure Load Balancer health probes
  • 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point for a personal or club logbook; move up to Standard_D2s_v3 for very large logs or heavy contest use. NSG inbound: allow 22/tcp from your management network, 80/tcp for the application and 443/tcp if you terminate TLS on the VM. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network.

Step 1 - Deploy from the Azure Marketplace

In the Azure portal choose Create a resource, search for Wavelog Amateur Radio Logbook on Ubuntu 24.04 LTS by cloudimg, and select Create. Pick your subscription, resource group and region, choose the Standard_B2s size, select SSH public key authentication with the username azureuser, and allow inbound 22, 80 and 443. Your logbook data and the MariaDB database live on the OS disk, so you do not need to attach any extra disk.

Step 2 - Deploy from the Azure CLI

The image is launched exactly like any other Marketplace VM. The two commands below create the VM and open the web ports; because they are specific to your subscription they are shown for reference.

az vm create \
  --resource-group <your-rg> \
  --name wavelog \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name wavelog --port 80,443

Step 3 - Confirm the services are running

SSH to the VM as azureuser and confirm Apache, MariaDB, the first boot service and cron are all active. MariaDB is bound to 127.0.0.1:3306 only, while Apache serves on port 80.

systemctl is-active apache2 mariadb wavelog-firstboot cron
ss -tlnp | grep -E ':80 |:3306 ' | sed 's/  */ /g'

The health endpoint answers unauthenticated for the Azure Load Balancer, and an unauthenticated request to / correctly redirects to the Wavelog sign in page (Wavelog requires a login):

curl -s -o /dev/null -w 'GET /healthz -> %{http_code}\n' http://127.0.0.1/healthz
curl -s -o /dev/null -w 'GET / -> %{http_code} (redirect to %{redirect_url})\n' http://127.0.0.1/

The apache2, mariadb, wavelog-firstboot and cron services all reporting active, Apache listening on port 80 and MariaDB bound to loopback 127.0.0.1:3306, the healthz endpoint returning 200 and the root path redirecting to the login page

Step 4 - Retrieve the per VM administrator password

The first boot service generates an administrator password unique to your VM and writes it to a root only file, along with the loopback MariaDB details. Read it over SSH:

sudo cat /root/wavelog-credentials.txt

The per VM Wavelog credentials file showing the admin login user, the generated password masked, the application URL and the loopback MariaDB host, database and user details

WAVELOG_URL is the VM's own address as seen from inside the VM. Azure does not expose the public IP to the instance, so this is usually the private address. Browsing the public IP shown in the Azure portal works identically, because this image derives Wavelog's base URL from the request rather than baking one in at build time:

sudo grep -nE "X_FORWARDED_HOST|base_url" /var/www/wavelog/application/config/config.php | head -3

Step 5 - Sign in

Browse to http://<vm-ip>/ and sign in with the username admin and the password from the credentials file.

The Wavelog sign in page showing the username and password fields and the sign in button

After signing in you land on the dashboard, which summarises your QSO totals, recent activity, band and mode breakdowns and DXCC progress, with the main menu across the top.

The Wavelog dashboard after signing in, showing QSO statistics, recent contacts and band and mode activity tiles

Step 6 - Set up your station

Before logging, set your own station details under Account > Station Logbooks and Account > Station Location: your callsign, gridsquare locator, DXCC entity, CQ and ITU zones, and your rig and antenna. The image ships one starter station logbook so you can log immediately, but setting your real details makes DXCC, award and gridsquare tracking accurate. The same Account area is where you connect external services (LoTW, eQSL, QRZ and Clublog) and manage API keys for CAT and third party logging.

Step 7 - Log and browse your QSOs

The Logbook view lists your logged contacts with a live map of worked stations, and lets you filter, edit and export them. Use QSO or the advanced logbook to log a contact by hand or straight from your rig over CAT, with automatic callsign, DXCC and gridsquare lookup as you type.

The Wavelog logbook view showing logged QSOs in a table alongside a map of worked stations

The Wavelog advanced logbook and QSO logging screen with callsign, band, mode and report fields for logging a contact

To bulk load an existing log, use Import / Export to upload an ADIF or ADX file, and the same screen to export your log for LoTW, eQSL, QRZ, Clublog or a backup. The DXCC reference data needed to resolve entities is already loaded; you can confirm the pre populated reference data and the sample log from the VM:

sudo mariadb --protocol=socket -uroot -N wavelog -e "SELECT CONCAT('DXCC entities: ',COUNT(*)) FROM dxcc_entities;"
sudo mariadb --protocol=socket -uroot -N wavelog -e "SELECT CONCAT('Logged QSOs: ',COUNT(*)) FROM TABLE_HRD_CONTACTS_V01; SELECT CONCAT('Station logbooks: ',COUNT(*)) FROM station_logbooks;"

The pre populated DXCC entity count and the logged QSO and station logbook counts read from the bundled MariaDB

Step 8 - No known or default credentials

This image ships with no usable login. The administrator password baked at build time is rotated to a random value that is discarded and never recorded, and the first boot service sets a fresh password unique to your VM before Apache serves a single request. The admin superuser is the only account that can sign in, and the checks below confirm that the per VM password authenticates through the real Wavelog login form while a blank password and common weak guesses are all rejected. The bundled MariaDB stays bound to loopback only, and the installer is locked away.

sudo mariadb --protocol=socket -uroot -N -e "SELECT CONCAT(user_name,'  (the only Wavelog account that can sign in)') FROM wavelog.users WHERE user_type=99"
sudo bash /usr/local/sbin/wavelog-cred-roundtrip.sh
curl -s -o /dev/null -w 'GET /install/ -> %{http_code} (installer locked)\n' http://127.0.0.1/install/
ss -tlnp | grep ':3306 ' | sed 's/  */ /g'

The admin account as the only Wavelog login, the round trip check confirming the per VM administrator authenticates via the login form while blank and weak guesses are rejected, the installer returning 403, and MariaDB bound to loopback only

Change the administrator password to one of your own under Account once you have signed in for the first time.

Step 9 - Verify the stack and where your data lives

Confirm the application stack and the health endpoint. Your logbook lives entirely on the OS disk: the QSO database in the bundled MariaDB under /var/lib/mysql, and Wavelog's code and uploaded and generated files under /var/www/wavelog.

php -v | head -1; apache2 -v | head -1; mariadb --version
curl -sI http://127.0.0.1/healthz | head -1
df -h --output=source,target,size /var/lib/mysql /var/www/wavelog

Adding your own domain and TLS

Wavelog derives its base URL from the request, so pointing a DNS name at the VM is all that is needed for links and redirects to use that name. No configuration change is required. To terminate TLS on the VM itself, install a certificate with Certbot:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d wavelog.your-domain.com

Certbot configures the Apache virtual host and renews automatically. Wavelog switches its generated links to https:// on its own once requests arrive over TLS, because the base URL follows the request scheme.

If you prefer to pin one fixed public URL instead of following the request, replace the cloudimg host derived block near the end of /var/www/wavelog/application/config/config.php with a single line, for example $config['base_url'] = 'https://wavelog.your-domain.com/';, then reload Apache.

Backing up

Everything that matters is the MariaDB database and the Wavelog files tree. Dump the database and archive the application directory:

sudo mariadb-dump --protocol=socket -uroot --single-transaction --routines wavelog > /var/tmp/wavelog-db-backup.sql
sudo tar -czf /var/tmp/wavelog-files-backup.tar.gz -C /var/www wavelog

For a complete point in time backup, snapshot the VM's OS disk from the Azure portal or CLI.

Security notes

  • The administrator password is unique to every VM, generated on first boot into a 0600 root:root file. No default or shared login ships in the image.
  • The installation wizard is denied from the web (/install returns 403), so the customer never sees a setup wizard.
  • The bundled MariaDB listens on 127.0.0.1:3306 only and is never reachable from the network. On box maintenance uses sudo mariadb as root@localhost over the unix socket, with no password. The Wavelog app connects as wavelog@localhost over the socket with a per VM password held in application/config/database.php.
  • config.php and database.php, which hold the app to database secret and the CodeIgniter encryption key, are denied from the web by the virtual host.
  • The OS is fully patched at build time and unattended security upgrades stay enabled on your VM.
  • Restrict 22/tcp to your management network, and put the site behind TLS before logging over the public internet.

Trademark

Wavelog and Cloudlog are the property of their respective owners. cloudimg is not affiliated with or endorsed by the Wavelog or Cloudlog projects. All product and company names are trademarks or registered trademarks of their respective holders.

Support

cloudimg provides 24/7 technical support for this image by email (support@cloudimg.co.uk) and live chat, with a one hour average response time for critical issues.