WatuFlex
Find a partner
Home › Academy › Technical track
WatuFlex Academy · for implementing partners

The technical track

For the engineers who install, run and support Watu Boxes: Linux, Docker, the WatuOS commands, logs and troubleshooting, the desktop and kiosk, Watu Cloud and backups, networking, the databases and security. Every course is taught on a real box, and every command is one that a Watu Box actually carries.

Enrol (clients’ IT staff and individuals) Apply as an Implementing Partner

Nine courses, in order

Start with Linux and Docker if they are new to you; experienced engineers can go straight to TE-201. TE-101, TE-102, TE-201 and TE-202 are part of the Certified Implementer certification.

TE-101Linux essentials for WatuOSEnough Linux to look after a Watu Box with confidence: the console, files, services, logs, disk, memory and the network.TE-102Docker and Docker Compose on WatuOSHow WatuOS runs the applications as containers, and how to inspect them without breaking anything.TE-201WatuOS administration: the watu commandsThe commands every Watu Box carries, what each one does and when to use it.TE-202Logs, health and troubleshootingFind out what is wrong in minutes: the verdict, the report, the logs and the faults partners meet most.TE-203The WatuOS desktop and kioskThe browser desktop that runs the box, the launcher, the status screen, and the full-screen kiosk on an attached monitor.TE-204Watu Cloud, licences, updates and backupsThe box’s link to Watu Cloud, and keeping a client’s data safe.TE-205Installing and networking the boxFrom a bare computer to a box on the client’s network: hardware, installation, addresses and the firewall.TE-206The databases on the boxOne MariaDB server, one database per application, and how to keep them healthy without touching client data.TE-301Security and hardeningWhy a Watu Box is safe on a client’s network, and how to keep it that way.
The WatuOS Technical Handbook Every command in these courses, with its options, the folders and logs on a box, the services and timers, and a troubleshooting table — in the partner kit for implementing partners. Partner portal →
TE-101 Open

Linux essentials for WatuOS

Enough Linux to look after a Watu Box with confidence: the console, files, services, logs, disk, memory and the network.

What you learn

  1. The box and its screens. The status screen on the attached monitor, and why it has no shell. Signing in on a second console as the box’s own administrator, and using sudo.
  2. Finding your way. Moving around the file system, reading files safely, searching inside them, and the few folders that matter on a box: the WatuOS data folder, the logs and the WatuOS tools.
  3. Services and timers. What systemd is, how the box starts its applications in order, and how to check, restart and read a service — including the nightly backup and the daily cloud check-in timers.
  4. Disk, memory and processes. Reading free disk and memory the way the self-test does, and what to do before a disk fills up.
  5. The network from the box. The box’s address, which ports are listening, and checking that it can reach the router and the internet.
  6. Shutting down safely. Reboot and power-off, and the one moment never to do either: while a new box says “finishing setup”.

Commands you will use

ls, cd, less, tail, grepfind and read files and logs
systemctl status / restartcheck and restart a service
systemctl list-timerssee when the backup and cloud check-in run next
journalctl -u <service>read one service’s log
df -h · free -h · uptimedisk, memory and load
ip a · ss -tlnp · pingaddress, open ports, reachability
LabSign in on the second console, find the box’s address, read the setup log, check every WatuOS service and timer, and report disk and memory.
TE-102 Open

Docker and Docker Compose on WatuOS

How WatuOS runs the applications as containers, and how to inspect them without breaking anything.

What you learn

  1. Images, containers and volumes. The three ideas, and where each lives on a box. Why every application’s image is already on the box, and why the data lives outside the containers.
  2. How a Watu Box is laid out. One Compose project for the whole box; one container per application, plus its workers; one MariaDB server shared by all; profiles that decide which applications run — the licence.
  3. Reading the state. Listing containers and their health, live resource use, and the images and disk Docker holds.
  4. Logs and looking inside. Following one application’s log, and opening a shell inside its container to look — not to change.
  5. Starting and stopping, the WatuOS way. Why the WatuOS commands start and stop the stack instead of plain Compose, and why a plain “down” can leave bundle-installed applications running.
  6. What never to type. Commands that delete volumes, prune images or rebuild a container on a client’s box — and what to do instead.

Commands you will use

docker psevery container, its status and health
docker ps --filter name=watuflex-only the box’s own containers
docker logs --tail 100 -f <container>follow an application’s log
docker exec -it <container> shlook inside a container
docker stats --no-streamCPU and memory per application
docker system dfhow much disk images and containers use
LabOn a lab box: list the stack, follow WatuAccounts’ log while posting an invoice, find which container uses the most memory, and restart one application cleanly.
TE-201 Open

