Muito além do chmod: O poder oculto do setfacl e getfacl no Linux

O sistema de permissões padrão do Linux (Dono, Grupo, Outros) é robusto, mas extremamente rígido. Imagine o seguinte cenário: você tem um diretório de backups do banco de dados. O dono é o usuário informix e o grupo é dba. Agora, a equipe de auditoria pede acesso de somente leitura a essa pasta.

Você não pode mudar o dono. Você não quer colocar os auditores no grupo dba (dando a eles poderes demais). E você definitivamente não vai rodar um chmod 777. O que você faz?

A resposta está nas ACLs (Access Control Lists), gerenciadas pelos comandos subestimados setfacl e getfacl.

1. Permissões Cirúrgicas (O Básico)

O setfacl permite adicionar permissões granulares para usuários ou grupos específicos, sem alterar a estrutura original do arquivo.

Para dar acesso de leitura e execução ao usuário auditor na pasta /backups:

setfacl -m u:auditor:rx /backups

Para verificar como ficou, usamos o getfacl:

getfacl /backups

Nota: Ao listar com ls -l, você notará um sinal de mais (+) no final das permissões (ex: drwxr-x---+), indicando que existem ACLs ativas ali.

2. A Mágica da Herança (Default ACLs)

Este é o recurso que resolve o pesadelo de diretórios compartilhados. Normalmente, quando vários usuários criam arquivos na mesma pasta, os arquivos nascem com as permissões do umask do usuário criador, bloqueando o acesso dos colegas.

Com o setfacl, você pode definir uma ACL Padrão (Default). Qualquer arquivo ou pasta criada ali dentro herdará essas permissões automaticamente!

setfacl -d -m g:desenvolvedores:rwx /var/www/html

A flag -d (default) garante que a partir de agora, não importa quem crie o arquivo, o grupo desenvolvedores sempre terá acesso total.

3. O Truque Extraordinário: Backup e Restauração de Permissões

Aqui está o segredo que salva carreiras. Imagine que um script mal configurado (ou um erro humano) executou um chmod -R 777 /etc ou /var. O servidor está comprometido e os serviços vão parar de iniciar por falha de segurança.

Se você conhece o getfacl, você pode fazer um backup completo de todas as permissões de uma árvore de diretórios antes de fazer manutenções arriscadas:

getfacl -R /etc > /root/permissoes_etc_backup.txt

O comando acima lê recursivamente (-R) as permissões, donos e grupos de todos os arquivos e salva em um arquivo de texto. Se o desastre acontecer e as permissões forem bagunçadas, você restaura tudo com um único comando:

setfacl --restore=/root/permissoes_etc_backup.txt

Em segundos, cada arquivo volta a ter exatamente o dono, grupo e permissão (chmod) que tinha antes do desastre. É uma máquina do tempo para o sistema de arquivos!

Segurança e Controle Absoluto

A gestão de acessos em servidores críticos não permite improvisos. Dominar as ACLs do Linux é essencial para manter a conformidade e a segurança dos dados. Na AJMSolutions, aplicamos políticas de acesso de privilégio mínimo (PoLP) utilizando os recursos mais avançados do sistema operacional para proteger o seu banco de dados.

O Raio-X do Linux: Por que o comando 'strace' é a arma secreta dos Sysadmins

Você já passou pela situação de iniciar um serviço, ele falhar silenciosamente, e os arquivos de log em /var/log/ estarem completamente vazios? Ou pior: um processo do banco de dados congela do nada e não consome CPU, ficando em estado de "espera fantasma".

Quando as ferramentas tradicionais falham, os Sysadmins e DBAs seniores recorrem a uma ferramenta que muitos subestimam ou têm medo de usar devido à quantidade de informações que ela gera: o comando strace.

O que é o strace?

O strace (System Call Tracer) é um utilitário de diagnóstico, instrução e depuração no Linux. Ele intercepta e registra as "chamadas de sistema" (system calls) que um processo faz ao Kernel do Linux, bem como os sinais que o processo recebe.

Em termos simples: se um programa tenta abrir um arquivo, ler uma rede, alocar memória ou se conectar a um socket, o strace mostra exatamente o que ele pediu e qual foi a resposta do Kernel (como um erro de "Permissão Negada" ou "Arquivo não encontrado").

