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.

Alta Disponibilidade no Oracle SE2: Alternativas ao Data Guard

Quando falamos de bancos de dados de missão crítica, a primeira palavra que vem à mente dos gestores de TI é: Disponibilidade. No ecossistema Oracle, a solução definitiva para Disaster Recovery (DR) e Alta Disponibilidade (HA) é o Oracle Data Guard. No entanto, há um detalhe crucial: o Data Guard é um recurso exclusivo da versão Enterprise Edition (EE).

Para muitas empresas, o custo de licenciamento do Oracle EE é proibitivo, tornando o Oracle Standard Edition 2 (SE2) a escolha lógica e de excelente custo-benefício. Mas como proteger os dados e garantir a continuidade do negócio no SE2 sem o Data Guard? É exatamente isso que vamos explorar neste artigo.

O Desafio do Oracle SE2

O Oracle SE2 é um banco de dados extremamente robusto, capaz de lidar com cargas de trabalho intensas. O desafio não está na performance, mas na replicação nativa. Sem o Data Guard, não temos o transporte e a aplicação automática de Redo Logs para um servidor standby de forma nativa e "out-of-the-box".

Felizmente, a engenharia de infraestrutura nos oferece alternativas sólidas. Abaixo, detalho as três principais estratégias que implementamos para garantir HA em ambientes SE2.

1. Log Shipping Customizado (A Abordagem "Mão na Massa")

Para empresas que buscam uma solução de custo zero em licenciamento de terceiros, a criação de um mecanismo de Log Shipping customizado é a saída. Como DBAs Sêniores, podemos simular o comportamento básico do Data Guard através de scripts (Shell Script/Bash).

• Como funciona: O banco de dados primário é configurado em modo ARCHIVELOG. Um script é agendado (via Cron) para copiar os Archive Logs gerados para o servidor secundário (via rsync ou scp). No servidor secundário, o banco fica em estado de Mount (modo de recuperação), e outro script aplica esses archives continuamente.
• Vantagem: Custo zero de software.
• Desvantagem: O RPO (Recovery Point Objective) e o RTO (Recovery Time Objective) são maiores. Se o servidor principal cair, os dados gerados entre o último archive transferido e a queda podem ser perdidos, e o failover é um processo manual.

2. Soluções de Terceiros (Ex: Dbvisit Standby)

Quando o negócio exige um RPO e RTO muito baixos, mas o orçamento ainda não comporta o Oracle EE, a melhor alternativa do mercado é utilizar softwares de replicação de terceiros homologados para Oracle SE2. O mais famoso e confiável deles é o Dbvisit Standby.

• Como funciona: Ele atua exatamente onde o Data Guard faria falta. Ele captura, transfere e aplica os logs de forma automatizada, segura e comprimida. Além disso, oferece uma interface gráfica para monitoramento e permite realizar o Graceful Switchover (inversão de papéis entre primário e standby para manutenções) com poucos cliques.
• Vantagem: Confiabilidade enterprise, RPO de minutos (ou segundos) e facilidade de operação.
• Desvantagem: Exige aquisição de licença do software de terceiros (embora seja infinitamente mais barato que o upgrade para o Oracle EE).

3. Clusterização a Nível de Sistema Operacional (Pacemaker/Corosync)

Se o objetivo for apenas Alta Disponibilidade local (proteger contra a queima de uma placa-mãe ou falha de SO) e não um Disaster Recovery geográfico, podemos usar a clusterização do Linux.

• Como funciona: Dois servidores físicos (ou VMs) são conectados a um Storage Compartilhado (SAN/NAS). O banco de dados Oracle SE2 roda no Servidor A. Ferramentas como Pacemaker e Corosync monitoram a saúde do serviço. Se o Servidor A falhar, o cluster move o IP virtual (VIP) e monta o disco do storage no Servidor B, iniciando a instância do Oracle automaticamente.
• Vantagem: Failover automático sem perda de dados (pois o storage é o mesmo).
• Desvantagem: O storage compartilhado se torna o ponto único de falha (SPOF). Se o storage parar, o banco para.

