RosarioSIS on Ubuntu 24.04 on Azure User Guide

Overview

RosarioSIS is a complete open source Student Information System for primary and secondary schools and colleges. One web application covers student records and enrolment, the course catalogue and scheduling, the teacher gradebook, report cards, transcripts and GPA, attendance, discipline, eligibility, student billing, staff accounting, food service, school calendars and marking periods, and a portal where parents and students follow grades, attendance and schedules. The cloudimg image delivers the official RosarioSIS 12.9.4 release fully installed on Ubuntu 24.04, served over HTTPS, with every per VM secret generated on first boot, so a working school administration system is serving within minutes of launch. Backed by 24/7 cloudimg support.

RosarioSIS is free software published under the GNU General Public License version 2. RosarioSIS is a trademark of its respective owner; cloudimg is not affiliated with, endorsed by, or sponsored by the RosarioSIS project or its author. This image packages the upstream open source release, without any of the commercial add on modules sold separately upstream, together with cloudimg's provisioning, hardening and support.

What is included:

• RosarioSIS 12.9.4, served from /var/www/rosariosis
• PHP 8.3 (php8.3-fpm, over a local UNIX socket) behind Apache 2.4, reachable at https://<vm-ip>/; port 80 only ever redirects to HTTPS and serves no content of its own
• A local PostgreSQL 16 database, bound to 127.0.0.1 only
• A per VM administrator password, database password and HTTPS certificate, all generated on first boot and written to a root only file. No default, shared or published credential ships in the image: RosarioSIS's upstream demo accounts come with passwords equal to their usernames, and in this image none of them can sign in
• The database is installed at build time from the command line. The RosarioSIS web installer (InstallDatabase.php) and the diagnostic page are blocked, so there is no setup route for a stranger to reach
• Password reset links always point at this VM's own address, never at a hostname supplied by a browser
• 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 the recommended starting size for a single school; scale up for a district with many schools, many concurrent teachers entering grades, or large report runs. NSG inbound: allow 22/tcp from your management network and 443/tcp (HTTPS) from wherever staff, parents and students will browse. 80/tcp is optional and only redirects to HTTPS.

Step 1: Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for RosarioSIS by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size (Standard_B2s or larger); under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create and Create.

Step 2: Deploy from the Azure CLI

cloudimg images carry a Marketplace purchase plan, so accept its terms once per subscription, then create the VM and open HTTPS:

az vm image terms accept --urn cloudimg1647283583153:rosariosis-ubuntu-24-04:default:latest

az vm create \
  --resource-group my-rosariosis-rg \
  --name rosariosis \
  --image cloudimg1647283583153:rosariosis-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-rosariosis-rg --name rosariosis --port 443 --priority 900

Step 3: Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4: Confirm the RosarioSIS stack is running

First boot generates this VM's secrets and only then opens the front door, so if the web server is running the installation is ready. Check the three services:

systemctl is-active postgresql@16-main php8.3-fpm apache2

All three report active:

active
active
active

Confirm RosarioSIS answers over HTTPS on the VM itself. The image ships a self signed certificate, so -k is expected here until you install your own certificate in Step 11:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/index.php

That prints 200. Only SSH and HTTPS are reachable from off the VM; the database and PHP-FPM deliberately are not:

sudo ss -lnt | grep -E ':(22|80|443|5432) ' | sort

LISTEN 0      200        127.0.0.1:5432      0.0.0.0:*
LISTEN 0      4096            [::]:22           [::]:*
LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*
LISTEN 0      511                *:443             *:*
LISTEN 0      511                *:80              *:*

PostgreSQL appears only on 127.0.0.1:5432. PHP-FPM does not appear at all: it listens on a UNIX socket, not a TCP port.

Step 5: Retrieve the first boot credentials

Every secret on this VM was generated on its first boot and written to a file only root can read. Nothing here is shared with any other deployment:

sudo cat /root/rosariosis-credentials.txt

# cloudimg :: RosarioSIS appliance credentials
# Generated on this VM's first boot. This file is readable only by root.
# Sign in at https://<this-vm-address>/ and change the password afterwards.
rosariosis.admin.user=admin
rosariosis.admin.pass=<unique to this VM>
rosariosis.db.name=rosariosis
rosariosis.db.user=rosariosis
rosariosis.db.pass=<unique to this VM>

admin is RosarioSIS's own administrator account. Its upstream default password is not present in this image: it is replaced during the build before the database is ever committed, and your VM mints its own on first boot. The database password is the one RosarioSIS itself uses, stored in /var/www/rosariosis/config.inc.php (readable only by root and the web server). You can prove it works the same way RosarioSIS connects, over loopback:

