Aa
Developer Tools Azure

Apache Allura on Ubuntu 24.04 on Azure User Guide

| Product: Apache Allura on Ubuntu 24.04 LTS on Azure

Overview

Apache Allura is the open source project hosting platform, or forge, that powers SourceForge. It gives every project its own space with hosted git, Subversion and Mercurial repositories, a ticket tracker, a wiki, threaded discussion forums, blogs and file release areas, all behind one web application with its own membership and permission model. The cloudimg image ships Apache Allura 1.19.1 from the official ASF release tarball, served by nginx and gunicorn on a hardened, fully patched Ubuntu 24.04 LTS base, with the background task worker, full text search and the datastore already wired together and running. Every secret is minted uniquely on the first boot of each VM, so no credential is ever baked into the image. Backed by 24/7 cloudimg support.

What is included:

  • Apache Allura 1.19.1 (Apache-2.0) installed from the official ASF release tarball
  • nginx on port 80 proxying to a gunicorn application server on 127.0.0.1:8080
  • allura-taskd, the background task worker that builds repositories and search indexes
  • Apache Solr 9.10.1 for full text search, with the upstream configset ported forward to Solr 9
  • FerretDB 2.7.0 providing the MongoDB wire protocol over PostgreSQL 17 with the DocumentDB extension
  • git, Subversion and Mercurial installed so projects can host repositories
  • A per VM administrator password generated on first boot into a root only file
  • No shipped default login, and none of the upstream admin1 / test-user / root test accounts
  • Solr, FerretDB and PostgreSQL all bound to 127.0.0.1 only, never exposed to the network
  • 24/7 cloudimg support

A note on the datastore. Allura speaks the MongoDB wire protocol. This image deliberately does not ship MongoDB Community Server or Percona Server for MongoDB, because both are licensed under the SSPL. The wire protocol is provided instead by FerretDB 2.7.0 (Apache-2.0) backed by PostgreSQL 17 (PostgreSQL Licence) with the DocumentDB extension (MIT). The whole image is permissively licensed: Apache-2.0, MIT, the PostgreSQL Licence and SIL OFL 1.1, with no SSPL, AGPL or GPL component.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2ms (2 vCPU / 8 GiB RAM) is the recommended size for typical use: the forge runs comfortably in less, but a real deployment adds hosted repositories, multiple projects, concurrent users and a growing search index. NSG inbound: allow 22/tcp from your management network and 80/tcp for the forge, plus 443/tcp if you terminate TLS on the VM. Solr, FerretDB and PostgreSQL are never exposed, so ports 8983, 27017 and 5432 stay off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Allura by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22), HTTP (80) and HTTPS (443). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name allura1 \
  --image <marketplace-image-urn> \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open ports 80 and 443:

az vm open-port --resource-group <your-rg> --name allura1 --port 80,443

Step 3 - Confirm the services are running

SSH in as azureuser and confirm all six services are active. The forge is a multi service stack: nginx fronts gunicorn, allura-taskd performs the asynchronous work, and Solr, FerretDB and PostgreSQL back it.

systemctl is-active postgresql ferretdb solr allura-web allura-taskd nginx

Expected output:

active
active
active
active
active
active

Only the web front end is reachable from the network. Confirm that search, the datastore and PostgreSQL are all bound to loopback:

sudo ss -tlnH | grep -E ':(80|8080|8983|27017|5432) ' | awk '{print $4}' | sort -u

All six Allura services active with search, FerretDB and PostgreSQL bound to loopback only

Step 4 - Retrieve the per VM administrator password

Every VM generates a unique administrator password on its first boot and records it in a root only file. Read it over SSH:

sudo ls -l /root/allura-credentials.txt

Expected output shows a root owned file with mode 0600:

-rw------- 1 root root 944 /root/allura-credentials.txt

Then read the file itself to get the forge URL, the administrator user name and its per VM password:

sudo cat /root/allura-credentials.txt

There is no shipped default login. The administrator password, the session signing key, the PostgreSQL role password and the field level encryption key are all regenerated on the first boot of every VM, so no two customer VMs share a secret. Upstream's bootstrap would otherwise create the well known admin1, test-user and root accounts all with the password foo; this image is built with that test data disabled, and the absence of those accounts is verified at build time rather than assumed.

The per VM credentials file exists with mode 0600 and the upstream test accounts are probed and absent

Step 5 - Sign in

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

The Apache Allura password login page

After signing in you land on your dashboard, which lists the projects you administer alongside your tickets, merge requests and recent activity. On a freshly deployed VM this dashboard starts empty; the screenshot below shows it after a couple of projects have been created.

The Allura dashboard listing projects, tickets and recent activity

Step 6 - Register your first project