Conclusão

Não ter o Oracle Data Guard não significa que seu banco de dados precisa ficar vulnerável. A escolha entre Log Shipping customizado, ferramentas como Dbvisit ou Clusterização de SO depende exclusivamente do orçamento da sua empresa e do tempo máximo que o seu negócio suporta ficar fora do ar (RTO).

Precisa de ajuda para desenhar a arquitetura do seu banco de dados?

A AJMSolutions é especialista em arquitetura, tuning e alta disponibilidade para ambientes de missão crítica (Oracle, Informix e PostgreSQL). Nós analisamos o seu cenário e implementamos a solução que protege seus dados sem estourar o seu orçamento de TI.

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.

Expandindo Horizontes: Minha Primeira Certificação Fortinet em Cibersegurança

Na área de tecnologia, a estagnação é o maior risco que um profissional pode correr. Durante anos, meu foco principal tem sido a arquitetura, alta disponibilidade e performance de bancos de dados de missão crítica (como IBM Informix e Oracle) e infraestrutura Linux.

No entanto, não podemos ignorar a realidade atual: os dados são o ativo mais valioso de qualquer empresa e o alvo principal dos cibercriminosos.

Não basta apenas garantir que o banco de dados seja rápido e tenha backups eficientes; é preciso entender profundamente o perímetro de rede que o protege. Por isso, decidi expandir meus horizontes e mergulhar no ecossistema de segurança da Fortinet, uma das líderes globais em cibersegurança.

Minha Primeira Certificação Fortinet

É com muita satisfação que compartilho a conquista da minha primeira certificação oficial da trilha de segurança: Introduction to the Threat Landscape 3.0.

Este módulo aprofunda o conhecimento sobre o cenário atual de ameaças, táticas de invasão, evolução dos malwares e como os cibercriminosos exploram vulnerabilidades na infraestrutura para chegar até o "pote de ouro": os servidores de banco de dados.

Introduction to the Threat Landscape 3.0

Emitido por Fortinet

Verificar Credencial no Credly

O que isso significa para os clientes da AJMSolutions?

A arquitetura de TI moderna exige uma visão holística. Quando um cliente confia a infraestrutura da sua empresa à AJMSolutions, ele não está contratando apenas um especialista em banco de dados ou Linux.

Ele está contando com um profissional que entende como as camadas de rede, firewalls (FortiGate) e políticas de segurança interagem com os servidores de dados. Isso nos permite desenhar topologias mais seguras, configurar auditorias (Audit Trails) de forma mais inteligente e garantir que a performance não comprometa a segurança (e vice-versa).

Este é apenas o primeiro passo na trilha da Fortinet. O aprendizado contínuo é a única forma de manter os ambientes de missão crítica verdadeiramente blindados.

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?

Maximizando a Performance do IBM Informix em Servidores Multi-Core com Afinidade de CPU e NUMA

Quando migramos bancos de dados de missão crítica para servidores modernos de grande porte, um erro comum é acreditar que "mais CPUs" significa automaticamente "mais performance". Na realidade, sem a configuração correta, adicionar processadores pode até piorar o desempenho do seu IBM Informix.

O grande vilão invisível em servidores multi-core modernos chama-se Latência NUMA (Non-Uniform Memory Access). Neste artigo, vamos entender como a Afinidade de CPU (CPU Affinity) no Informix pode resolver esse problema e extrair 100% do poder do seu hardware.

O Problema da Arquitetura NUMA

Em servidores com múltiplos processadores físicos (sockets), a memória RAM é dividida e conectada diretamente a cada processador. Isso cria os chamados "Nós NUMA".

Se uma thread do Informix (um Virtual Processor - VP) está rodando na CPU do Nó 0, mas precisa acessar dados que estão na memória RAM conectada ao Nó 1, ocorre o Cross-Node Memory Access. Esse tráfego passa pelo barramento de interconexão da placa-mãe, gerando latência e destruindo a performance de consultas pesadas.

