Sakai

1. Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for Sakai by SecureAnyCloud.
2. Select Create.
3. On the Basics tab, pick your subscription, resource group, region and size (Standard_B2ms or larger).
4. Under Administrator account, choose SSH public key and paste your key.
5. Under Inbound port rules, allow SSH (22) and HTTPS (443).
6. Choose Review + create, then Create.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:sakai-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name sakai \
  --image sac1647283583153:sakai-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard \
  --os-disk-delete-option Delete \
  --nic-delete-option Delete

Then open the ports that you need:

az vm open-port --resource-group <your-rg> --name sakai --port 443 --priority 1010
az vm open-port --resource-group <your-rg> --name sakai --port 80 --priority 1020

First boot generates this VM's own secrets and then starts Sakai. Sakai deploys roughly one hundred web applications into a single JVM, so this takes a while. On a Standard_B2ms, expect about fifteen to twenty minutes before the sign-in page answers (measured: 18 minutes on a freshly launched VM). Later reboots are quicker.

Until first boot has finished, nginx deliberately refuses to start. The VM is therefore unreachable rather than serving a half-configured LMS. This is by design, not a fault.

To read the credentials file, connect over SSH from your own machine:

ssh azureuser@<vm-public-ip>

Then, on the VM, run:

sudo cat /root/sakai-credentials.txt

The output looks similar to this:

# sac :: Sakai appliance credentials
# Generated on this VM's first boot. This file is readable only by root. # Change the administrator password after your first sign-in. sakai.admin.user=admin sakai.admin.pass=<a unique 24-character password> sakai.db.name=sakai sakai.db.user=sakai sakai.db.pass=<a unique 32-character password> sakai.server.id=sac-<unique>

The file is mode 600 and owned by root, so only a user who can sudo can read it. The admin account in this file is Sakai's own administrator account, not the Linux root user.

If the page is not answering yet, check progress with:

systemctl is-active sakai-firstboot.service sakai.service nginx.service
sudo journalctl -u sakai.service --no-pager -n 20

Browse to https://<vm-public-ip>/portal. Your browser warns about the self-signed certificate that first boot generated. This is expected until you install your own certificate (Step 8). Accept the warning, then sign in with the username admin and the password from /root/sakai-credentials.txt.

Change the administrator password immediately after your first sign-in. Choose Administration Workspace from the sites menu, then Users, search for admin, and set a new password. Then create a named account for each administrator instead of sharing the admin account.

From Administration Workspace, choose Sites, then New Site. Pick course site or project site and give it a title and description. Choose the tools you want (Lessons, Assignments, Tests & Quizzes, Gradebook, Resources and Forums are the usual starting set), add participants with their roles, and publish the site.

You create and manage course and project sites from Worksite Setup. Once a site exists, it appears in the sites menu at the top of the portal, with the tools you selected down the left-hand side.

Sakai runs its scheduled jobs through an in-process Quartz scheduler rather than a public web endpoint, so nothing needs to be exposed for jobs to run. The scheduler deliberately starts five minutes after Tomcat, so it may not be registered immediately after boot.

Review and schedule jobs from Administration Workspace, then Job Scheduler. To confirm from the shell that the scheduler is alive, run:

sudo mysql --protocol=socket -u root sakai \
  -e "SELECT TRIGGER_NAME, TRIGGER_STATE, PREV_FIRE_TIME, NEXT_FIRE_TIME FROM QRTZ_TRIGGERS;"

A trigger in WAITING state with a future NEXT_FIRE_TIME is an armed job. After a job has run, its PREV_FIRE_TIME moves off -1. This shows that the scheduler actually executed a job, not merely that it was configured.

QRTZ_SCHEDULER_STATE stays empty on this image. That table is Quartz's clustering check-in, and this is a single-node deployment.

Sakai builds absolute links from the serverUrl it is configured with, so tell Sakai your hostname once you have one. The image rewrites serverUrl from the VM's own address on every boot. This makes an Azure public IP that changes across a stop and start work transparently. Set a real hostname explicitly so that the rewrite does not overwrite it.

Create an A record that points your hostname at the VM's public IP, then edit /opt/tomcat/sakai/sakai.properties:

sudo sed -i 's|^serverUrl=.*|serverUrl=https://lms.example.edu|' /opt/tomcat/sakai/sakai.properties
sudo sed -i 's|^serverName=.*|serverName=lms.example.edu|' /opt/tomcat/sakai/sakai.properties
sudo systemctl disable sakai-baseurl.service
sudo systemctl restart sakai.service

Disabling sakai-baseurl.service stops the per-boot rewrite from replacing your hostname with the VM's IP address again.

The image generates a self-signed certificate on first boot so that HTTPS works out of the box. Once you have a hostname, replace it with a real certificate:

sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d lms.example.edu

Certbot edits the nginx server block in /etc/nginx/sites-available/sakai.conf and installs a renewal timer. Keep the existing proxy_cookie_domain line in that file. The line strips the cookie Domain attribute, which allows sign-in to work when you reach Sakai by IP address rather than by name.

Sakai sends notifications and needs an SMTP relay to do so. Set the relay in /opt/tomcat/sakai/sakai.properties:

smtp@org.sakaiproject.email.api.EmailService=smtp.example.edu smtp.port@org.sakaiproject.email.api.EmailService=587 setup.request=noreply@example.edu

Then restart Sakai:

sudo systemctl restart sakai.service

To send a test message, open Administration Workspace, then Email Test.

Everything that matters lives in two places: the MySQL database and the uploaded content under /var/lib/sakai/files. Back up both:

sudo mysqldump --protocol=socket -u root --single-transaction --routines --triggers \
  sakai | gzip > /var/backups/sakai-$(date +%F).sql.gz
sudo tar czf /var/backups/sakai-files-$(date +%F).tar.gz -C /var/lib/sakai files

Copy both off the VM, to Azure Blob Storage or your own backup target, and test a restore before you rely on it. A VM snapshot alone is not a substitute for a database dump taken with --single-transaction.

For a Sakai 25 maintenance release (25.3, 25.4 and so on), replace the deployed application and let Sakai upgrade its own schema:

# Always take a backup first (Step 10).
sudo systemctl stop sakai.service cd /tmp curl -fsSLO https://source.sakaiproject.org/release/25.3/artifacts/sakai-bin-25.3.tar.gz
# Verify the download against the .MD5 published alongside it before extracting.
sudo rm -rf /opt/tomcat/components /opt/tomcat/webapps
sudo tar -xzf sakai-bin-25.3.tar.gz -C /opt/tomcat
sudo find /opt/tomcat/components -name 'components-demo.xml' -delete sudo find /opt/tomcat/components -name 'sakai-sample-provider-*.jar' -delete sudo chown -R sakai:sakai /opt/tomcat
sudo systemctl start sakai.service

auto.ddl=true is set in sakai.properties, so Sakai applies its own schema changes on the next start. Watch /opt/tomcat/logs/catalina.out until the portal answers again.

Delete the demo provider files again after every upgrade, because the upstream archive ships them each time.

unattended-upgrades, which is enabled in the image, handles operating system patches.