Befehle für die Appliance

Die Befehle ironflock appliance installieren die IronFlock-Appliance auf einem Linux-Server, den Sie selbst betreiben, und kümmern sich von da an um sie. Mit ihnen installieren Sie die Appliance, ändern ihre Einstellungen, aktualisieren sie, starten, stoppen und starten sie neu, lesen ihre Logs, setzen das Admin-Passwort zurück, sichern, stellen wieder her und rotieren ihre Secrets und entfernen sie wieder.

Die Appliance ist das vollständige IronFlock-System auf einer Maschine vor Ort. Was sie ist, ihre HTTPS-Modi, ihr Netzwerk und ihr Betrieb sind unter IronFlock Appliance beschrieben. Die Anforderungen an die Maschine (CPU, Arbeitsspeicher, Speicherplatz, Zeitsynchronisation) stehen auf ihrer Seite Installation.

Hinweis: Diese Befehle sind neu in Release 2.1.0 von ironflock. Sie haben einen Testlauf bestanden, von appliance install bis appliance remove --purge, auf einer frischen virtuellen Maschine mit Ubuntu 24.04 (amd64). Noch nicht erprobt ist ein Update, das fehlschlägt, mit seinem Rollback auf das Release davor.

Die Appliance

Die Appliance-Befehle laufen unter Linux. appliance install braucht ein System auf Basis von Debian oder Ubuntu mit systemd. Unter macOS enden die Befehle mit Exit-Code 3, bevor sie sich irgendetwas ansehen; führen Sie sie auf der Maschine der Appliance aus oder vom Mac aus mit --host.

Führen Sie sie als root aus, mit sudo. Ein Befehl, der das System ändert, endet ohne Root-Rechte mit Exit-Code 3 und ruft sudo nicht selbst auf (Root-Rechte).

Jeder Befehl akzeptiert außerdem die globalen Flags --yes, --json, --download-base, --host, --hosts und --parallel (Globale Flags). Eine Frage braucht ein Terminal; ohne Terminal geben Sie --yes an (Fragen und Bestätigung).

ironflock status zeigt die installierte Appliance: ihre Version und ihren Kanal, die Adresse ihrer Oberfläche, ob ihre Lizenz vorhanden ist, ihren Dienst, den Zustand ihrer Dienste und ein wartendes Update (ironflock status).

So sieht eine installierte Appliance aus

Neben ironflock.service richtet die Installation einen Watchdog ein, der alle fünf Minuten den Router und das Backend prüft und ironflock.service neu startet, wenn es ihnen nicht gut geht, höchstens einmal in fünf Minuten, sowie einen Timer, der ein fehlgeschlagenes Update aus der Oberfläche stündlich erneut versucht.

Lassen Sie /usr/local/bin/ironflock an seinem Platz: Die Units der Appliance führen es bei jedem Start aus. appliance install lehnt es ab, von einem anderen Ort aus zu laufen, und sagt, wie Sie es dort installieren. ironflock status, als root ausgeführt, warnt, wenn diese Binärdatei fehlt oder älter ist als die, die die Appliance zuletzt installiert oder aktualisiert hat. sudo ironflock self-update ersetzt sie durch das neueste Release (ironflock self-update).

Die Appliance betreibt außerdem den eigenen Geräte-Agenten des Hosts, den appliance install installiert, wenn Sie nicht --no-agent angeben. Um diesen Agenten kümmern sich die agent-Befehle.

Eine Änderung nach der anderen

Es läuft immer nur eine Installation, ein Update oder eine andere Änderung der Appliance. Eine zweite wartet auf die erste und sagt das:

Another IronFlock install, update or other change of the appliance is running on this host (process <pid>); waiting up to <time> for it to finish

install, update, configure, rotate, revoke-direct-access, reset-admin-password und restore warten bis zu einer Stunde. start, stop, restart und remove warten bis zu 30 Sekunden. Läuft der andere Vorgang dann noch, ändert der Befehl nichts und endet mit Exit-Code 3.

ironflock appliance install

Installiert die IronFlock-Appliance in /opt/ironflock und startet sie. Der Befehl wartet, bis jeder Dienst gesund ist und die IronFlock-Cloud die Appliance erreicht, und zeigt dann die Admin-Anmeldung der Weboberfläche an, einmal, in einem Terminal.

ironflock appliance install --license-file <file> [flags]

Läuft unter: Linux auf Basis von Debian oder Ubuntu, mit systemd. Root-Rechte: nötig.

Die Installation richtet ein:

• das Release des Kanals oder das, das --version nennt, geprüft gegen den Release-Schlüssel der Appliance;
• die Konfiguration und die Secrets der Appliance;
• den eigenen Geräte-Agenten des Hosts und Docker, wenn es fehlt;
• die Einstellungen des Hosts;
• die Anmeldung von Docker an der Registry mit dem Lizenzschlüssel;
• die Images des Release;
• ironflock.service.

