61. pepsi-setup

Provisionner la base de données, les clés de signature et le DNS pour un déploiement.

61.1. Rôle

pepsi-setup est l’outil d’amorçage d’administration. En une seule invocation, il valide la configuration, installe le schéma, génère les clés de signature et imprime les enregistrements DNS à publier ; un check distinct vérifie le DNS publié. Références : pepsi-setup(1) / pepsi.conf(5).

61.2. Fonctionnalités

  • Validation de la configuration. Analyse [pepsi], [pepsi-ingress] et le pipeline [stage-*] ; vérifie que [stage-init] existe, que chaque NEXT_STAGE/BOUNCE_STAGE se résout, que la configuration du programme de chaque étape (y compris l’acheminement smarthost) s’analyse, et que les domaines et les valeurs PUBLIC_IP sont bien formés. En cas d’erreur, il ne change rien et sort avec un code non nul.

  • Provisionnement des certificats TLS. Pour chaque section de listener/certificat terminant le TLS qui n’a pas de TLS_CERT/TLS_KEY, il remplit la disposition de chemins certbot standard (en réécrivant le fichier de configuration sur place, commentaires préservés) puis exécute certbot certonly --standalone pour obtenir tout certificat pas encore présent sur disque (ou pour élargir un certificat qui ne couvre plus tous les noms). Passez --no-certbot pour omettre l’appel à certbot et gérer les certificats vous-même. Un certificat manquant qui ne peut pas être obtenu est différé, et non fatal : le reste de l’exécution se poursuit et le récapitulatif de fin d’exécution indique ce qu’il reste à faire.

  • Provisionnement de l’accès TLS. Les serveurs s’exécutent sous des utilisateurs non privilégiés, tandis que certbot conserve /etc/letsencrypt réservé à root. Sous systemd, pepsi-setup écrit un drop-in LoadCredential= par unité, de sorte que systemd lit chaque certificat et chaque clé en tant que root au démarrage de l’unité et remet au service une copie privée — les permissions des fichiers n’ont alors plus aucune importance. Il accorde également des ACL POSIX et installe un hook de déploiement certbot (qui réaccorde les droits et redémarre les serveurs, afin qu’un certificat renouvelé soit réellement servi), puis vérifie enfin — en devenant l’utilisateur de service et en ouvrant le fichier — que tout ce qui subsiste est réellement lisible.

  • Installation du schéma. Le seul installateur de l’unique schéma pepsi : applique la série de patchs numérotés et les procédures recréables depuis SQL_DIR ; idempotent et réexécutable. Il enregistre ce qu’il a appliqué, par empreinte du contenu, afin que chaque programme puisse refuser un schéma d’une autre version, et il refuse lui-même d’installer par-dessus un schéma plus récent (voir Mise à niveau). run --reset supprime et recrée le schéma (détruisant le courrier en file d’attente ; les clés sur disque sont conservées).

  • Génération de clés. Pour chaque domaine pour lequel Pepsi fait autorité — l’union de ACCEPTED_DOMAINS, du domaine SERVER_NAME/POSTMASTER de chaque étape, de tout SIGNING_DOMAIN, SRS_DOMAIN ou RESPONSE_FROM fixe explicite, et de ARC_DOMAIN — crée une clé DKIM RSA-2048 et une Ed25519 (RFC 8463) sous KEY_DIR (mode 0600 dans des répertoires 0700) si elles sont absentes ; les clés existantes ne sont jamais écrasées.

  • Sortie d’enregistrements DNS. Imprime, au format de zone BIND, les clés publiques DKIM (<selector>._domainkey et <selector>-ed25519._domainkey), une politique SPF construite à partir du PUBLIC_IP de chaque étape relais (union), une suggestion DMARC là où aucune n’est publiée, un enregistrement TXT MTA-STS _mta-sts (RFC 8461), un enregistrement TLSRPT lorsque [pepsi-tlsrpt] RUA est défini, et des enregistrements DANE/TLSA pour les listeners TLS. Les enregistrements déjà publiés avec la bonne valeur sont omis. Le fichier de politique lui-même est servi par pepsi-httpd, pas imprimé. Les longs enregistrements RSA sont scindés en plusieurs chaînes de caractères. Le même enregistrement SPF est suggéré pour chaque domaine servi ; la sortie note que des configurations multi-hôtes particulières peuvent préférer un regroupement par domaine plus strict, toujours correct, que pepsi-setup ne calcule pas automatiquement.

  • Vérification du DNS publié (check) : interroge le DNS et rapporte, par domaine, si le p= DKIM publié correspond à la clé locale, si l’enregistrement SPF liste chaque PUBLIC_IP, si l’enregistrement DMARC est valide, et si le TXT _mta-sts est présent et analysable ; il compare aussi la politique MTA-STS aux enregistrements MX réels et à ce qui est effectivement servi, et vérifie que le domaine SRS peut recevoir ses rejets. Purement informatif : ses constats ne déterminent jamais le code de sortie.

  • Assistant de configuration initiale (--wizard) : un court questionnaire interactif qui écrit un fichier de configuration complet et déjà validé (au chemin --config, ou /etc/pepsi/pepsi.conf par défaut) puis propose d’exécuter la configuration initiale complète. Il importe les réponses d’une exécution précédente depuis la section [pepsi-wizard] du fichier ; --force écrase sans demander un fichier dépourvu d’une telle section.

