Dokumentation
Lizenzierung und Aktivierung
Eine Lizenz je Server, offline gegen ein signiertes Token verifiziert. Der Lizenzdienst muss nicht erreichbar sein, damit der Scanner arbeitet — für die Erneuerung muss er es aber sein.
Die Bestandteile
| Begriff | Bedeutung |
|---|---|
| Lizenzschlüssel | STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX — Crockford Base32, 25 Nutzzeichen einschließlich zweier Prüfzeichen. Wird bei der Erstellung der Lizenz erzeugt und genau einmal im Klartext zurückgegeben; der Dienst speichert nur sha256(key) sowie die ersten neun Zeichen als Anzeigepräfix. |
| Lizenz | Der Datensatz: Tarif, maximale Serveranzahl (standardmäßig 1), Status (active, suspended, terminated), Ablauf und die Verknüpfung mit Ihrem Konto. |
| Aktivierung | Die Bindung einer Lizenz an einen Server-Fingerabdruck. Höchstens max_servers gleichzeitig; deactivate gibt einen Platz frei. |
| Lizenz-Token | Ein Ed25519-signiertes Dokument, das der Daemon offline verifiziert. |
| Server-Fingerabdruck | sha256 über ein festes Präfix und den Inhalt von /etc/machine-id. Der Hostname wird nur zur Information übermittelt. |
Aktivierung
shelltrap license activate STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
shelltrap license status
shelltrap license renew
shelltrap license deactivate
Das Token landet in /etc/shelltrap/license.token, Eigentümer root, Modus 0600. Der Schlüssel
selbst wird nur als Präfix in /etc/shelltrap/license.key abgelegt, ebenfalls 0600, damit Sie
ihn für Erneuerungen nicht erneut eingeben müssen. Wenn Sie den Schlüssel lieber gar nicht auf
dem Server haben möchten, löschen Sie diese Datei und erneuern manuell.
Ein shelltrap-license.timer führt die Erneuerung täglich mit bis zu einer Stunde Jitter aus.
Dieser Dienst ist eine vom Daemon getrennte systemd-Unit, weil er die einzige Komponente ist, die
überhaupt AF_INET oder AF_INET6 benötigt — shelltrapd selbst ist auf AF_UNIX beschränkt.
$ shelltrap license activate STL-7QK3M-P2VDA-XN94T-B6HRE-Z8SWF
plan server
key prefix STL-7QK3M
valid until 2027-09-04
token until 2026-10-04
fingerprint e3b0c44298fc1c14…
servers 1 of 1
token written to /etc/shelltrap/license.token (0600, root)
$ shelltrap --json health
{"status":"ok","watcher_tier":"A","scanner_workers":2,"clamd":"ok",
"ruleset_gen":"20260903T120000Z-0001","policy_gen":17,"queue_age_s":0,
"overflows":0,"feeds":"ok"}
Aktivierung, anschließend eine Health-Prüfung. Gezeigt werden die Felder, die die CLI dokumentiert: Tarif, Präfix, Gültigkeit, Token-Gültigkeit, Fingerabdruck und Server-Kontingent.
Was im Token steht
Die Nutzlast ist kanonisches JSON mit sortierten Schlüsseln. Die betrieblich wichtigen Felder:
not_after— Gültigkeit des Tokens, 30 Tage nach der Ausstellung. Danach ist das Token ungültig, selbst wenn die Lizenz selbst länger läuft. Das ist es, was die Erneuerung erzwingt.license_expires_at— bezahlt bis, zuzüglich 14 Tagen Kulanzfrist. Liegt dieses Datum vornot_after, gilt das frühere Datum.fingerprint— der Server, für den dieses Token gilt. Ein auf eine andere Maschine verschobenes Token funktioniert nicht.features— die Liste der Funktionen, die die Lizenz freischaltet.key_id— gegen welchen Signaturschlüssel zu prüfen ist.
Die Verifikation nutzt gepinnte öffentliche Lizenzschlüssel. Das Paket liefert den
öffentlichen Panomity-Lizenzschlüssel unter /usr/share/shelltrap/keys/license-panomity.pub
aus, und die Konfiguration darf Schlüssel nur ergänzen, dieses Pinning aber nie ersetzen. Das
ist Absicht: Es hindert einen Serverbetreiber daran, den Vertrauensanker auszutauschen.
Die drei Zustände
| Zustand | Wann | Was der Daemon tut |
|---|---|---|
licensed | gültiges Token, passender Fingerabdruck | normaler Betrieb |
grace | Token läuft in weniger als 7 Tagen ab und die Erneuerung schlägt fehl | normaler Betrieb, dazu eine Warnung im Log, Health degraded mit license_renewal_failed und eine Administratorbenachrichtigung pro Tag |
unlicensed | kein Token, ungültige Signatur, Ablauf überschritten oder fremder Fingerabdruck | siehe unten |
Im Zustand unlicensed stürzt der Daemon nicht ab und läuft nicht in eine Neustartschleife:
- der Watcher läuft weiter, Ereignisse werden gezählt, aber nicht gescannt,
- der Scheduler plant nichts,
- das Upload-Gate antwortet mit
allowund dem Grundunlicensed, - Health meldet
status: "unlicensed"mit einem präzisendegraded_reasons-Eintrag —license_missing,license_expired,license_invalidoderlicense_fingerprint_mismatch, - ein Audit-Eintrag
license.statewird geschrieben, - die Metriken
shelltrap_license_state{state=…}undshelltrap_license_expires_secondsbilden das ab, - der Feed-Dienst antwortet mit 401, und der Feed-Controller meldet
feeds: unlicensed.
Das Entwurfsziel dahinter sei ausdrücklich genannt: Eine abgelaufene Lizenz muss laut nutzlos sein, niemals leise gefährlich. Ein Gate, das Uploads abzuweisen beginnt, weil eine Rechnung überfällig ist, wäre ein schlechteres Produkt als eines, das dies in Health meldet und den Verkehr durchlässt.
Feeds und die Lizenz
Jeder Feed-Abruf sendet das kompakte Token als Bearer-Credential. Ohne gültiges Token antwortet der Dienst mit 401. Signaturen, Updates und Support sind die kommerzielle Grenze dieses Produkts — unter Signatur-Feeds steht, was ankommt, wenn das Token gültig ist.
Downloads
GET /v1/downloads/index.json ist ohne Lizenz lesbar, damit eine Website die aktuellen Versionen
anzeigen kann. Die Pakete selbst werden nur gegen eine aktive Lizenz ausgeliefert:
GET /v1/downloads/<file>?key=STL-…. Der Dienst protokolliert das Schlüsselpräfix, nie den
Schlüssel. Es gibt keine unauthentifizierten Paketlinks; deshalb hat die
Download-Seite
ein Formular statt einer Liste von URLs.
Eine Lizenz auf einen anderen Server umziehen
# auf der alten Maschine
shelltrap license deactivate
# auf der neuen Maschine
shelltrap license activate STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Die erneute Aktivierung eines bereits aktiven Fingerabdrucks stellt lediglich ein neues Token aus und verbraucht keinen zweiten Platz; eine Erneuerung sperrt Sie also nie aus Ihrem eigenen Server aus.
Was eine Lizenzprüfung nicht leisten kann
Ein Angreifer mit Root-Rechten auf Ihrem Server kann jedes Binary darauf patchen, unseres eingeschlossen, und keine clientseitige Prüfung übersteht das. Das schreiben wir auch in den Lizenzbedingungen . Der kommerzielle Schutz beruht darauf, dass Signaturen, Updates und Support nur mit einer aktiven Lizenz erreichbar sind und dass kein Quellcode ausgeliefert wird.
Weiter
Gekürzt aus dem Shelltrap-Lizenzierungshandbuch, Revision 2026-09-04.