Fehlt Docker, führt die Installation das Installationsskript von Docker von get.docker.com als root aus. Dieser Download ist nur durch TLS geschützt.

Die HTTPS-Modi und was jeder von ihnen verschlüsselt, beschreiben HTTPS & Zertifikate und Sicherheit. Für das Proxy-Passwort gelten die Regeln unter Secrets: Eine Proxy-URL mit Passwort darin ist eine falsche Befehlszeile.

Der Lizenzschlüssel

Der Lizenzschlüssel ist der Instance Key, den Sie auf ironflock.com unter Profil → Instanzen erstellen (Installation). Er kommt aus --license-file oder --license. Eine bereits installierte Appliance behält ihren Schlüssel ohne beide. Ein Schlüssel in license.env, der kein gültiger Lizenzschlüssel ist (ein Lizenzschlüssel ist eine UUID), wird von jedem Appliance-Befehl mit einer Warnung ignoriert; der Lauf braucht dann einen Schlüssel oder --skip-login.

Umgebungsvariablen

Einige Flags nehmen ihren Standard aus einer Umgebungsvariablen:

sudo verwirft die meisten Variablen Ihrer Shell. Übergeben Sie sie mit sudo env NAME=value ironflock appliance install ....

Die festgehaltenen Optionen der Installation

<install-dir>/install.json, allein für root, hält die Optionen fest, die weder die .env noch die Units festhalten: die Registry und ihren Benutzer, den Host der Appliance (IRONFLOCK_APPLIANCE_HOST), --no-agent, die Download-Basis von --bucket-url und die Version des ironflock, das die Appliance zuletzt installiert oder aktualisiert hat. Sie enthält kein Passwort, kein Token und keinen Schlüssel.

Ein späteres appliance install, ein appliance update und appliance configure behalten diese Optionen bei, wenn kein Flag (oder seine Variable) etwas anderes sagt. Ein angegebenes Flag hat Vorrang und wird festgehalten. Um zu einem Standard zurückzukehren, geben Sie --registry "", --no-agent=false oder ein leeres IRONFLOCK_APPLIANCE_HOST an.

Eine Aufzeichnung, die sich nicht lesen lässt oder die ein späteres Format hat, hält install, update und configure an, bevor sie etwas ändern, mit Exit-Code 3. Die Meldung sagt, was zu tun ist: die Aufzeichnung beiseitelegen und mit den Flags erneut installieren, oder das neuere ironflock verwenden.

Erneut ausführen

Auf einer installierten Appliance ausgeführt, bringt der Befehl sie auf das Release und die Optionen, die angegeben sind, und behält ihre Secrets und Einstellungen. So wechseln Sie das Release gezielt: ironflock appliance install --version <version> lädt dieses Release erneut, startet es neu und prüft es, auch wenn es bereits läuft.

Ein Lauf, der angehalten hat, macht dort weiter, wo er angehalten hat, wenn derselbe Befehl erneut läuft.

Sobald ihre Prüfungen der Dienste bestanden sind, entfernt die Installation die Kopie eines Release davor, die ein Update aufbewahrt hat (/opt/ironflock/.update-previous): Das Release, das sie installiert hat, ist das, das laufen soll.

Ab ihrer ersten Änderung halten ein verlorenes Terminal oder eine verlorene SSH-Sitzung (SIGHUP) oder eine Ausgabe, die niemand mehr liest (eine geschlossene Pipe), die Installation nicht an. Strg+C und SIGTERM schon. Die Installation schreibt nach einer verlorenen SSH-Sitzung weiter ins Terminal, damit das Admin-Passwort nicht verloren geht. Mit der sudo-Einstellung use_pty kann ein Terminal, das offen bleibt, aber nicht mehr gelesen wird, die Installation deshalb aufhalten, während sie die Installationssperre hält.

Beispiele

# Die Appliance installieren; der Lizenzschlüssel kommt aus einer Datei
sudo ironflock appliance install --license-file license.txt
# Mit HTTPS aus der eigenen CA der Appliance installieren; der Schlüssel kommt von der Standardeingabe
sudo ironflock appliance install --license-file - --tls < license.txt
# Hinter einem Proxy installieren; Hosts unter .corp.example.com umgehen ihn
sudo ironflock appliance install --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
# Nach Adresse und Domain der Appliance fragen und mit HTTPS installieren
sudo ironflock appliance install --license-file license.txt --interactive --tls

Wann der Befehl ablehnt oder fehlschlägt

• Eine Download-Basis von --bucket-url, die die Units nicht so nennen können, wie sie ist (Anmeldedaten darin, %, Leerraum, $, \, ein Anführungszeichen, ein Steuerzeichen, Bytes, die kein UTF-8 sind), wird abgelehnt, bevor etwas geschrieben wird, mit Exit-Code 2.
• Der Befehl lehnt mit Exit-Code 3 ab, wenn er nicht als root läuft, wenn sich die Aufzeichnung der Optionen der Installation nicht lesen lässt und wenn ein anderer Lauf die Installationssperre über die Wartezeit von einer Stunde hinaus hält. Er lehnt auch ab, wenn das laufende ironflock nicht /usr/local/bin/ironflock ist, und sagt, wie Sie es dort installieren.
• Ein fehlgeschlagener Schritt beendet den Befehl mit Exit-Code 1. Führen Sie denselben Befehl erneut aus, um fortzufahren.