From the dashboard choose Add Project. Give the project a display name and a short URL name. Project short names are capped at 15 characters and are rejected inline if longer, so pick something concise.

The Allura project registration form

Registration is handed to the background task worker, so give it a few seconds before the project's tools finish provisioning. The new project comes with an activity feed, a wiki, a code repository area, discussion forums, a ticket tracker and an admin section.

A newly registered Allura project with its wiki, code, discussion, tickets and admin tools

Step 7 - Use the wiki and the ticket tracker

Open the project's Wiki tab and choose Create Page. Allura's markdown editor gives you formatting controls, a live preview and attachment support.

Editing an Allura wiki page in the markdown editor

Saving renders the page and records you as its author, with a full revision history behind the page.

A saved Allura wiki page rendered with its author and revision controls

The Tickets tab is the project's issue tracker. Create a ticket with a summary and a markdown description; each ticket carries a milestone, status, owner, labels, voting and a threaded discussion.

An Allura ticket showing its milestone, status, owner and description

Step 8 - Search across the project

Indexing is performed asynchronously by allura-taskd into Apache Solr, so content becomes searchable a few seconds after you save it. Use the project's Search box to search tickets, wiki pages, forum posts and commits together.

An Allura project search returning the indexed ticket with a result count of one

You can confirm the search index directly from the shell. The core reports zero initialisation failures and a real document count, and a query returns real indexed content:

curl -s 'http://127.0.0.1:8983/solr/admin/cores?action=STATUS&wt=json' | head -c 200; echo

The Solr core loads with no initialisation failures and returns real indexed documents

Step 9 - What is installed

Confirm the shipped component versions, and that no SSPL licensed MongoDB package is present:

sudo -u postgres psql -tAc 'show server_version'
echo "MongoDB packages installed: $(dpkg -l | grep -Eic 'mongodb-org|percona-server-mongodb' || true)"

Expected output, showing PostgreSQL 17 and a count of zero:

17.10 (Ubuntu 17.10-1.pgdg24.04+1)
MongoDB packages installed: 0

FerretDB, PostgreSQL, DocumentDB and Solr versions with zero MongoDB packages installed

Security model

  • No default login. No credential is baked into the image. On the first boot of every VM, allura-firstboot.service generates a fresh administrator password, a fresh PostgreSQL role password, a fresh session signing key and a fresh field level encryption key, and records the administrator credential in /root/allura-credentials.txt (mode 0600, root only).
  • Per VM encryption keys. Allura 1.19.1 encrypts sensitive fields client side before they reach the datastore, using a local KMS key. That key is regenerated per VM, so one customer's key can never decrypt another customer's data. Upstream ships a placeholder key that this image always replaces.
  • No test accounts. The upstream bootstrap creates admin1, test-user and root with the password foo when test data is enabled. This image is built with test data disabled and ships with those accounts absent.
  • Loopback only backends. Apache Solr (8983), FerretDB (27017) and PostgreSQL (5432) all bind to 127.0.0.1 only. Keep those ports closed in your NSG.
  • Plain HTTP by default. The forge ships on plain HTTP on port 80 for first contact. Put it behind TLS before exposing it to any untrusted network, and review the new user registration policy before opening the forge up.
  • Fully patched base. The Ubuntu 24.04 LTS base is fully patched at build time and keeps unattended security upgrades enabled on the running VM.

Where your data lives

Allura's documents live in FerretDB, which stores them in PostgreSQL on the OS disk. Project repositories and uploaded files live under /var/lib/allura, the application itself under /opt/allura, and its Python environment under /opt/allura-venv. The search index lives under Solr's data directory and is rebuilt from the datastore if it is ever lost.

sudo du -sh /opt/allura /opt/allura-venv /var/lib/allura

Enable HTTPS (optional)

For production, front the appliance with your own domain and a TLS certificate. Point a DNS record at the VM's public IP, then install a certificate with Certbot:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

After changing the host name that customers use, update the forge's own base URL so that Allura's redirects and notification links point at the right address. Set base_url and domain in /opt/allura/Allura/production.ini, then restart the application:

sudo systemctl restart allura-web allura-taskd

Troubleshooting

A ticket or wiki page saved but does not appear in search. Indexing is asynchronous. Confirm the task worker is running with systemctl is-active allura-taskd, then re-run the search after a few seconds.

A project appears not to have been created. Project registration is also handed to the task worker. Check journalctl -u allura-taskd -n 50 for the registration task, and confirm the short name was 15 characters or fewer.

The forge redirects to an unexpected address. Allura issues absolute redirects built from the base_url set in /opt/allura/Allura/production.ini. If you reach the VM by a different name or address than the one recorded there, update base_url and domain and restart allura-web.

Support

Every cloudimg image includes 24/7 support. If you have any questions about deploying or operating Apache Allura on Azure, contact the cloudimg team.