PGPASSWORD="$(sudo grep '^rosariosis.db.pass=' /root/rosariosis-credentials.txt | cut -d= -f2-)" psql -h 127.0.0.1 -U rosariosis -d rosariosis -Atc "SELECT config_value FROM config WHERE title = 'VERSION';"

That prints 12.9.4, the schema version of your database.

Step 6: Sign in and confirm the installation

Browse to https://<vm-public-ip>/. Your browser will warn about the self signed certificate; accept it to continue, or install your own certificate first (Step 11). Sign in with the username admin and the rosariosis.admin.pass value from Step 5.

On the first sign in RosarioSIS shows its own Confirm Successful Installation screen. If the VM can reach rosariosis.org it first offers an optional, anonymous installation poll: answer it or choose Cancel. The confirmation screen then requires you to choose a new administrator password before it opens the system, so the random first boot password is only ever used once. From then on sign in with the password you chose; the value in the credentials file will no longer work.

The screen suggests checking diagnostic.php. On this image that page is deliberately blocked (it discloses server configuration to anyone who asks), and the checks it performs were already run when the image was built, so a 403 Forbidden there is expected.

After you select OK the portal opens with the full administrator menu and a dashboard for the default school and the 2026-2027 school year:

Step 7: Work with student records

RosarioSIS ships with one school (Default School), the 2026-2027 school year with its semesters and quarters, grade levels from Kindergarten upwards, and one template student. Open Students → Student Info and search with no criteria to open that student's record:

To enrol your first real student choose Students → Add a Student, enter the first and last name, pick the Grade Level and the Enrollment Code (for example Beginning of Year), and select Save. RosarioSIS assigns the student an ID and re-opens the record, where the Addresses & Contacts and Medical tabs and every other module (scheduling, grades, attendance, billing) now apply to them:

Rename the school and set its address under School → School Information, and review the calendar and marking periods under School before you enrol students in bulk.

Step 8: The demo accounts cannot sign in

The upstream database seeds four accounts, admin, teacher, parent and student, each with a published password equal to its username. In this image the administrator's password is replaced before it is ever written, and the three demo accounts have no password at all, which RosarioSIS always rejects:

sudo -u postgres psql -d rosariosis -c "SELECT username, profile, CASE WHEN password IS NULL THEN 'no password (cannot sign in)' ELSE 'password set' END AS sign_in FROM staff UNION ALL SELECT username, 'student', CASE WHEN password IS NULL THEN 'no password (cannot sign in)' ELSE 'password set' END FROM students WHERE username = 'student' ORDER BY 1;"

 username | profile |           sign_in
----------+---------+------------------------------
 admin    | admin   | password set
 parent   | parent  | no password (cannot sign in)
 student  | student | no password (cannot sign in)
 teacher  | teacher | no password (cannot sign in)
(4 rows)

To use one of them, set a password under Users → User Info (or Students → Student Info for the student), or delete them and create your own staff under Users → Add a User. The web installer and the files that carry configuration are refused as well:

for p in /index.php /InstallDatabase.php /diagnostic.php /config.inc.php /rosariosis.sql; do printf '%-22s %s\n' "$p" "$(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1$p)"; done

/index.php             200
/InstallDatabase.php   403
/diagnostic.php        403
/config.inc.php        403
/rosariosis.sql        403

Step 9: How RosarioSIS learns its address

RosarioSIS puts absolute links in the email it sends, most importantly password reset links, and it builds them from the web server's name. A web server that takes that name from the browser's Host header would let a stranger request a reset for one of your users and have the link point at a site they control. On this image Apache always uses a server name that this VM writes for itself: rosariosis-baseurl.service runs on every boot, finds the VM's public IP address (or its private address if it has none), and writes it here:

grep '^ServerName' /etc/apache2/conf-available/rosariosis-servername.conf

That prints ServerName followed by your VM's public IP address. The same service issues the self signed HTTPS certificate for that address, and because it runs on every boot, an Azure public IP that changes across a stop and start is picked up automatically:

systemctl is-enabled rosariosis-baseurl.service && sudo openssl x509 -in /etc/ssl/rosariosis/rosariosis.crt -noout -subject

The session cookie is issued with Secure, HttpOnly and SameSite=Strict and without a Domain attribute, so it works on the bare IP address in every browser.

Step 10: Configure outbound email

RosarioSIS sends password reset links and new account notifications through PHP's mail function, and this image does not ship a mail transfer agent, so no mail leaves the VM until you configure one. Azure blocks outbound port 25 on most subscriptions, so relay through an authenticated SMTP provider on port 587. Two common routes:

• Install RosarioSIS's free Email SMTP plugin: download it from the RosarioSIS add ons page, unzip it into /var/www/rosariosis/plugins/ as root, activate it under School → Configuration → Plugins, and enter your provider's host, port, username and password.
• Or install a relay that provides sendmail, such as msmtp-mta, and point it at your provider.