Exemplos Práticos de Sobrevivência

A saída padrão do strace pode ser assustadora, mas dominando algumas flags, ele se torna o seu melhor amigo:

• Descobrir por que um processo travou:
  strace -p
  Anexa o strace a um processo que já está rodando. Se ele estiver travado tentando ler um arquivo de rede inacessível, você verá a chamada read() ou connect() pendurada na tela.
• Onde este programa está procurando o arquivo de configuração?
  strace -e trace=open,openat comando_aqui
  Filtra a saída para mostrar apenas as tentativas de abertura de arquivos. Excelente para descobrir qual .conf um serviço obscuro está tentando ler durante a inicialização.
• Seguir processos filhos (Forks):
  strace -f -p
  Muitos serviços (como Apache, Nginx ou bancos de dados) criam processos filhos. A flag -f garante que o strace acompanhe todos eles, não apenas o processo pai.
• Criar um relatório de gargalos (Profiling):
  strace -c -p
  Em vez de mostrar um fluxo infinito de texto, a flag -c conta o tempo gasto em cada chamada de sistema e exibe uma tabela limpa no final. Perfeito para descobrir se a lentidão do seu banco de dados é culpa de I/O de disco ou de rede.

O Caso Clássico do "Permission Denied" Invisível

Imagine que um script falha, mas não diz o porquê. Rodando strace ./seu_script.sh, você pode procurar na saída por algo como EACCES (Permission denied). O strace revelará o caminho exato do arquivo ou diretório que está bloqueando a execução, permitindo que você corrija o chmod ou chown cirurgicamente, sem precisar dar permissão 777 para tudo.

Troubleshooting no nível do Kernel

Não dependa de adivinhações quando um sistema crítico falha. O uso de ferramentas de baixo nível como o strace é o que garante diagnósticos precisos e rápidos. Na AJMSolutions, utilizamos as técnicas mais avançadas de depuração do Linux para manter a performance e a estabilidade dos seus ambientes de banco de dados.

O Botão de Pânico do Linux: Dominando as Teclas 'Magic SysRq'

Todo administrador de sistemas já passou por isso: o servidor Linux sofre um pico de I/O ou um vazamento de memória tão severo que o sistema congela completamente. O SSH para de responder, o console não aceita comandos e até o ping começa a falhar. Qual é o seu próximo passo? O temido "Hard Reset" (desligar no botão)?

Se você gerencia bancos de dados, sabe que um desligamento forçado pode corromper blocos de dados e destruir horas de trabalho. É exatamente para evitar essa catástrofe que o Kernel do Linux possui um recurso oculto e poderoso: o Magic SysRq.

O que é o Magic SysRq?

O Magic SysRq é um mecanismo de "fuga" (escape) embutido diretamente no Kernel do Linux. Ele permite que você envie comandos de baixo nível para o sistema operacional, ignorando completamente o espaço do usuário (user space). Mesmo que o sistema esteja travado e não consiga abrir um terminal, o Kernel ainda escutará esses comandos.

Como habilitar o recurso

Por motivos de segurança, muitas distribuições modernas vêm com esse recurso parcialmente desabilitado. Para ativá-lo totalmente de forma temporária, você pode usar o comando:

sysctl -w kernel.sysrq=1

Para torná-lo permanente, adicione kernel.sysrq = 1 ao arquivo /etc/sysctl.conf.

A Sequência Salva-Vidas: R E I S U B

Se você estiver fisicamente na frente do servidor (ou usando um console iLO/iDRAC), a combinação de teclas é Alt + SysRq + . A sequência mnemônica mais famosa para reiniciar um servidor travado com segurança é a palavra REISUB (muitos memorizam com a frase "Raising Elephants Is So Utterly Boring").

Você deve pressionar e segurar Alt + SysRq e, lentamente, digitar as letras, dando alguns segundos entre cada uma:

• R (Raw): Retoma o controle do teclado do servidor X (interface gráfica, se houver).
• E (tErminate): Envia o sinal SIGTERM para todos os processos (exceto o init/systemd), pedindo que eles fechem graciosamente.
• I (kIll): Envia o sinal SIGKILL para todos os processos que se recusaram a fechar no passo anterior.
• S (Sync): O passo mais importante para DBAs! Força a gravação de todos os dados que estão na memória RAM (cache) para os discos físicos.
• U (Unmount): Remonta todos os sistemas de arquivos em modo "Somente Leitura" (Read-Only), evitando corrupção durante o boot.
• B (Boot): Finalmente, reinicia a máquina imediatamente.

E se eu só tiver acesso via SSH?

Se o servidor estiver travado, mas você ainda tiver uma sessão SSH ou um script rodando como root que consiga executar comandos básicos, você não precisa do teclado físico. Você pode acionar o SysRq escrevendo diretamente no sistema de arquivos virtual do Kernel (o /proc).

Para forçar um "Sync" e depois um "Reboot" remotamente, você executaria:

echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger

Recuperação de Desastres levada a sério

Conhecer os atalhos do Kernel pode ser a diferença entre um reinício rápido e a perda total de um banco de dados. Na AJMSolutions, nossa expertise em infraestrutura garante que seus sistemas tenham as melhores práticas de contingência e recuperação aplicadas em todos os níveis.

O Guia Definitivo do Comando 'screen': Multiplexação para Sysadmins

Em ambientes de missão crítica, perder a conexão SSH durante a execução de um script de backup, uma reestruturação de disco ou uma compilação de kernel é um verdadeiro pesadelo. É aqui que entra o GNU Screen.

Muito mais do que um simples utilitário para manter processos rodando em segundo plano, o screen é um multiplexador de terminal completo. Ele permite criar múltiplas janelas dentro de uma única sessão SSH, dividir a tela, compartilhar o terminal com outros usuários e manter um histórico de logs impecável.

Neste guia definitivo, vamos explorar todas as facetas deste comando essencial para qualquer Sysadmin ou DBA Sênior.

1. O Ciclo de Vida Básico (Attach / Detach)

O conceito fundamental do screen é a capacidade de "desconectar" (detach) de uma sessão, deixando os processos rodando no servidor, e "reconectar" (attach) mais tarde, de qualquer outro lugar.

• Iniciar uma nova sessão: Basta digitar screen no terminal.
• Desconectar (Detach): Pressione Ctrl + a, solte as teclas, e pressione d. Você voltará ao terminal original, mas a sessão continuará viva no background.
• Listar sessões ativas: screen -ls ou screen -list.
• Reconectar (Attach): screen -r (onde PID é o número mostrado na listagem).

2. Gestão Avançada de Sessões (Linha de Comando)

Para uso profissional, depender de PIDs gerados aleatoriamente não é eficiente. O poder real está nas flags de inicialização:

• screen -S nome_da_sessao : Cria uma sessão nomeada (ex: screen -S backup_banco). Para reconectar, basta usar screen -r backup_banco.
• screen -d -r nome_da_sessao : O comando salva-vidas. Se a sua internet cair e a sessão ficar "presa" (Attached) no servidor, este comando força a desconexão da sessão fantasma e a reconecta no seu terminal atual.
• screen -D -R nome_da_sessao : O "God Mode". Se a sessão existir, ele a rouba e reconecta. Se não existir, ele cria uma nova com esse nome. Excelente para colocar em scripts de login.
• screen -x nome_da_sessao : Compartilhamento de tela (Multi-display). Permite que dois usuários SSH diferentes se conectem à mesma sessão simultaneamente. O que um digita, o outro vê em tempo real. Perfeito para pair programming ou treinamento.
• screen -L : Inicia a sessão forçando a gravação de todo o output do terminal em um arquivo chamado screenlog.0 no diretório atual. Ideal para auditoria de scripts longos.

3. Dominando as Janelas Internas (O Prefixo Ctrl+a)

Dentro de uma sessão do screen, todos os comandos internos começam com o prefixo Ctrl + a. Após pressionar essa combinação, você digita uma segunda tecla para executar a ação:

• Ctrl+a seguido de c : Cria uma nova janela (Create).
• Ctrl+a seguido de n ou p : Navega para a próxima janela (Next) ou a anterior (Previous).
• Ctrl+a seguido de " (aspas duplas) : Abre um menu interativo listando todas as janelas abertas para você escolher.
• Ctrl+a seguido de A (maiúsculo) : Permite renomear a janela atual. Fundamental para não se perder quando se tem 10 janelas abertas.
• Ctrl+a seguido de k : Mata (Kill) a janela atual.
• Ctrl+a seguido de \ : Mata todas as janelas e encerra a sessão do screen completamente.

4. Divisão de Tela (Split Screen)

Você não precisa do tmux para dividir a tela. O screen faz isso nativamente, permitindo monitorar logs de um lado e digitar comandos do outro.

• Ctrl+a seguido de S (maiúsculo) : Divide a tela horizontalmente.
• Ctrl+a seguido de | (pipe) : Divide a tela verticalmente.
• Ctrl+a seguido de Tab : Move o cursor para a próxima região dividida. (Nota: a nova região nasce em branco. Você precisa pressionar Ctrl+a c para criar um terminal nela ou Ctrl+a " para puxar uma janela existente).
• Ctrl+a seguido de X (maiúsculo) : Fecha a região atual.
• Ctrl+a seguido de Q (maiúsculo) : Fecha todas as outras regiões, deixando apenas a atual em tela cheia.

5. Modo de Cópia e Scrollback (Rolagem de Tela)

Um dos maiores choques para iniciantes é descobrir que a rodinha do mouse ou o Page Up não funcionam dentro do screen. Para rolar a tela para cima e ver o histórico de um log, você precisa entrar no "Copy Mode":

1. Pressione Ctrl+a seguido de [ (ou ESC).
2. Agora você pode usar as setas do teclado, Page Up e Page Down para navegar pelo histórico.
3. Para copiar um texto: mova o cursor até o início do texto, pressione Espaço, mova o cursor até o final do texto, e pressione Espaço novamente.
4. Para colar o texto copiado: pressione Ctrl+a seguido de ].

6. Segurança: Bloqueando a Sessão

Se você precisa se afastar da mesa, mas quer deixar o processo rodando na tela de forma segura, use:

Ctrl+a seguido de x : Isso bloqueia a sessão do screen. Para desbloquear, será exigida a senha do usuário do sistema operacional.

7. O Arquivo de Configuração Profissional (.screenrc)

O comportamento padrão do screen é muito espartano. Para transformá-lo em uma ferramenta moderna, crie um arquivo chamado .screenrc no diretório home do seu usuário (~/.screenrc) e adicione as seguintes linhas:

# Desativa a mensagem de boas-vindas
startup_message off

# Aumenta o buffer de histórico para 10.000 linhas
defscrollback 10000

# Cria uma barra de status visual na parte inferior da tela
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %Y-%m-%d %{W}%c %{g}]'

# Atalhos rápidos para alternar janelas com F1 e F2
bindkey -k k1 prev
bindkey -k k2 next

Com esse arquivo, seu screen passará a exibir uma barra verde na parte inferior mostrando o nome do servidor, as abas abertas (destacando a aba atual em vermelho) e um relógio no canto direito.

A infraestrutura não perdoa falhas

Ferramentas como o screen garantem que processos críticos sobrevivam a instabilidades de rede. Na AJMSolutions, aplicamos as melhores práticas de administração de sistemas para garantir que seus bancos de dados e servidores operem com resiliência máxima, 24 horas por dia.

O Segredo Extraordinário do Comando 'cal' no Linux

No dia a dia da administração de sistemas Linux e bancos de dados, vivemos imersos em comandos complexos, scripts de automação e monitoramento de performance. No meio de tanta complexidade, utilitários clássicos e minimalistas acabam sendo subestimados. Um dos maiores exemplos disso é o comando cal.

A maioria dos profissionais digita apenas cal no terminal para dar uma olhada rápida no mês atual. Mas este pequeno utilitário esconde truques de produtividade e um rigor histórico impressionante.

Exemplos Práticos que Poucos Usam

Antes de irmos para o segredo extraordinário deste comando, aqui estão algumas flags que deveriam estar no seu cinto de utilidades:

• cal -3 : Mostra o mês anterior, o atual e o próximo lado a lado. Excelente para planejar janelas de manutenção que viram o mês.
• cal -y : Exibe o calendário do ano inteiro atual na sua tela.
• cal 2026 : Exibe o calendário completo de um ano específico do futuro (ou do passado).
• cal -j : Mostra o calendário no formato "Juliano" (dia do ano de 1 a 365). Muito útil para DBAs que precisam cruzar dados com logs de banco de dados que usam esse formato de data.
• ncal -e 2025 : (Usando a variação ncal) Calcula e mostra exatamente a data da Páscoa de qualquer ano.

O Segredo Extraordinário: O Mês que Perdeu 11 Dias

O Unix é famoso por sua precisão, e o comando cal leva isso ao extremo da precisão histórica. Se você quer ver algo que surpreende até os Sysadmins mais experientes, abra o seu terminal agora e digite exatamente isso:

$ cal 9 1752

Olhe atentamente para o resultado. Você notará que o mês de setembro de 1752 pula do dia 2 diretamente para o dia 14! Faltam 11 dias no calendário.

Isso é um bug? Não! É um recurso de precisão histórica. Em setembro de 1752, o Império Britânico (e suas colônias) finalmente abandonou o Calendário Juliano e adotou o Calendário Gregoriano. Para alinhar as datas com o resto da Europa, o Rei George II ordenou que 11 dias fossem simplesmente apagados da existência. As pessoas foram dormir na noite de 2 de setembro e acordaram na manhã de 14 de setembro.

Os criadores do Unix decidiram que o comando cal deveria refletir a realidade histórica exata, tornando-o não apenas uma ferramenta de TI, mas um pequeno museu digital da história humana.

Conhecimento é a base da infraestrutura

Dominar os fundamentos do sistema operacional é o que diferencia um operador de um verdadeiro Engenheiro de Sistemas. Na AJMSolutions, aplicamos esse mesmo nível de rigor e conhecimento profundo para otimizar e proteger os seus bancos de dados.

Migração de Usuários no Linux: Como transferir contas e recriar diretórios

A migração de servidores Linux é uma tarefa rotineira para administradores de infraestrutura. Copiar os dados é a parte fácil; o verdadeiro desafio é migrar os usuários garantindo que as senhas, as permissões e os UIDs/GIDs (User e Group IDs) permaneçam exatamente os mesmos no novo ambiente.

Neste artigo, vou mostrar como extrair e migrar usuários comuns (UID > 1000) de um servidor de produção para um ambiente de testes, lidando com o desafio do arquivo /etc/shadow e recriando os diretórios home de forma automatizada e segura.

O Desafio do /etc/shadow

Para migrar os usuários, precisamos copiar as informações de três arquivos cruciais: /etc/passwd, /etc/group e /etc/shadow.

Filtrar o passwd e o group é simples, pois ambos possuem a coluna de UID/GID. Podemos usar o awk para pegar apenas os usuários criados por nós (geralmente com ID maior que 1000) e ignorar usuários de sistema (como o nobody, que costuma ter o ID 65534):

# Exportando usuários e grupos comuns
awk -F: '$3 > 1000 && $3 != 65534' /etc/passwd > passwd.mig
awk -F: '$3 > 1000 && $3 != 65534' /etc/group  > group.mig

O problema surge no /etc/shadow. Ele armazena os hashes das senhas, mas não possui uma coluna de UID. Como saber quais linhas exportar?

A Solução: Filtragem Cruzada (One-Liner)

A lógica correta é usar o /etc/passwd para descobrir os logins (nomes de usuário) que têm UID > 1000, e então usar essa lista para "pescar" as linhas correspondentes dentro do /etc/shadow. Podemos fazer isso em um único comando elegante usando awk e grep:

# Extrai os logins do passwd e usa como filtro para o shadow
awk -F: '$3 > 1000 && $3 != 65534 { print $1 }' /etc/passwd | grep -F -f - /etc/shadow > shadow.mig

Com os arquivos passwd.mig, group.mig e shadow.mig em mãos, basta fazer o append (>>) deles nos respectivos arquivos do novo servidor.

