Apache Archiva on Ubuntu 24.04 on Azure User Guide

Overview

Apache Archiva is a build-artifact repository manager. It stores and serves the binary artifacts your builds produce and consume - Maven (and other) repositories - and can proxy and cache remote repositories such as Maven Central so your CI fleet pulls dependencies from a single fast local mirror. The cloudimg image installs Apache Archiva 2.2.10 as a self-contained standalone distribution: a bundled Jetty servlet container serves the Archiva web application and an embedded Apache Derby database holds the redback security store (users and roles) and the Archiva configuration. Archiva runs as a dedicated archiva service account bound to the loopback connector behind an nginx reverse proxy on port 80, keeps all repository storage, the security database and the search indexes on a dedicated Azure data disk, and generates a unique admin password on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Apache Archiva 2.2.10 (standalone distribution, bundled Jetty) on OpenJDK 8
• The Archiva web console for browsing, searching, uploading and administering repositories
• nginx on :80 as a reverse proxy to the loopback Archiva connector on 127.0.0.1:8080
• A per-VM admin account generated on first boot and recorded in a root-only file
• A dedicated Azure data disk at /var/lib/archiva for repository storage, the redback/Derby security database and the search indexes
• archiva.service (running as the unprivileged archiva user) + nginx.service as systemd units, enabled and active
• An unauthenticated /health endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2ms (2 vCPU / 8 GiB RAM) is a reasonable starting point; size up for larger repositories or busier proxy traffic. NSG inbound: allow 22/tcp from your management network and 80/tcp. Archiva serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Archiva 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 -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name archiva \
  --image <marketplace-image-urn> \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name archiva --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active archiva.service nginx.service

Both report active. Archiva runs as the dedicated archiva user and listens on the loopback connector 127.0.0.1:8080; nginx fronts it on port 80. All repository storage, the redback/Derby security database and the search indexes live on the dedicated Azure data disk mounted at /var/lib/archiva.

Step 5 - Retrieve your admin password

The Archiva admin password is generated uniquely on the first boot of your VM and written to a root-only file:

sudo cat /root/archiva-credentials.txt

This file contains ARCHIVA_ADMIN_USER (admin) and ARCHIVA_ADMIN_PASSWORD, along with the Archiva URL. Store the password somewhere safe.

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -s http://localhost/health

It returns ok. This endpoint never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 7 - Sign in to the Archiva web console

Browse to http://<vm-public-ip>/ and click Login in the top-right. Sign in as admin with the password from Step 5.

Once signed in, the Browse view (under Artifacts) lets you walk the group / artifact / version hierarchy of your managed repositories.

The Search view finds artifacts by coordinates or class name across every repository Archiva manages.

Under Administration -> Repositories you manage the bundled managed repositories (internal, snapshots) and add proxy connectors to remote repositories such as Maven Central.

Step 8 - Verify admin authentication from the command line

Archiva's redback REST API rejects a wrong password and returns the admin user record for the per-VM password. Read the password from the credentials file first, then call the login service. Because the command embeds your unique password, run it interactively rather than from a script - substitute the value of ARCHIVA_ADMIN_PASSWORD from Step 5 for <ARCHIVA_ADMIN_PASSWORD>:

RB=http://127.0.0.1:8080/restServices/redbackServices; curl -s -X POST -H 'Content-Type: application/json' --data '{"username":"admin","password":"<ARCHIVA_ADMIN_PASSWORD>"}' $RB/loginService/logIn

The response is a JSON object beginning {"username":"admin",...}. A wrong password returns an error body with no username field.

Step 9 - Point Maven at your Archiva repositories

Archiva exposes each managed repository under http://<vm-public-ip>/repository/<id>/. To resolve dependencies through Archiva's proxy of Maven Central, add a mirror to your ~/.m2/settings.xml:

<settings>
  <mirrors>
    <mirror>
      <id>archiva-internal</id>
      <name>cloudimg Archiva</name>
      <url>http://<vm-public-ip>/repository/internal/</url>
      <mirrorOf>*</mirrorOf>
    </mirror>
  </mirrors>
</settings>

To deploy your own build artifacts, add distributionManagement pointing at the internal (releases) and snapshots repositories, and a matching <server> credential entry in settings.xml using the admin account (or a dedicated deployment user you create under Administration -> Users).

Step 10 - Confirm repository data lives on the dedicated disk

Archiva's appserver.base - the managed repositories, the redback/Derby security database, the search indexes, configuration and logs - is stored on the dedicated Azure data disk so it survives OS changes and can be resized independently:

findmnt /var/lib/archiva

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM.

Maintenance

• Users and roles: add or rotate accounts under Administration -> Users in the web console, or via the redback REST API.
• Repositories: create managed repositories and proxy connectors under Administration -> Repositories and Proxy Connectors.
• Storage: managed repositories, the Derby security database and the search indexes live under /var/lib/archiva on the data disk; back up that volume to protect your artifacts and configuration.
• Logs: Archiva logs are under /var/lib/archiva/logs on the data disk.
• Tuning: edit the JVM heap (-Xms / -Xmx) in the archiva.service unit (/etc/systemd/system/archiva.service), then sudo systemctl daemon-reload && sudo systemctl restart archiva.
• TLS: Archiva serves plain HTTP on port 80; front it with TLS (e.g. certbot) and your own domain before production use.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.