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.