4. Paquets Debian

Un paquet source construit quatre paquets binaires : le serveur de courrier et trois scissions issues de lui. Deux de ces scissions relèvent du jugement d’empaquetage ordinaire — une étape que personne ne devrait avoir à télécharger sans l’utiliser, un collecteur qui a sa place sur la machine de quelqu’un d’autre. La troisième est un contrôle de sécurité : elle contient l’unique mécanisme par lequel une requête HTTP peut provoquer un changement privilégié sur l’hôte, et rien d’autre, de sorte que la retirer enlève le mécanisme plutôt que le bouton qui l’atteint.

Installation traite de l’installation et de l’amorçage d’un déploiement ; ce chapitre porte sur ce que contient chaque paquet et sur la manière de se servir de la scission.

4.1. L’ensemble des paquets

Paquet	Arch	Ce qu’il contient
pepsi	any	Le serveur de courrier : chaque programme sauf les deux séparés ci-dessous, le schéma SQL, les modèles, les valeurs de configuration par défaut livrées, les pages de manuel, le manuel info, la configuration provisoire copiée dans /etc/pepsi/pepsi.conf lors de la première installation (pas un conffile, de sorte que les mises à niveau laissent la configuration intacte), le fragment tmpfiles.d, et chaque unité systemd sauf les deux de l’applicateur et les deux du collecteur.
pepsi-httpd-admin	all	pepsi-setup-apply.socket et pepsi-setup-apply.service. Rien d’autre — aucun binaire, aucune configuration, aucun objet ELF du tout.
pepsi-stage-detect-language	any	pepsi-stage-detect-language, l’outil de diagnostic pepsi-detect-language (le même exécutable sous un second nom), et les deux pages de manuel.
pepsi-telemetry	any	pepsi-telemetry, ses unités systemd (pepsi-telemetry.service et pepsi-telemetry.socket — la socket est ce que lie le listener SERVE = systemd livré), son propre fichier de configuration /etc/pepsi-telemetry/pepsi-telemetry.conf, sa page de manuel, des fichiers de site nginx et Apache (installés désactivés, sous leurs noms de site canoniques, prêts à être activés par un lien symbolique), et update-feature-stability.sh, le script qui transforme un rapport de collecteur en la table de stabilité des fonctionnalités du manuel.

4.1.1. pepsi

Le paquet de base, et le seul dont vous ayez besoin sur un hôte administré depuis un terminal. Il installe la disposition de release décrite sous Installation dans Installation : le binaire multi-appel à /usr/libexec/pepsi/pepsi avec un lien symbolique /usr/bin par programme plié, et les programmes autonomes — ceux à bit setuid et setgid, plus ceux qu’on invoque séparément comme pepsi-setup — comme de véritables exécutables à part. À côté d’eux vont les fichiers de patch SQL que lit pepsi-setup, la liste des hébergeurs publics, les modèles de messages, les valeurs par défaut de config.d qui sont analysées avant pepsi.conf, toutes les pages de manuel, et le manuel GNU info.

Il revendique aussi l’interface mail-transport-agent de Debian — Provides/Conflicts/Replaces: mail-transport-agent — de sorte que /usr/sbin/sendmail, mailq et newaliases deviennent ceux de Pepsi et qu’aucun second MTA ne puisse être installé à ses côtés. Il Depends de postgresql, adduser et acl, et son postinst crée les comptes de service, les groupes qui font barrière, les répertoires d’exécution, les entrées dpkg-statoverride des binaires privilégiés et (au mieux) les rôles de base de données. Voir Utilisateurs, groupes et privilèges dans Installation pour ce que sont ces identités et pourquoi chacune existe.

Tout ce qu’il livre est installé désactivé. Démarrer le pipeline se fait par systemctl enable --now pepsi.target, une fois qu’un fichier de configuration existe et que pepsi-setup a tourné. C’est un énoncé qui ne porte que sur l’installation – voir Mises à jour, retrait et état des services pour ce qu’un apt upgrade ou un apt remove ultérieur fait à un pipeline déjà en marche.

Important

pepsi-setup lui-même est dans ce paquet, non dans pepsi-httpd-admin : un hôte sans paquet d’administration installé doit rester entièrement configurable depuis un terminal.

4.1.2. pepsi-httpd-admin

Deux fichiers d’unité systemd. C’est toute la charge utile — raison pour laquelle il est aussi en Architecture: all et n’a besoin d’aucun ${shlibs:Depends}.

