Tema: automation
-
rc.conf, sysrc y service en FreeBSD: habilitar, iniciar y comprobar qué se ejecuta al arrancar
Los servicios de FreeBSD se habilitan de forma declarativa mediante una variable de rc.conf (en /etc/rc.conf o en un archivo por servicio bajo /etc/rc.conf.d); sysrc y service <name> enable simplemente escriben esa variable, y el propio rc.conf no está pensado para ejecutar nada directamente — solo establece variables que leen los scripts rc de /etc/rc.d. sysrc edita esas variables de forma segura desde un script, y service inicia, detiene e informa del estado del script de rc.d correspondiente.
-
Por qué un script desatendido falla en silencio en macOS: los permisos TCC para archivos, Accesibilidad y Automatización
macOS media el acceso a archivos fuera del contenedor de una app, al control de teclado/pantalla y a los eventos de Apple entre apps mediante TCC, asociado a la identidad de código del binario que llama y no al usuario de Unix — de modo que root no lo elude, y una herramienta recompilada sin firmar o firmada ad hoc reinicia el proceso de concesión de permisos.
-
Establecer la configuración regional, la zona horaria y reconfigurar paquetes sin interacción en Debian y Ubuntu
localectl, timedatectl y update-locale cambian la configuración regional y la zona horaria sin un cuadro de diálogo en modo texto, y dpkg-reconfigure -f noninteractive vuelve a ejecutar el paso de configuración de un paquete basado en debconf de la misma forma en que lo haría un script durante la instalación original, ambos utilizables en scripts de aprovisionamiento sin ninguna terminal conectada.
-
Ansible ad-hoc commands and check mode for a safe first run against a fleet
An ad-hoc `ansible` command runs one module against one or more hosts without a playbook, and combining it with `--check --diff` and a narrow `--limit` lets an agent see what a change would do to a fleet before it does it.
-
Automatizar z/OS mediante z/OSMF: las API REST de trabajos, conjuntos de datos y archivos
z/OSMF expone los trabajos, los conjuntos de datos y los archivos UNIX de z/OS como recursos HTTPS/REST normales, lo que lo convierte en la interfaz más adecuada para agentes con la que interactuar con el sistema; las solicitudes necesitan la cabecera personalizada X-CSRF-ZOSMF-HEADER (las que cambian el estado se rechazan sin ella), y las respuestas usan códigos de estado HTTP estándar en lugar de texto de mensaje 3270.
-
Los temporizadores de systemd como sustituto de cron: OnCalendar, Persistent= y RandomizedDelaySec
Una unidad .timer de systemd emparejada con un .service de tipo oneshot puede sustituir a una entrada de crontab, y además añade ejecuciones de recuperación tras un periodo de inactividad y una dispersión aleatoria entre los hosts de un parque. Esta metodología escribe, valida y habilita ese par de unidades, y explica qué hacen realmente Persistent= y RandomizedDelaySec=.
-
Usar SMIT como generador de comandos en lugar de como sistema de menús
Los menús de smit/smitty acaban ejecutando comandos AIX comunes, y la herramienta está diseñada para mostrar cuáles: la ventana de salida muestra la instrucción de comando construida, y smit.log/smit.script registran cada comando con sus opciones exactas y marcas de tiempo. Leer smit.script después de una tarea realizada mediante menús es una forma rápida de aprender el comando no interactivo equivalente.
-
Actualizar FreeBSD: freebsd-update para el sistema base, pkg upgrade para los paquetes y pkg audit para las vulnerabilidades conocidas
FreeBSD divide la aplicación de parches en dos herramientas independientes: freebsd-update fetch/install para el sistema base (con upgrade -r para un cambio de versión mayor), y pkg upgrade para los paquetes instalados. pkgbase —instalar el propio sistema base como paquetes pkg(8)— está documentado como experimental en FreeBSD 14 y como vista previa tecnológica para FreeBSD 15.0, todavía no como la vía por defecto.
-
Ejecución no interactiva de comandos administrativos de Linux para agentes desatendidos
Los comportamientos predeterminados interactivos —un paginador, una solicitud de confirmación, una configuración regional que reformatea los números, una solicitud de contraseña de sudo sin terminal para responderla— son las razones más comunes por las que una sesión desatendida de un agente se cuelga o interpreta mal la salida en Linux. Este artículo enumera las opciones y variables de entorno que desactivan cada una.
-
Dominios de launchd: elegir entre un LaunchAgent o un LaunchDaemon y cargarlo con launchctl
Los LaunchAgents y los LaunchDaemons residen en directorios distintos, se ejecutan en dominios de launchd distintos, y se gestionan con los subcomandos modernos bootstrap/bootout/enable/kickstart/print en lugar del par obsoleto load/unload. Esta metodología cubre cómo elegir el dominio correcto, escribir un plist mínimo y comprobar el estado.
-
Storing secrets for unattended scripts: systemd credentials, DPAPI, macOS keychain — and what not to do
Each OS has a mechanism to hand a script a secret without an environment variable or command-line argument that any co-resident process or log can read: systemd's LoadCredential=, Windows DPAPI via Export-Clixml or SecretManagement, and the macOS keychain via security find-generic-password.
-
Detectar el sistema operativo desde un script: uname, os-release, sw_vers, oslevel y un orden de reserva
Un script portable necesita una forma fiable de bifurcar según el sistema operativo y su versión antes de ejecutar un comando específico del sistema operativo procedente de cualquier otro artículo de esta serie. Esta metodología ofrece un orden de reserva —desde la fuente más específica y fiable hasta una suposición de último recurso— para shells POSIX y PowerShell.
-
SSH known_hosts and host key verification for automation: ssh-keyscan plus an out-of-band check
Automation that connects over SSH still needs to verify the server's host key; ssh-keyscan alone only harvests a key without proving it is genuine. StrictHostKeyChecking=accept-new, HashKnownHosts and SSHFP records each address a different part of doing this safely without an interactive prompt.
-
Administrar SUSE Linux con zypper: refresh, patch frente a update frente a dup, y ejecuciones no interactivas
zypper separa en cuatro comandos distintos la actualización de los metadatos del repositorio, la instalación de parches oficiales, la actualización de paquetes individuales y la actualización completa de la distribución. Saber cuál usar, cómo ejecutar zypper sin supervisión, cómo encontrar procesos que aún usan archivos eliminados tras una actualización, y cómo bloquear la versión de un paquete evita que un agente rompa un host SUSE.
-
The PF firewall on FreeBSD: testing pf.conf with pfctl -n before loading it, and a scheduled rollback against SSH lockout
pf.conf rules are organized around a default pass/block policy, optional anchors for attaching sub-rulesets, and are loaded with pfctl -f only after pfctl -nf has parsed them without loading. Because a mistaken rule set can cut off the very SSH session used to apply it, scheduling an unattended revert with at(1) before loading new rules is a common safety pattern (not a PF feature) for testing changes on a remote FreeBSD host.
-
Running apt and dpkg non-interactively on Debian and Ubuntu without hanging on prompts
A scripted apt-get or dpkg run can stall on a debconf prompt, a modified-conffile question or a held dpkg lock. Setting DEBIAN_FRONTEND, the right confold/confdef options and preseeding debconf answers first turns an install into a command that either finishes or fails loudly.
-
Running Homebrew non-interactively on a build agent: NONINTERACTIVE, env vars and Brewfile
Homebrew's installer, its auto-update and analytics behaviour, and formula versions can all be controlled without a prompt for use on a CI runner, and a Brewfile makes the installed set reproducible across runners.
-
Building an unattended RHEL install with a Kickstart file
A Kickstart file drives a RHEL, Rocky Linux or AlmaLinux install with no interactive prompts, combining one-line commands with %pre and %post scriptlets. This methodology covers validating the file before use, passing it at boot, and keeping secrets out of a file that is often served unauthenticated.
-
Configuring unattended-upgrades for automatic security patching on Debian and Ubuntu
unattended-upgrades applies package updates on a timer using two files: 20auto-upgrades (whether and how often) and 50unattended-upgrades (which origins and whether to reboot). Testing with --dry-run --debug before enabling it in production avoids surprise reboots or half-applied upgrades.
Legible por máquina: JSON