4. Debian-Pakete

Ein Quellpaket baut vier Binärpakete: den Mailserver und drei Abspaltungen davon. Zwei dieser Abspaltungen sind gewöhnliches Paketierungsurteil — eine Stage, die niemand herunterladen können muss, der sie nicht nutzt, ein Collector, der auf die Maschine eines anderen gehört. Die dritte ist eine Sicherheitskontrolle: Sie enthält den einen Mechanismus, mit dem eine HTTP-Anfrage eine privilegierte Änderung auf dem Host bewirken kann, und sonst nichts — sie zu entfernen nimmt also den Mechanismus fort und nicht den Knopf, der ihn erreicht.

Installation behandelt das Installieren und Bootstrappen einer Installation; dieses Kapitel behandelt, was jedes Paket enthält und wie man die Aufteilung nutzt.

4.1. Die Paketmenge

Paket	Arch	Was es enthält
pepsi	any	Der Mailserver: jedes Programm außer den beiden unten abgetrennten, das SQL-Schema, die Vorlagen, die paketierten Konfigurations-Standardwerte, die Handbuchseiten, das Info-Handbuch, der bei der Erstinstallation nach /etc/pepsi/pepsi.conf kopierte Platzhalter (keine Conffile, sodass Upgrades die Konfiguration in Ruhe lassen), das tmpfiles.d-Schnipsel und jede systemd-Unit außer den beiden des Appliers und den beiden des Collectors.
pepsi-httpd-admin	all	pepsi-setup-apply.socket und pepsi-setup-apply.service. Sonst nichts — kein Binärprogramm, keine Konfiguration, überhaupt kein ELF-Objekt.
pepsi-stage-detect-language	any	pepsi-stage-detect-language, das Diagnosewerkzeug pepsi-detect-language (dieselbe ausführbare Datei unter einem zweiten Namen) und beide Handbuchseiten.
pepsi-telemetry	any	pepsi-telemetry, seine systemd-Units (pepsi-telemetry.service und pepsi-telemetry.socket — der Socket ist das, was der mitgelieferte SERVE = systemd-Listener bindet), seine eigene Konfigurationsdatei /etc/pepsi-telemetry/pepsi-telemetry.conf, seine Handbuchseite, nginx- und Apache-Site-Dateien (deaktiviert installiert, unter ihren kanonischen Site-Namen, bereit zur Aktivierung per Symlink) sowie update-feature-stability.sh, das Skript, das einen Collector-Bericht in die Funktionsstabilitätstabelle des Handbuchs verwandelt.

4.1.1. pepsi

Das Basispaket, und auf einem vom Terminal aus verwalteten Host das einzige, das Sie brauchen. Es installiert das Release-Layout, das unter Installieren in Installation beschrieben ist: das Multi-Call-Binärprogramm unter /usr/libexec/pepsi/pepsi mit einem /usr/bin-Symlink je eingefaltetem Programm, und die eigenständigen Programme — die setuid- und setgid-behafteten sowie die getrennt aufgerufenen wie pepsi-setup — als eigene echte ausführbare Dateien. Daneben gehen die SQL-Patchdateien, die pepsi-setup liest, die Liste öffentlicher Hoster, die Nachrichtenvorlagen, die config.d-Standardwerte, die vor pepsi.conf geparst werden, sämtliche Handbuchseiten und das GNU-Info-Handbuch.

Es beansprucht außerdem Debians mail-transport-agent-Schnittstelle — Provides/Conflicts/Replaces: mail-transport-agent —, sodass /usr/sbin/sendmail, mailq und newaliases zu Pepsis werden und kein zweiter MTA daneben installiert werden kann. Es Depends auf postgresql, adduser und acl, und sein postinst legt die Dienstkonten, die absichernden Gruppen, die Laufzeitverzeichnisse, die dpkg-statoverride-Einträge für die privilegierten Binärprogramme und (nach Möglichkeit) die Datenbankrollen an. Siehe Benutzer, Gruppen und Privilegien in Installation dafür, was diese Identitäten sind und warum es jede gibt.