WatuOS administration: the watu commands

The commands every Watu Box carries, what each one does and when to use it.

What you learn

  1. Licensing applications. Switching applications on and off, listing what is licensed, and what happens to the links when a new application is enabled.
  2. Linking the applications. How the box links every licensed application to WatuAccounts, WatuStock, WatuHRM and each other with signed keys; checking the links; issuing new keys.
  3. Accounts and first passwords. Why factory passwords are replaced at commissioning, printing the installation note once, and changing an application login the right way — inside the application’s own container.
  4. Health and repair. The self-test and its report, repairing an empty or half-loaded database, pointing each application’s web server at its code.
  5. Upgrades and new applications. Applying an application’s upgrade SQL with a backup first; installing a signed application bundle; applying a signed WatuOS update.
  6. Sample data. Loading and clearing an application’s sample data, and the safeguards that stop invented people mixing with real ones.

Commands you will use

watu-enable / watu-disablelicense applications; --list, --status
watu-link-appslink the licensed apps; --status, --rekey
watu-first-passwords --showthe installation note, once
watu-set-password <app> <login>change an application login
watu-selftest · watu-reportcheck now · the last report
watu-db-repair · watu-migraterepair a schema · apply upgrades
watu-demo-data--list, --status, --load, --clear
watu-install-bundle · watu-apply-updatesigned apps · signed updates
LabEnable a second application on a lab box, confirm the links, give its administrator a new password, run the self-test and read the report.
TE-202 Open

Logs, health and troubleshooting

Find out what is wrong in minutes: the verdict, the report, the logs and the faults partners meet most.

What you learn

  1. The verdict. READY, READY WITH WARNINGS and NOT READY: what the self-test checks, its exit codes, and how table counts are compared with the box’s own baseline.
  2. Where the logs are. The setup, first-boot, self-test, backup, migration and desktop logs; the systemd journal for each WatuOS service; each application’s container log; the desktop’s Logs tool.
  3. A method. From the screen, to the report, to one service’s log, to one container’s log — and what to write down before you call for help.
  4. The usual faults. The box name does not open; a new box “stuck” finishing setup; an application answering “Forbidden”; an empty database; the database restarting for lack of memory; a full disk; enrolment failing; an app connection test failing; a duplicate in the books.
  5. Escalating. What WatuFlex engineers need from you: the self-test report, the log extract, the time it started and what changed.

Commands you will use

watu-reportthe last self-test, in full
watu-selftest --no-repaircheck again, change nothing
journalctl -u watu-apps --since todaywhy the stack did (not) start
tail -n 100 /var/log/watuos-*.logsetup, first boot, self-test, backup
docker logs --tail 200 <container>one application’s errors
watu-link-apps --statuswhich application links work
LabBreak-and-fix: the trainer breaks a lab box six ways; you find each fault from the screen and the logs, fix it with the WatuOS commands, and write the incident note.
TE-203 Open

The WatuOS desktop and kiosk

The browser desktop that runs the box, the launcher, the status screen, and the full-screen kiosk on an attached monitor.

What you learn

  1. Three screens, three jobs. The launcher on port 80 for staff; the WatuOS desktop on port 8080 for administrators; the status screen on the box’s own monitor.
  2. The desktop, tile by tile. Tiles, the start menu and the tray. System, Applications, Users, Security, Backup, Logs, Setup, Handover, Help and My password. English and Kiswahili.
  3. Desktop users and roles. Administrator and other roles, one account per person, and the installation note shown once.
  4. The kiosk. The optional full-screen desktop on a monitor attached to the box: what it installs, the service that runs it, switching between the kiosk and a console, and adding it to a box installed without it.
  5. Setup and handover in the desktop. The first-run checklist, box health buttons, and the printable handover sheet with signatures and stamps.

Commands you will use

http://watubox.local/the launcher (port 80)
http://watubox.local:8080the WatuOS desktop
systemctl status watu-adminthe desktop’s service
systemctl status watu-kioskthe kiosk’s service
Ctrl+Alt+F2 · Ctrl+Alt+F7a console · back to the kiosk
LabCommission a lab box’s desktop: create the client’s administrator, switch an application on, take a backup, and print a handover sheet; then set up the kiosk on an attached monitor.
TE-204 Open

Watu Cloud, licences, updates and backups

The box’s link to Watu Cloud, and keeping a client’s data safe.

