Utility tools — Stirling-PDF, IT-Tools, CyberChef
Three browser tools for students and teaching staff, deployed 2026-08-21 as the first user-facing wave: a PDF toolbox, a developer utility belt and GCHQ's data-transform workbench. They were picked from the service ideas list because none of them keeps state, holds an account store or needs a support queue.
| Stirling-PDF | IT-Tools | CyberChef | |
|---|---|---|---|
| What it does | merge, split, rotate, compress, sign, OCR | JWT, encodings, hashes, cron expressions, converters | encryption, encodings, format analysis, forensics recipes |
| Public name | pdf.isc-vs.ch | tools.isc-vs.ch | cyberchef.isc-vs.ch |
| Guest | srv-stirling, CT 117, 192.168.88.168 | srv-it-tools, CT 118, 192.168.88.169 | srv-cyberchef, CT 119, 192.168.88.170 |
| Resources | 2 cores / 4 GB / 12 GB | 1 core / 512 MB / 4 GB | 1 core / 512 MB / 6 GB |
| Internal URL | http://srv-stirling.isc3 | http://srv-it-tools.isc3 | http://srv-cyberchef.isc3 |
| Sign-in | edu-ID, or a local realm account, on the public name; none on the internal one | none | none |
| Version | 2.14.3 | 2024.10.22 | 11.4.0 |
All three are unprivileged LXC on rumba, nesting=1, published through
srv-web01 which terminates TLS. The internal names above (and their .isc3
aliases) resolve on the CCR2004, and each container answers on plain port 80 — a local Caddy in
srv-stirling fronts Stirling's own 8080, with 30-minute proxy timeouts so an OCR run on a large
file is not cut off.
The internal path carries no authentication, deliberately: the gate protects the published name, and this one is only reachable over the VPN, the same arrangement as every other internal service on the rack. It is also the way in while a new public name is still absent from a resolver's cache (see the DNS caution).
Managed from provisioning/tools/ — deploy-static-tool.sh cyberchef|it-tools and
deploy-stirling.sh, both idempotent: a re-run reinstalls only when the upstream release tag
changed, so upgrading is one command with no version argument.
Why only the PDF tool asks for a login
IT-Tools and CyberChef are static JavaScript. Everything the user types stays in the browser tab; the container serves files and computes nothing, so there is no work an anonymous visitor could make it do and no data that could reach it. They are open to anyone.
Stirling-PDF receives uploaded files and processes them server-side with LibreOffice, Ghostscript
and Tesseract. Published open, that is CPU and temporary storage offered to the Internet, so it sits
behind the user gate: membership of isc or hevs, both derived from
edu-ID claims at every login, so staff and students pass with no list to maintain and no account to
create. Nothing is stored per user — the gate authorises, it does not personalise.
Someone with no edu-ID — an external partner, a guest — gets a
local account in realm isc, in the group guests:
ssh root@srv-keycloak 'bash -s' -- < provisioning/keycloak/local-users.sh add <username>
They sign in on the same Keycloak page as everyone else, on the username/password form beside the
edu-ID button. Nothing reaches Stirling-PDF, which still has no accounts of its own. Passwords are
in secretzone/rumba.md. Keep the number near zero — each one is a password to rotate and a person
whose departure nobody will notice, which is the failure mode brokering identity through edu-ID
exists to avoid.
Stirling-PDF specifics
SECURITY_ENABLELOGIN=false: authentication is the proxy's job, so the app keeps no user database
and the container needs no backup. Turning it on would put an unauthenticated login page behind an
authenticating proxy.
The release publishes three jars. Stirling-PDF.jar is the one with the web frontend;
-server.jar is the REST API alone and serves an "API Server" placeholder page instead of the tool;
-with-login.jar adds the user database that the setting above exists to avoid.
The jar is compiled for class-file version 69. Debian 13 ships both openjdk-21-jre-headless and
openjdk-25-jre-headless, and 21 fails with UnsupportedClassVersionError, so the unit names
/usr/lib/jvm/java-25-openjdk-amd64/bin/java rather than leaving the choice to
update-alternatives.
unoconvert is not packaged in Debian 13Office conversions go through unoconvert, and neither unoserver nor the older unoconv exists
in trixie. deploy-stirling.sh installs it with pip into /opt/unoserver, a venv created with
--system-site-packages so it can still import uno from python3-uno; PEP 668 blocks a
system-wide pip install.
Server-side paths verified on deployment: txt→PDF through LibreOffice, OCR with the French language data, and compression through Ghostscript.
The static pair
Both are unpacked from the project's own release zip into /var/www/site, with the release tag in
/var/www/site/.release as the version marker. Two details in the shared Caddy config:
try_files {path} {path}/ /index.html— both are single-page apps with history-mode routing, so a deep link has no file behind it and must fall back to the app shell.precompressed br gzip— the CyberChef release ships.brand.gzsidecars beside each of its 76 MB of JavaScript modules; serving those avoids compressing them on every cold load.
CyberChef's zip has no index.html: it ships CyberChef_<version>.html at the root, which the
deploy script copies into place. IT-Tools wraps everything in dist/.
Open items: ops todo.