Alles, was es ausliefert, wird deaktiviert installiert. Die Pipeline hochzufahren ist systemctl enable --now pepsi.target, nachdem eine Konfigurationsdatei existiert und pepsi-setup gelaufen ist. Das ist eine Aussage allein über die Installation – siehe Aktualisierungen, Entfernung und Dienstzustand dazu, was ein späteres apt upgrade oder apt remove mit einer schon laufenden Pipeline tut.

Wichtig

pepsi-setup selbst ist in diesem Paket, nicht in pepsi-httpd-admin: Ein Host ohne installiertes administratives Paket muss weiterhin vollständig vom Terminal aus konfigurierbar sein.

4.1.2. pepsi-httpd-admin

Zwei systemd-Unit-Dateien. Das ist die gesamte Nutzlast — weshalb es auch Architecture: all ist und kein ${shlibs:Depends} braucht.

Diese beiden Dateien sind die privilegierte Hälfte der Browser-Konsole, und der Rest dieses Kapitels handelt von ihnen. Die Abhängigkeitsrichtung ist der Punkt: pepsi-httpd-admin Depends auf pepsi (allein ist es nutzlos), während pepsi pepsi-httpd-admin bloß Recommends. Eine Standardinstallation hat es daher — das Setup-Interview der Konsole funktioniert von Haus aus — und apt remove pepsi-httpd-admin gelingt, ohne den Mailserver mitzunehmen. Ein Depends machte den Hebel unziehbar; ein Suggests machte aus jeder Standardinstallation eine, deren Konsole stillschweigend nichts anwenden kann.

Die Units werden wie alle anderen deaktiviert ausgeliefert, und das postinst des Pakets gibt das zur Installationszeit aus, statt einen Operator aus einem Paketnamen erschließen zu lassen, was gerade möglich geworden ist. Es leert außerdem die Warteschlange der Einrichtungsaufgaben, während es sie installiert — siehe Das Installieren leert zuerst die Warteschlange dafür, warum Ankommen nicht bedeuten darf, alles auszuführen, was in der Abwesenheit angefordert wurde.

4.1.3. pepsi-stage-detect-language

Die Spracherkennungs-Stage, abgetrennt, weil sie umfangreiche statistische Spracherkennungsmodelle einbettet und die meisten Pipelines sie nie laden. pepsi Suggests sie; die Stage Enhances pepsi und Depends auf genau dieselbe Binärversion. Die Validierung trägt eine Prüfung, die genau für diese Aufteilung geschrieben wurde: Wenn die konfigurierte Pipeline die Stage nutzt und das Binärprogramm nicht auf $PATH liegt, warnt pepsi-setup und nennt die apt install-Zeile — sodass das Fehlen vor dem Start diagnostiziert und nicht dann entdeckt wird, wenn der Dispatcher keinen Worker starten kann.

Das Paket trägt außerdem pepsi-detect-language, das Offline-Diagnose- und Tuning-Werkzeug — einen $PATH-Symlink auf genau dieselbe ausführbare Datei, die eine aus einer Datei gelesene Nachricht klassifiziert und nur ausgibt, was die Stage festgehalten hätte. Es ist hier statt in pepsi, weil es dieses Binärprogramm ist: Es teilt sich den gesamten Klassifikationspfad und die Sprachmodelle, sodass es getrennt auszuliefern genau den Umfang verdoppelte, den diese Aufteilung vermeiden soll. Siehe pepsi-stage-detect-language und pepsi-detect-language.

4.1.4. pepsi-telemetry

