Sujet : automation
-
Tale MCP : point de terminaison de déploiement et périmètre d'organisation
Tale expose un point de terminaison MCP propre à chaque déploiement pour la connaissance et les automatisations, avec des clés d'API de type bearer et un cloisonnement par organisation. Cette référence résume les modalités de connexion et les limites de permissions telles que la documentation les décrit.
-
rc.conf, sysrc et service sous FreeBSD : activer, démarrer et vérifier ce qui s'exécute au démarrage
Sous FreeBSD, les services sont activés de manière déclarative par une variable rc.conf (dans /etc/rc.conf ou dans un fichier propre au service sous /etc/rc.conf.d) ; sysrc et service <nom> enable ne font qu'écrire cette variable, et rc.conf n'est pas censé exécuter quoi que ce soit directement : il se contente de définir des variables que lisent les scripts rc de /etc/rc.d. sysrc modifie ces variables de façon sûre depuis un script, et service démarre et arrête le script rc.d correspondant et en indique l'état.
-
Pourquoi un script non supervisé échoue silencieusement sous macOS : permissions TCC pour les fichiers, l'accessibilité et l'automatisation
macOS contrôle via TCC l'accès aux fichiers situés hors du conteneur d'une application, le pilotage du clavier et de l'écran, ainsi que les Apple Events entre applications. Les autorisations sont liées à l'identité de code du binaire appelant, et non à l'utilisateur Unix : être root ne permet donc pas de contourner TCC, et un outil recompilé non signé ou signé ad hoc doit repasser par l'étape d'autorisation.
-
Définir la locale, le fuseau horaire et reconfigurer des paquets sans interaction sous Debian et Ubuntu
localectl, timedatectl et update-locale modifient la locale et le fuseau horaire sans boîte de dialogue en mode texte, et dpkg-reconfigure -f noninteractive relance la configuration debconf d'un paquet comme le ferait un script lors de l'installation initiale ; les deux sont utilisables dans des scripts de provisionnement sans terminal.
-
Commandes ad-hoc Ansible et mode check : un premier passage sûr sur un parc de machines
Une commande `ansible` ad-hoc exécute un module sur un ou plusieurs hôtes sans playbook ; associée à `--check --diff` et à un `--limit` restreint, elle permet à un agent de voir l'effet d'une modification sur un parc avant de l'appliquer.
-
Automatiser z/OS via z/OSMF : les API REST pour les jobs, les datasets et les fichiers
z/OSMF expose les jobs, les datasets et les fichiers z/OS UNIX sous forme de ressources HTTPS/REST classiques, ce qui en fait l'interface du système la mieux adaptée aux agents. Les requêtes doivent porter l'en-tête personnalisé X-CSRF-ZOSMF-HEADER (les requêtes qui modifient l'état sont rejetées sans lui), et les réponses utilisent les codes d'état HTTP standard plutôt que des messages texte 3270.
-
Timers systemd en remplacement de cron : OnCalendar, Persistent= et RandomizedDelaySec
Une unité systemd .timer associée à un service .service de type oneshot peut remplacer une entrée crontab, tout en ajoutant le rattrapage des exécutions manquées après une indisponibilité et un décalage aléatoire au sein d'un parc de machines. Cette méthodologie décrit l'écriture, la validation et l'activation d'une telle paire, et explique ce que font réellement Persistent= et RandomizedDelaySec=.
-
Utiliser SMIT comme générateur de commandes plutôt que comme système de menus
Les menus smit/smitty exécutent au final des commandes AIX ordinaires, et l'outil permet de voir lesquelles : la fenêtre de sortie affiche la commande construite, et smit.log/smit.script enregistrent chaque commande avec ses options exactes et un horodatage. Lire smit.script après une tâche réalisée par les menus est un moyen rapide de découvrir la commande non interactive équivalente.
-
Mettre à jour FreeBSD : freebsd-update pour le système de base, pkg upgrade pour les paquets et pkg audit pour les vulnérabilités connues
FreeBSD sépare les mises à jour en deux outils indépendants : freebsd-update fetch/install pour le système de base (avec upgrade -r pour changer de version majeure) et pkg upgrade pour les paquets installés. pkgbase, qui installe le système de base lui-même sous forme de paquets pkg(8), est documenté comme expérimental sous FreeBSD 14 et comme préversion technologique pour FreeBSD 15.0 ; ce n'est pas encore la voie par défaut.
-
Exécuter des commandes d'administration Linux en mode non interactif pour des agents sans supervision
Pager, invite de confirmation, locale qui reformate les nombres, demande de mot de passe sudo sans terminal pour y répondre : ces comportements interactifs par défaut sont les causes les plus fréquentes de blocage d'une session d'agent sans supervision sous Linux, ou d'une mauvaise lecture de la sortie. Cet article recense les options et variables d'environnement qui désactivent chacun d'eux.
-
Domaines launchd : choisir entre LaunchAgent et LaunchDaemon et les charger avec launchctl
Les LaunchAgents et les LaunchDaemons résident dans des répertoires différents, s'exécutent dans des domaines launchd distincts et se gèrent avec les sous-commandes modernes bootstrap/bootout/enable/kickstart/print, et non avec la paire obsolète load/unload. Cette méthodologie explique comment choisir le bon domaine, écrire un plist minimal et vérifier l'état du service.
-
Stocker des secrets pour des scripts non supervisés : credentials systemd, DPAPI, trousseau macOS — et ce qu'il faut éviter
Chaque système d'exploitation propose un mécanisme pour fournir un secret à un script sans variable d'environnement ni argument de ligne de commande, lisibles par tout processus voisin ou journal : LoadCredential= de systemd, DPAPI sous Windows via Export-Clixml ou SecretManagement, et le trousseau macOS via security find-generic-password.
-
Détecter le système d'exploitation depuis un script : uname, os-release, sw_vers, oslevel et ordre de repli
Un script portable doit pouvoir déterminer de façon fiable le système d'exploitation et sa version avant d'exécuter une commande propre à un OS, tirée des autres articles de cette série. Cette méthodologie propose un ordre de repli, de la source la plus précise et la plus fiable jusqu'à une estimation de dernier recours, pour les shells POSIX et PowerShell.
-
SSH known_hosts et vérification de la clé d'hôte en automatisation : ssh-keyscan complété par un contrôle hors bande
Un processus automatisé qui se connecte en SSH doit tout de même vérifier la clé d'hôte du serveur : ssh-keyscan se contente de récupérer une clé sans prouver qu'elle est authentique. StrictHostKeyChecking=accept-new, HashKnownHosts et les enregistrements SSHFP couvrent chacun un aspect différent d'une mise en œuvre sûre, sans invite interactive.
-
Administrer SUSE Linux avec zypper : refresh, patch, update ou dup, et exécutions non interactives
zypper distingue quatre commandes : rafraîchir les métadonnées des dépôts, installer les correctifs officiels, mettre à jour des paquets individuels et effectuer une mise à niveau complète de la distribution. Savoir laquelle choisir, lancer zypper sans intervention, repérer les processus qui utilisent encore des fichiers supprimés après une mise à jour et verrouiller la version d'un paquet évite à un agent de casser un hôte SUSE.
-
Pare-feu PF sous FreeBSD : tester pf.conf avec pfctl -n avant de le charger, et retour arrière planifié contre le verrouillage SSH
Les règles de pf.conf s'organisent autour d'une politique par défaut pass/block et d'ancres facultatives pour rattacher des sous-jeux de règles ; on ne les charge avec pfctl -f qu'après les avoir analysées avec pfctl -nf, sans chargement. Un jeu de règles erroné pouvant couper la session SSH même qui sert à l'appliquer, planifier avec at(1) une restauration automatique avant de charger les nouvelles règles est un schéma de sécurité courant (et non une fonctionnalité de PF) pour tester des modifications sur un hôte FreeBSD distant.
-
Exécuter apt et dpkg en mode non interactif sur Debian et Ubuntu sans blocage sur les invites
Une exécution scriptée d'apt-get ou de dpkg peut se bloquer sur une invite debconf, sur une question concernant un fichier de configuration modifié ou sur un verrou dpkg détenu. Définir DEBIAN_FRONTEND, choisir les bonnes options confold/confdef et préremplir au préalable les réponses debconf transforme une installation en une commande qui soit se termine, soit échoue de manière explicite.
-
Exécuter Homebrew en mode non interactif sur un agent de build : NONINTERACTIVE, variables d'environnement et Brewfile
Le programme d'installation de Homebrew, sa mise à jour automatique, sa télémétrie et les versions des formules se pilotent sans aucune invite sur un runner CI, et un Brewfile rend l'ensemble des paquets installés reproductible d'un runner à l'autre.
-
Mettre en place une installation RHEL sans surveillance avec un fichier Kickstart
Un fichier Kickstart pilote l'installation de RHEL, Rocky Linux ou AlmaLinux sans aucune invite interactive, en combinant des commandes d'une ligne et des scriptlets %pre et %post. Cette méthodologie couvre la validation du fichier avant usage, sa transmission au démarrage, et la manière de tenir les secrets hors d'un fichier souvent servi sans authentification.
-
Configurer unattended-upgrades pour les correctifs de sécurité automatiques sur Debian et Ubuntu
unattended-upgrades installe les mises à jour de paquets selon un minuteur, à l'aide de deux fichiers : 20auto-upgrades (activation et fréquence) et 50unattended-upgrades (dépôts concernés et redémarrage). Un essai avec --dry-run --debug avant la mise en production évite les redémarrages inattendus ou les mises à jour appliquées à moitié.
Lisible par machine : JSON