Add ons are installed from the shell on this image: uploading or deleting modules and plugins through the web interface is switched off in config.inc.php, so a stolen administrator session cannot be turned into code running on your server.

Step 11: Use a domain name and your own certificate

Point a DNS A record at the VM's public IP, then pin that name so Apache (and every link RosarioSIS emails) uses it instead of the IP address:

echo 'sis.example.com' | sudo tee /etc/rosariosis/server-name
sudo /usr/local/sbin/rosariosis-baseurl.sh

With the name resolving publicly, obtain a Let's Encrypt certificate and point Apache at it:

sudo apt-get update && sudo apt-get install -y certbot
sudo certbot certonly --webroot -w /var/www/rosariosis -d sis.example.com --deploy-hook 'systemctl reload apache2'
sudo sed -i -e 's#/etc/ssl/rosariosis/rosariosis.crt#/etc/letsencrypt/live/sis.example.com/fullchain.pem#' \
            -e 's#/etc/ssl/rosariosis/rosariosis.key#/etc/letsencrypt/live/sis.example.com/privkey.pem#' \
            /etc/apache2/sites-available/rosariosis.conf
sudo systemctl reload apache2

Port 80 must be open in your NSG while certbot validates, because the challenge arrives there and is redirected to HTTPS. Certbot renews the certificate automatically and reloads Apache after each renewal.

Step 12: Start a new school year

At the end of the year run School → Rollover to copy courses, users and enrolment into the next school year. RosarioSIS then asks you to update the default school year in config.inc.php, which on this image is readable but not writable by the web server, so make that one change from the shell:

sudo sed -i "s/^\$DefaultSyear = '2026';/\$DefaultSyear = '2027';/" /var/www/rosariosis/config.inc.php

Step 13: Security model

• No default or shared credential ships in the image. The RosarioSIS administrator password, the database password and the HTTPS certificate are all generated on this VM's first boot, and RosarioSIS requires a new administrator password at the first sign in.
• The upstream demo accounts (teacher, parent, student) have no password and cannot sign in until you give them one.
• The web installer (InstallDatabase.php) and diagnostic.php are refused, as are config.inc.php, the SQL schema and the project's metadata files.
• The application code is owned by root and read only to the web server; only the three upload folders (assets/FileUploads, assets/StudentPhotos, assets/UserPhotos) are writable, and nothing uploaded there is ever executed as code.
• Only 22/tcp and 443/tcp are reachable from off the VM. 80/tcp issues a permanent redirect to HTTPS and serves nothing else. PostgreSQL is bound to 127.0.0.1 and PHP-FPM uses a UNIX socket.
• Password reset links use the server name this VM writes for itself, never a browser supplied host name.
• SSH refuses root and password logins; sign in as azureuser with your key. Ubuntu's unattended security upgrades remain enabled.

Step 14: Back up your school data

RosarioSIS keeps its state in the PostgreSQL database and in the three upload folders:

sudo -u postgres pg_dump -Fc rosariosis > ~/rosariosis-db-$(date +%F).dump
sudo tar czf ~/rosariosis-files-$(date +%F).tar.gz -C /var/www/rosariosis assets/FileUploads assets/StudentPhotos assets/UserPhotos config.inc.php

Copy both off the VM, and take an Azure disk snapshot before any upgrade.

Step 15: Maintenance and upgrades

Ubuntu security updates are applied automatically. Check which RosarioSIS release is installed:

grep "define( 'ROSARIO_VERSION'" /var/www/rosariosis/Warehouse.php

To move to a later release, back up first (Step 14), then unpack the new release over the existing code. The release archives do not contain config.inc.php, so your configuration is kept:

cd /tmp && curl -fsSLO https://github.com/francoisjacquet/rosariosis/archive/refs/tags/v12.9.5.tar.gz
sudo tar -xzf v12.9.5.tar.gz -C /var/www/rosariosis --strip-components=1
sudo chown -R root:root /var/www/rosariosis
sudo chown -R www-data:www-data /var/www/rosariosis/assets/FileUploads /var/www/rosariosis/assets/StudentPhotos /var/www/rosariosis/assets/UserPhotos
sudo chown root:www-data /var/www/rosariosis/config.inc.php && sudo chmod 640 /var/www/rosariosis/config.inc.php

Replace 12.9.5 with the release you are installing. RosarioSIS applies any database updates for the new release automatically on the next page request after the code changes.

Support

cloudimg provides 24/7 support for this image. Contact us at support@cloudimg.co.uk or through the cloudimg support page. For questions about RosarioSIS itself, see the RosarioSIS documentation.