Auton 1.0.0 — publication et guide de mise à niveau

Auton exécute à distance des commandes configurées. Le client gère la sélection des cibles et la progression des scénarios ; chaque daemon gère l’autorisation, l’exécution et l’historique local. La console Web optionnelle lance un point d’entrée sur son propre daemon. Les scénarios multi-cibles relèvent de la CLI/TUI. Aucun serveur central n’est nécessaire.

Installer la version

Utilisez Python 3.10 à 3.12 sous Linux/Unix, de préférence dans un environnement virtuel dédié :

python -m pip install 'auton==1.0.0'
python -m pip install 'autond[auth]==1.0.0'

Installez uniquement le composant nécessaire sur chaque machine. L’extension auth du daemon fournit Argon2. L’image Docker est decryptus/auton:1.0.0 (également v1.0.0). Le démarrage rapide du README construit la même version depuis son tag Git et crée un compte local de manière interactive. Il n’existe ni identifiant intégré ni daemon de démonstration public.

Mettre à niveau une installation 0.3.2

  1. Sauvegardez la version des paquets ou de l’image, la configuration, les composants des points d’entrée et les fichiers d’authentification. Planifiez la maintenance et laissez les tâches actives se terminer avant d’arrêter l’ancien daemon. Ses résultats en mémoire par défaut ne survivent pas au redémarrage.

  2. Conservez la configuration montée existante. Mettez le client et le daemon à la même version. La mise à niveau ne réécrit pas la configuration et n’importe pas automatiquement les comptes Basic dans SQLite.

  3. Sans auth_mode, les configurations existantes gardent l’authentification historique par route, avec un avertissement. Définissez auth_mode: legacy pour rendre ce choix temporaire explicite ; chaque route protégée exige toujours auth: true. Un fichier de mots de passe Basic seul ne protège pas une route en mode legacy.

  4. Préférez auth_mode: required avec les identifiants Basic existants sur HTTPS, ou créez des comptes/jetons SQLite et configurez explicitement ce stockage. Conservez les ACL utilisateurs des points d’entrée. Les portées read/run/maintenance ne remplacent ni les ACL ni la propriété des tâches. Les nouveaux exemples imposent l’authentification et la boucle locale par défaut.

  5. Testez une commande autorisée, un point d’entrée interdit et l’accès aux résultats avec l’identité réelle de l’opérateur avant de rouvrir le trafic. run/status, --uri, le traitement des arguments et les curseurs de sortie restent pris en charge. Plusieurs URI servent toujours au basculement, jamais à une exécution multi-cibles implicite.

Lors d’un changement de stockage d’authentification, créez les comptes avec les identités prévues et fournissez explicitement de nouveaux jetons. Les anciens fichiers Basic ne sont pas une source de migration SQLite. Stockez les jetons clients dans des fichiers privés ; les profils multi-origines doivent couvrir toutes les origines sélectionnées, basculement compris. La console Web optionnelle exige SQLite et la web_origin externe exacte ; configurez HTTPS avant l’exposition distante.

Historique durable optionnel

L’historique reste en mémoire tant que general.job_storage.backend: sqlite n’est pas configuré. Authentification et historique utilisent des fichiers privés séparés et des configurations indépendantes. Créez des répertoires parents privés accessibles en écriture au compte du daemon. Chaque historique appartient à un seul daemon. Sauvegardez SQLite avec le daemon arrêté.

SQLite conserve les instantanés d’admission et finaux, ainsi que la sortie terminale, selon les limites de TTL/capacité. Il ne récupère pas les anciennes tâches 0.3.2 en mémoire. Après redémarrage, les tâches interrompues deviennent explicitement incertaines/interrompues et ne sont jamais rejouées. Un plantage brutal peut laisser un processus enfant actif : vérifiez ses effets avant toute nouvelle soumission.

Pour revenir en arrière, arrêtez le nouveau daemon et restaurez le paquet/l’image et la configuration sauvegardés. La version 0.3.2 ne peut pas utiliser les nouvelles fonctions SQLite d’authentification/historique, de console ou de scénarios. Gardez les nouvelles sauvegardes ; l’ancienne version ne saura pas nécessairement les lire. Un retour arrière n’annule jamais les commandes exécutées à distance.

Limites prises en charge

  • Une étape en échec ou au résultat inconnu arrête les suivantes sur cette cible ; les autres peuvent continuer. Arrêter le client n’annule ni les tâches distantes actives ni leurs effets.

  • Une soumission ambiguë n’est ni retentée ni basculée. L’état reste lié à l’origine qui l’a acceptée. Les hôtes de basculement doivent être équivalents pour la commande configurée.

  • Configurations des points d’entrée et modèles Mako sont des entrées d’administration de confiance. Auton exécute avec les privilèges configurés du daemon ; ce n’est pas un bac à sable.

  • Les logs JSONL ont une rotation bornée. L’audit des refus d’authentification ne prétend ni attribuer les événements par utilisateur ni fournir un historique administratif complet.

  • Python 3.13+, Redis, SSO/OIDC, mTLS et l’annulation sont reportés. Les dépendances sont contraintes mais pas totalement verrouillées ; la reproductibilité octet pour octet n’est pas promise.

Le site public et la documentation navigable sont maintenus séparément sur auton.run. Le dépôt du site reste privé.