Der zentrale Collector für Pepsis anonyme Funktionstelemetrie auf Opt-in-Basis — ein kleiner HTTP-Server, gedacht für den Betrieb auf einem Host hinter einem bestehenden nginx oder Apache, weshalb das Paket auch für jeden von beiden eine vollständige Site-Datei ausliefert — installiert unter ihrem kanonischen Namen in sites-available/, deaktiviert und bereits auf den Socket zeigend, den die mitgelieferten Units binden, sodass zum Aktivieren nur noch der Symlink fehlt (a2ensite oder ln -s nach sites-enabled/) — und einen Front-Server sowie certbot Recommends. Beide sind conffiles: Ändern Sie den server_name für einen privaten Collector, und die Änderung übersteht Upgrades. Gewöhnliche Pepsi-Knoten brauchen ihn nie; was sie betreiben, ist der Telemetrie-Client, der Teil des pepsi-Pakets ist und von [pepsi] SHARE_TELEMETRY gesteuert wird. Dieser Schalter ist Opt-in und standardmäßig no: Bis ein Operator ihn auf yes setzt, bleibt der Daemon (falls überhaupt gestartet) ruhend — kein Socket, nichts wird übermittelt —, und die In-Process-Aufrufe sind No-Ops, sodass die Unit des Clients im Hauptpaket eine Installation nichts kostet, worum sie nicht gebeten hat. Beachten Sie, dass das Collector-Paket dennoch Depends auf pepsi in derselben Binärversion: „läuft auf einem eigenen Host“ ist eine Aussage darüber, wo Sie es installieren, nicht darüber, dass es eigenständig wäre. Siehe pepsi-telemetry.

4.2. Aktualisierungen, Entfernung und Dienstzustand

Alles wird deaktiviert ausgeliefert, und dieses Versprechen gilt der Installation. Eine Aktualisierung darf nicht ändern, was läuft: eine Installation, deren Pipeline oben war, bleibt oben, eine, deren Pipeline unten war, bleibt unten, und keine der beiden Antworten wird irgendwo festgehalten – sie wird vom laufenden System abgelesen, Unit für Unit, durch systemctl try-restart, das eine aktive Unit neu startet und mit einer inaktiven nichts tut. Ein socket-aktivierter Dienst, der untätig wartet, bleibt untätig, und eine erste Installation startet weiterhin nichts, weil der Neustart daran hängt, dass dpkg eine zuvor konfigurierte Version übergeben hat.

Bemerkung

Dieses Verhalten ruht auf einem dh_installsystemd-Flag mit einer Falle darin. --restart-after-upgrade ist die Voreinstellung des Werkzeugs – aber nur, solange --no-start fehlt, und Pepsi übergibt --no-start gerade deshalb, weil eine frische Installation nichts starten darf, was die Voreinstellung stillschweigend aufhebt. Ohne beide Flags stoppt eine Aktualisierung jede Unit vor dem Entpacken und hat nichts, das eine davon wieder startet, und lädt systemd nicht einmal neu. make check scheitert, wenn ein Aufruf das Flag je verliert.

Die Entfernung ist die andere Hälfte. apt remove stoppt die Units, und das prerm jedes Pakets ist das, was es tut: dasselbe --no-start unterdrückt auch das Stop-bei-Entfernung-Bruchstück von debhelper, und ohne Ersatz würde eine Entfernung pepsi-dispatch gegen gelöschte Binärdateien weiterlaufen lassen und pepsi-setup-apply.socket lauschen lassen, nachdem das Paket verschwunden ist, dessen Abwesenheit die Sicherheitsgrenze sein soll. Das prerm hält außerdem fest, welche seiner Units liefen.