ironflock appliance configure

Ändert die Einstellungen einer installierten Appliance: ihre Lizenz, den TLS-Modus (auch mit einem eigenen Zertifikat), den Proxy, weitere Hostnamen für die Oberfläche, den Tunnel und die Richtlinie für den zweiten Faktor.

ironflock appliance configure [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig.

Die Einstellungen bleiben in der .env und den Dateien der Appliance, sodass ein Update sie behält. Eine Einstellung, die nicht angegeben ist, behält, was die Appliance hat. Nur ein Lauf, der etwas geändert hat, startet die Appliance neu, sodass derselbe Befehl beim zweiten Mal nichts ändert.

• Eine neue Lizenz (--license, --license-file oder --license-file - für die Standardeingabe) muss die Registry öffnen, bevor sie geschrieben wird. Ihre Anmeldung geht an --registry als --registry-user, sonst an die, die die Installation gewählt hat (die Aufzeichnung), sonst an die Registry, aus der der Spiegel der Appliance synchronisiert. Eine Anmeldung mit --registry oder --registry-user hält diese für die Updates in der Aufzeichnung fest.
• --tls-cert und --tls-key installieren Ihr Zertifikat und schalten TLS ein, und die Geräte wechseln auf die Domain der Appliance.
• --http-proxy "" oder --https-proxy "", allein angegeben, entfernt den Proxy.
• --no-agent der Installation bleibt, wie es war.
• Das Caddyfile, das TLS braucht, kommt von --bucket-url, sonst von dort, wo die Installation die Releases bezogen hat.

Beispiele

# Der Appliance einen neuen Lizenzschlüssel aus einer Datei geben
sudo ironflock appliance configure --license-file license.txt
# Die Oberfläche mit dem Zertifikat Ihrer Organisation bereitstellen
sudo ironflock appliance configure --tls-cert wildcard.crt --tls-key wildcard.key
# Einen Proxy setzen und wieder entfernen
sudo ironflock appliance configure --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
sudo ironflock appliance configure --https-proxy ""
# Von jedem Benutzer einen zweiten Faktor verlangen
sudo ironflock appliance configure --2fa required

Bevor Sie --2fa required setzen, stellen Sie sicher, dass jedes Konto einen zweiten Faktor hat: Ein Benutzer ohne zweiten Faktor kann sich nicht mehr anmelden (Konten und Zugriff).

Wann der Befehl ablehnt

Der Befehl lehnt mit Exit-Code 3 ab und ändert nichts, wenn er nicht als root läuft, wenn sich die Aufzeichnung der Optionen der Installation nicht lesen lässt, wenn ein anderer Lauf die Installationssperre über die Wartezeit von einer Stunde hinaus hält und solange ein Update abgebrochen ist (Wenn ein Update abgebrochen wurde).

ironflock appliance update

Aktualisiert die Appliance auf dieser Maschine auf das neueste Release ihres Kanals oder auf das Release, das --version nennt. Das Release wird gegen den Release-Schlüssel der Appliance geprüft, seine Images werden geladen, und die Appliance startet damit neu. Der Befehl wartet, bis jeder Dienst gesund ist und die IronFlock-Cloud die Appliance erreicht. Die Appliance behält ihre Secrets und Einstellungen. Die Images früherer Releases werden entfernt, sobald das neue gesund ist.

ironflock appliance update [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: nichts, außer mit --discard-previous.

Die Releases kommen von --bucket-url, sonst von IRONFLOCK_BUCKET_URL, sonst von dort, wo die Installation sie bezogen hat (die Aufzeichnung ihrer Optionen, /opt/ironflock/install.json, oder ihre Units nennen es), sonst von IronFlock. Die Registry, ihr Benutzer, der Host der Appliance und --no-agent bleiben, wie die Installation sie gewählt hat.

Ein neuer Kanal bleibt, wenn das Update gelingt; bei einem Rollback kommt der Kanal davor zurück. Apply update in der Oberfläche führt dasselbe Update aus.

Sobald ihre Prüfungen bestanden sind, stellt eine Installation oder ein Update außerdem das eigene Gerät der Appliance von dem Secret, das sich früher jede Appliance teilte, auf den Wert von APPLIANCE_DEVICE_SECRET um. Sein Agent startet dann 35 Sekunden nach dem Lauf neu. Eine Umstellung, die sich nicht durchführen lässt, ist eine Warnung, die sagt, warum; die nächste Installation oder das nächste Update versucht es erneut.

Bereits aktuell

Eine Appliance, die bereits das neueste Release ihres Kanals ausführt (oder das Release, das --version nennt), auf demselben Kanal und derselben Download-Basis, bleibt, wie sie ist. Der Befehl sagt das und endet mit Exit-Code 0; mit --json ist das result nothing-to-do. Um dieses Release gezielt erneut zu laden, neu zu starten und zu prüfen, führen Sie ironflock appliance install --version <version> aus.

Das gilt nur für eine Appliance, die das letzte Update sauber hinterlassen hat. Mit einer aufbewahrten Kopie eines Release davor (einem abgebrochenen Update) oder einer Statusdatei, die failed oder running sagt, führt das Update alles erneut aus.

Rollback

Bevor das Update etwas ändert, bewahrt es die Dateien des laufenden Release in /opt/ironflock/.update-previous auf. Schlägt das Update fehl, nachdem es die Appliance geändert hat, werden diese Dateien zurückgelegt, und das Release davor startet wieder. Das braucht kein Netzwerk, da seine Images auf der Maschine liegen. Es wird bis zu dreimal versucht. Danach gibt der Befehl auf und lässt die Dateien des Release davor an ihrem Platz, sodass der nächste Start der Appliance dieses Release ist.

Ein Update, das fehlschlägt, bevor es etwas geändert hat, ändert nichts weiter und sagt das: zum Beispiel bei einem Release, das nicht vorhanden oder nicht signiert ist, oder einer Download-Basis, die nicht antwortet.

Ein Release kann ein neueres ironflock brauchen als das laufende. Dann wird nichts geändert, und der Befehl sagt, welches ironflock zuerst zu installieren ist. appliance update aktualisiert ironflock nicht von selbst; ironflock self-update installiert das neueste.

Statusdatei und Wiederholung

Das Update schreibt seinen Fortschritt in triggers/apply-update.status, wie das Update aus der Oberfläche, sodass die Oberfläche ihn anzeigt. Seine Ausgabe geht außerdem in triggers/apply-update.log. Der Timer, der ein fehlgeschlagenes Update aus der Oberfläche erneut versucht, versucht ein Update dieses Befehls nicht erneut, das fehlgeschlagen ist oder angehalten wurde, bevor es etwas geändert hat.

Unterbrechungen

• Strg+C oder SIGTERM, bevor das Update etwas geändert hat, halten es an. Danach bringt das erste das Release davor zurück (Exit-Code 130), und ein zweites hält sofort an.
• Ein verlorenes Terminal oder eine verlorene SSH-Sitzung (SIGHUP) oder eine Ausgabe, die niemand mehr liest, halten das Update nicht an. Das Update und ein Rollback laufen bis zu ihrem Ende. Die Statusdatei und ironflock status sagen, wie es geendet hat.
• Über --host ohne Terminal erreichen die ersten beiden Strg+C die Maschine. Nach dem ersten wartet der Befehl bis zu 30 Minuten, dass das Update dort endet; nach dem zweiten 15 Sekunden; ein drittes beendet ihn hier sofort. Eine verlorene Sitzung hier oder SIGTERM ist kein Strg+C: Der Befehl endet hier sofort. Wann immer er hier zuerst endet, läuft das Update auf der Maschine weiter, und ironflock --host <machine> status zeigt, wie es geendet hat.

Wenn ein Update abgebrochen wurde

Ein Update wurde abgebrochen, wenn es begonnen hat, die Appliance zu ändern, und dann nicht zu Ende kam: Es wurde angehalten, die Maschine ist ausgefallen, oder sein Rollback hat das Release davor nicht wieder hochgebracht. Das Installationsverzeichnis kann dann Dateien zweier Releases enthalten. Die aufbewahrte Kopie nennt das Release, von dem bekannt ist, dass es läuft, und ironflock status nennt es ebenfalls.

• Das nächste Update legt diese Kopie zuerst zurück und aktualisiert dann. Eine Kopie, die sich nicht lesen oder zurücklegen lässt, hält das Update mit Exit-Code 3 an, und der Fehler nennt ironflock appliance install --version <version>.
• Der stündliche Wiederholungs-Timer legt die Kopie von sich aus zurück, startet dieses Release neu und prüft es, auch wenn es kein neueres Release gibt.
• configure, rotate, revoke-direct-access, restore und reset-admin-password lehnen vor jeder Änderung ab, mit Exit-Code 3. Sie nennen die drei Auswege: ironflock appliance update; ironflock appliance install --version <version>; und ohne Netzwerk ironflock appliance update --discard-previous.
• backup liest nur und warnt. start, stop und restart lassen die Kopie in Ruhe. remove nimmt die Kopie mit den übrigen Dateien der Appliance mit.
• appliance install läuft wie immer und entfernt die Kopie, sobald seine Prüfungen der Dienste bestanden sind.

Um die Dateien eines abgebrochenen Updates von Hand zu bearbeiten, setzen Sie zuerst IRONFLOCK_UPDATE_RETRY=off in der .env. Sonst legt der Wiederholungs-Timer das Release davor innerhalb von etwa einer Stunde zurück. Diese Einstellung schaltet den Wiederholungs-Timer als Ganzes aus, sein Rollback eingeschlossen.

--discard-previous

ironflock appliance update --discard-previous [--yes]

Aktualisiert nichts. Entfernt die Kopie des Release davor, die ein Update aufbewahrt hat (/opt/ironflock/.update-previous), in jedem Zustand und auch, wenn sie sich nicht lesen lässt, und ändert sonst nichts. Braucht kein Netzwerk.

Es ist der Ausweg ohne Netzwerk, wenn ein Update abgebrochen wurde und sein Release davor nicht wieder startet. Die Dateien des Installationsverzeichnisses bleiben, wie sie jetzt sind, dieses Release lässt sich nicht mehr zurücklegen, und die Befehle, die abgelehnt haben, laufen wieder.

Es sagt, was es entfernt, und fragt vorher, mit „Nein“ vorausgewählt; --yes antwortet mit Ja. Ohne Terminal oder mit --json braucht es --yes, sonst endet es mit Exit-Code 4. Ohne Kopie sagt es das und endet mit Exit-Code 0. Es lässt sich nicht mit --version, --channel oder --bucket-url kombinieren (Exit-Code 2). Mit --json hat das Ergebnis action (discarded, cleaned oder none), path, version, state und removed.

Beispiele

# Auf das neueste Release des Kanals aktualisieren
sudo ironflock appliance update
# Release 1.6.41 installieren, auch um zu ihm zurückzugehen
sudo ironflock appliance update --version 1.6.41
# Auf den Testkanal wechseln und das Ergebnis als JSON lesen
sudo ironflock appliance update --channel test --json
# Die Kopie des Release davor entfernen, ohne Netzwerk
sudo ironflock appliance update --discard-previous

Ergebnis

{"from":"1.6.40","target":"1.6.41","version":"1.6.41","result":"updated"}

Ein fehlgeschlagenes Update ist ein Fehler, der sagt, ob die Appliance zum Release davor zurückgekehrt ist. Mit --json ist sein kind einer der folgenden, auch wenn es unterbrochen wurde:

ironflock appliance start

Startet die Appliance, wenn sie nicht läuft: ironflock.service startet ihre Container (docker compose up), und ihr Watchdog sowie ihre anderen Paths und Timer starten wieder. Die Dienste brauchen ein bis zwei Minuten, bis sie oben sind; ironflock status zeigt ihren Zustand.

ironflock appliance start [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: nichts. Der Befehl hat keine eigenen Flags.

Hat eine Wiederherstellung Datenbankrollen auf ihren alten Passwörtern gelassen, weil die Appliance damals nicht lief, erhalten diese die Passwörter der wiederhergestellten .env, sobald ihre Datenbanken laufen (bis zu einer Minute). Eine Rolle, die nicht antwortet, bleibt mit einer Warnung für den nächsten Start, und der Start geht weiter.

sudo ironflock appliance start
sudo ironflock appliance start --json

Während ein anderer Lauf die Appliance ändert, wartet der Befehl bis zu 30 Sekunden und sagt das; läuft dieser Lauf weiter, ändert er nichts und endet mit Exit-Code 3.

ironflock appliance stop

Stoppt die Appliance: ihren Watchdog und ihre anderen Paths und Timer und was sie gestartet haben, dann ironflock.service, das ihre Container stoppt und entfernt (docker compose down). Ihre Daten bleiben.

ironflock appliance stop [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: ja, nachdem er gesagt hat, was das Stoppen beendet; --yes antwortet.

Die Oberfläche geht offline, ebenso jedes Gerät, das sich mit der Appliance verbindet, auch der Agent dieser Maschine. ironflock appliance start startet die Appliance wieder, ebenso der nächste Boot. Der Befehl hat keine eigenen Flags.

# Die Appliance stoppen; der Befehl sagt, was das beendet, und fragt
sudo ironflock appliance stop
# Sie ohne Frage stoppen
sudo ironflock appliance stop --yes

Die Antwort Nein oder eine Frage ohne Terminal und ohne --yes beendet den Befehl mit Exit-Code 4. Während ein anderer Lauf die Appliance ändert, wartet der Befehl wie start.

ironflock appliance restart

Startet die Appliance neu: ironflock.service stoppt ihre Container und startet sie wieder (docker compose down, dann up), wie es ihr Watchdog tut. Die Paths und Timer, die appliance stop gestoppt hat, starten wieder.

ironflock appliance restart [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: nichts. Der Befehl hat keine eigenen Flags.

Die Oberfläche und die Geräte, die sich mit der Appliance verbinden, sind für ein bis zwei Minuten offline; ihre Daten bleiben. ironflock status zeigt den Zustand der Dienste, sobald sie oben sind. Datenbankrollen, die eine Wiederherstellung auf ihren alten Passwörtern gelassen hat, erhalten die der .env, wie bei start.

sudo ironflock appliance restart
sudo ironflock appliance restart --json

Während ein anderer Lauf die Appliance ändert, wartet der Befehl wie start.

ironflock appliance logs

Zeigt, was die Dienste der Appliance geschrieben haben, so wie docker compose logs es zeigt: standardmäßig die letzten 100 Zeilen jedes Dienstes. Ändert nichts.

ironflock appliance logs [<service>...] [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: nichts.

Nennen Sie Dienste, um nur deren Zeilen zu sehen, etwa router, backend, kratos oder caddy.

Mit --json ist jede Zeile ein JSON-Objekt, mit der Zeile als Nachricht.

# Die letzten 100 Zeilen jedes Dienstes
sudo ironflock appliance logs
# Alles, was das Backend in der letzten Stunde geschrieben hat
sudo ironflock appliance logs backend --since 1h
# Die letzten 20 Zeilen des Routers und von Kratos, dann jede neue Zeile bis Strg+C
sudo ironflock appliance logs router kratos --follow --lines 20

ironflock appliance reset-admin-password

Gibt dem Benutzer admin der Oberfläche ein neues Passwort, für einen Betreiber, der es verloren hat. Das Passwort wird zuerst in der Datenbank gesetzt, was jede aktive Sitzung des Admins beendet, dann in der .env als APPLIANCE_ADMIN_PASSWORD. Die Appliance muss laufen.

ironflock appliance reset-admin-password [flags]

Läuft unter: Linux, mit einer laufenden Appliance. Root-Rechte: nötig.

Das neue Passwort wird einmal angezeigt, und nur in einem Terminal. Ohne Terminal und mit --json sagt der Befehl stattdessen, wo es gespeichert ist. Er lehnt mit Exit-Code 3 ab, solange ein Update abgebrochen ist (Wenn ein Update abgebrochen wurde).

sudo ironflock appliance reset-admin-password

ironflock appliance backup

Schreibt alles der Appliance, was sich nicht neu erzeugen lässt, in ein tar.gz-Archiv: die .env mit jedem Secret, license.env, die lokale CA des TLS-Zertifikats, das Token-Schlüsselpaar der Registry, das Verzeichnis der Secrets und rotation.log.

ironflock appliance backup [-o <file>] [flags]

Läuft unter: Linux. Root-Rechte: nötig.

Ohne -o geht das Archiv auf die Standardausgabe, die kein Terminal sein darf. Eine Datei, in die sie umgeleitet wird, wird nur für ihren Eigentümer lesbar gemacht.

Warnung: Das Archiv enthält jedes Secret der Appliance. Ein verlorener FLEETDB_SECRET_KEYS oder FILE_CRED_KEY lässt sich auf keinem anderen Weg wiederherstellen. Verschlüsseln Sie das Archiv und bewahren Sie es bei den Backups der Volumes auf.

Nicht im Archiv: das TLS-Zertifikat und sein Schlüssel (ein generiertes wird aus der CA neu signiert), die Kratos-Konfiguration, die Dateien des Release und die Docker-Volumes. Aus certs/ca und registry-token-certs nimmt es die Dateien, die eine Installation dort anlegt (rootCA.crt, rootCA.key, rootCA.srl; token_private.key, token_public.crt, token_public.der, auch mit .prev oder .new). Jede andere Datei dort wird ausgelassen, mit einer Warnung, die sie nennt, da restore keine andere annimmt.

# Das Archiv in eine Datei schreiben, die nur root lesen kann
sudo ironflock appliance backup -o /root/appliance-secrets.tar.gz
# Es auf die Standardausgabe schreiben, in eine Datei
sudo ironflock appliance backup > appliance-secrets.tar.gz

ironflock appliance restore

Spielt ein Backup, das appliance backup geschrieben hat, in das Installationsverzeichnis zurück.

ironflock appliance restore <file> [flags]

Läuft unter: Linux. Root-Rechte: nötig.

Der Befehl nimmt die Dateien, die ein Backup enthält, und nichts anderes, jede mit dem Eigentümer und dem Modus, den eine Installation ihr gibt. In certs/ca und registry-token-certs nimmt er nur die Dateien, die eine Installation dort anlegt. Ein Archiv, das mehr enthält, wird abgelehnt, bevor sich etwas ändert, und der Fehler nennt, was.

Die Secrets einer installierten Appliance werden nur mit --force ersetzt; ihre .env bleibt als .env.prev erhalten. Ohne --force wird die Wiederherstellung über eine installierte Appliance vor jeder Änderung abgelehnt, mit Exit-Code 3, und die Meldung nennt die Wiederherstellung mit --force und danach appliance restart.

Ein Lizenzschlüssel im Backup, der kein gültiger Lizenzschlüssel ist, wird so wiederhergestellt, wie er ist, mit einer Warnung: Jeder Appliance-Befehl ignoriert ihn.

Datenbankpasswörter

• Während die Datenbank der Appliance läuft, übernehmen ihre Rollen die wiederhergestellten Passwörter sofort. Starten Sie die Appliance dann neu (appliance restart), damit jeder Dienst die wiederhergestellten Dateien liest.
• Während die Appliance nicht läuft, behalten ihre Datenbankrollen die Passwörter von vorher. Die Wiederherstellung markiert sie (<install-dir>/.db-roles-pending; roles_pending mit --json). Der nächste Start setzt sie auf die wiederhergestellte .env: appliance start oder restart, der Start beim Boot, eine Installation oder ein Update.

# Auf einer installierten Appliance wiederherstellen und sie dann neu starten
sudo ironflock appliance restore appliance-secrets.tar.gz --force
sudo ironflock appliance restart

Der Befehl lehnt mit Exit-Code 3 ab, solange ein Update abgebrochen ist (Wenn ein Update abgebrochen wurde).

ironflock appliance rotate

Gibt einem Secret der Appliance einen neuen Wert. Der neue Wert kommt dorthin, wo der alte hinterlegt ist (eine Datenbankrolle, die Gerätedatei des Agenten, das Token-Schlüsselpaar der Registry), und in die .env. Dann werden nur die Dienste neu erstellt, die das Secret lesen, und der Befehl prüft, dass sie gesund sind.

ironflock appliance rotate <name> [flags]

Läuft unter: Linux, mit einer laufenden Appliance. Root-Rechte: nötig. Fragt: bei einem Secret, das auch etwas anderes hält; --yes antwortet.

Die .env vor der Änderung bleibt als .env.prev erhalten, nur für root lesbar. rotation.log listet jede Rotation auf, nie einen Wert.

• Ein Secret, das auch etwas anderes hält (Daten, ein Gerät, ein Token), fragt vor seiner Rotation; --yes antwortet.
• FILE_CRED_KEY braucht eine Entscheidung für die Direktzugriffsschlüssel der Kunden. --keep-direct-access: Sie funktionieren weiter, für eine planmäßige Rotation; beenden Sie sie später mit revoke-direct-access. --revoke-direct-access: Sie funktionieren nicht mehr und werden entfernt, nach einem vermuteten Leck.
• APPLIANCE_ADMIN_PASSWORD ist dasselbe wie reset-admin-password.

Die Secrets, die der Befehl rotiert:

POSTGRES_PASSWORD, PGPASSWORD_KRATOS, PGPASSWORD_ACCT_MANAGER,
PGPASSWORD_ACCT_PUSHER, PGPASSWORD_EXT_ACCT_USER, PGPASSWORD_AUDIT_SANDBOX,
DATASERVICE_PASSWORD, WAMP_SYSTEM_SECRET, WAMP_SECRET_SVC_VDM,
WAMP_SECRET_SVC_IDE, WAMP_SECRET_SVC_IDE_PROXY, WAMP_SECRET_SVC_GIT,
WAMP_SECRET_SVC_REGISTRY, WAMP_SECRET_SVC_REGISTRY_PROXY,
WAMP_SECRET_SVC_ACCT, WAMP_SECRET_SVC_ACCT_PUSH, WAMP_SECRET_SVC_PAYMENT,
WAMP_SECRET_SVC_FLEETDB, WAMP_SECRET_SVC_FLEETFILES, WAMP_SECRET_SVC_AI,
WAMP_SECRET_SVC_TUNNEL, WAMP_SECRET_SVC_RENDERER, WAMP_SECRET_SVC_WEBSERVER,
WAMP_SECRET_SVC_REAPI, WAMP_SECRET_SVC_AUTH, RENDER_TICKET_KEY,
FILES_FORWARD_SECRET, KRATOS_WEBHOOK_SECRET, KRATOS_SECRETS_PAGINATION,
REGISTRY_HTTP_SECRET, TUNNEL_DASHBOARD_PASSWORD, EDGE_SESSION_SECRET,
OBJECTSTORE_ADMIN_ACCESS_KEY, OBJECTSTORE_ADMIN_SECRET_KEY, FILE_CRED_KEY,
FLEETDB_SECRET_KEYS, KRATOS_SECRETS_COOKIE, KRATOS_SECRETS_CIPHER,
APPLIANCE_DEVICE_SECRET, APPLIANCE_ADMIN_PASSWORD, REGISTRY_TOKEN_KEY

Was eine Rotation bei jeder Art von Secret bewirkt und welche Secrets Sie nur gemeinsam mit dem IronFlock-Team rotieren, beschreibt Ein internes Secret rotieren.

# Das Secret eines Dienstes rotieren
sudo ironflock appliance rotate WAMP_SECRET_SVC_AI
# Den Dateischlüssel planmäßig rotieren; die Direktzugriffsschlüssel funktionieren weiter
sudo ironflock appliance rotate FILE_CRED_KEY --keep-direct-access --yes

Der Befehl lehnt mit Exit-Code 3 ab, solange ein Update abgebrochen ist (Wenn ein Update abgebrochen wurde).

ironflock appliance revoke-direct-access

Beendet eine Rotation von FILE_CRED_KEY, die mit --keep-direct-access erfolgt ist. Jeder Direktzugriffsschlüssel der Kunden, der nicht mit dem aktuellen FILE_CRED_KEY erstellt wurde, funktioniert nicht mehr und wird entfernt; der Schlüssel selbst bleibt. Der Dienst fleetfiles wird neu erstellt und meldet, was er entfernt hat.

ironflock appliance revoke-direct-access [flags]

Läuft unter: Linux, mit einer installierten Appliance. Root-Rechte: nötig. Fragt: ja, da die Eigentümer dieser Schlüssel neue erstellen müssen; --yes antwortet.

sudo ironflock appliance revoke-direct-access

Der Befehl lehnt mit Exit-Code 3 ab, solange ein Update abgebrochen ist (Wenn ein Update abgebrochen wurde).

ironflock appliance remove

Entfernt die IronFlock-Appliance von dieser Maschine und macht rückgängig, was ihre Installation am Host festgehalten hat. Ihre Daten bleiben, wenn Sie nicht --purge angeben.

ironflock appliance remove [flags]

Läuft unter: Linux. Root-Rechte: nötig. Fragt: ja, nachdem er aufgelistet hat, was geht und was bleibt. Bei der Frage ist „Nein“ vorausgewählt: Enter allein entfernt nichts.

Der Befehl entfernt:

• die systemd-Units der Appliance, ihre Container und ihr Netzwerk in Docker;
• die Anmeldung von Docker an der IronFlock-Registry;
• jede Änderung, die ihre Installation am Host festgehalten hat (/etc/ironflock/appliance.json): die Proxy-Einstellungen, die sie geschrieben hat, ihre Einstellungen in der daemon.json von Docker, die Einstellungen des Journals und die maskierten Sleep-Targets;
• die Kopie des Release davor, die ein Update für seinen Rollback aufbewahrt hat (.update-previous im Installationsverzeichnis).

Die anonymen Volumes der Container der Appliance gehen ebenfalls, mit oder ohne --purge: nie ein benanntes Volume und nie eines, das ein Container noch verwendet.

Was bleibt

Ohne --purge bleiben die Daten der Appliance, sodass eine spätere Installation sie übernimmt:

• das Installationsverzeichnis (/opt/ironflock) mit der .env, die die Secrets enthält, license.env, der Aufzeichnung der Optionen der Installation (install.json) und der Markierung der Datenbankpasswörter, die eine Wiederherstellung nicht setzen konnte (.db-roles-pending);
• die Volumes in Docker.

--purge entfernt auch diese und die Images: Was die Appliance enthielt, ist endgültig weg.

Auch mit --purge bleiben:

• Docker selbst und der Geräte-Agent des Hosts. ironflock agent remove entfernt den Agenten.
• Eine Datei, die die Appliance geschrieben hat und die seitdem geändert wurde, etwa die Proxy-Einstellungen, die ironflock agent configure gesetzt hat, mit den Drop-ins, die sie nennen, damit der Agent seinen Proxy behält.
• Was die Aufzeichnung des Agenten (/opt/ironflock/device-init/installed.json) als die des Agenten nennt, und die Sleep-Targets, die der Agent maskiert hat. ironflock agent remove nimmt sie mit.

Wenn ein Aufruf fehlschlägt

Schlägt ein Aufruf beim Rückgängigmachen weiter fehl (zum Beispiel ein Neustart eines Docker, das von Hand entfernt wurde), bleibt die Aufzeichnung. Der Befehl sagt, welcher Aufruf fehlgeschlagen ist, und endet mit einem Fehler. Führen Sie ihn erneut aus, sobald das funktioniert, oder mit --force, das die Aufzeichnung trotzdem verwirft und über eine Unit, die sich nicht deaktivieren lässt, oder ein Docker, das nicht antwortet, hinweg weitermacht.

Während eine Installation, ein Update oder eine andere Änderung der Appliance läuft, wartet der Befehl bis zu 30 Sekunden und sagt das. Läuft dieser Vorgang weiter, ändert er nichts und endet mit Exit-Code 3.

Beispiele

# Die Appliance entfernen und ihre Daten behalten; der Befehl listet auf, was geht, und fragt
sudo ironflock appliance remove
# Die Appliance mit allen ihren Daten entfernen, ohne Frage
sudo ironflock appliance remove --purge --yes

Die Antwort Nein oder eine Frage ohne Terminal und ohne --yes beendet den Befehl mit Exit-Code 4.

Bevor Sie eine Appliance endgültig entfernen, ziehen Sie ihre Lizenz um oder geben Sie sie frei, solange sie noch online ist (Außerbetriebnahme).