Ces deux fichiers sont la moitié privilégiée de la console de navigateur, et le reste de ce chapitre porte sur eux. Le sens de la dépendance compte : pepsi-httpd-admin Depends de pepsi (il est inutile seul), tandis que pepsi ne fait que Recommends pepsi-httpd-admin. Une installation par défaut l’a donc — le questionnaire de configuration de la console fonctionne d’emblée — et apt remove pepsi-httpd-admin réussit sans emporter le serveur de courrier. Un Depends rendrait le levier impossible à tirer ; un Suggests ferait de chaque installation par défaut une installation dont la console ne peut silencieusement rien appliquer.

Les unités sont livrées désactivées comme toutes les autres, et le postinst du paquet le dit au moment de l’installation plutôt que de laisser un opérateur déduire d’un nom de paquet ce qui vient de devenir possible. Il vide aussi la file des tâches de configuration en les installant — voir L’installer vide d’abord la file pour comprendre pourquoi arriver ne doit pas signifier exécuter tout ce qui a été demandé pendant l’absence.

4.1.3. pepsi-stage-detect-language

L’étape de détection de langue, séparée parce qu’elle embarque des modèles statistiques de reconnaissance de langue volumineux et que la plupart des pipelines ne la chargent jamais. pepsi la Suggests ; l’étape Enhances pepsi et Depends exactement de la même version binaire. La validation porte une vérification écrite précisément pour cette scission : lorsque le pipeline configuré emploie l’étape et que le binaire n’est pas sur $PATH, pepsi-setup avertit et nomme la ligne apt install — de sorte que l’omission soit diagnostiquée avant le démarrage plutôt que découverte lorsque le dispatcher échoue à lancer un worker.

Le paquet porte aussi pepsi-detect-language, l’outil hors-ligne de diagnostic et d’ajustement — un lien symbolique de $PATH vers exactement le même exécutable, qui classifie un message lu depuis un fichier et n’imprime que ce que l’étape aurait noté. Il est ici plutôt que dans pepsi parce qu’il est ce binaire : il partage tout le chemin de classification et les modèles de langue, si bien que le livrer séparément dupliquerait exactement le volume que cette scission existe pour éviter. Voir pepsi-stage-detect-language et pepsi-detect-language.

4.1.4. pepsi-telemetry

Le collecteur central de la télémétrie de fonctionnalités anonyme et sur consentement explicite de Pepsi — un petit serveur HTTP destiné à tourner sur un hôte derrière un nginx ou un Apache existant, raison pour laquelle le paquet livre aussi un fichier de site complet pour chacun — installé sous son nom canonique dans sites-available/, désactivé, et pointant déjà vers la socket que lient les unités livrées, si bien qu’en activer un se réduit au lien symbolique (a2ensite, ou ln -s dans sites-enabled/) — et Recommends un serveur frontal et certbot. Les deux sont des conffiles : modifiez le server_name pour un collecteur privé et la modification survit aux mises à niveau. Les nœuds Pepsi ordinaires n’en ont jamais besoin ; ce qu”ils exécutent est le client de télémétrie, qui fait partie du paquet pepsi et est régi par [pepsi] SHARE_TELEMETRY. Cet interrupteur fonctionne sur consentement explicite et vaut no par défaut : tant qu’un opérateur ne le règle pas sur yes, le démon (s’il est démarré) reste dormant — aucune socket, rien de soumis — et les appels en-processus sont sans effet, de sorte que la présence de l’unité du client dans le paquet principal ne coûte à un déploiement rien qu’il n’ait demandé. Notez que le paquet du collecteur Depends tout de même de pepsi à la même version binaire : « tourne sur son propre hôte » est une affirmation sur l’endroit où vous le déployez, non sur son autonomie. Voir pepsi-telemetry.

4.2. Mises à jour, retrait et état des services

Tout est livré désactivé, et cette promesse porte sur l”installation. Une mise à jour ne doit pas changer ce qui tourne : un déploiement dont le pipeline était en marche le reste, un déploiement dont il était arrêté le reste, et aucune de ces deux réponses n’est consignée où que ce soit – elle est lue sur le système en marche, une unité à la fois, par systemctl try-restart, qui redémarre une unité active et ne fait rien à une unité inactive. Un service activé par socket qui attend sans rien faire continue d’attendre, et une première installation ne démarre toujours rien, parce que le redémarrage est conditionné au fait que dpkg ait transmis une version précédemment configurée.

