FOSSology on Ubuntu 24.04 on Azure User Guide

Overview

FOSSology is a mature, open source license compliance toolkit and workflow system. You upload source packages and FOSSology unpacks them and runs its license, copyright and export control scanners (nomos, monk, ojo and copyright) over every file, then presents the findings in a web interface where reviewers clear licenses, record decisions and generate SPDX and compliance reports. It gives engineering and legal teams one place to run and record open source license compliance across the code they ship. The cloudimg image ships FOSSology 4.7.1 served by Apache with PHP on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local PostgreSQL server so the appliance is complete and useful on its own. The web interface is served on port 80 at /repo/. The bundled PostgreSQL listens only on the loopback interface (127.0.0.1:5432) and keeps its data on a dedicated Azure data disk. A unique administrator password, and a unique database secret, are generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• FOSSology 4.7.1 served by Apache 2 with mod_php (prefork), managed by systemd
• A bundled PostgreSQL 16 server holding the FOSSology database, already installed and initialised, with the full reference license knowledge base loaded
• The FOSSology scheduler (fossology.service) driving the scan agents
• The web interface served on :80 at /repo/
• A per VM administrator password generated on first boot and recorded in a root only file
• No shipped default login: FOSSology's well known fossy / fossy default is replaced by a unique per VM secret, and no known or blank credential authenticates
• A per VM PostgreSQL secret: the database role password and the FOSSology Db.conf secret are also rotated on first boot, so nothing is baked into the image
• PostgreSQL bound to 127.0.0.1 only, never exposed to the network
• A dedicated Azure data disk carrying the PostgreSQL cluster and the FOSSology repository, so all of your scan data lives off the operating system disk
• postgresql.service, apache2.service and fossology.service as enabled systemd units
• 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; size up for scanning large packages or busier instances. NSG inbound: allow 22/tcp from your management network and 80/tcp for the FOSSology web interface. FOSSology serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain. The bundled PostgreSQL is never exposed: it listens on 127.0.0.1 only, so port 5432 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for FOSSology 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) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create then Create.

Step 2 - Deploy from the Azure CLI

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

Then open port 80 to the FOSSology web interface:

az vm open-port --resource-group <your-rg> --name fossology --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm PostgreSQL, Apache and the FOSSology scheduler are all active. Note that PostgreSQL listens only on 127.0.0.1:5432 while Apache serves the web interface on port 80.

systemctl is-active postgresql apache2 fossology fossology-firstboot

Expected output:

active
active
active
active

Confirm the listening sockets - Apache is public on :80, PostgreSQL is loopback only:

sudo ss -tlnp | grep -E ':80 |:5432 ' | awk '{print $1, $4}'

LISTEN 127.0.0.1:5432
LISTEN *:80

Step 4 - Retrieve the per VM administrator password

The administrator password is generated on the first boot of this specific VM and written to a root only file. Read it over SSH:

sudo sed -E 's/^(FOSSOLOGY_ADMIN_PASSWORD=).*/\1********/' /root/fossology-credentials.txt | grep -E '^FOSSOLOGY'

FOSSOLOGY_URL=http://<your-vm-ip>/repo/
FOSSOLOGY_ADMIN_USER=fossy
FOSSOLOGY_ADMIN_PASSWORD=********

To see the real password value, read the file without the redaction: sudo cat /root/fossology-credentials.txt. The file is mode 0600, owned by root, so only an administrator can read it.

Step 5 - Sign in to FOSSology

Browse to http://<your-vm-ip>/repo/. Sign in with user fossy and the per VM password from Step 4. FOSSology ships no other usable login.

Step 6 - The FOSSology dashboard

After signing in you land on the Getting Started page, with the top menu giving you Home, Search, Browse, Upload, Jobs, Organize, Admin and Help. This is the hub for uploading packages, scheduling scans, browsing results and administering the instance.

Step 7 - Upload a package to scan

Choose Upload then From File (or From URL / From Server) to add a source package. Pick the analysis agents to run - Nomos and Monk for license scanning, Ojo for SPDX license identifiers, and Copyright/Email/URL/Author analysis - then schedule the job. The scheduler (fossology.service) runs the agents in the background, and the results appear under Browse once the job completes.

