-
TESM 2.2.0 Stable
released this
2026-09-09 21:48:39 +02:00 | 73 commits to main since this releaseVorschau: Bilder zoomen, PDF-Formulare ausfuellen
Bisher lief jede Vorschau durch einen Rahmen, und der Browser entschied selbst.
Auf einem iPad heisst das: ein Foto ist 4032 Pixel breit und wird 1:1 gezeigt,
also als Ausschnitt aus der Mitte. Ein PDF ist dort nur ein Standbild der ersten
Seite -- Formularfelder lassen sich nicht anfassen.Jetzt waehlt die Vorschau die Anzeige nach der Art der Datei:
- Bilder passen sich der Flaeche an und lassen sich zoomen und verschieben:
zwei Finger, Mausrad, Doppeltippen oder die Knoepfe unten links. - PDFs rendert pdf.js mit Formularmodus -- Felder sind echte Eingabefelder,
auch in Safari. Ausgefuellt speichern legt das ausgefuellte Formular als
eigene Datei neben das Original (vorlage-ausgefuellt.pdf); die leere
Vorlage bleibt leer. - Alles andere bleibt beim Rahmen. Faellt pdf.js aus, faellt die Anzeige
ebenfalls dorthin zurueck -- kein weisses Feld.
HEIC ist neu in der Vorschau: das Format, in dem ein iPad fotografiert.
Safari zeigt es; andere Browser bekommen den Hinweis, dass sie es nicht koennen.pdf.js (4.10.38, Apache-2.0) liegt im Paket -- TESM laeuft in abgeschotteten
Netzen. Geladen wird es erst beim ersten PDF.Herunterladen laedt herunter
iOS Safari entscheidet nach dem MIME-Typ und oeffnete eine
application/pdfim
Browser, obwohl sie als Anhang ausgeliefert wurde. Ein ausdruecklicher Download
bekommt jetzt den neutralen Typ; angesehen wird die Datei in der Vorschau.Eine Uploadgrenze statt drei
Wirksam war bisher die kleinste (64 MB aus einer Umgebungsvariablen), sichtbar
die groesste (512 MB auf der Freigabeseite), und nginx hatte eine dritte. Jetzt
gilt eine Zahl, einstellbar unter Einstellungen -> Webserver und TLS:- die Anwendung liest sie pro Anfrage -- keine Aenderung braucht einen
Neustart, - nginx bekommt beim Uebernehmen 16 MB mehr, damit die Anwendung die
Fehlermeldung schreiben darf, - und die Meldung nennt die Grenze und wo sie steht.
Downloads
- Bilder passen sich der Flaeche an und lassen sich zoomen und verschieben:
-
TESM 2.1.2 Stable
released this
2026-09-09 00:27:04 +02:00 | 74 commits to main since this releaseEin Sub-Paket kommt nicht mehr auf eine Wurzelinstanz
Die Pruefung sah bisher nur nach, ob im Zielverzeichnis das Teilpaket
tesm_license/masterliegt. Jede Master-Installation, die vor 2.1.0
eingerichtet wurde, kennt es aber noch nicht -- dort waere ein Paket der
Sub-Ausgabe anstandslos durchgelaufen, und die Wurzelinstanz haette danach
keinen Weg mehr zu einer Master-Lizenz.Jetzt entscheidet zusaetzlich die Rolle der eingespielten Lizenz. Ist sie
masterund das Paket die Sub-Ausgabe, brichtinstall.shvor dem ersten
Schreibzugriff ab und nennt das passende Repositorium.Wer eine Wurzelinstanz betreibt, aktualisiert sie aus
tesm-license-master:sudo bash /srv/tesm-license/deploy/update.sh tesm-license latest --yesupdate.sherkennt die Ausgabe selbst; den Zugriffstoken fuer das private
Repositorium erwartet es inTESM_RELEASE_TOKENoder/etc/tesm-release.token.Downloads
-
TESM 2.1.1 Stable
released this
2026-09-09 00:20:46 +02:00 | 75 commits to main since this releaseNachtrag zu 2.1.0 -- eine Zeile, die im Betrieb zaehlt.
update.sh endet nicht mehr still
Ohne Terminal las die Rueckfrage EOF, die Antwort blieb leer, und das Skript
endete mit 0: aus einem anderen Skript oder per SSH aufgerufen sah das nach
einem erledigten Update aus, obwohl nichts passiert war.Jetzt gilt dasselbe wie bei
install.shundupgrade.sh:sudo bash /srv/tesm/deploy/update.sh tesm latest --yesOhne Terminal und ohne
--yesbricht es mit Code 3 ab und sagt, warum.Downloads
-
TESM 2.1.0 Stable
released this
2026-09-09 00:13:10 +02:00 | 76 commits to main since this releaseRueckweg bei jedem Fehlschlag
Aktualisierung und Upgrade rollen jetzt bei jedem Fehlschlag zurueck, nicht
nur bei dem einen, der abgefangen war: Export, Uebersetzen, Einspielen, nginx,
Systempakete, ein Ctrl-C. Der Rueckweg haengt an einer EXIT-Falle. Eine
Neuinstallation loescht nichts -- im Zielverzeichnis kann eine Fassung 1.x
liegen, deren Sicherungupgrade.shhaelt.Anlass war ein echter Abbruch: install.sh scheiterte an einer sudoers-Datei,
die ein neueres visudo ablehnte. Der alte Dienst war zu diesem Zeitpunkt schon
gestoppt und deaktiviert, der neue existierte nicht.Eine Datei genuegt
install.shliegt oben im Paket und funktioniert auch allein -- ohne Paket
drumherum laedt es sich das aktuelle Release selbst:curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm/raw/branch/main/install.sh sudo bash install.sh --app tesm --httpsDamit gilt fuer alle drei Wege dasselbe:
install.sh,update.sh,
upgrade.sh-- eine Datei auf das Ziel legen, ausfuehren, fertig.Jede Instanz mit eigenem Port
Bisher bekam jede Instanz denselben internen Port (Basis+100). Die zweite
startete deshalb nie ("Address already in use") -- und weil die
Gesundheitspruefung genau diesen Port fragte, antwortete die erste, und die
Installation meldete "Fertig" ueber einen toten Dienst. Jetzt wird der naechste
freie Port gesucht, und die Pruefung sieht zusaetzlich den Dienst selbst an.Downloads
-
TESM 2.0.10 Stable
released this
2026-09-08 23:13:44 +02:00 | 80 commits to main since this releaseDas Upgrade brach an der sudoers-Datei ab
Auf einem frisch aufgesetzten Server:
syntax error: unknown setting: 'requiretty' visudo: invalid sudoers file !! sudoers-Datei ist fehlerhaftDefaults:<benutzer> !requirettystand in beiden sudoers-Dateien. Auf Debian
und Ubuntu istrequirettynie gesetzt -- die Zeile war von Anfang an
wirkungslos -- und ab sudo 1.9.16 kenntvisudodie Einstellung nicht mehr
und lehnt dafür die ganze Datei ab. Sie ist entfernt.Ein Rückweg für fehlgeschlagene Upgrades
Schlimmer als der Fehler war die Folge: der alte Dienst war schon gestoppt und
deaktiviert, das Verzeichnis teils ersetzt, der neue Dienst nicht vorhanden.upgrade.shfängt einen Fehlschlag jetzt ab und dreht den Lauf selbst zurück.
Und später von Hand:sudo bash upgrade.sh --app tesm --rollback sudo bash upgrade.sh --app tesm --rollback /srv/tesm-upgrade-20260908-225428Dafür enthält die Sicherung mehr als das Verzeichnis: bei einem Upgrade in
dasselbe Verzeichnis schreibtinstall.shauch systemd-Unit, nginx-Site,
logrotate und Banner neu und ersetzt das venv. Ein Manifest hält fest, woher
der Stand kam -- ein Rückweg Tage später muss nicht raten.Und ein gefährlicherer Fund beim Nachstellen
Die Liste der „alten Units" war fest verdrahtet: für
--app tesmimmer
tesm.service. Nach einemrename.shheisst so aber die laufende
Installation. Wer die archivierte 1.x in eine eigene Instanz hochzieht und
--keep-old-runningvergisst, hätte damit den Produktionsdienst gestoppt und
deaktiviert. Erkannt werden die Units jetzt daran, dass sie in genau das
Quellverzeichnis zeigen.Installation
sudo bash /srv/tesm/deploy/update.sh tesmDownloads
-
TESM 2.0.9 Stable
released this
2026-09-03 16:18:53 +02:00 | 81 commits to main since this releaseEine Datei genügt
upgrade.shundupdate.shholen sich das Release jetzt selbst. Auf einem
System, auf dem noch nichts von dieser Fassung liegt -- und das ist bei einem
Upgrade von 1.2.8 der Regelfall:curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm/raw/branch/main/deploy/upgrade.sh sudo bash upgrade.sh --app tesmBisher verlangte
upgrade.shein entpacktes Release daneben und brach sonst ab
-- die falsche Voraussetzung für genau den Fall, für den es gedacht ist. Liegt
das Skript doch in einem entpackten Release, wird dieses benutzt statt
eines Downloads: wer ein Paket ausgepackt hat, will nicht, dass ungefragt ein
anderes geladen wird. Mit--tag v2.0.9lässt sich eine Version festlegen.Der Bootstrap steht wortgleich in beiden Skripten; zwei eigenständige Dateien
können sich keine dritte teilen. Drei Tests halten das zusammen: die Blöcke
müssen gleich sein,upgrade.shdarf kein Release daneben verlangen, und mit
leeremPATHmuss der Block das fehlende Werkzeug benennen.update.shruftinstall.shnicht mehr perexecauf -- dadurch lief die
Aufräumfalle nie, und jedes Update liess ein entpacktes Release unter/tmp
liegen.Geprüft, nicht behauptet
Die einzelne
upgrade.shhat eine echte 1.2.8 in dasselbe Verzeichnis auf
diese Fassung gebracht: Release geladen, Clients, Zugangsdaten und die
DHCP-Konfiguration übernommen, Dienst läuft. Die Sicherung enthält die alte
Installation samtsqlite.dbundfernet.key(Verzeichnis 0700, Passphrase
0600),/tmpbleibt leer.Kleinigkeit
opusist aus allen Beispielen verschwunden. Das war der Name einer
Testinstanz; seit die Installationen wie ihre Anwendung heissen, ist er in
einer Hilfe nur ein Rätsel. In der Betriebsdoku stand dabei zweimal/opt
statt/srv.Installation
sudo bash /srv/tesm/deploy/update.sh tesmDownloads
-
TESM 2.0.8 Stable
released this
2026-09-03 14:53:37 +02:00 | 82 commits to main since this releaseUpgrade von 1.2.8 (Branch
SONNET5)upgrade.shfindet die alte Fassung jetzt auch dann, wenn sie nicht mehr unter
ihrem Hauptnamen liegt. Nach einemrename.shsteht unter/srv/tesmdie
laufende Installation und die Fassung 1.x unter/srv/tesm-sonnet5--
die Vorgabe zeigte danach auf die neue Installation und brach ab (sauber, aber
unbrauchbar). Gesucht wird nun an beiden Orten; erkannt wird eine 1.x an der
sqlite.dbim Wurzelverzeichnis, denn diese Fassung legt ihre Datenbank unter
data/app.dbab.Der Weg selbst ist gegen echte Altdaten geprüft: aus einer 1.2.8 kamen Clients,
Zugangsdaten und die DHCP-Konfiguration in eine Probeinstallation, aus einem
1.2.7-Lizenzserver Kunden, Tickets und neu signierte Lizenzen samt
übernommenem Signaturschlüssel und Anbieterblock.sudo bash deploy/upgrade.sh --app tesmInstallation
sudo bash /srv/tesm/deploy/update.sh tesmDownloads
-
TESM 2.0.7 Stable
released this
2026-09-03 14:44:33 +02:00 | 83 commits to main since this releaseAnmeldeseite
- Die Wortmarke steht jetzt auf beiden Anmeldeseiten -- bisher hing sie an
der Funktionszeile, und die hatte der Lizenzserver nicht. Die Zeile darunter
ist optional: bei TESMÜBERWACHEN · BOOTEN · ANBINDEN, beim Lizenzserver
LIZENZIEREN. - Der Kartenkopf ist weg: eine Kachel mit zwei Buchstaben, die Überschrift
"Anmelden" und der Anwendungsname darunter sagten dasselbe wie die Marke
darüber und der Knopf darunter. - Marke und Karte stehen übereinander im Fluss statt gestapelt -- auf einem
flachen Fenster schnitt die Karte mitten durch den Schriftzug. - Die Marke ist kürzer, symmetrisch um die Mitte aufgebaut und hat volle
Deckkraft (sie ist kein Wasserzeichen hinter der Karte mehr). - Der Farbverlauf im Hintergrund hat wieder Geometrie und Stärke der
Fassung 1.x. - "Bitte melden Sie sich an." ist weg -- auf einer Seite aus Anmeldefeld,
Passwortfeld und einem Knopf "Anmelden" sagte das nichts. Wessen Sitzung
gerade ablief, erfährt jetzt stattdessen, warum er wieder hier ist.
Drei Dinge, die lautlos nichts taten
- Die Versionsnummer in der Fusszeile war falsch.
__version__stand fest
verdrahtet in drei Dateien: angezeigt wurde vier Releases lang 2.0.2. Die
Nummer kommt jetzt aus den Metadaten des installierten Pakets, Quelle ist
pyproject.toml. gap: var(--sp-7)-- die Skala kennt kein--sp-7. Eine undefinierte
CSS-Variable verwirft die ganze Deklaration ohne Meldung.- Ein Test dagegen fand sofort
--surface-0: dreimal benutzt, nie
definiert. Die Schrift auf der Kachel "kritisch" blieb dunkelgrau auf Rot,
die Dateivorschau hatte keinen Grund, und das Feld "Recht nicht vorhanden" in
der Rechtematrix war durchsichtig -- also so hell wie die Karte, obwohl es
dunkler sein sollte.
Installation
sudo bash /srv/tesm/deploy/update.sh tesmDownloads
- Die Wortmarke steht jetzt auf beiden Anmeldeseiten -- bisher hing sie an
-
TESM 2.0.6 Stable
released this
2026-09-03 14:12:41 +02:00 | 84 commits to main since this releaseInstallation umbenennen
Neu:
deploy/rename.sh. Aus einer Instanz wird die Hauptinstallation (oder
umgekehrt):sudo bash deploy/rename.sh --app tesm --from tesm-opus --to tesmDer Name steckt an mehr Stellen als im Verzeichnisnamen, und drei davon sind
leicht zu übersehen: derSITE_KEYin der Umgebungsdatei (daraus entsteht der
Name des Sitzungscookies), die Zertifikats- und ACME-Pfade in der Datenbank,
und derserver_nameder nginx-Site --install.shschreibt die Site aus
seiner Vorlage neu, sobald sich diealias-Pfade ändern, und ohne den Namen
aus der Datenbank stehen danach zwei Sites mitserver_name _auf Port 80.Das venv wird verworfen und neu gebaut: seine Konsolenskripte tragen den
absoluten Pfad im Shebang, und danach zeigtvenv/bin/gunicornauf einen
Interpreter, den es nicht mehr gibt.Belegt der Zielname noch eine Installation der Fassung 1.x, wandert alles,
was ihn belegt, in ein Archiv/srv/<ziel>-sonnet5-- Verzeichnis, Protokolle,
ACME-Pfad, logrotate-Datei, systemd-Units und nginx-Site. Gelöscht wird nichts.Ports und HTTPS bleiben wie sie waren, ein vorhandenes Zertifikat zieht mit.
Alle angemeldeten Benutzer werden abgemeldet: das Sitzungscookie heisst
danach anders.Installation
sudo bash /srv/tesm/deploy/update.sh tesmDownloads
-
TESM 2.0.5 Stable
released this
2026-09-03 12:48:33 +02:00 | 86 commits to main since this releaseAnmeldebanner (MOTD)
Der Zustand der Installation steht wieder im SSH-Login-Banner:
TESM · TimEShepManager UEBERWACHEN · BOOTEN · ANBINDEN (DHCP) · BETRIEBSSYSTEM GEBEN (PXE) 3 Clients online · 0 nicht erreichbar · DHCP: 2 Leases aktivDas Banner der Fassung 1.x hing am alten Quellverzeichnis und importierte
dafür die ganze Anwendung samt venv. Nach einem Umstieg zeigte es damit die
Zahlen einer Datenbank, die niemand mehr füllt -- eingefroren, aber
unverdächtig.Diese Fassung benutzt nur die Standardbibliothek: kein venv, kein Import
der Anwendung, die Datenbank wird nur lesend geöffnet. Ein Lauf dauert
Millisekunden statt eines Flask-Starts, und der Aufruf ist mittimeout 3
abgesichert -- ein Banner darf eine Anmeldung nie blockieren.install.shlegt es an; ein Banner der Vorgängerfassung wird entfernt, aber
nur, wenn es genau auf dessenmotd_banner.pyzeigt. Von Hand prüfen:sudo /usr/local/lib/tesm/tesm-motd --app tesm --root /srv/<name>Damit es nicht zwei Wahrheiten über "online" gibt, steht die Zählung der
Statusübersicht jetzt an einer Stelle; das Banner trägt sie wortgleich, und ein
Test vergleicht beide.Installation
sudo bash /opt/tesm/deploy/update.sh tesm latest --instance <name>Downloads