R2
Applications Azure

RSpace 2.26 on Ubuntu 24.04 on Azure User Guide

| Product: RSpace 2.26 on Ubuntu 24.04 LTS on Azure

Overview

RSpace is an open source research data management platform built around an electronic lab notebook. Researchers write up experiments as structured, versioned, auditable documents, attach instrument files and images, and track the physical samples, containers and instruments behind the work in a linked Inventory module. It is designed as the connective tissue of a lab's data: entries can be signed and witnessed, exported, and pushed on to repositories, so the record stays findable and reusable rather than scattered across drives and paper notebooks. Install the cloudimg image and you have your own private lab notebook server ready on first boot.

The image installs RSpace 2.26.0 from the official release WAR on Apache Tomcat 10 under OpenJDK 17, backed by MariaDB, with Apache httpd terminating TLS in front. Tomcat and MariaDB are bound to the loopback interface, so only SSH, HTTP and HTTPS are reachable from off the VM. A unique sysadmin password, database password, monitoring password and TLS certificate are generated on the first boot of every VM, rotating RSpace's published default sysadmin1 and admin credentials, so no VM ever ships with a known credential. The web interface stays sealed behind a holding page until that provisioning finishes. Backed by 24/7 cloudimg support.

What is included:

  • RSpace 2.26.0 deployed from the official upstream release WAR (SHA-256 verified) on Apache Tomcat 10 under OpenJDK 17
  • MariaDB bound to 127.0.0.1, schema initialised from the official RSpace base schema
  • Apache httpd terminating TLS on port 443, with port 80 permanently redirecting to HTTPS
  • Tomcat bound to 127.0.0.1:8080 and never exposed directly
  • A unique sysadmin1 password generated on first boot, recorded in a root only file
  • RSpace's published default credentials (sysadmin1 / sysWisc23! and admin / admin23!) rotated away before the image is ever captured
  • A self signed TLS certificate minted per VM, so no two VMs share a private key
  • Self registration disabled, so only the sysadmin can create accounts
  • The JavaMelody monitoring console restricted to localhost and given a per VM password
  • rspace-set-url, a one line helper for putting your own domain name in front of RSpace
  • mariadb, tomcat10 and apache2 as systemd units, enabled and active
  • 24/7 cloudimg support

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 starting size: RSpace's own guidance is 8 GiB for up to 50 users, and this image runs the Tomcat JVM and MariaDB on the same node. Size up for larger teams and bigger file stores. NSG inbound: allow 22/tcp from your management network and 443/tcp for the web interface; 80/tcp only redirects to HTTPS, so open it if you want that convenience.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for RSpace 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 HTTPS (443). Then Review + create, then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name rspace \
  --image <marketplace-image-urn> \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard \
  --nsg-rule NONE

az vm open-port --resource-group <your-rg> --name rspace --port 22 --priority 1001
az vm open-port --resource-group <your-rg> --name rspace --port 443 --priority 1002

Step 3 - Connect to your VM

ssh azureuser@<vm-ip>

Step 4 - Confirm the services are running

First boot installs this VM's own credentials and certificate before it opens the front door, which takes a couple of minutes. Check that everything is up:

systemctl is-active mariadb tomcat10 apache2 rspace-firstboot
java -version 2>&1 | head -1; dpkg-query -W -f='tomcat10 ${Version}\n' tomcat10; mariadb --version
curl -s -o /dev/null -w 'https://127.0.0.1/login -> HTTP %{http_code}\n' -k https://127.0.0.1/login

All four units report active, and the login page returns 200:

RSpace services active on Ubuntu 24.04, showing MariaDB, Tomcat 10, Apache and the first boot unit, with the login page returning HTTP 200

While first boot is still running, the site deliberately answers 503 with a holding page instead of exposing RSpace before its per VM secrets exist. If you see that page, wait a minute and reload.

Step 5 - Retrieve your per VM credentials

Every credential on this VM is generated on its first boot and written to a root only file:

sudo cat /root/rspace-credentials.txt
sudo stat -c '%a %U:%G %n' /root/rspace-credentials.txt /etc/rspace/deployment.properties /etc/rspace/tls/rspace.key