Mapeando a Topologia do Servidor (Linux)

Antes de configurar o banco, precisamos entender o hardware. Vamos usar como exemplo um servidor robusto com 96 CPUs lógicas (2 sockets, 24 cores físicos por socket, com Hyper-Threading habilitado).

O primeiro passo é rodar o comando lscpu no Linux para mapear quais CPUs pertencem a quais nós NUMA:

# Verificando a topologia NUMA no Linux
lscpu | grep NUMA

Exemplo de Saída:

NUMA node(s):          2
NUMA node0 CPU(s):     0-23,48-71
NUMA node1 CPU(s):     24-47,72-95

Neste cenário, sabemos exatamente quais IDs de CPU pertencem a cada processador físico. Também sabemos que as CPUs de 48 a 95 são threads virtuais (Hyper-Threading), que geralmente evitamos para os VPs principais de CPU do banco de dados para garantir ciclos de clock dedicados.

Configurando a Afinidade no Informix (onconfig)

O IBM Informix (especialmente nas versões mais recentes, como a 14.10) possui um controle granular excelente sobre onde seus Virtual Processors vão rodar. Isso é feito através do parâmetro VPCLASS no arquivo onconfig.

Em vez de deixar o sistema operacional (Linux) jogar os processos do Informix de um lado para o outro (causando context switching e perda de cache L3), nós "amarramos" (pin) os VPs a CPUs específicas.

Exemplo Prático de Configuração:
Vamos alocar 24 VPs de CPU para o Informix, distribuindo a carga de forma inteligente e usando apenas núcleos físicos reais. Vamos definir a afinidade para usar as CPUs de 0 a 11 (Nó 0) e de 24 a 35 (Nó 1).

# Configuração no arquivo onconfig
# num=24 : Cria 24 Virtual Processors da classe CPU
# aff=(0-11,24-35) : Amarra os VPs aos núcleos físicos específicos
VPCLASS cpu,num=24,aff=(0-11,24-35)

Por que essa configuração é um divisor de águas?

1. Isolamento de Cache L3: Como o VP do Informix nunca muda de CPU, os dados que ele processa permanecem quentes no cache L3 do processador, acelerando leituras subsequentes.
2. Redução de Context Switching: O Linux não gasta recursos tentando balancear os processos do banco de dados entre os núcleos.
3. Previsibilidade: Em ambientes de alta concorrência, você garante que o Informix sempre terá aqueles 24 núcleos físicos dedicados a ele, imunes a picos de processamento de outras aplicações (como agentes de backup ou monitoramento).

Conclusão

Afinidade de CPU não é "micro-otimização", é arquitetura básica para servidores de grande porte. Se você roda IBM Informix em máquinas com dezenas de núcleos e não configurou o parâmetro aff= no seu VPCLASS, seu banco de dados está deixando performance na mesa.

Sempre mapeie sua topologia com lscpu, isole os núcleos físicos dos lógicos (HT) e amarre seus VPs. O tempo de resposta das suas queries vai agradecer.

O Fim do "A culpa é do Banco" (Foco em Linux + Performance)

Todo DBA Sênior já participou daquela clássica "sala de guerra" (War Room). O sistema está lento, os usuários estão reclamando e a primeira frase que se ouve é: "A culpa é do banco de dados, olha lá!".

Você analisa as métricas da sua instância (seja IBM Informix, Oracle ou PostgreSQL) e nota um alto índice de esperas por I/O (I/O Waits). No entanto, a equipe de infraestrutura abre o painel do Storage e afirma categoricamente: "Nosso storage está entregando latência de 1ms, o problema não é aqui".

Como sair desse impasse de "achismos"? A resposta não está no iostat ou no sar. A resposta definitiva está dentro do próprio kernel do Linux, utilizando a tecnologia eBPF.

