Developer Tools Azure

Open OnDemand on Ubuntu 24.04 on Azure User Guide

| Product: Open OnDemand on Ubuntu 24.04 LTS on Azure

Overview

Open OnDemand is an open source web portal, created by the Ohio Supercomputer Center, that puts a research computing environment in the browser. Instead of asking every user to master SSH, batch schedulers and remote file transfer, it presents one authenticated dashboard from which people browse and edit their files, open a live terminal, compose and submit jobs to a scheduler, watch those jobs run, and launch interactive apps. The cloudimg image ships Open OnDemand (licensed under the MIT License) on a hardened, fully patched Ubuntu 24.04 LTS base, fronted by Apache with Phusion Passenger. To make it a self contained appliance, the image also bundles a single node Slurm cluster (with accounting) so that jobs launched from the portal actually run on the VM itself, with no external cluster required. The web front door is gated by an HTTP Basic credential that is generated uniquely on the first boot of every VM, so no known or default password ships in the image. Backed by 24/7 cloudimg support.

cloudimg is not affiliated with, endorsed by, or sponsored by the Ohio Supercomputer Center or the Open OnDemand project. Open OnDemand is used here only to identify the open source software packaged in this image.

What is included:

  • Open OnDemand 4.2 (MIT), installed from the official OSC package repository, with the Dashboard, File Manager, browser Shell, Job Composer, Active Jobs and Interactive Apps
  • A self contained single node Slurm cluster named cluster (Slurm and slurmdbd are GPL-2.0), with accounting backed by a local MariaDB bound to 127.0.0.1, so jobs submitted from the portal run on this VM
  • Apache with Phusion Passenger serving each signed in user their own Per User NGINX (PUN)
  • HTTP Basic authentication over a per VM credential generated on first boot and recorded in a root only file, mapped to the local Linux user demo
  • No known login: the image ships with an empty credential store, so every login is refused until first boot writes the per VM secret, and the demo OS account has a locked password
  • A per VM Slurm authentication (munge) key and a hostname correct scheduler configuration, both regenerated on first boot
  • An unauthenticated /public/healthz endpoint on port 80 for Azure Load Balancer probes
  • Enabled systemd units for Apache, munge, MariaDB, slurmdbd, slurmctld and slurmd, so the portal and scheduler start on every boot
  • 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 evaluation and light use; size up for more concurrent users or heavier jobs. NSG inbound: allow 22/tcp from your management network and 80/tcp for the web portal. The portal is served over plain HTTP on port 80; for production, place your own TLS certificate, a reverse proxy, or an Azure Application Gateway or Load Balancer with a managed certificate in front of the appliance, and consider wiring Open OnDemand to your own identity provider.

Step 1 - Deploy from the Azure Marketplace

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

Step 2 - Deploy from the Azure CLI

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

Then open port 80 to the web portal:

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

Step 3 - Confirm the portal and scheduler are running

