Kursthemen

  • Course overview

    This course teaches you how to install, upgrade, and manage a SORMAS server in production. SORMAS (Surveillance, Outbreak Response Management and Analysis System) is an open-source system used by public-health authorities to manage disease surveillance and outbreak response. Getting the server right — a correctly installed application server, a tuned database, and a secure proxy in front — is what keeps the system fast, reliable, and safe for the teams who depend on it.

    By the end you will be able to install a new SORMAS server from scratch, upgrade an existing one safely, and perform the routine administration tasks that keep it healthy.

    Who this course is for

    Anyone responsible for running a SORMAS server: public-health IT staff, system administrators, and technical implementers. The course is written for a mixed audience — the core steps are approachable if you are newer to Linux servers, and each module includes optional 🔎 Deep dive callouts for readers who want the extra detail.

    Prerequisites

    • A Linux server (this course targets Ubuntu 22.x) with sudo/root access.
    • Basic comfort with a terminal: running commands, editing a text file (e.g. with nano or vim), moving between directories.
    • Network access so the server can download software packages and the SORMAS release.

    You do not need prior experience with Payara, PostgreSQL tuning, or Apache — this course explains what you need as you go.

    How long it takes

    Plan for roughly 4–6 hours to work through all modules, plus time for the hands-on installation on your own server. A first real-world installation typically takes 1–2 hours once prerequisites are in place.

    Learning objectives

    After completing this course you will be able to:

    1. Explain how a SORMAS server is composed (application server, database, proxy) and why each part exists.
    2. Prepare a Linux server with the correct OS packages, Java, and PostgreSQL configuration.
    3. Install and deploy a new SORMAS server using the official setup scripts.
    4. Put a production-grade Apache reverse proxy and firewall in front of the server.
    5. Upgrade an existing SORMAS server to a new release safely.
    6. Perform routine administration: starting/stopping services, basic tuning, backups, and troubleshooting.

    Conventions used in this course

    Marker Meaning
    code block A command to run in the server terminal, or a file's contents.
    💡 Tip A helpful shortcut or good practice.
    ⚠️ Warning Something that can break your installation or lose data if ignored.
    🔎 Deep dive Optional detail for readers who want to understand why.
    ✅ Checkpoint A quick check to confirm a step worked before moving on.
    ❓ Quiz A short knowledge check. Answers appear immediately below each quiz.

    💡 Tip: Throughout this course, commands are shown for Ubuntu/Debian using apt. If you use a different distribution, the package names and paths may differ slightly, but the SORMAS steps are the same.

  • Introduction & orientation

    About this module

    Before installing anything, it helps to understand what you are actually building. A SORMAS server is not a single program — it is a small stack of cooperating pieces. Knowing how they fit together makes every later step make sense, and it makes troubleshooting far easier: when something breaks, you will know which piece to look at.

    • A running SORMAS server has three main layers:

      1. PostgreSQL database — stores all SORMAS data: cases, contacts, samples, users, and configuration. This is the system of record; everything else can be rebuilt, but this must be protected and backed up.

      2. Payara application server — runs the actual SORMAS web application (the Java code). Payara is a Java application server (a Jakarta EE / GlassFish derivative). SORMAS runs inside a Payara domain, which is a self-contained instance with its own configuration, ports, and logs. The application server talks to PostgreSQL to read and write data.

      3. Apache web server (reverse proxy) — sits in front of Payara in production. Web browsers and the mobile app connect to Apache over standard HTTPS (port 443); Apache forwards those requests to Payara on its internal port. This gives you TLS/SSL encryption, a clean public URL, and a security boundary between the internet and the application server.

      A simplified request path looks like this:

      Browser / mobile app
        │  https (443)
        ▼
   Apache (reverse proxy)  ── TLS termination, single public entry point
        │  http (localhost:6080)
        ▼
   Payara application server  ── runs the SORMAS web app
        │  database connection
        ▼
   PostgreSQL database  ── stores all SORMAS data

      Two supporting pieces round out a full install:

      • The temporal_tables PostgreSQL extension — SORMAS uses it to keep a full history of data changes over time (who changed what, when). It must be installed into PostgreSQL before SORMAS will work.
      • The R software environment (optional) — enables disease-network / contact-network diagrams in the contact dashboard. You can skip it if you do not need those diagrams.

      🔎 Deep dive — why a reverse proxy instead of exposing Payara directly? You could let browsers talk to Payara directly, but a reverse proxy is standard practice because it: (1) terminates HTTPS in one well-understood place, (2) lets you present a clean https://your.domain/ URL instead of an internal port, (3) shields the application server from direct internet exposure, and (4) gives you a single place for logging, redirects, and access rules. This is why production SORMAS installs always put Apache in front.

    • SORMAS ships two scripts that do the heavy lifting. You will use them in every module:

      Script What it does
      server-setup.sh Prepares the runtime environment once: installs and configures the Payara application server, creates the SORMAS database, connects the application server to the database, and installs OS start-up/shutdown scripts.
      server-update.sh Deploys the SORMAS application: backs up the database, undeploys any existing version, and deploys the new SORMAS web application and mobile app. You run this on first install and on every upgrade.

      The key insight, which we return to in Module 2: a fresh install runs server-setup.sh once and then server-update.sh; an upgrade just runs server-update.sh again with a newer release.

    • Quiz - Introduction & orientation H5P
      Teilnehmer/innen müssen
      Eine Bewertung erhalten
      Bestehensgrenze erreichen