• v2.2.0 2c3ca4acc1

    TESM 2.2.0 Stable

    alientim released this 2026-09-09 21:48:39 +02:00 | 73 commits to main since this release

    Vorschau: 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/pdf im
    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
  • v2.1.2 f16ba7d875

    TESM 2.1.2 Stable

    alientim released this 2026-09-09 00:27:04 +02:00 | 74 commits to main since this release

    Ein Sub-Paket kommt nicht mehr auf eine Wurzelinstanz

    Die Pruefung sah bisher nur nach, ob im Zielverzeichnis das Teilpaket
    tesm_license/master liegt. 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
    master und das Paket die Sub-Ausgabe, bricht install.sh vor 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 --yes
    

    update.sh erkennt die Ausgabe selbst; den Zugriffstoken fuer das private
    Repositorium erwartet es in TESM_RELEASE_TOKEN oder /etc/tesm-release.token.

    Downloads
  • v2.1.1 7bfe328e4b

    TESM 2.1.1 Stable

    alientim released this 2026-09-09 00:20:46 +02:00 | 75 commits to main since this release

    Nachtrag 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.sh und upgrade.sh:

    sudo bash /srv/tesm/deploy/update.sh tesm latest --yes
    

    Ohne Terminal und ohne --yes bricht es mit Code 3 ab und sagt, warum.

    Downloads
  • v2.1.0 5b9373bb24

    TESM 2.1.0 Stable

    alientim released this 2026-09-09 00:13:10 +02:00 | 76 commits to main since this release

    Rueckweg 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 Sicherung upgrade.sh haelt.

    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.sh liegt 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 --https
    

    Damit 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

    alientim released this 2026-09-08 23:13:44 +02:00 | 80 commits to main since this release

    Das Upgrade brach an der sudoers-Datei ab

    Auf einem frisch aufgesetzten Server:

    syntax error: unknown setting: 'requiretty'
    visudo: invalid sudoers file
     !! sudoers-Datei ist fehlerhaft
    

    Defaults:<benutzer> !requiretty stand in beiden sudoers-Dateien. Auf Debian
    und Ubuntu ist requiretty nie gesetzt -- die Zeile war von Anfang an
    wirkungslos -- und ab sudo 1.9.16 kennt visudo die 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.sh fä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-225428
    

    Dafür enthält die Sicherung mehr als das Verzeichnis: bei einem Upgrade in
    dasselbe Verzeichnis schreibt install.sh auch 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 tesm immer
    tesm.service. Nach einem rename.sh heisst so aber die laufende
    Installation. Wer die archivierte 1.x in eine eigene Instanz hochzieht und
    --keep-old-running vergisst, 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 tesm
    
    Downloads
  • v2.0.9 160675e368

    TESM 2.0.9 Stable

    alientim released this 2026-09-03 16:18:53 +02:00 | 81 commits to main since this release

    Eine Datei genügt

    upgrade.sh und update.sh holen 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 tesm
    

    Bisher verlangte upgrade.sh ein 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.9 lä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.sh darf kein Release daneben verlangen, und mit
    leerem PATH muss der Block das fehlende Werkzeug benennen.

    update.sh ruft install.sh nicht mehr per exec auf -- dadurch lief die
    Aufräumfalle nie, und jedes Update liess ein entpacktes Release unter /tmp
    liegen.

    Geprüft, nicht behauptet

    Die einzelne upgrade.sh hat 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 samt sqlite.db und fernet.key (Verzeichnis 0700, Passphrase
    0600), /tmp bleibt leer.

    Kleinigkeit

    opus ist 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 tesm
    
    Downloads
  • v2.0.8 3bbddd7d29

    TESM 2.0.8 Stable

    alientim released this 2026-09-03 14:53:37 +02:00 | 82 commits to main since this release

    Upgrade von 1.2.8 (Branch SONNET5)

    upgrade.sh findet die alte Fassung jetzt auch dann, wenn sie nicht mehr unter
    ihrem Hauptnamen liegt. Nach einem rename.sh steht unter /srv/tesm die
    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.db im Wurzelverzeichnis, denn diese Fassung legt ihre Datenbank unter
    data/app.db ab.

    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 tesm
    

    Installation

    sudo bash /srv/tesm/deploy/update.sh tesm
    
    Downloads
  • v2.0.7 7407f4bc00

    TESM 2.0.7 Stable

    alientim released this 2026-09-03 14:44:33 +02:00 | 83 commits to main since this release

    Anmeldeseite

    • 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 tesm
    
    Downloads
  • v2.0.6 635722089e

    TESM 2.0.6 Stable

    alientim released this 2026-09-03 14:12:41 +02:00 | 84 commits to main since this release

    Installation umbenennen

    Neu: deploy/rename.sh. Aus einer Instanz wird die Hauptinstallation (oder
    umgekehrt):

    sudo bash deploy/rename.sh --app tesm --from tesm-opus --to tesm
    

    Der Name steckt an mehr Stellen als im Verzeichnisnamen, und drei davon sind
    leicht zu übersehen: der SITE_KEY in der Umgebungsdatei (daraus entsteht der
    Name des Sitzungscookies), die Zertifikats- und ACME-Pfade in der Datenbank,
    und der server_name der nginx-Site -- install.sh schreibt die Site aus
    seiner Vorlage neu, sobald sich die alias-Pfade ändern, und ohne den Namen
    aus der Datenbank stehen danach zwei Sites mit server_name _ auf Port 80.

    Das venv wird verworfen und neu gebaut: seine Konsolenskripte tragen den
    absoluten Pfad im Shebang, und danach zeigt venv/bin/gunicorn auf 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 tesm
    
    Downloads
  • v2.0.5 6dff1ed137

    TESM 2.0.5 Stable

    alientim released this 2026-09-03 12:48:33 +02:00 | 86 commits to main since this release

    Anmeldebanner (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 aktiv
    

    Das 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 mit timeout 3
    abgesichert -- ein Banner darf eine Anmeldung nie blockieren.

    install.sh legt es an; ein Banner der Vorgängerfassung wird entfernt, aber
    nur, wenn es genau auf dessen motd_banner.py zeigt. 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