Recriando os Diretórios /home com Segurança

Após importar os usuários no novo servidor, eles ainda não terão seus diretórios pessoais (/home/usuario). Fazer isso manualmente é inviável. Abaixo, apresento um script Bash robusto para automatizar essa criação.

Este script não apenas cria a pasta, mas verifica se o usuário realmente existe, copia os arquivos ocultos padrão do sistema (/etc/skel) e garante que o UID e GID fiquem corretos.

#!/bin/bash

# Supondo que você salvou a lista de logins em um arquivo chamado 'users.lista'
while IFS= read -r user; do
    # 1. Garante que o usuário existe no novo sistema antes de prosseguir
    if ! id "$user" &>/dev/null; then
        echo "⚠️ Usuário $user não existe neste sistema. Pulando."
        continue
    fi

    home="/home/$user"

    # 2. Cria o diretório home se não existir e copia o esqueleto padrão
    if [ ! -d "$home" ]; then
        mkdir -p "$home"
        cp -a /etc/skel/. "$home"/
    fi

    # 3. Ajusta o proprietário usando os IDs reais e define permissões seguras
    chown "$(id -u "$user")":"$(id -g "$user")" "$home"
    chmod 755 "$home"

    echo "✅ Home de $user preparado com sucesso em $home"
done < users.lista

Conclusão

Migrar usuários no Linux não precisa ser uma dor de cabeça e você não precisa de ferramentas de terceiros. Dominar o uso do awk para manipulação de colunas e a criação de loops defensivos no Bash garante uma migração limpa, rápida e sem falhas de segurança.

3 Segredos Obscuros do Linux que todo DBA e Sysadmin Sênior deveria conhecer

Mesmo que você administre servidores Linux há mais de uma década, o pinguim sempre guarda segredos nas profundezas do seu kernel e do seu shell. Muitas ferramentas que consideramos indispensáveis podem ser substituídas por recursos nativos que quase ninguém conhece.

Se você é um Sysadmin ou DBA Sênior lidando com ambientes de missão crítica, aqui estão 3 segredos obscuros do Linux que vão mudar a forma como você trabalha.

1. O Scanner de Portas Invisível (O segredo do /dev/tcp)

Você está em um servidor de produção extremamente restrito. O firewall bloqueia instalações, não há telnet, não há nc (netcat) e nem nmap. Você precisa testar urgentemente se a porta do banco de dados (ex: 1521 do Oracle ou 9088 do Informix) está aberta em outro servidor.

O que quase ninguém sabe é que o próprio Bash possui um pseudo-dispositivo de rede embutido. Você não precisa de nenhuma ferramenta externa para abrir sockets TCP/UDP.

# Testando se a porta 9088 está aberta no IP 192.168.1.50 usando apenas o Bash
if timeout 2 bash -c 'echo > /dev/tcp/192.168.1.50/9088' 2>/dev/null; then
    echo "🚨 Porta ABERTA e respondendo!"
else
    echo "❌ Porta FECHADA ou bloqueada por Firewall."
fi

Como funciona: O Bash intercepta qualquer redirecionamento para /dev/tcp/HOST/PORTA e tenta abrir um socket de rede real. É a ferramenta de troubleshooting perfeita para ambientes "pelados" (como containers Docker minimalistas).

2. A Jaula Temporária (systemd-run)

Imagine o cenário: você precisa rodar um script de backup massivo (como um tar gigante ou uma exportação de dados), mas o servidor está em horário de pico. Se o seu script consumir muita CPU ou estourar o I/O, o banco de dados vai sofrer.

A maioria dos administradores tenta usar o nice ou ionice, que são ineficientes em servidores modernos. O segredo moderno é usar o systemd-run para criar um Cgroup (Control Group) temporário e descartável, limitando os recursos do comando "on-the-fly", sem editar nenhum arquivo de configuração.

# Executa o script de backup limitando-o a usar no máximo 1 CPU core (100%) 
# e no máximo 2GB de RAM. Se passar de 2GB, o Linux mata apenas o script.
systemd-run --scope -p CPUQuota=100% -p MemoryMax=2G ./meu_backup_pesado.sh