Dieser Vermerk ist das, was Entfernen und dann Neuinstallieren zurückbringt. Neuinstallieren stellt von sich aus nichts wieder her: die Aktivierung übersteht eine Entfernung unangetastet (die Symlinks in /etc/systemd/system/*.wants gehören keinem Paket, und nur purge räumt sie ab), ohne den Vermerk bleibt ein Betreiber also mit einer Pipeline zurück, die aktiviert ist, beim nächsten Systemstart hochkommt und bis dahin ohne sichtbaren Grund unten ist. Die Markierung liegt unter /var/lib/pepsi/<package>.was-active, bewusst nicht unter /tmp: die Zeitspanne zwischen Entfernung und Neuinstallation kann einen Systemstart, einen Stromausfall oder vierzehn Tage enthalten. Sie wird unter einem temporären Namen im selben Verzeichnis geschrieben und an ihren Platz umbenannt, eine Unterbrechung hinterlässt also eine ganze Markierung oder keine. purge löscht sie.

Die Aktivierung selbst wird nie festgehalten und nie wiederhergestellt. Es gibt nichts zu erinnern – dpkg rührt diese Symlinks nicht an – und ein Mechanismus, der ein Target deaktivierte, um es später wieder zu aktivieren, würde genau das Fenster erzeugen, das er zu schließen scheint: eine mitten darin unterbrochene Aktualisierung würde die Installation deaktiviert hinterlassen, mit ihrer einzigen Spur in einer Datei.

4.3. Die Aufteilung als Härtungshebel

4.3.1. Warum es überhaupt eine entfernbare Hälfte gibt

Das Setup ist privilegierte Arbeit: /etc/pepsi/pepsi.conf schreiben, jedes secrets.d-Fragment dem einzigen Konto übergeben, das es liest, certbot ausführen, Datenbankrollen anlegen, Schlüsselmaterial erzeugen. pepsi-httpd, das die Browser-Konsole bedient, tut nichts davon. Es wechselt auf das Konto pepsi-httpd, bevor es eine Verbindung annimmt, und darf nie zurückerlangen können, was es abgegeben hat.

Es handelt also nicht. Es hält einen Absichtsdatensatz in pepsi.setup_task fest, der beschreibt, was wahr sein soll, und verbindet sich dann mit einem UNIX-Socket und schließt ihn. Diese Verbindung ist die gesamte Botschaft: Nichts wird hineingeschrieben und nie etwas daraus gelesen, sodass sie kein Befehlskanal werden kann. Was sie bewirkt, ist, dass systemds Socket-Aktivierung pepsi-setup apply als root startet, das seine Arbeit aus der Datenbank nimmt — wo jeder Datensatz gegen eine geschlossene Aufgabenliste geprüft und protokolliert wird — und wieder endet, wenn es keine gibt. Root wird über eine Datenbanktabelle erreicht, nie über einen Socket, der ein Protokoll spricht. Das vollständige Vertrauensmodell, einschließlich der Dinge, die der Applier bewusst nicht kann, ist Das Vertrauensmodell des Appliers in pepsi-setup, und es ist Pflichtlektüre, bevor irgendetwas davon aktiviert wird.

Diese Form macht die Fähigkeit abtrennbar. Die Türklingel-Socket-Unit und die Applier-Service-Unit sind der gesamte Mechanismus, sie sind zwei Dateien, und es sind die zwei Dateien, die pepsi-httpd-admin enthält.

4.3.2. Was das Entfernen tatsächlich entfernt

apt remove pepsi-httpd-admin stoppt beide Units und löscht ihre Dateien. Von diesem Moment an leert nichts pepsi.setup_task von selbst. Ein INSERT in diese Tabelle ist inaktiv: Er liegt dort, und nichts wird darauf reagieren, sofern nicht ein Mensch mit einer root-Shell es beschließt (pepsi-setup apply --once funktioniert weiterhin — das Paket trägt die Units, nicht das Programm).

Die Schleife wird am Mechanismus gebrochen, nicht an der Benutzeroberfläche. Es spielt keine Rolle, was danach mit der Web-Schicht geschieht — ein feindlicher Administrator mit gültiger Sitzung, ein gestohlenes Bearer-Token, ein Remote-Code-Execution-Fehler in pepsi-httpd selbst —, denn keines davon verleiht die Fähigkeit, einen root-Prozess zu starten. Die Web-Schicht hatte diese Fähigkeit nie; sie hatte immer nur eine Türklingel, und die Türklingel ist fort.

Zwei Dinge werden ausdrücklich nicht entfernt, und sie mit dem Applier zu verwechseln ist hier der naheliegendste Fehler:

• Konfigurations-Überschreibungen funktionieren weiterhin. /api/v1/config und die Konfigurationsseiten der Konsole schreiben pepsi.config_override, die Datenbank-Überlagerung, die jede Komponente zur Laufzeit liest — keine Datei in /etc. Sie behalten ihre eigene Schranke, [pepsi-admin] CONFIG_DB, und sind unberührt. Der Applier hat mit ihnen nichts zu tun, und die Nur-lesen-Regel darauf auszuweiten entfernte eine Fähigkeit, um die es bei dieser Aufteilung nie ging. Siehe Konfiguration in der Datenbank in Konfiguration.

• Am Mailfluss ändert sich nichts. pepsi-ingress, pepsi-dispatch, jede Stage und die MTA-STS- und Metriken-Oberflächen von pepsi-httpd bleiben unangetastet. Dies ist kein Build des Mailservers mit reduziertem Funktionsumfang.

4.3.3. Wie pepsi-httpd es bemerkt

Eine Konsole, die auf einem Host ohne Applier Formulare anbietet, ist das schlechteste Ergebnis der Aufteilung: Ein Operator füllt ein Interview aus, drückt „anwenden“, sieht einen pending-Datensatz und wartet auf eine Änderung, die nie kommen wird. Der Server fragt daher vor jeder Änderung, ob von hier aus überhaupt eine privilegierte Änderung geschehen kann.

Er hat bereits Privilegien abgegeben, kann also dpkg nicht fragen und nicht mit systemds privatem Bus sprechen — und darf keinen Weg dazu bekommen. Was er kann, ist zwei Dateien betrachten, die zusammen installiert und scharfgestellt beantworten:

1. pepsi-setup-apply.socket existiert als Unit-Datei in einem der Verzeichnisse, die systemd durchsucht (/etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, /usr/lib/systemd/system, /lib/systemd/system); und

2. [pepsi-admin] APPLY_SOCKET existiert, ist ein Socket und ist für dieses Konto beschreibbar — sich mit einem UNIX-Socket zu verbinden braucht Schreibrecht, und eine Türklingel, die nicht betätigt werden kann, ist keine Fähigkeit.

Zwei stats und ein access, ohne benötigtes Privileg. Die Probe verbindet sich bewusst nicht: Sich zu verbinden ist das Betätigen der Türklingel und startete bei jedem Seitenaufbau einen root-Prozess.

Keine der beiden Prüfungen ist überflüssig, und keine sollte später wegoptimiert werden:

• Ohne die Unit-Datei-Prüfung liest sich ein veralteter Socket-Knoten als lebendige Türklingel. Veraltete Knoten sind in der Praxis erreichbar: systemds RemoveOnStop= ist standardmäßig aus (die ausgelieferte Unit setzt es; eine von Hand bearbeitete vielleicht nicht), und ein Paket, dessen Dateien gelöscht statt gestoppt werden, lässt den Knoten schlicht zurück. Das ist genau das Szenario, für das es diese Funktion gibt, und es falsch zu behandeln würde offen scheitern.

• Ohne die Socket-Prüfung läse sich ein frisch installiertes Paket, dessen Socket nie aktiviert wurde, als bereit, und jede Aufgabe bliebe für immer pending.

Die Prüfung scheitert geschlossen. Ein Pfad, der nicht untersucht werden kann, ein Pfad, der kein Socket ist, ein Rechtefehler, ein nicht lesbares Elternverzeichnis — jede Unsicherheit liest sich als „kein Applier“, und die Konsole wird nur lesend. Der so entstehende Fehlschlag ist, dass einem Operator gesagt wird, er solle etwas installieren, das bereits installiert ist; der Fehlschlag in der anderen Richtung ist, dass ein Operator glaubt, eine Änderung sei vorgenommen worden. Nur der erste ist durch das Lesen der Meldung behebbar, und die Meldungen sind zum Lesen geschrieben: Sie unterscheiden nicht installiert von installiert, aber nicht gestartet von hier liegt ein veralteter Knoten, und jede nennt ihre eigene Abhilfe.

4.3.4. Wie „nur lesend“ aussieht

Alles wird weiterhin gerendert. Jede Einstellung, nach der das Setup-Interview fragt, wird gezeigt, mit ihrer vorbereiteten Antwort oder ihrem Standardwert; jedes Bedienelement, das eine ändern würde, ist deaktiviert, unter einem Banner, das das fehlende Paket benennt. Die Seiten zu verbergen wäre die einfache Lesart von „nur lesend“ und die falsche — ein Operator, der den Applier bewusst entfernt hat, muss weiterhin sehen können, wozu die Installation konfiguriert ist.

Die API weist die entsprechenden Änderungen mit einem eigenen Status und Code zurück statt mit einem generischen Fehlschlag:

HTTP/1.1 503 Service Unavailable
{"code":   "setup_applier_unavailable",
 "hint":   "the administrative package 'pepsi-httpd-admin' is not installed …",
 "detail": {"package": "pepsi-httpd-admin", "unit": "pepsi-setup-apply.socket"}}

Es gilt für POST /api/v1/setup/tasks, /setup/preflight, /setup/dns-check, /setup/certificates, PUT /api/v1/setup/answers und die Selbstbedienungs-Schlüsselanfragen POST /api/v1/identities, /api/v1/identities/client und ein widerrufendes PATCH /api/v1/identities/{id} sowie für die eigenen Formular-Posts der Konsole — POST /ui/setup/{step}, /ui/setup/tasks, /ui/domains/check, /ui/identities/request/{generate,register} und /ui/identities/{id}/revoke. Sie alle erreichen die Warteschlange über eine Einreihungsfunktion, die zuerst nachfragt, sodass die Ablehnung eine einzige Entscheidung ist statt einer je Oberfläche, und das deaktivierte Bedienelement auf der Seite sitzt über dieser Prüfung statt an ihrer Stelle. Das Vorbereiten von Antworten ist mit Absicht eingeschlossen: Der einzige Zweck einer Entwurfsantwort ist, angewandt zu werden, und ein Assistent, der sechs Schritte davon auf einem Host anhäuft, auf dem nichts sie anwenden kann, ist genau die stillschweigende Wirkungslosigkeit, die der Entwurf vermeidet. DELETE /api/v1/setup/answers ist nicht gesperrt — Entwürfe zu verwerfen kann keine privilegierte Änderung bewirken, und eine nur lesende Konsole muss ein halbfertiges Interview weiterhin leeren können.

Der Code unterscheidet sich von setup_write_unavailable (was bedeutet, dass es keine CONFIG_DB-Verbindung gibt), weil die beiden verschiedene Abhilfen haben, und der Applier wird zuerst gemeldet, wenn beides zutrifft: Eine Datenbankrolle zu konfigurieren hätte nicht geholfen.

4.3.5. Was mit entferntem Paket weiterhin funktioniert

Alles, von einem Terminal aus. pepsi-setup liegt im pepsi-Paket, sodass:

pepsi-setup -c /etc/pepsi/pepsi.conf run
pepsi-setup -c /etc/pepsi/pepsi.conf --wizard
pepsi-setup -c /etc/pepsi/pepsi.conf check

sich genau so verhalten wie mit installiertem Paket, ebenso wie pepsi.conf von Hand zu bearbeiten, Schlüssel zu erzeugen, certbot selbst auszuführen und jede andere administrative Aufgabe. Der Applier-Unterbefehl ist ebenfalls noch da: Was das Paket trägt, sind die Units, nicht das Programm.

Entfernt wird nur eines: die Fähigkeit der Web-Schicht, ihn zu starten.

4.3.6. Es scharfzustellen ist ein eigener, bewusster Schritt

pepsi-httpd-admin zu installieren macht die Fähigkeit verfügbar. Es schaltet sie nicht ein. Wie jede andere Pepsi-Unit werden die beiden deaktiviert ausgeliefert, sodass ein Host, der das Paket hat, aber nie

# systemctl enable --now pepsi-setup-apply.socket

ausgeführt hat, keine Türklingel besitzt, und die Konsole bleibt nur lesend und sagt, welcher Befehl das ändern würde. Ein Paket zu installieren und ein Privileg scharfzustellen bleiben zwei getrennte Entscheidungen.

4.3.7. Das Installieren leert zuerst die Warteschlange

Den Applier zu entfernen bricht die Schleife am Mechanismus, und Datensätze können pepsi.setup_task weiterhin erreichen, solange er fort ist: Ein Operator mit einer root-Shell kann einen von Hand einreihen, und eine Konsole, der nur gesagt wird, dass sie nur lesend ist, ist ein Release von einem Pfad entfernt, der zu fragen vergisst. Nichts lässt einen solchen Datensatz verfallen. Eine Anfrage ist dauerhaft, und die Warteschlange wird in der Reihenfolge geleert, in der sie geschrieben wurde.

Zusammengenommen würde ein Applier, der Monate später auftaucht, jeden einzelnen davon beim ersten Betätigen der Türklingel ausführen, gegen eine Installation, die weitergezogen ist — eine Konfiguration, geschrieben aus einer Antwortmenge, an die sich niemand erinnert, ein Zertifikat, beschafft für einen Host, der umbenannt wurde.

Daher löscht das Installieren von pepsi-httpd-admin die Warteschlange, bevor seine Units scharfgestellt werden. Das postinst führt

# pepsi-setup -c /etc/pepsi/pepsi.conf apply --clear

aus, was jeden Datensatz entfernt, ohne einen davon auszuführen, und das unter Nennung des Grundes sagt, sodass ein Operator, der etwas legitim eingereiht hatte, weiß, was daraus geworden ist, und erneut fragen kann. Was angefordert wurde, geht so oder so nicht verloren: Jede Anfrage, Ablehnung, jeder Erfolg und Fehlschlag ist ein eigener dauerhafter Eintrag im Prüfprotokoll, das das Zurücksetzen nicht anfasst. Derselbe Befehl steht jederzeit von Hand zur Verfügung — siehe pepsi-setup.

Es geschieht nach Möglichkeit, wie ein Maintainer-Skript es muss. Zur Installationszeit gibt es womöglich keine Konfigurationsdatei, kein Schema, keine Datenbank und kein laufendes PostgreSQL; jedes davon wird gemeldet und übersprungen, nie eine fehlgeschlagene Installation. (Eine Datenbank ohne Pepsi-Schema ist nicht einmal ein Überspringen: Sie hat nie eine Aufgabe gehalten, also ist sie eine leere Warteschlange.) Das Zurücksetzen läuft bei jedem configure, nicht nur bei einer Erstinstallation, denn dpkg meldet eine Neuinstallation nach apt remove als Upgrade — und entfernen-dann-neu-installieren ist genau der Fall, für den es das gibt.

4.3.8. Derselbe Hebel aus dem Quelltext

Eine make install-Installation bekommt die identische Kontrolle:

make install INSTALL_ADMIN_UNITS=no

was alles außer pepsi-setup-apply.service und pepsi-setup-apply.socket installiert und ausgibt, was es weggelassen hat. make uninstall entfernt stets beide Mengen, unabhängig vom Wert der Variablen bei diesem Aufruf: Eine privilegierte Unit, die eine Deinstallation überlebt, weil eine make-Variable sich geändert hat, ist genau der Fehlschlag, um den es bei dieser Aufteilung geht.

4.3.9. Eine Haltung wählen

Die Probe, die Konfigurationsoption und die Paketmenge setzen sich zusammen, sodass die Frage „kann diese Konsole diese Maschine ändern?“ mehr als zwei Antworten hat. [pepsi-admin] APPLIER ist die Überschreibung, vollständig dokumentiert in pepsi.conf(5):

Haltung	Wie	Ergebnis
Vom Browser aus verwaltet	Paket installiert, Socket aktiviert, APPLIER = auto (der Standardwert)	Die Konsole kann Einrichtungsaufgaben anwenden.
Installiert, aber nicht scharfgestellt	Paket installiert, Socket nie aktiviert	Nur lesend; die Ablehnung nennt systemctl enable --now pepsi-setup-apply.socket.
Vom Terminal aus verwaltet	apt remove pepsi-httpd-admin (oder INSTALL_ADMIN_UNITS=no)	Nur lesend; die Ablehnung nennt das Paket, und nichts leert die Aufgabenwarteschlange unbeaufsichtigt.
Nur lesend per Richtlinie	[pepsi-admin] APPLIER = no, Paket installiert gelassen	Nur lesend durch Konfiguration statt durch die installierten Pakete, und die Ablehnung sagt das. Umkehrbar durch das Bearbeiten einer Option — eine Richtlinie, keine Grenze.
Anders angewandt	pepsi-setup apply --once aus cron oder eine handgeschriebene Unit, plus [pepsi-admin] APPLIER = yes	Die Konsole bietet die Formulare an. yes ist ein Versprechen, das der Operator gibt; nichts prüft es.

Bei zwei dieser Zeilen lohnt es, den Unterschied auszubuchstabieren. APPLIER = no und das Entfernen des Pakets erzeugen beide eine nur lesende Konsole, und sie sind nicht dieselbe Verteidigung. APPLIER = no ist eine Zeile in einer Konfigurationsdatei, die pepsi-httpd heranzieht; jeder, der diese Datei ändern kann oder pepsi-httpd dazu bringen kann, eine andere zu lesen, macht es rückgängig. Das Paket zu entfernen löscht die Units, die den root-Prozess ausgeführt hätten, und kein Maß an Einfluss auf pepsi-httpd bringt sie zurück. Verwenden Sie die Option, um eine Absicht zu erklären; entfernen Sie das Paket, um sie durchzusetzen.

Die letzte Zeile ist ein Versprechen, keine Prüfung: Mit APPLIER = yes reiht die Konsole bereitwillig Aufgaben ein, ob sie etwas leert oder nicht. Sie existiert für die Installationen, die die Probe wirklich nicht sehen kann — ein cron-Leerer, ein Host ohne systemd, Unit-Dateien, die irgendwo installiert sind, wo systemd nicht sucht —, und sie ist die eine Stelle in diesem Mechanismus, an der der Code einem Operator aufs Wort glaubt.

Es gibt einen von Hand hergestellten Zustand, den die Paketierung nicht erzeugen kann: der Socket vorhanden und beschreibbar, während die Service-Unit maskiert oder kaputt ist. Die Probe liest das als verfügbar, die Aufgabe wird eingereiht und bleibt pending. Die Aufgabenseite zeigt diesen Status, statt etwas anderes vorzugeben. Beide Units werden in einem Paket ausgeliefert, sodass es bewusster Anstrengung bedarf, diesen Zustand zu erreichen.

4.4. Siehe auch

Installation – die Installation auf beiden Wegen sowie die Konten, Gruppen und privilegierten Bits, die das postinst des Pakets pepsi anlegt. Aktualisierungen, Entfernung und Dienstzustand – was Aktualisieren, Entfernen und Neuinstallieren mit den laufenden Diensten tut. Sicherheitsmodell – das Bedrohungsmodell, in dem diese Aufteilung eine Abmilderung ist, insbesondere was ein Angreifer, der pepsi-httpd übernimmt, erhält und was nicht. Die Verwaltungskonsole und Die administrative API – die Konsolen- und API-Oberflächen, die nur lesend werden. pepsi-setup – das Vertrauensmodell des Appliers, seine geschlossene Aufgabenliste und seine Zulassungsprüfungen. pepsi-httpd – die Erkennung, die freigeschalteten Endpunkte und [pepsi-admin] in Referenzform.