SSH in as azureuser and confirm the web tier and the single node Slurm cluster are active. Apache serves the portal; munge provides Slurm authentication; MariaDB and slurmdbd provide Slurm accounting (which Open OnDemand's job views depend on); slurmctld and slurmd are the Slurm controller and compute daemon. sinfo should report the single node in the cluster partition as idle.

systemctl is-active apache2 munge mariadb slurmdbd slurmctld slurmd
sinfo
sudo ss -tlnp | grep -E ':80 '

The apache2, munge, mariadb, slurmdbd, slurmctld and slurmd services reported active, the sinfo output showing the single node cluster partition idle, and the installed Open OnDemand version

Step 4 - Retrieve the per VM web credential

The web login is generated uniquely on the first boot of every VM and written to a root only file. Read it over SSH. The username is demo and the password is unique to your VM; the file also records the portal URL built from your VM's public IP.

sudo cat /root/open-ondemand-credentials.txt

The file is mode 0600, owned by root, and contains WEB_USER, WEB_PASSWORD and ONDEMAND_URL. There is exactly one web principal (demo), and the demo operating system account has a locked password, so no default operating system user can sign in to the portal or its browser shell.

The per VM credentials file shown with mode 0600 root owned, the ONDEMAND_URL built from the VM public IP, WEB_USER demo and the WEB_PASSWORD masked, and confirmation that the htpasswd holds exactly one principal and the demo OS account is locked

You can confirm the portal answers on the loopback interface with the credential (replace the placeholders with the values from the file above):

curl -s -o /dev/null -w 'dashboard: HTTP %{http_code}\n' -u '<WEB_USER>:<WEB_PASSWORD>' http://127.0.0.1/pun/sys/dashboard/

An unauthenticated request is rejected, which confirms the portal is not open:

curl -s -o /dev/null -w 'no credential: HTTP %{http_code}  (expect 401)\n' http://127.0.0.1/pun/sys/dashboard/

Step 5 - Sign in to the dashboard

Open the ONDEMAND_URL from the credentials file in your browser (http://<your-vm-public-ip>/). Your browser prompts for the HTTP Basic credential; enter demo and the per VM password. Open OnDemand signs you in as the Linux user demo and launches your Per User NGINX. The dashboard is the single access point to the File Manager, Jobs, Clusters and Interactive Apps.

The authenticated Open OnDemand dashboard with the top navigation for Files, Jobs, Clusters and Interactive Apps, showing the single access point landing page and the Open OnDemand version

Step 6 - Browse and manage your files

From Files choose Home Directory to open the File Manager. It lists your home directory and lets you upload, download, rename, edit and delete files, create directories, and open a terminal in the current location. Everything here runs as your Linux user, with your own permissions.

The Open OnDemand File Manager listing the demo home directory with the upload, download, new file, new directory, copy or move and delete controls and an open in terminal button

Step 7 - Submit and monitor jobs on the local cluster

Jobs run on the bundled single node cluster named cluster. You can submit from the terminal with sbatch, or build and submit jobs from the browser with the Job Composer. The example below submits a short job as the demo user and shows it in Slurm's multi cluster view (the same view Open OnDemand's Active Jobs page uses), then prints the job's output once it completes.

sudo -u demo bash -lc 'cd ~ && sbatch --wrap="echo hello from Open OnDemand; sleep 5"'
sudo -u demo squeue -M cluster

A batch job submitted with sbatch, the squeue multi cluster view for cluster showing the job, and the job output hello from Open OnDemand followed by job complete

In the browser, Jobs then Active Jobs shows every job on the cluster with its state, time used and queue, updating live as jobs move from queued to running to completed.

The Open OnDemand Active Jobs page showing jobs named ood-demo on the Local Cluster, one completed and one running, with their IDs, owning user, time used, queue and status

Jobs then Job Composer lets you build a job from a template, edit its script and options in the browser, submit it to the cluster and track it, without touching the command line.

The Open OnDemand Job Composer with the New Job and Create Template controls, the Edit Files, Job Options, Open Terminal, Submit, Stop and Delete actions, and the jobs table listing composed jobs by name, ID, cluster and status

Step 8 - Interactive apps, clusters and the browser shell

Under Interactive Apps you can launch sessions of graphical or notebook style applications that stream back to your browser tab, and under Clusters you can open a full terminal (Shell Access) on the VM as your Linux user, straight from the browser. Because everything runs as demo on the single node cluster, these all work out of the box on this self contained appliance.

First boot and where things live

On the first boot of every VM, open-ondemand-firstboot.service generates the per VM web password (written to the htpasswd file and to /root/open-ondemand-credentials.txt), a per VM Slurm authentication (munge) key, and a hostname correct Slurm configuration, then records a sentinel so it does not run again. You can confirm the first boot service and unattended security upgrades:

systemctl is-enabled open-ondemand-firstboot.service
grep -q 'Unattended-Upgrade "1"' /etc/apt/apt.conf.d/20auto-upgrades && echo "unattended security upgrades enabled"

The open-ondemand-firstboot service reported enabled, unattended-upgrades active, the running kernel version, and apt-mark showhold reporting no packages held back from security updates

Key paths: the portal configuration is /etc/ood/config/ood_portal.yml; the cluster definition is /etc/ood/config/clusters.d/cluster.yml; the Basic auth credential store is /etc/ood/.htpasswd; the Slurm configuration is /etc/slurm/slurm.conf; and each user's portal data lives under their home directory in ~/ondemand. The image is fully patched with unattended security upgrades enabled.

Security notes

The portal grants file and shell access to whoever signs in, so it is important that it is never exposed without authentication. This image ships with an empty credential store, so every login is refused until first boot writes the unique per VM password; there is never a known or default password in the image. Only one web identity exists (demo), and it maps to a Linux account whose password is locked, so no built in operating system user can reach the portal. The Slurm authentication key is regenerated per VM, and the MariaDB accounting store is bound to 127.0.0.1 and used only by the local scheduler. For production, put TLS in front of the portal and consider integrating Open OnDemand with your own identity provider (OpenID Connect, CAS or LDAP) in ood_portal.yml, then retire the Basic auth gate.

Support

Every cloudimg image is backed by 24/7 support. If you have any questions about deploying or operating this image, contact the cloudimg team.