O resultado: O seu script roda em uma "jaula" invisível. O banco de dados continua com acesso total ao resto do servidor, e assim que o script termina, a jaula deixa de existir automaticamente.

3. O Reboot de 5 Segundos (Bypass de BIOS/Hardware com kexec)

Se você administra servidores bare-metal parrudões (com 96 CPUs, múltiplos nós NUMA e centenas de Gigabytes de RAM), sabe que um simples reboot pode demorar de 10 a 15 minutos. O servidor perde um tempo enorme fazendo a checagem de memória (POST), inicializando controladoras RAID e placas HBA.

E se você pudesse reiniciar o Linux sem reiniciar o hardware?

Isso é possível com o kexec (Kernel Execution). Ele permite que o kernel atual carregue um novo kernel diretamente na memória e passe o controle para ele, ignorando completamente a BIOS/UEFI.

# 1. Instale a ferramenta (se não tiver)
sudo apt install kexec-tools  # Ubuntu/Debian
sudo yum install kexec-tools  # RHEL/Oracle Linux

# 2. Carregue o kernel atual na memória para o próximo boot
sudo kexec -l /boot/vmlinuz-$(uname -r) \
           --initrd=/boot/initrd.img-$(uname -r) \
           --reuse-cmdline

# 3. Execute o "Reboot Quente" (Aviso: O servidor vai reiniciar IMEDIATAMENTE)
sudo systemctl kexec

O impacto: O tempo de downtime do seu servidor cai de 15 minutos para cerca de 10 a 15 segundos. Para ambientes de alta disponibilidade, isso é um divisor de águas na hora de aplicar patches de segurança no kernel.

Conclusão

O Linux é um ecossistema vasto. Dominar o /dev/tcp para troubleshooting de rede, o systemd-run para isolamento de recursos e o kexec para reboots ultrarrápidos são habilidades raras que separam os usuários avançados dos verdadeiros mestres do sistema operacional.

Qual desses três recursos você não conhecia e vai testar hoje mesmo?

Dominando o journalctl: Log Management Avançado para Sysadmins e DBAs

A transição do tradicional syslog para o systemd-journald mudou drasticamente a forma como gerenciamos logs no Linux. Para analistas de infraestrutura e DBAs que lidam com bancos de dados de missão crítica, como IBM Informix e PostgreSQL, o journalctl não é apenas um leitor de logs, mas uma ferramenta de diagnóstico de alta precisão.

Como o journald armazena logs em formato binário e indexado, ele permite consultas complexas, correlação de eventos e formatação estruturada que seriam impossíveis com arquivos de texto puro perdidos em /var/log.

Abaixo, exploramos técnicas avançadas para extrair o máximo do journalctl em ambientes de produção.

1. Filtragem Cirúrgica de Eventos

Em servidores com alta carga (dezenas de CPUs e alto I/O), ler logs sequencialmente é inviável. O verdadeiro poder do journalctl está nos seus metadados indexados.

Por Unidade de Serviço (Unit): Isole completamente os logs de um serviço específico, ignorando o ruído do sistema operacional.

# Acompanha em tempo real (tail) apenas os logs do banco
journalctl -u postgresql.service -f

Por Janela de Tempo: Evite o excesso de dados filtrando por períodos exatos. O journalctl entende linguagem natural e timestamps absolutos.

# Busca incidentes em uma janela específica de ontem
journalctl -u informix.service --since "2023-10-25 14:00:00" --until "2023-10-25 15:30:00"

# Busca o que aconteceu na última hora
journalctl --since "1 hour ago"

Por PID ou UID: Se você identificou um processo problemático (ex: um worker consumindo muita CPU), pode rastrear apenas o que aquele PID registrou.

journalctl _PID=4598
journalctl _UID=1001

2. Rastreamento de Boots e Kernel (Post-Mortem)

Quando um servidor reinicia inesperadamente, a primeira ação de um analista sênior é verificar o log do boot anterior e os eventos do kernel (OOM Killer, falhas de disco, etc).

# Lista todos os boots registrados no sistema com seus IDs
journalctl --list-boots