Step 8 - The administration area

The Admin menu is where you manage users, groups, folders and the scan agents. The Edit User Account page shows the fossy account as a Full Administrator; from here you set the account password, create additional users, and choose which analysis agents run by default.

Step 9 - No known or default credentials

The cloudimg image ships no usable default login. FOSSology's well known fossy / fossy default is replaced with a unique per VM password (stored as a bcrypt hash with a per user seed), and the PostgreSQL role secret is rotated too. Confirm the stored password is a bcrypt hash and that a seed is set:

sudo -u postgres psql -d fossology -tAc "SELECT user_name, left(user_pass,4) AS algo, (user_seed IS NOT NULL AND user_seed<>'') AS seeded FROM users WHERE user_name='fossy';"

fossy|$2y$|t

Now prove end to end that the per VM administrator authenticates via the web login while the default fossy / fossy and common weak guesses are rejected. The bundled round-trip check does exactly this:

sudo bash /usr/local/sbin/fossology-cred-roundtrip.sh

OK per-VM fossy authenticates via FOSSology web login; default + weak guesses rejected

You can also confirm the per VM password authenticates directly against the login endpoint (the password is substituted from the credentials file):

JAR=$(mktemp)
curl -s -o /dev/null -c "$JAR" -b "$JAR" "http://127.0.0.1/repo/?mod=auth"
curl -s -o /dev/null -c "$JAR" -b "$JAR" --data-urlencode "username=fossy" --data-urlencode "password=<FOSSOLOGY_ADMIN_PASSWORD>" "http://127.0.0.1/repo/?mod=auth"
curl -s -b "$JAR" "http://127.0.0.1/repo/?mod=user_edit" | grep -c "Edit User Account" || true
rm -f "$JAR"

A count of 1 confirms the per VM administrator reached the admin-only User Account page.

Step 10 - Verify the stack and where your data lives

Confirm the web interface answers, the reference license knowledge base is loaded, and that both the PostgreSQL cluster and the FOSSology repository live on the dedicated data disk mounted at /data.

curl -s -o /dev/null -w 'GET /repo/ -> HTTP %{http_code}\n' http://127.0.0.1/repo/
sudo -u postgres psql -d fossology -tAc "SELECT concat(count(*),' reference licenses loaded') FROM license_ref;"
findmnt -no SOURCE,TARGET,FSTYPE /data
findmnt -no SOURCE,TARGET,FSTYPE /var/lib/postgresql

GET /repo/ -> HTTP 200
778 reference licenses loaded
/dev/sdc /data ext4
/dev/sdc[/postgresql] /var/lib/postgresql ext4

The PostgreSQL cluster is bind mounted onto /var/lib/postgresql from the data disk, and the FOSSology repository (where uploaded packages and unpacked file trees are stored) sits at /data/fossology/repository, so all of your scan data lives on the dedicated disk and survives an operating system disk rebuild.

Adding your own domain and TLS

FOSSology is served over plain HTTP on port 80. For production, put a reverse proxy or load balancer in front of it that terminates TLS with your own certificate and domain, and restrict inbound 80/tcp to that proxy. The application itself needs no reconfiguration to sit behind a proxy at /repo/.

Security notes

• The web interface listens on :80; PostgreSQL listens on 127.0.0.1:5432 only and is never exposed to the network. Keep the NSG limited to 22/tcp from your management network and 80/tcp (ideally behind a TLS proxy).
• The administrator password and the database secret are unique per VM, generated on first boot, and stored in /root/fossology-credentials.txt (mode 0600). Change the fossy password from the Admin area after first sign in, or create your own named administrator and disable fossy.
• The operating system is fully patched at build time and unattended security upgrades remain enabled on the running VM.
• Keep the VM patched with sudo apt-get update && sudo apt-get upgrade.

Support

cloudimg images are backed by 24/7 support. If you need help with this image, contact us at support@cloudimg.co.uk.