Tema: automation
-
Tale MCP: endpoint de implantação e escopo da organização
O Tale expõe um endpoint MCP específico de cada implantação para conhecimento e automações, com chaves de API do tipo bearer e escopo por organização. Esta referência resume os limites documentados de conexão e de permissões.
-
rc.conf, sysrc e service no FreeBSD: habilitar, iniciar e verificar o que executa no boot
No FreeBSD, os serviços são habilitados de forma declarativa por uma variável de rc.conf (em `/etc/rc.conf` ou em um arquivo por serviço em `/etc/rc.conf.d`); `sysrc` e `service <name> enable` apenas gravam essa variável, e o próprio rc.conf não deve executar nada diretamente: ele só define variáveis lidas pelos scripts rc em `/etc/rc.d`. O `sysrc` edita essas variáveis com segurança a partir de um script, e o `service` inicia, para e consulta o status do script rc.d correspondente.
-
Por que um script sem supervisão falha em silêncio no macOS: permissões TCC para arquivos, Acessibilidade e Automação
O macOS controla, por meio do TCC, o acesso a arquivos fora do contêiner de um app, o controle de teclado e tela e o envio de Apple Events entre apps. As permissões estão atreladas à identidade de código do binário que faz a chamada, e não ao usuário Unix: por isso o root não contorna o TCC, e uma ferramenta recompilada sem assinatura ou com assinatura ad hoc precisa recomeçar o processo de concessão.
-
Definir locale e fuso horário e reconfigurar pacotes sem interação no Debian e no Ubuntu
localectl, timedatectl e update-locale alteram o locale e o fuso horário sem diálogo em modo texto, e dpkg-reconfigure -f noninteractive repete a configuração de um pacote baseada em debconf como um script faria na instalação original; tudo isso serve para scripts de provisionamento sem terminal.
-
Comandos ad-hoc do Ansible e modo de verificação para uma primeira execução segura em uma frota de hosts
Um comando `ansible` ad-hoc executa um módulo em um ou mais hosts sem precisar de playbook; combinado com `--check --diff` e um `--limit` restrito, permite que um agente veja o que uma mudança faria na frota antes de aplicá-la.
-
Automatizando o z/OS com o z/OSMF: as APIs REST de jobs, datasets e arquivos
O z/OSMF expõe jobs, datasets e arquivos z/OS UNIX como recursos HTTPS/REST comuns, o que o torna a interface do sistema mais adequada para agentes. As requisições exigem o cabeçalho personalizado X-CSRF-ZOSMF-HEADER (as que alteram estado são rejeitadas sem ele), e as respostas usam códigos de status HTTP padrão em vez de texto de mensagens 3270.
-
Timers do systemd como substituto do cron: OnCalendar, Persistent= e RandomizedDelaySec
Uma unidade .timer do systemd combinada com um .service do tipo oneshot pode substituir uma entrada do crontab e ainda executa tarefas perdidas após períodos de inatividade e distribui a carga com atrasos aleatórios em vários hosts. Esta metodologia cria, valida e ativa esse par de unidades e explica o que Persistent= e RandomizedDelaySec= realmente fazem.
-
Usar o SMIT como gerador de comandos em vez de sistema de menus
Os menus do smit/smitty acabam por executar comandos comuns do AIX, e a ferramenta foi feita para mostrar quais: a janela de saída exibe o comando montado, e smit.log/smit.script registram cada comando e suas flags exatas, com data e hora. Ler o smit.script depois de uma tarefa feita pelos menus é uma forma rápida de descobrir o comando não interativo equivalente.
-
Atualizando o FreeBSD: freebsd-update para o sistema base, pkg upgrade para pacotes e pkg audit para vulnerabilidades conhecidas
O FreeBSD separa a aplicação de patches em duas ferramentas independentes: freebsd-update fetch/install para o sistema base (com upgrade -r para troca de release maior) e pkg upgrade para os pacotes instalados. O pkgbase, que instala o próprio sistema base como pacotes do pkg(8), está documentado como experimental no FreeBSD 14 e como technology preview no FreeBSD 15.0, ainda sem ser o caminho padrão.
-
Executar comandos administrativos do Linux de forma não interativa em agentes autônomos
Comportamentos padrão interativos — um paginador, um prompt de confirmação, um locale que reformata números, um pedido de senha do sudo sem terminal para respondê-lo — são as causas mais comuns de travamentos e de saídas mal interpretadas em sessões autônomas de agentes no Linux. Este artigo lista as flags e variáveis de ambiente que desativam cada um deles.
-
Domínios do launchd: escolher entre LaunchAgent e LaunchDaemon e carregá-lo com o launchctl
LaunchAgents e LaunchDaemons ficam em diretórios diferentes, rodam em domínios distintos do launchd e são gerenciados com os subcomandos modernos bootstrap/bootout/enable/kickstart/print, e não com o par obsoleto load/unload. Esta metodologia mostra como escolher o domínio correto, escrever um plist mínimo e verificar o estado.
-
Armazenar segredos para scripts não supervisionados: systemd credentials, DPAPI, keychain do macOS — e o que não fazer
Cada sistema operacional tem um mecanismo para entregar um segredo a um script sem usar variável de ambiente nem argumento de linha de comando, que qualquer processo vizinho ou log pode ler: LoadCredential= no systemd, DPAPI no Windows (via Export-Clixml ou SecretManagement) e o keychain do macOS com security find-generic-password.
-
Detectar o sistema operacional a partir de um script: uname, os-release, sw_vers, oslevel e uma ordem de fallback
Um script portátil precisa de uma forma confiável de ramificar conforme o sistema operacional e a versão antes de executar um comando específico de SO dos outros artigos desta série. Esta metodologia define uma ordem de fallback, da fonte mais específica e confiável até um palpite de último recurso, para shells POSIX e PowerShell.
-
SSH known_hosts e verificação da chave do host em automação: ssh-keyscan mais uma verificação fora de banda
Uma automação que se conecta por SSH ainda precisa verificar a chave do host do servidor; o ssh-keyscan sozinho apenas coleta uma chave, sem provar que ela é autêntica. StrictHostKeyChecking=accept-new, HashKnownHosts e registros SSHFP tratam, cada um, de uma parte diferente de fazer isso com segurança, sem prompt interativo.
-
Administração do SUSE Linux com zypper: refresh, patch, update e dup, e execuções não interativas
O zypper separa em quatro comandos distintos a atualização dos metadados dos repositórios, a instalação de patches oficiais, a atualização de pacotes individuais e a atualização completa da distribuição. Saber qual usar, como executá-lo sem supervisão, como achar processos que ainda usam arquivos apagados após uma atualização e como fixar a versão de um pacote evita que um agente quebre um host SUSE.
-
O firewall PF no FreeBSD: testar o pf.conf com pfctl -n antes de carregá-lo e reversão agendada contra bloqueio do SSH
As regras do pf.conf giram em torno de uma política padrão de pass/block e de âncoras opcionais para anexar sub-conjuntos de regras, e só devem ser carregadas com pfctl -f depois de o pfctl -nf as analisar sem carregá-las. Como um conjunto de regras errado pode derrubar a própria sessão SSH usada para aplicá-lo, agendar uma reversão automática com at(1) antes de carregar as novas regras é um padrão de segurança comum (não é um recurso do PF) para testar mudanças em um host FreeBSD remoto.
-
Executar apt e dpkg de forma não interativa no Debian e no Ubuntu sem travar em prompts
Uma execução de apt-get ou dpkg em script pode parar numa pergunta do debconf, numa pergunta sobre arquivo de configuração modificado ou num lock do dpkg retido. Definir DEBIAN_FRONTEND, usar as opções confold/confdef adequadas e pré-configurar as respostas do debconf faz com que a instalação termine ou falhe de forma explícita.
-
Executar o Homebrew de forma não interativa em um agente de build: NONINTERACTIVE, variáveis de ambiente e Brewfile
O instalador do Homebrew, o comportamento de atualização automática e de analytics e as versões das fórmulas podem ser controlados sem prompts em um runner de CI, e um Brewfile torna o conjunto instalado reproduzível entre runners.
-
Instalação autônoma do RHEL com um arquivo Kickstart
Um arquivo Kickstart conduz a instalação do RHEL, Rocky Linux ou AlmaLinux sem nenhuma interação, combinando comandos de uma linha com scriptlets %pre e %post. Esta metodologia mostra como validar o arquivo antes do uso, passá-lo no boot e manter segredos fora de um arquivo que muitas vezes é servido sem autenticação.
-
Configurar o unattended-upgrades para aplicar patches de segurança automaticamente no Debian e no Ubuntu
O unattended-upgrades aplica atualizações de pacotes de forma agendada, com dois arquivos: 20auto-upgrades (se e com que frequência) e 50unattended-upgrades (quais origens e se deve reiniciar). Testar com --dry-run --debug antes de ativar em produção evita reinicializações inesperadas ou atualizações aplicadas pela metade.
Legível por máquina: JSON