Utilisez pepsi-config pour inspecter la configuration effective.

61.3. Options de ligne de commande

L’exécution sans sous-commande effectue la configuration initiale complète (identique à run). Le détail complet est dans pepsi-setup(1) ; les options sont :

Sous-commandes :

  • run — valider, provisionner le TLS, installer le schéma, générer les clés, imprimer le DNS (l’action par défaut). -r/--reset supprime et recrée d’abord le schéma (détruit tout le courrier en file d’attente ; les clés sur disque sont conservées).

  • schema — installer ou mettre à niveau le schéma et les droits des rôles, et rien d’autre ; n’a besoin que de [pepsi-postgres], et fonctionne donc aussi avec le fichier de configuration d’un collecteur de télémétrie. Refuse un schéma plus récent (code de sortie 78). --backup-dir DIR enregistre d’abord le schéma avec pg_dump lorsqu’il y a quelque chose à mettre à niveau ; --if-installed ne fait rien sur une base de données qui n’a pas encore de schéma. C’est ce qu’exécute une mise à niveau de paquet ; voir Mise à niveau.

  • check — interroger le DNS publié et signaler les écarts ; ne fait aucun changement, et ses constats ne déterminent jamais le code de sortie.

  • visualize — imprimer le pipeline [stage-*] sous forme de graphe Graphviz dot sur la sortie standard (une arête pleine par NEXT_STAGE, une arête rouge en pointillés par BOUNCE_STAGE) ; passez-le à dot -Tpng.

  • questions — imprimer l’entretien de configuration en JSON : les étapes, la forme de chaque question, sa valeur par défaut, son texte d’aide et le moment où elle est posée. C’est le modèle par lequel sont décrits aussi bien l’assistant en terminal que la configuration dans le navigateur, et le schéma auquel se conforme un fichier --answers.

  • apply — effectuer le travail de configuration privilégié demandé par l’interface du navigateur, en lisant les lignes d’intention de pepsi.setup_task. Normalement démarré à la demande par systemd. --once écoule ce qui est en attente puis sort ; --idle SECS fixe le temps d’attente sans rien à faire avant de sortir ; --clear supprime toutes les lignes en file sans en exécuter aucune (mutuellement exclusive avec les deux autres).

  • bootstrap — frapper et imprimer le jeton porteur à usage unique qui crée le premier compte administrateur (--valid-for SECS, --admin-url URL).

  • import [MTA] — signaler ce qui serait migré depuis un MTA existant (postfix, exim, sendmail, qmail, stalwart) sans rien écrire ; --root lit sous un autre répertoire, --out écrit le rapport et les fichiers de tables convertis, --alias-style choisit la façon dont les noms d’alias nus sont qualifiés.

Options, qui viennent toutes avant la sous-commande :

  • --no-certbot — ne pas invoquer certbot pour les certificats TLS manquants ; ils sont différés à la place (voir Provisionnement des certificats TLS ci-dessus).

  • --no-reverse-proxy — ne pas s’intégrer automatiquement à un serveur HTTP frontal existant ; laisser pepsi-httpd lier le port 443 directement.

  • -y/--yes-to-all, -n/--no-to-all — répondre de la même façon à chaque proposition interactive, de sorte que la configuration ne se bloque jamais sur une saisie.

  • --wizard — exécuter l’assistant de configuration interactif (n’exige pas de fichier de configuration existant) ; --force écrase sans demander un fichier non importable. Avec lui : --expert SPEC pose en outre les options plus profondes (--expert=help les liste), --import MTA / --no-import / --import-root DIR commandent la migration des paramètres d’un MTA existant, et --answers FILE répond à chaque question à partir d’un JSON au lieu de la poser.

  • -c/--config FILE, -L/--log LEVEL, -v/--verbose, -h/--help, -V/--version — les options partagées par tous les outils Pepsi.

61.4. Configuration

Lit les sections partagées [pepsi] (KEY_DIR, DKIM_SELECTOR, DKIM_ALGORITHMS, ARC_DOMAIN, ARC_ALGORITHM, ORIGINATE_SUCCESS_DSN, MTA_STS_MODE, MTA_STS_MAX_AGE), [pepsi-postgres] (CONFIG, SQL_DIR), [pepsi-ingress] (HOSTNAME, ACCEPTED_DOMAINS), et les sections [stage-*] — y compris le PUBLIC_IP de chaque étape relais (collecté par PROGRAM). Référence complète : pepsi.conf(5).

61.5. Voir aussi

Installation, Configuration, pepsi-setup(1), pepsi.conf(5).