The per VM RSpace credentials file with passwords masked, showing the sysadmin, database and monitoring accounts and their root only file permissions

The file records the sysadmin login, the secondary admin account, the MariaDB password and the JavaMelody monitoring password. It is 0600 root:root, so only root can read it.

Step 6 - Confirm the shipped defaults are rejected

RSpace publishes its seeded logins in its own documentation, so this image rotates both of them before it is ever captured. You can prove it on your own VM: a failed sign in lands back on /login, a successful one lands on /workspace.

ss -tlnH | awk '{print $1, $4}' | sort -u
bash /opt/rspace/roundtrip.sh

Listening sockets showing only ports 22, 80 and 443 reachable off the VM, both upstream default logins rejected back to the login page, and the credential round trip returning OK

Only 22, 80 and 443 are reachable from off the VM. MariaDB (3306) and Tomcat (8080) are bound to loopback, and both published upstream defaults are redirected straight back to the login page.

Step 7 - Sign in to RSpace

Browse to https://<vm-ip>/ and sign in as sysadmin1 with the password from Step 5. The certificate is self signed and unique to this VM, so your browser warns on the first visit; Step 10 covers installing your own.

The RSpace sign in page served over HTTPS, showing the user and password fields and version 2.26.0 in the footer

Step 8 - Record your first lab notebook entry

You land on the Workspace, which is the root of your notebook. It starts with the seeded Templates, Examples and Shared folders. Choose CREATE, pick Basic Document, give it a name, and write up the experiment in the rich text editor; SAVE then Save & View stores it and shows the read only record.

The RSpace Workspace listing a saved lab notebook entry alongside the Templates, Examples and Shared folders

Every entry gets a permanent identifier (SD41 here), a version history, and slots for attachments and linked inventory items:

A saved RSpace lab notebook entry open in read only view, showing the recorded assay method text, its unique document ID and the attachments panel

Step 9 - Track samples in Inventory

Inventory is the second half of RSpace: containers, samples, subsamples and instruments, each with its own record that notebook entries can link to. Use CREATE in the Inventory sidebar to add your first container or sample template.

The RSpace Inventory module showing the bench view and the containers, samples, subsamples and instruments navigation

Step 10 - Point RSpace at your own domain name

RSpace validates the origin of every save against the address it is configured with, so if you put a DNS name, a load balancer or a reverse proxy in front of this VM you must tell RSpace about it. If you skip this, pages load but saving fails with a 500. The image ships a helper that updates the setting and restarts RSpace for you:

sudo rspace-set-url https://rspace.example.org

To install a CA issued certificate, replace the per VM self signed pair and reload Apache:

sudo install -m 0600 -o root -g root /path/to/privkey.pem /etc/rspace/tls/rspace.key
sudo install -m 0644 -o root -g root /path/to/fullchain.pem /etc/rspace/tls/rspace.crt
sudo systemctl reload apache2

Maintenance

Review the shipped configuration and the state of the file store and database:

grep -vE '^\s*(#|$)' /etc/rspace/deployment.properties | head -14
mariadb -N -B -e "SELECT CONCAT(table_schema,': ',COUNT(*),' tables') FROM information_schema.tables WHERE table_schema='rspace' GROUP BY table_schema;"
du -sh /media/rspace; ls /media/rspace

The RSpace deployment configuration with the database password masked, the database table count, and the contents of the RSpace file store

RSpace's configuration lives in /etc/rspace/deployment.properties; restart with sudo systemctl restart tomcat10 after editing it. Documents, attachments, archives and the search indices live under /media/rspace, and the relational data lives in MariaDB. Back up both: sudo mariadb-dump --single-transaction rspace > rspace.sql alongside an archive of /media/rspace. Self registration is disabled, so create accounts from System then Create Account while signed in as sysadmin1. Ubuntu security updates are applied automatically by unattended-upgrades.

Support

Backed by 24/7 cloudimg support. Email support@cloudimg.co.uk.

RSpace is a trademark of Research Space. This image packages the unmodified open source RSpace release, distributed under the GNU Affero General Public License v3, and cloudimg is not affiliated with or endorsed by Research Space.