O que é o eBPF e o bcc-tools?

O eBPF (Extended Berkeley Packet Filter) é uma das maiores revoluções recentes do Linux. Ele permite que você execute programas em um ambiente seguro (sandbox) diretamente dentro do kernel do sistema operacional, sem precisar recompilar o kernel ou carregar módulos perigosos.

Para facilitar a vida dos administradores, foi criado o pacote bcc-tools (BPF Compiler Collection), que traz dezenas de scripts prontos para extrair métricas de performance com precisão de microssegundos, com impacto quase zero na CPU.

Instalando as ferramentas

A instalação é simples e está disponível nos repositórios oficiais das principais distribuições Linux corporativas:

# Em sistemas baseados em Debian/Ubuntu
sudo apt-get update
sudo apt-get install bpfcc-tools linux-headers-$(uname -r)

# Em sistemas baseados em RHEL/CentOS/Oracle Linux
sudo yum install bcc-tools kernel-devel-$(uname -r)

Nota: Dependendo da distribuição, os comandos ganham o sufixo -bpfcc (ex: biolatency-bpfcc).

1. biolatency: O Raio-X do seu Disco

O iostat mostra médias. E médias mentem. Se você tem 99 operações levando 1ms e 1 operação levando 1000ms, a média parecerá aceitável, mas aquela única operação lenta pode estar travando um checkpoint crítico do seu banco de dados.

O comando biolatency rastreia o tempo exato que o dispositivo de bloco (disco) levou para responder ao sistema operacional e gera um histograma visual.

# Medindo a latência de I/O em milissegundos por 10 segundos
sudo biolatency-bpfcc -m 10

Exemplo de Saída:

msecs               : count     distribution
    0 -> 1          : 3245     |****************************************|
    2 -> 3          : 453      |*****                                   |
    4 -> 7          : 12       |                                        |
    8 -> 15         : 3        |                                        |
   16 -> 31         : 0        |                                        |
   32 -> 63         : 0        |                                        |
   64 -> 127        : 1        |                                        |
  128 -> 255        : 150      |**                                      |

Como ler isso na reunião: "Equipe de Infra, a maioria das operações realmente ocorre em 1ms. Porém, observem o pico bimodal no final do histograma. Tivemos 150 operações que levaram entre 128ms e 255ms para serem concluídas no nível do bloco. O gargalo existe e está afetando o banco."

2. ext4slower / xfs_slower: A "Arma Fumegante"

Se o biolatency prova que o disco está lento, as ferramentas da família slower provam quem está sofrendo com isso e qual arquivo está sendo lido ou gravado no momento da lentidão.

Se o seu banco de dados está em um sistema de arquivos XFS, você pode pedir ao kernel para mostrar apenas as operações de I/O que demoraram mais de 10 milissegundos:

# Rastreando operações no XFS mais lentas que 10ms
sudo xfsslower-bpfcc 10

Exemplo de Saída:

TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
14:32:12 oninit         4512   W 8192    124000     15.23 rootdbs.000
14:32:15 oninit         4512   R 16384   854120     42.10 datadbs1.000
14:32:18 oracle         8921   W 8192    512000     85.50 redo01.log

O xeque-mate: Com esse comando, você entrega o relatório exato. Você mostra o horário, o processo do banco de dados (oninit, oracle, etc.), se era leitura (R) ou gravação (W), a latência exata em milissegundos e, o mais importante, o nome do arquivo físico que sofreu a lentidão (ex: um dbspace ou um redo log).

Conclusão

A administração de bancos de dados de missão crítica exige observabilidade avançada. Quando você para de usar ferramentas baseadas em médias e passa a usar o eBPF para analisar eventos no nível do kernel, o diagnóstico deixa de ser uma opinião e passa a ser um fato matemático.

Se o seu ambiente de banco de dados apresenta lentidões misteriosas, travamentos de aplicação ou picos de I/O inexplicáveis, não tente adivinhar. Meça com as ferramentas certas.

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.