What you learn

  1. Enrolment. Joining a box to a Watu Cloud account with a one-time token, the daily check-in, and what the box keeps working on when the line is down.
  2. The backup passphrase. Why the client’s own administrator chooses it, why off-site copies cannot be read without it, and who must know it.
  3. Backups. The nightly backup and how many copies the box keeps; taking one now; sending copies off-site encrypted; agreeing at handover where copies go and who checks them.
  4. Restoring. Restoring a backup on a test box first, then on the client’s box with WatuFlex support.
  5. Applications and updates from the cloud. What the box may install, fetching a signed bundle, checking for a newer WatuOS, and the automatic roll-back if the desktop stops answering.

Commands you will use

watu-cloud enrol WATU-XXXXjoin a cloud account
watu-cloud status · checkinwhat the box knows · check in now
watu-cloud passphrase --setchoose the backup passphrase
watu-cloud backupsend an encrypted backup now
watu-backup --localtake a local backup only
watu-cloud catalogue · install <app>what may be installed · install it
watu-cloud updateis there a newer WatuOS?
LabEnrol a lab box, set its passphrase, send a backup off-site, then restore last night’s backup onto a second box and prove the books match.
TE-205 Open

Installing and networking the box

From a bare computer to a box on the client’s network: hardware, installation, addresses and the firewall.

What you learn

  1. Choosing the hardware. Memory, SSD, wired network and a UPS; when 16 GB of memory is worth it; a client’s own computer or a Watu Box.
  2. Installing WatuOS. Writing the installer to a USB stick, what the installer asks, the encrypted disk, and the unattended first boot and commissioning.
  3. Finding the box. watubox.local, the address on the status screen, and asking the client’s router for a fixed address.
  4. Ports and the firewall. Which ports the launcher, the desktop and each application use; the firewall that answers only the local network; why nothing on the internet can call in.
  5. The client’s network. Routers, switches, Wi-Fi for users and a cable for the box; printers; power cuts and the UPS.

Commands you will use

http://watubox.local/the name to bookmark
ip athe box’s address
ss -tlnpwhat is listening, port by port
sudo nft list rulesetthe firewall, as the box sees it
ping -c 3 <router>is the network there?
LabInstall WatuOS on a bare lab computer, follow first boot to READY, reach it by name and by address from a laptop, and map every application port.
TE-206 Open

The databases on the box

One MariaDB server, one database per application, and how to keep them healthy without touching client data.

What you learn

  1. How the data is kept. MariaDB 10.11, one database and one user per application, reachable only from inside the box.
  2. Table counts and the baseline. Why a healthy database shows fewer tables than its schema file, and why a count that drops is a real fault.
  3. Repair and upgrade. Loading a schema that came up empty; applying an application’s upgrade SQL, once, with a backup first.
  4. Looking, not touching. Opening the database read-only to answer a question — and the rule that client data is changed only through the application.

Commands you will use

watu-db-repair --checkreport empty or half-loaded databases
watu-db-repair <app>reload one application’s schema
watu-migrate <app> --dry-runwhat an upgrade would apply
watu-migrate --allapply pending upgrades, backup first
LabFind and repair a database the trainer emptied, then upgrade an application on a lab box with a dry run first.
TE-301 Open

Security and hardening

Why a Watu Box is safe on a client’s network, and how to keep it that way.

What you learn

  1. The encrypted disk. Full-disk encryption; boxes with a TPM 2.0 that unlock themselves after a power cut; boxes that need the passphrase at every boot; and why a lost passphrase means lost data.
  2. SSH. Installed but off. Switched on in the desktop’s Security tool only while you use it, and off before you leave.
  3. The firewall and USB. Local-network-only access, nothing inbound from the internet, and USB storage switched off on the box.
  4. Passwords and people. No factory password survives commissioning; one account per person, in the desktop and in each application; removing leavers every month.
  5. Signed software only. The vendor key: why an application bundle or a WatuOS update that does not verify is refused unopened, and why nobody works around it.

Commands you will use

Desktop → SecuritySSH on or off; disk-encryption level
watu-first-passwordsreplace factory passwords
watu-set-password <app> <login>reset one login
sudo nft list rulesetcheck the firewall
systemctl is-enabled sshconfirm SSH is off
LabAudit a lab box against the monthly security routine, close everything that is open, and record it on the handover sheet.

Who it is for

IT technicians and engineers at implementing partners, and clients’ own IT staff who look after a Watu Box. Comfortable with a computer and a network; no Linux or Docker experience needed for TE-101.

Enrol All courses