Démarrer

#Prérequis

• Linux sur x86_64 : le filtre seccomp refuse toute autre architecture plutôt que de deviner.
• La chaîne d’outils Rust (cargo).
• Pour appliquer réellement le sandbox : un sous-arbre cgroup v2 délégué, ce que fournit un service utilisateur systemd avec Delegate=yes.

#Cloner et vérifier

git clone https://github.com/bext-stack/automonique.git
cd automonique

Lancez les vérifications adaptées à la zone que vous modifiez. Les plus utiles :

python3 tools/check_licenses.py
cargo fmt --manifest-path rust/Cargo.toml --all -- --check
cargo test --manifest-path rust/Cargo.toml --workspace --all-targets --locked
cargo clippy --manifest-path rust/Cargo.toml --workspace --all-targets --locked -- -D warnings

#Lancer le daemon

Le paquet automonique construit trois binaires (automonique, automonique-release, legacyctl) sans binaire par défaut : précisez toujours --bin automonique avec cargo run.

L’exécutable exige des racines XDG privées et explicites pour le runtime et l’état. Il ne se replie jamais sur le répertoire personnel. Sur une session Linux normale, ces variables sont souvent déjà définies.

export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:?set a private runtime directory}"
export XDG_STATE_HOME="${XDG_STATE_HOME:?set a private state directory}"
cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- daemon --foreground

Le daemon ne crée que des enfants automonique/ sous ces racines, appartenant à son utilisateur et en mode 0700, et refuse les chemins trop permissifs ou appartenant à un autre utilisateur.

Il n’écoute que sur des sockets Unix locaux privés : administration (admin.sock), progression (progress.sock) et adoption de tentatives. Son seul écouteur réseau est le broker de sortie, ouvert par exécution sur un port loopback éphémère.

#Inspecter l’état

Depuis un autre terminal, avec le même environnement :

cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- status
cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- status --json
cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- doctor

Le champ execution_state indique ce que l’hôte peut réellement appliquer :

#Soumettre un travail synthétique

printf '%s' 'local fixture' | cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- \
  submit workspace:test fixture:1

La syntaxe est submit <scope> <clé-d’idempotence>. Elle alimente la voie synthétique : un travail local borné, lu sur stdin, sérialisé par scope et enregistré comme un terminal déterministe plus un fake.receipt en attente. Il n’exécute aucun processus, n’appelle aucun fournisseur et n’envoie aucun effet externe. accepting_intake=true ne concerne que cette voie.

Démarrer un vrai travail passe par une requête distincte (run submit), authentifiée séparément : détenir un document et l’exécuter restent deux décisions.

#Arrêter

cargo run --manifest-path rust/Cargo.toml -p automonique --bin automonique -- shutdown

#Tester le confinement

Les tests de confinement du runner ont besoin d’un sous-arbre cgroup v2 délégué, ce qu’une session interactive n’a pas. Hors de ce cadre, ils vérifient le refus en mode fermé. Pour exercer réellement la frontière, lancez-les dans un scope délégué en exigeant l’application :

systemd-run --user --scope -p Delegate=yes \
  --setenv=AUTOMONIQUE_REQUIRE_ENFORCED_CONTAINMENT=1 \
  cargo test --manifest-path rust/Cargo.toml -p automonique-runner --test containment

Un hôte qui ne peut pas prouver l’application échoue alors bruyamment, au lieu d’afficher un résultat vert mais vide.