Note

Ce comportement repose sur un drapeau de dh_installsystemd qui comporte un piège. --restart-after-upgrade est le défaut de l’outil – mais seulement tant que --no-start est absent, et Pepsi passe --no-start précisément parce qu’une installation neuve ne doit rien démarrer, ce qui annule le défaut en silence. Sans les deux drapeaux, une mise à jour arrête chaque unité avant le dépaquetage et n’a rien qui en redémarre une, et ne recharge même pas systemd. make check échoue si un appel perd un jour le drapeau.

Le retrait est l’autre moitié. apt remove arrête les unités, et c’est le prerm de chaque paquet qui le fait : le même --no-start supprime aussi le fragment d’arrêt-au-retrait de debhelper, et sans remplacement un retrait laisserait pepsi-dispatch tourner contre des binaires supprimés, et laisserait pepsi-setup-apply.socket à l’écoute après la disparition du paquet dont l’absence est censée être la frontière de sécurité. Le prerm consigne également lesquelles de ses unités tournaient.

Cette trace est ce qui fait revenir un retrait suivi d’une réinstallation. Réinstaller ne restaure rien par soi-même : l’activation survit intacte à un retrait (les liens de /etc/systemd/system/*.wants n’appartiennent à aucun paquet et seul purge les efface), sans la trace un exploitant se retrouve donc avec un pipeline activé, qui remontera au prochain démarrage et qui d’ici là est arrêté sans raison visible. Le marqueur réside dans /var/lib/pepsi/<package>.was-active, délibérément pas sous /tmp : l’intervalle entre le retrait et la réinstallation peut contenir un redémarrage, une coupure de courant ou une quinzaine. Il est écrit sous un nom temporaire dans le même répertoire puis renommé à sa place, si bien qu’une interruption laisse un marqueur entier ou aucun. purge le supprime.

L’activation elle-même n’est jamais consignée ni rejouée. Il n’y a rien à retenir – dpkg ne touche pas à ces liens – et un mécanisme qui désactiverait une cible pour la réactiver ensuite créerait exactement la fenêtre qu’il semble fermer : une mise à jour interrompue en son milieu laisserait le déploiement désactivé, avec pour seule trace un fichier.

4.3. La scission comme levier de durcissement

4.3.1. Pourquoi il existe une moitié retirable

La configuration est un travail privilégié : écrire /etc/pepsi/pepsi.conf, remettre chaque fragment secrets.d à l’unique compte qui le lit, exécuter certbot, créer des rôles de base, générer du matériel de clé. pepsi-httpd, qui sert la console de navigateur, ne fait rien de tout cela. Il descend vers le compte pepsi-httpd avant d’accepter une connexion et ne doit jamais pouvoir regagner ce qu’il a abandonné.

Il n’agit donc pas. Il note une ligne d’intention dans pepsi.setup_task décrivant ce qui devrait être vrai, puis se connecte à une socket UNIX et la ferme. Cette connexion est tout le message : rien n’y est écrit et rien n’en est jamais lu, elle ne peut donc pas devenir un canal de commandes. Ce qu’elle fait, c’est laisser l’activation par socket de systemd démarrer pepsi-setup apply en tant que root, qui prend son travail dans la base — où chaque ligne est validée contre une liste fermée de tâches et audité — et ressort quand il n’y en a plus. On atteint root par une table de base de données, jamais par une socket parlant un protocole. Le modèle de confiance complet, y compris ce que l’applicateur ne peut délibérément pas faire, est Le modèle de confiance de l’applicateur dans pepsi-setup, et c’est une lecture obligatoire avant d’activer quoi que ce soit de tout cela.

Cette forme est ce qui rend la capacité séparable. L’unité socket de sonnette et l’unité de service de l’applicateur sont tout le mécanisme, ce sont deux fichiers, et ce sont les deux fichiers que contient pepsi-httpd-admin.

4.3.2. Ce que le retrait retire réellement

apt remove pepsi-httpd-admin arrête les deux unités et supprime leurs fichiers. Dès cet instant, rien ne vide pepsi.setup_task de lui-même. Un INSERT dans cette table est inerte : il reste là, et rien n’agira dessus à moins qu’un humain disposant d’un shell root ne le décide (pepsi-setup apply --once fonctionne toujours — le paquet porte les unités, non le programme).

La boucle est rompue au mécanisme, non à l’interface utilisateur. Peu importe ce qu’il advient ensuite de la couche web — un administrateur hostile disposant d’une session valide, un jeton porteur volé, un bogue d’exécution de code à distance dans pepsi-httpd lui-même — car aucun de ces cas ne confère la capacité de démarrer un processus root. La couche web n’a jamais eu cette capacité ; elle n’a jamais eu qu’une sonnette, et la sonnette a disparu.

Deux choses ne sont expressément pas retirées, et les confondre avec l’applicateur est l’erreur la plus facile à commettre ici :

• Les redéfinitions de configuration continuent de fonctionner. /api/v1/config et les pages de configuration de la console écrivent pepsi.config_override, la surcouche en base que chaque composant lit à l’exécution — non un fichier de /etc. Elles gardent leur propre barrière, [pepsi-admin] CONFIG_DB, et ne sont pas affectées. L’applicateur n’a rien à y voir, et étendre la règle de lecture seule pour les couvrir retirerait une capacité dont cette scission n’a jamais traité. Voir Configuration en base de données dans Configuration.

• Rien ne change au flux de courrier. pepsi-ingress, pepsi-dispatch, chaque étape et les surfaces MTA-STS et métriques de pepsi-httpd restent intactes. Ce n’est pas un build du serveur de courrier à fonctionnalités réduites.

4.3.3. Comment pepsi-httpd s’en aperçoit

Une console qui propose des formulaires sur un hôte sans applicateur est le pire résultat de la scission : un opérateur remplit un questionnaire, appuie sur « appliquer », voit une ligne pending et attend un changement qui n’aura jamais lieu. Le serveur demande donc, avant chaque mutation, si un changement privilégié peut réellement se produire depuis ici.

Il a déjà abandonné ses privilèges : il ne peut donc pas interroger dpkg ni parler au bus privé de systemd — et ne doit pas acquérir de moyen de le faire. Ce qu’il peut faire, c’est regarder deux fichiers, qui à eux deux répondent installé et armé :

1. pepsi-setup-apply.socket existe comme fichier d’unité dans l’un des répertoires que systemd parcourt (/etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, /usr/lib/systemd/system, /lib/systemd/system) ; et

2. [pepsi-admin] APPLY_SOCKET existe, est une socket, et est accessible en écriture à ce compte — se connecter à une socket UNIX exige le droit d’écriture, et une sonnette qu’on ne peut pas actionner n’est pas une capacité.

Deux stat et un access, sans privilège requis. La sonde ne se connecte délibérément pas : se connecter est le coup de sonnette, et démarrerait un processus root à chaque rendu de page.

Aucun des deux tests n’est redondant, et aucun ne doit être supprimé par optimisation plus tard :

• Sans le test du fichier d’unité, un nœud de socket périmé se lit comme une sonnette vivante. Les nœuds périmés sont atteignables en pratique : le RemoveOnStop= de systemd vaut « off » par défaut (l’unité livrée le règle ; une unité éditée à la main peut ne pas le faire), et un paquet dont les fichiers sont supprimés plutôt qu’arrêtés laisse purement et simplement le nœud derrière lui. C’est précisément le scénario pour lequel cette fonctionnalité existe, et s’y tromper échouerait de façon ouverte.

• Sans le test de la socket, un paquet fraîchement installé dont la socket n’a jamais été activée se lirait comme prêt, et chaque tâche resterait pending à jamais.

La vérification échoue de façon fermée. Un chemin qui ne peut pas être examiné, un chemin qui n’est pas une socket, une erreur de permission, un répertoire parent illisible — chaque incertitude se lit comme « pas d’applicateur » et la console passe en lecture seule. L’échec ainsi produit est qu’on dit à un opérateur d’installer quelque chose qui est déjà installé ; l’échec dans l’autre sens est qu’un opérateur croie qu’un changement a été fait. Seul le premier se rattrape en lisant le message, et les messages sont écrits pour être lus : ils distinguent non installé de installé mais non démarré de il y a ici un nœud périmé, et chacun nomme son propre remède.

4.3.4. À quoi ressemble la lecture seule

Tout est toujours affiché. Chaque réglage sur lequel porte le questionnaire de configuration est montré, avec sa réponse en attente ou sa valeur par défaut ; chaque contrôle qui en modifierait un est désactivé, sous une bannière nommant le paquet manquant. Masquer les pages serait la lecture facile de « lecture seule » et la mauvaise — un opérateur qui a délibérément retiré l’applicateur doit encore pouvoir voir ce que le déploiement est configuré pour faire.

L’API refuse les mutations correspondantes avec un statut et un code qui leur sont propres plutôt qu’un échec générique :

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"}}

Cela s’applique à POST /api/v1/setup/tasks, /setup/preflight, /setup/dns-check, /setup/certificates, PUT /api/v1/setup/answers et aux demandes de clé en libre-service POST /api/v1/identities, /api/v1/identities/client et à un PATCH /api/v1/identities/{id} de révocation, ainsi qu’aux propres envois de formulaires de la console — POST /ui/setup/{step}, /ui/setup/tasks, /ui/domains/check, /ui/identities/request/{generate,register} et /ui/identities/{id}/revoke. Tous atteignent la file par une unique fonction de mise en file qui demande d’abord, de sorte que le refus soit une seule décision plutôt qu’une par surface, et que le contrôle désactivé sur la page se pose par-dessus cette vérification plutôt qu’à sa place. La mise en attente des réponses est incluse à dessein : le seul but d’une réponse brouillon est d’être appliquée, et un assistant qui en accumule six étapes sur un hôte où rien ne peut les appliquer est exactement l’inaction silencieuse que la conception évite. DELETE /api/v1/setup/answers n’est pas soumis à cette barrière — écarter des brouillons ne peut causer aucun changement privilégié, et une console en lecture seule doit encore pouvoir vider un questionnaire à moitié terminé.

Le code est distinct de setup_write_unavailable (qui signifie qu’il n’y a pas de connexion CONFIG_DB) parce que les deux appellent des remèdes différents, et l’applicateur est signalé en premier lorsque les deux s’appliquent : configurer un rôle de base de données n’aurait pas aidé.

4.3.5. Ce qui fonctionne encore une fois le paquet retiré

Tout, depuis un terminal. pepsi-setup est dans le paquet pepsi, de sorte que

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

se comportent exactement comme avec le paquet installé, tout comme éditer pepsi.conf à la main, générer des clés, exécuter certbot soi-même et toute autre tâche d’administration. La sous-commande de l’applicateur est elle aussi toujours là : ce que le paquet porte, ce sont les unités, non le programme.

Ce qui est retiré n’est qu’une chose : la capacité de la couche web à le démarrer.

4.3.6. L’armer est une étape distincte et délibérée

Installer pepsi-httpd-admin rend la capacité disponible. Cela ne l’active pas. Comme toute autre unité Pepsi, les deux sont livrées désactivées, de sorte qu’un hôte qui a le paquet mais n’a jamais exécuté

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

n’a pas de sonnette, et la console reste en lecture seule et indique quelle commande changerait cela. Installer un paquet et armer un privilège restent deux décisions distinctes.

4.3.7. L’installer vide d’abord la file

Retirer l’applicateur rompt la boucle au mécanisme, et des lignes peuvent toujours atteindre pepsi.setup_task pendant son absence : un opérateur disposant d’un shell root peut en mettre un en file à la main, et une console à qui l’on dit seulement qu’elle est en lecture seule n’est qu’à une version d’un chemin qui oublierait de demander. Rien ne fait expirer une telle ligne. Une requête est durable, et la file est vidée dans l’ordre où elle a été écrite.

Mis bout à bout, un applicateur qui refait surface des mois plus tard exécuterait chacun d’eux au premier coup de sonnette, contre un déploiement qui a évolué — une configuration écrite à partir d’un jeu de réponses dont personne ne se souvient, un certificat obtenu pour un hôte qui a été renommé.

Aussi, installer pepsi-httpd-admin supprime la file avant que ses unités ne soient armées. Le postinst exécute

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

qui retire chaque ligne sans en exécuter aucune et le dit, en nommant la raison, de sorte qu’un opérateur ayant légitimement mis quelque chose en file sache ce qu’il en est advenu et puisse redemander. Ce qui a été demandé n’est perdu dans aucun des cas : chaque requête, refus, succès et échec est une entrée durable indépendante dans le journal d’audit, que la remise à zéro ne touche pas. La même commande est disponible à la main à tout moment — voir pepsi-setup.

Cela se fait au mieux, comme doit le faire un script de mainteneur. Au moment de l’installation, il peut n’y avoir ni fichier de configuration, ni schéma, ni base de données, ni PostgreSQL en fonctionnement ; chacun de ces cas est signalé et sauté, jamais une installation en échec. (Une base sans schéma Pepsi n’est même pas un saut : elle n’a jamais contenu de tâche, c’est donc une file vide.) La remise à zéro s’exécute à chaque configure, non seulement à une première installation, car dpkg rapporte une réinstallation après apt remove comme une mise à niveau — et retirer-puis-réinstaller est exactement le cas pour lequel cela existe.

4.3.8. Le même levier depuis les sources

Un déploiement par make install obtient le contrôle identique

make install INSTALL_ADMIN_UNITS=no

qui installe tout sauf pepsi-setup-apply.service et pepsi-setup-apply.socket, et imprime ce qu’il a laissé de côté. make uninstall retire toujours les deux ensembles quelle que soit la valeur de la variable lors de cette invocation : une unité privilégiée survivant à une désinstallation parce qu’une variable make a changé est exactement la défaillance dont traite cette scission.

4.3.9. Choisir une posture

La sonde, l’option de configuration et l’ensemble des paquets se composent : la question « cette console peut-elle changer cette machine ? » a donc plus de deux réponses. [pepsi-admin] APPLIER est la redéfinition, documentée en entier dans pepsi.conf(5) :

Posture	Comment	Résultat
Administré depuis un navigateur	Paquet installé, socket activée, APPLIER = auto (la valeur par défaut)	La console peut appliquer des tâches de configuration.
Installé mais non armé	Paquet installé, socket jamais activée	Lecture seule ; le refus nomme systemctl enable --now pepsi-setup-apply.socket.
Administré depuis un terminal	apt remove pepsi-httpd-admin (ou INSTALL_ADMIN_UNITS=no)	Lecture seule ; le refus nomme le paquet, et rien ne vide la file des tâches sans surveillance.
Lecture seule par politique	[pepsi-admin] APPLIER = no, paquet laissé installé	Lecture seule par configuration plutôt que par les paquets installés, et le refus le dit. Réversible en éditant une option — une politique, non une limite.
Appliqué autrement	pepsi-setup apply --once depuis cron, ou une unité écrite à la main, plus [pepsi-admin] APPLIER = yes	La console propose les formulaires. yes est une promesse que fait l’opérateur ; rien ne la vérifie.

Deux de ces lignes méritent que leur différence soit explicitée. APPLIER = no et retirer le paquet produisent tous deux une console en lecture seule, et ce ne sont pas la même défense. APPLIER = no est une ligne d’un fichier de configuration que pepsi-httpd consulte ; quiconque peut modifier ce fichier, ou faire lire un autre fichier à pepsi-httpd, l’annule. Retirer le paquet supprime les unités qui auraient exécuté le processus root, et aucune influence sur pepsi-httpd ne les remet en place. Employez l’option pour énoncer une intention ; retirez le paquet pour l’imposer.

La dernière ligne est une promesse, non une vérification : avec APPLIER = yes, la console met volontiers des tâches en file, que quoi que ce soit les vide ou non. Elle existe pour les déploiements que la sonde ne peut véritablement pas voir — un drain cron, un hôte sans systemd, des fichiers d’unité installés là où systemd ne cherche pas — et c’est le seul endroit de ce mécanisme où le code croit un opérateur sur parole.

Il existe un état fabriqué à la main que l’empaquetage ne peut pas produire : la socket présente et accessible en écriture alors que l’unité de service est masquée ou cassée. La sonde le lit comme disponible, la tâche est mise en file, et elle reste pending. La page des tâches montre ce statut plutôt que de prétendre autre chose. Les deux unités sont livrées dans un seul paquet : atteindre cet état demande donc un effort délibéré.

4.4. Voir aussi

Installation – l’installation par les deux voies, et les comptes, groupes et bits privilégiés que le postinst du paquet pepsi crée. Mises à jour, retrait et état des services – ce que mettre à jour, retirer et réinstaller font aux services qui tournaient. Modèle de sécurité – le modèle de menace dans lequel cette séparation est une atténuation, en particulier ce qu’un attaquant qui compromet pepsi-httpd obtient et n’obtient pas. La console d’administration et L’API d’administration – les surfaces de console et d’API qui passent en lecture seule. pepsi-setup – le modèle de confiance de l’applicateur, sa liste de tâches fermée et ses contrôles d’admission. pepsi-httpd – la détection, les points d’accès conditionnés et [pepsi-admin] sous forme de référence.