# Exibe os logs do boot que falhou (o boot anterior ao atual)
journalctl -b -1

# Exibe apenas mensagens do Kernel (similar ao dmesg) do boot atual
journalctl -k -b

3. Formatação de Saída para Automação e SIEM

Se você precisa integrar a análise de logs com scripts em Python, Bash ou enviar dados para um SIEM (como Splunk, ELK ou Datadog), a saída padrão em texto não é a ideal.

# Exporta todos os metadados do log em formato JSON estruturado
journalctl -u sshd.service -o json-pretty

# Mostra todos os campos indexados (excelente para descobrir variáveis para filtros)
journalctl -o verbose -n 5

4. Gerenciamento de Espaço e Retenção (Vacuuming)

Logs binários podem crescer rapidamente. Um administrador proativo não espera o disco encher; ele gerencia a retenção.

# Verifica o uso atual de disco pelo journal
journalctl --disk-usage

# Força a rotação e exclusão até que o diretório ocupe no máximo 1GB
journalctl --vacuum-size=1G

# Remove qualquer entrada de log mais antiga que 30 dias
journalctl --vacuum-time=30d

Dica de Ouro: Para tornar a retenção persistente, edite o arquivo /etc/systemd/journald.conf e ajuste os parâmetros SystemMaxUse= e SystemKeepFree=, reiniciando o serviço em seguida.

5. Bônus Prático: Automação de Alertas com Bash

Como DBAs seniores, não ficamos olhando para a tela esperando o erro acontecer; nós automatizamos a detecção. Abaixo, apresento modelos de scripts em Bash que utilizam o journalctl para buscar erros críticos nos últimos 10 minutos.

Estes scripts são ideais para serem agendados no cron e integrados com APIs de comunicação (como Slack ou Teams).

Monitorando PostgreSQL (Erros Fatais)

Queremos ser alertados imediatamente caso ocorram erros do tipo FATAL ou PANIC, que geralmente indicam queda de conexão em massa ou corrupção.

#!/bin/bash
# check_pg_errors.sh

# Busca logs dos últimos 10 minutos, remove paginação e filtra erros críticos
CRITICAL_EVENTS=$(journalctl -u postgresql.service --since "10 minutes ago" --no-pager | grep -iE "FATAL|PANIC")

if [ -n "$CRITICAL_EVENTS" ]; then
    echo "🚨 ALERTA CRÍTICO: Erros detectados no PostgreSQL!"

    # Exemplo de integração via Webhook com o Slack
    PAYLOAD=$(jq -n --arg text "🚨 *Erro Crítico no PostgreSQL:*\n$CRITICAL_EVENTS" '{text: $text}')
    curl -X POST -H 'Content-type: application/json' --data "$PAYLOAD" https://hooks.slack.com/services/SEU/WEBHOOK/AQUI
fi

Monitorando IBM Informix (Asserts e Logical Logs)

Para ambientes rodando Informix (como a versão 14.10), os pesadelos de qualquer DBA envolvem Assert Failed (falhas internas do motor) ou o esgotamento do espaço de logs lógicos.

#!/bin/bash
# check_ifx_errors.sh

# Filtra o journal do serviço Informix buscando falhas críticas
IFX_ALERTS=$(journalctl -u informix.service --since "10 minutes ago" --no-pager | grep -iE "Assert Failed|Logical Log Files are Full")

if [ -n "$IFX_ALERTS" ]; then
    echo "🚨 ALERTA CRÍTICO: Anomalia detectada no motor do Informix!"

    # Dispara coleta de dados de diagnóstico automaticamente antes que o ambiente trave
    /opt/informix/bin/onstat -a > /tmp/onstat_assert_$(date +%Y%m%d_%H%M).out

    # Aqui você pode adicionar o mesmo curl do Slack mostrado acima
fi

Por que usar o journalctl no script e não ler o arquivo online.log direto?
Porque o journalctl lida nativamente com a janela de tempo (--since "10 minutes ago"). Se você fizesse um grep direto em um arquivo de texto, teria que criar uma lógica complexa com awk ou sed para isolar apenas as linhas geradas recentemente. O systemd faz esse trabalho pesado para você com precisão absoluta.