Instalando o Docker em Linux - 2025

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Instalando o Docker em Linux – Guia Atualizado 2025

O Docker continua sendo uma ferramenta central para ambientes de containers, mesmo em 2025. Apesar da concorrência crescente de alternativas como Podman, o Docker mantém sua força devido à simplicidade e vasta documentação.

Este guia é objetivo: vamos instalar o Docker em sistemas baseados em Debian/Ubuntu e também cobrir a instalação em distribuições RHEL/CentOS/Oracle Linux.

1. Pré-requisitos

• Distribuição Linux atualizada
• Acesso root ou sudo
• Conexão com a internet

2. Instalando Docker em Debian/Ubuntu

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

Após a instalação, verifique o serviço:

sudo systemctl status docker

3. Instalando Docker em RHEL/CentOS/Oracle Linux

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install docker-ce docker-ce-cli containerd.io
sudo systemctl start docker
sudo systemctl enable docker

Confirme a instalação com:

docker --version

4. Pós-instalação (Opcional)

Para evitar usar sudo em cada comando Docker:

sudo usermod -aG docker $USER
newgrp docker

Agora você pode rodar comandos Docker diretamente sem precisar de sudo.

5. Considerações Finais

O Docker evoluiu, mas a base da instalação continua muito similar. Manter o ambiente atualizado e seguro é crucial para projetos sérios de infraestrutura.

Nos próximos artigos, vamos aprofundar o uso de Dockerfiles, Volumes, Redes e práticas seguras em ambientes de containers.

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

Waiting for confirmation of MySQL service startup...

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Docker travado em “Waiting for confirmation of MySQL service startup”

Esse erro, apesar de simples à primeira vista, é um dos travamentos mais silenciosos e frustrantes ao tentar migrar containers MySQL. Logo após o primeiro docker run, o container trava antes mesmo de subir:

Waiting for confirmation of MySQL service startup

Esse tipo de erro normalmente indica que algo no volume de dados está impedindo a inicialização do banco, e o entrypoint padrão do container está preso esperando algo que não virá.

🔍 Possíveis causas

• Volume com dados parcialmente migrados ou corrompidos
• Permissões erradas nos arquivos do MySQL
• Arquivos de instalação (como ibdata1, auto.cnf) presentes mas inválidos
• Configuração personalizada my.cnf quebrada ou incompatível

🛠️ Como resolver

1️⃣ Testar sem volume

Rode o container limpo, sem montar volume. Se funcionar, o problema está nos dados:

docker run -e MYSQL_ROOT_PASSWORD=test --rm mysql:5.7

2️⃣ Verificar estrutura do volume

Confira se o volume está realmente com os arquivos corretos do MySQL:

ls -la /var/lib/mysql

Se necessário, corrija permissões:

chown -R mysql:mysql /var/lib/mysql

3️⃣ Apagar arquivos de PID ou socket

Se você migrou arquivos com o banco ligado, talvez arquivos "fantasmas" estejam bloqueando o start:

rm -f /var/run/mysqld/mysqld.pid
rm -f /var/run/mysqld/mysqld.sock

4️⃣ Ver logs detalhados

Use essas variáveis para visualizar o que está acontecendo:

-e MYSQL_LOG_CONSOLE=true
--log-error-verbosity=3

5️⃣ Teste interativo

Entre no container antes do daemon tentar iniciar:

docker run -it --rm -e MYSQL_ROOT_PASSWORD=test mysql:5.7 bash
mysqld --initialize --user=mysql
mysqld
  

Isso revelará erros internos antes que o script padrão tente inicializar o banco e trave.

"Nem sempre o MySQL trava por estar corrompido. Às vezes ele só está perdido em um novo lugar, tentando achar o caminho de casa."

Ao migrar um container MySQL, certifique-se de que os dados estão íntegros, as permissões corretas e o ambiente limpo. Um banco de dados exige cuidado — mesmo em um mundo de containers descartáveis.

Migrando Containers

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como Migrar um Container Docker para Outro Servidor

Saiba como transportar containers e volumes com segurança entre máquinas diferentes usando comandos simples.

📦 Método 1: Exportar container e volumes manualmente

1. Crie a imagem a partir do container

docker commit meu_container minha_imagem:latest

2. Exporte a imagem para um arquivo

docker save minha_imagem:latest -o minha_imagem.tar

3. Exporte dados do volume (se aplicável)

tar czf meus_dados.tar.gz /caminho/do/volume

4. Transfira para o novo servidor

scp minha_imagem.tar meus_dados.tar.gz usuario@servidor:/caminho/destino

5. Importe a imagem e os dados no novo host

docker load -i minha_imagem.tar
tar xzf meus_dados.tar.gz -C /caminho/destino

6. Suba novamente o container

docker run -d -v /caminho/destino:/dados minha_imagem

🧩 Método 2: Usando Docker Compose (ideal para múltiplos serviços)

1. Copie o arquivo docker-compose.yml e os volumes

Garanta que os dados estejam compactados ou montados via diretórios locais.

2. No novo servidor, execute:

docker-compose up -d

Essa abordagem é mais prática para aplicações complexas ou multi-containers.

"Containers são passageiros, mas dados são valiosos. Cuide da migração de ambos."

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

Como expurgar binlogs do MySQL

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como expurgar binlogs do MySQL quando a partição está 100% cheia

O que fazer quando o disco enche e o MySQL trava por conta dos binlogs acumulados.

📦 O problema

Quando a partição do servidor MySQL atinge 100% de uso, o banco de dados não consegue mais gravar novos arquivos binários nem atualizar o index (mysql-bin.index), impedindo o expurgo automático dos binlogs antigos.

🔧 Solução recomendada (com MySQL parado)

1. Pare o MySQL

sudo systemctl stop mysql

2. Acesse a pasta dos binlogs

cd /var/lib/mysql

3. Liste os arquivos e remova os antigos manualmente

ls -lh mysql-bin.*
sudo rm mysql-bin.000001 mysql-bin.000002

4. Edite o index mysql-bin.index

Remova as linhas que apontam para os arquivos deletados:

sudo nano mysql-bin.index

5. Inicie novamente o MySQL

sudo systemctl start mysql

💡 Alternativa com o MySQL em execução

Caso o MySQL ainda esteja rodando (com algum espaço livre):

PURGE BINARY LOGS TO 'mysql-bin.000010';

ou:

PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

✅ Dica de prevenção

Adicione ao seu my.cnf:

expire_logs_days = 7
max_binlog_size = 100M

"Às vezes, apagar com cuidado é a melhor forma de manter o controle."

API do Zabbix via Bash

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Testando a Conexão com a API do Zabbix via Bash

Autenticação simples usando curl para validar acesso à API JSON-RPC do Zabbix.

📡 O que estamos testando?

A API do Zabbix é baseada em JSON-RPC e exige autenticação com o método user.login. O teste mais direto é enviar uma requisição POST para verificar se sua URL e credenciais estão corretas.

🧪 Comando para testar via bash:

curl -X POST https://SEU_ZABBIX/zabbix/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
      "user": "Admin",
      "password": "zabbix"
    },
    "id": 1,
    "auth": null
  }'

Substitua SEU_ZABBIX pela URL do seu servidor Zabbix e ajuste o usuário/senha conforme sua configuração.

📥 Resposta esperada:

{
  "jsonrpc": "2.0",
  "result": "ca5386cf6d9e8d8c4c802dc670d7b647",
  "id": 1
}

O campo result traz o token de autenticação para futuras requisições.

🔐 Dica de segurança:

Evite deixar senhas no histórico do terminal. Para ambientes mais seguros, utilize variáveis de ambiente ou arquivos .env.

"Entender como sua API responde é o primeiro passo para automatizar, monitorar e controlar."

Como inicializar o Oracle Linux 8 em modo de segurança (rescue ou single-user mode)

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como inicializar o Oracle Linux 8 em modo de segurança

O modo de segurança (rescue mode ou single-user) é útil para recuperar o sistema após falhas críticas, redefinir senhas, corrigir falhas no fstab ou desabilitar serviços que impedem a inicialização.

🛠️ Passo a passo para entrar no modo de segurança

1. Reinicie o servidor
2. Na tela do GRUB, selecione a entrada padrão e pressione e para editar
3. Localize a linha que começa com linux ou linuxefi
4. Adicione ao final da linha:
   systemd.unit=rescue.target
5. Pressione Ctrl + X ou F10 para iniciar

🔒 Senha de root

Você será levado a um prompt com acesso root (após digitar a senha). Se não lembrar a senha de root, use o modo de emergência para redefinir.

🆘 Alternativa: Modo de emergência

Substitua rescue.target por emergency.target no passo 4 para um modo ainda mais restrito (sem montar partições adicionais).

⚠️ Importante

• Evite editar arquivos críticos sem backup
• Use journalctl para verificar erros recentes
• Use mount -o remount,rw / se o sistema estiver montado como somente leitura

---

“No modo mais silencioso do sistema, ouvimos o que realmente falhou.”

É possível desativar o auditd via GRUB no Oracle Linux 8?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como desativar o auditd via GRUB no Oracle Linux 8

O serviço auditd é usado para auditoria de eventos no Linux. Em alguns sistemas, especialmente quando há problemas de performance ou erros como “auditd: backlog limit exceeded”, pode ser necessário desativá-lo.

⚙️ Desativando via GRUB (temporário ou persistente)

Você pode desativar o auditd adicionando o parâmetro audit=0 na linha do kernel.

🔧 Passo a passo:

1. Reinicie o sistema
2. Na tela do GRUB, pressione e para editar a entrada do kernel
3. Localize a linha que começa com linux ou linuxefi
4. Adicione ao final: audit=0
5. Pressione Ctrl + X ou F10 para bootar

💾 Para tornar permanente:

Edite o arquivo de configuração do GRUB:

sudo nano /etc/default/grub

Adicione o parâmetro em:

GRUB_CMDLINE_LINUX="... audit=0"

Salve e atualize o GRUB:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

⚠️ Atenção

• Desabilitar o auditd pode impactar logs de segurança
• Evite em ambientes que exigem compliance (PCI, HIPAA, etc.)
• Para desabilitar o serviço por completo:

  sudo systemctl disable auditd

  sudo systemctl mask auditd

---

“Nem toda segurança vem sem custo — e nem todo sistema aguenta auditoria sem limites.”

Como verificar a limitação de threads em um container Docker quando não existe a pasta /sys/fs/cgroup/docker (ou cgroups padrão)

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como verificar limitação de threads em container Docker

Se você está tentando identificar quantas threads ou processos um container pode criar, mas não encontrou a pasta /sys/fs/cgroup/docker, saiba que é possível obter essa informação por outros meios.

🔧 Por que a pasta pode não existir?

• O sistema está usando cgroups v2, que tem um layout diferente
• O container está em um ambiente minimalista, sem montar o cgroup completo
• O Docker foi configurado com outro caminho de cgroup

✅ Método alternativo: /proc/self/limits

Dentro do container, execute:

cat /proc/self/limits

Procure pela linha:

Max processes    4096    4096    processes

Esse número indica quantos processos (e portanto, threads) você pode criar dentro do container.

📦 Usando docker inspect

Do host, verifique o container:

docker inspect --format='{{.HostConfig.PidsLimit}}' nome_ou_id

Se estiver em branco, o limite está herdando do sistema (normalmente ilimitado).

🧠 Dica avançada (cgroup v2)

Se estiver usando cgroups v2, verifique o caminho:

cat /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/pids.max

Ou use:

systemd-cgls
systemctl status docker

---

“Nem toda limitação está visível — mas os processos sempre revelam suas fronteiras.”

Docker error: “Cannot initialize async manager: cannot create thread – operation not permitted”

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Erro Docker no CentOS: cannot create thread – operation not permitted

Se ao tentar iniciar um container no Docker você se deparou com a mensagem:

Cannot initialize async manager: cannot create thread – operation not permitted

Esse erro geralmente está relacionado a limites de sistema (ulimit) ou restrições de segurança no CentOS ou Red Hat-based systems.

🔍 Possíveis causas

• Limite de threads (max user processes) está muito baixo
• Docker sendo executado em um ambiente restrito (como contêiner ou com SELinux/apparmor ativo)
• Container tentando criar mais threads do que o sistema permite

✅ Como resolver

1. Aumentar o limite de threads (ulimit)

ulimit -u 65535

Ou edite o arquivo /etc/security/limits.conf:

* soft nproc 65535
* hard nproc 65535

2. Ajustar systemd

Se o Docker for iniciado via systemd:

sudo systemctl edit docker

Adicione:

[Service]
LimitNPROC=infinity

Depois reinicie o serviço:

sudo systemctl daemon-reexec
sudo systemctl restart docker

3. SELinux (se ativado)

Para testar, você pode temporariamente desabilitar:

sudo setenforce 0

(⚠️ use com cautela — preferencialmente ajuste permissões via audit2allow)

---

“Limitações silenciosas do sistema podem se tornar barreiras para contêineres. Saber onde mexer é a chave.”

HTTP errors

🔍 Categorias de códigos HTTP

• 1xx – Informativo
  O pedido foi recebido e o processo continua. Raro de ver no dia a dia.
• 2xx – Sucesso
  O pedido foi aceito, compreendido e processado com sucesso.
• 3xx – Redirecionamento
  O cliente precisa realizar mais ações para completar a requisição, como seguir para outro endereço.
• 4xx – Erro do Cliente
  O pedido tem algo errado, geralmente vindo do lado do usuário.
• 5xx – Erro do Servidor
  O servidor falhou ao processar o pedido. A culpa, dessa vez, não é sua.

⚠️ Principais erros e seus significados - Guia para Referência rápida

• 400 Bad Request
  O servidor não conseguiu entender a requisição devido à sintaxe inválida.
• 401 Unauthorized
  Você precisa estar autenticado. Um aviso de que “não basta estar conectado”.
• 403 Forbidden
  Você não tem permissão para acessar esse recurso. Mesmo se estiver autenticado.
• 404 Not Found
  O endereço solicitado não existe. Um dos erros mais conhecidos da internet.
• 408 Request Timeout
  O servidor esperou demais por você. Às vezes, até os sistemas perdem a paciência.
• 429 Too Many Requests
  Calma. Você pediu demais em pouco tempo.
• 500 Internal Server Error
  O servidor teve um problema inesperado. Algo deu errado e ele não sabe lidar com isso.
• 502 Bad Gateway
  O servidor agiu como intermediário e recebeu uma resposta inválida.
• 503 Service Unavailable
  O servidor está temporariamente fora do ar. Pode ser manutenção. Pode ser caos.
• 504 Gateway Timeout
  O servidor não recebeu resposta a tempo de outro servidor intermediário.

🚨 Guia detalhado de Códigos HTTP por Categoria

1xx – Informacional

• 100 – Continue: O servidor recebeu os cabeçalhos da requisição e o cliente deve prosseguir com o envio do corpo da requisição.
• 101 – Switching Protocols: O cliente solicitou a mudança de protocolo e o servidor concordou em realizar a troca.
• 102 – Processing: Indica que o servidor recebeu e está processando a requisição, mas ainda não tem uma resposta disponível.

2xx – Sucesso

• 200 – OK: A requisição foi bem-sucedida e o servidor retornou os dados solicitados.
• 201 – Created: A requisição foi bem-sucedida e um novo recurso foi criado no servidor.
• 202 – Accepted: A requisição foi aceita para processamento, mas ainda não foi concluída.
• 204 – No Content: A requisição foi bem-sucedida, mas o servidor não retornou nenhum conteúdo.

3xx – Redirecionamento

• 301 – Moved Permanently: O recurso solicitado foi movido permanentemente para uma nova URL.
• 302 – Found: O recurso foi encontrado em outra URL temporariamente.
• 303 – See Other: O cliente deve realizar uma nova requisição para uma outra URL utilizando o método GET.
• 304 – Not Modified: Indica que o recurso não foi modificado desde a última requisição.
• 307 – Temporary Redirect: O recurso está temporariamente em outra URL e deve ser acessado com o mesmo método HTTP.
• 308 – Permanent Redirect: O recurso foi permanentemente movido para outra URL e o método HTTP deve ser mantido.

4xx – Erros do Cliente

• 400 – Bad Request: O servidor não conseguiu entender a requisição devido a uma sintaxe inválida.
• 401 – Unauthorized: A requisição requer autenticação. O cliente não forneceu credenciais válidas.
• 403 – Forbidden: O cliente está autenticado, mas não tem permissão para acessar o recurso.
• 404 – Not Found: O recurso solicitado não foi encontrado no servidor.
• 405 – Method Not Allowed: O método HTTP usado não é permitido para o recurso solicitado.
• 408 – Request Timeout: O servidor não recebeu a requisição completa dentro do tempo esperado.
• 409 – Conflict: Existe um conflito com o estado atual do recurso, impedindo a execução da requisição.
• 429 – Too Many Requests: O cliente enviou muitas requisições em um curto período de tempo.

5xx – Erros do Servidor

• 500 – Internal Server Error: Erro genérico do servidor. Algo inesperado aconteceu ao processar a requisição.
• 501 – Not Implemented: O servidor não reconhece o método da requisição ou não tem capacidade para processá-la.
• 502 – Bad Gateway: O servidor recebeu uma resposta inválida ao atuar como gateway ou proxy.
• 503 – Service Unavailable: O servidor está temporariamente fora de serviço por manutenção ou sobrecarga.
• 504 – Gateway Timeout: O servidor não recebeu uma resposta a tempo de outro servidor ao atuar como gateway.
• 505 – HTTP Version Not Supported: A versão do protocolo HTTP utilizada na requisição não é suportada pelo servidor.

Guia técnico detalhado — ideal para desenvolvedores, analistas de suporte ou estudantes de redes.

"404: Você não foi encontrado. 503: Eu também não estava disponível."

No fim, até os erros HTTP parecem espelhar a vida real. Às vezes você busca algo que não está lá. Às vezes você pede demais. E outras vezes, o problema não é você — é o servidor. O importante é saber ler os sinais e aprender a tentar de novo.

SERVFAIL no Unbound com uma única interface

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

SERVFAIL no Unbound com uma interface: O que pode ser?

Se você configurou o Unbound como servidor DNS local e ao tentar uma consulta está recebendo o erro SERVFAIL, especialmente quando o Unbound está configurado para ouvir em apenas uma interface, há algumas possíveis causas para investigar.

🔎 Entendendo o erro

SERVFAIL indica que o servidor não conseguiu resolver a requisição, mesmo sendo tecnicamente funcional. O problema pode estar em:

• Falta de acesso externo (internet/firewall)
• Restrições no arquivo de configuração
• Escopo de rede limitado pela diretiva interface:
• Restrições no access-control

📄 Verifique o arquivo de configuração (unbound.conf)

Se o Unbound está ouvindo apenas em 127.0.0.1, ele não poderá atender clientes externos. Exemplo de problema:

interface: 127.0.0.1
access-control: 192.168.0.0/16 deny

Para permitir requisições externas, adicione:

interface: 0.0.0.0
access-control: 192.168.0.0/16 allow

🧪 Testes úteis

Use ferramentas como:

• dig @127.0.0.1 google.com
• dig @localhost -p 53 google.com
• unbound-checkconf – verifica erros de sintaxe
• journalctl -u unbound – veja os logs

📌 Outras dicas

• Habilite logs com verbosity: 2 ou superior para depurar
• Verifique se o servidor tem acesso à internet para consultas externas (forwarding ou root hints)
• Use local-zone e stub-zone apenas quando necessário

---

“Um servidor DNS só é útil quando sabe escutar — e quando está no canal certo.”

É possível desativar o auditd via GRUB?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como desativar o auditd via GRUB no Linux

O auditd é o serviço de auditoria do Linux, responsável por registrar eventos críticos no sistema. No entanto, em alguns casos (como falhas de boot ou sistemas de baixo desempenho), pode ser necessário desativá-lo temporariamente.

🛠️ Como desativar temporariamente pelo GRUB

1. Reinicie o sistema.
2. Na tela do GRUB, selecione a entrada de boot e pressione e.
3. Encontre a linha que começa com linux.
4. Adicione ao final da linha:
   audit=0
5. Pressione Ctrl + X ou F10 para iniciar.

🔧 Como desativar permanentemente

Para tornar essa configuração persistente:

1. Abra o terminal como root.
2. Edite o arquivo:
   /etc/default/grub
3. Na linha:
   GRUB_CMDLINE_LINUX=
   adicione audit=0 dentro das aspas.
4. Atualize o GRUB com:
   grub2-mkconfig -o /boot/grub2/grub.cfg
   ou update-grub dependendo da distribuição.
5. Reinicie o sistema.

⚠️ Considerações de segurança

• Desativar o auditd pode afetar conformidade com normas de segurança.
• Se o sistema exige logs de auditoria (como em servidores de produção), use essa solução apenas para diagnóstico.

---

“Nem todo log precisa ser registrado, mas todo erro precisa ser resolvido.”

Como inicializar o Oracle Linux 8 em modo de segurança?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Como iniciar o Oracle Linux 8 em modo de segurança

Precisa acessar o sistema Oracle Linux 8 para corrigir falhas, redefinir senhas ou desativar serviços? O modo de segurança (single-user/rescue) é ideal para isso.

📌 O que é o modo de segurança?

É um ambiente mínimo de manutenção com acesso root sem interface gráfica, usado para:

• Reparar sistemas danificados
• Desabilitar serviços corrompidos
• Redefinir senhas
• Editar arquivos de configuração

🧭 Passo a passo para acessar:

1. Reinicie o computador/servidor.
2. Na tela do GRUB, use as teclas direcionais para selecionar a entrada padrão (geralmente a primeira).
3. Pressione e para editar os parâmetros de boot.
4. Encontre a linha que começa com linux ou linux16.
5. Ao final da linha, adicione:
   systemd.unit=rescue.target
   ou para modo ainda mais restrito:
   systemd.unit=emergency.target
6. Pressione Ctrl + X ou F10 para iniciar com essa configuração.

🔐 Acesso root

Você será levado a um terminal com permissão root. A partir daí, pode usar comandos como:

• passwd – para alterar senha de root
• systemctl disable nome-do-serviço – para impedir travamentos no boot
• mount -o remount,rw / – caso precise editar arquivos do sistema

⚠️ Cuidados

• Evite fazer alterações permanentes se não tiver certeza.
• Reinicie com reboot após a manutenção.

---

“Resgatar um sistema também é resgatar o controle sobre ele.”

O que fazer quando um sistema Linux não me deixa logar por causa de "auditd: backlog limit exceeded"?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Erro "auditd: backlog limit exceeded" no Linux

Ao tentar iniciar ou acessar um sistema Linux, especialmente em ambientes como Oracle Linux, RHEL ou CentOS, você pode se deparar com a seguinte mensagem:

auditd: backlog limit exceeded

Esse erro pode impedir o sistema de inicializar corretamente ou bloquear o login em modo gráfico ou console.

🧠 O que significa esse erro?

O auditd é o daemon responsável pelo sistema de auditoria do Linux. Ele monitora e registra eventos importantes para segurança e conformidade.

Quando muitos eventos acontecem em sequência e o sistema não consegue processar todos, o backlog (fila de eventos) estoura o limite definido — e o kernel considera isso uma falha de segurança.

🛠️ Soluções temporárias

• Reinicie o sistema e entre no modo de emergência ou rescue.
• Edite o GRUB temporariamente durante o boot:
• Pressione e na entrada do GRUB.
• Adicione o seguinte ao final da linha linux:

  audit=0

• Pressione Ctrl + X ou F10 para iniciar com essa opção.
• Isso desativa o audit temporariamente e pode permitir o login.

⚙️ Correção permanente

Se for seguro desabilitar o auditd no seu caso, você pode editar a configuração do GRUB:

1. Abra o arquivo /etc/default/grub como root.
2. Adicione audit=0 à variável GRUB_CMDLINE_LINUX
3. Atualize o GRUB com:

   grub2-mkconfig -o /boot/grub2/grub.cfg

   (ou equivalente na sua distro)
4. Reinicie o sistema.

📌 Alternativas

• Aumentar o limite de backlog com:

  audit_backlog_limit=8192

  no GRUB
• Corrigir travamentos causados por excesso de logs ou configurações excessivas do auditd

---

“Em sistemas auditáveis, o silêncio também pode ser interpretado como falha.”

Existe algum problema em fazer uma subzona de uma subzona em DNS?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

É problemático criar subzonas de subzonas no DNS?

No gerenciamento de DNS, é comum lidar com domínios e subdomínios. Mas uma dúvida frequente surge quando falamos de delegar zonas aninhadas, como por exemplo:

exemplo.com → ti.exemplo.com → dev.ti.exemplo.com

Será que criar uma subzona dentro de outra subzona é um problema?

🔍 A resposta curta: Não necessariamente

O DNS foi projetado como uma estrutura hierárquica. É totalmente possível — e tecnicamente válido — delegar subzonas de subzonas.

No exemplo acima, dev.ti.exemplo.com pode ter seu próprio servidor autoritativo, independente de ti.exemplo.com, se houver delegação correta com registros NS e glue records (se necessário).

🧠 Quando isso pode ser útil?

• Divisão de responsabilidade entre equipes (ex: devops, segurança, TI).
• Ambientes isolados para projetos, clusters ou serviços.
• Separação de zonas por ambientes (ex: prod, dev, qa).

⚠️ Mas fique atento a:

• Delegações mal feitas podem gerar falhas de resolução (SERVFAIL).
• Dependências entre servidores autoritativos diferentes tornam o sistema mais complexo.
• Manter documentação clara de quem gerencia o quê é essencial.

✅ Boas práticas

• Use subzonas de subzonas apenas quando houver justificativa administrativa ou técnica.
• Garanta que cada zona tenha servidores NS consistentes.
• Teste a resolução com ferramentas como dig, host ou nslookup.

---

“O DNS é como um mapa de responsabilidades — e quanto mais complexas forem as rotas, maior deve ser o cuidado ao desenhá-las.”

Roteiro de Troubleshooting LBDN

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

🔍 Roteiro de Troubleshooting - Falha de LBDN no Infoblox

Objetivo: Diagnosticar problemas relacionados a LBDN (Local BIND DNS Name) no ambiente Infoblox, garantindo que as resoluções DNS funcionem corretamente.

✅ 1. Verificar se o LBDN está corretamente configurado

• Acesse: Data Management > DNS > Zones
• Verifique se o LBDN está associado ao nome correto e à zone correta.
• Confirme se possui os registros DNS (A, AAAA, CNAME) necessários.
• Verifique se está na DNS View esperada.
• Certifique-se de que a opção Enable está ativada.

✅ 2. Verificar a view DNS

• Confirme se a consulta está sendo feita pela view correta.
• Verifique as ACLs para garantir que o IP de origem tem permissão.
• Confirme se o LBDN está presente nessa view.

✅ 3. Regras baseadas em atributos

• Se for um LBDN com DNS Policy, revise as condições da regra.
• Verifique se a ação está permitindo a resposta (ex: respond, redirect, refuse).

✅ 4. Verificar logs de DNS

• Acesse: Grid > Grid Manager > Members > (selecione o membro DNS) > Logs
• Verifique o arquivo dns.log ou os query logs.
• Busque por erros como: REFUSED, NXDOMAIN, SERVFAIL.

grep 'nomedohost' /var/log/named/query.log

✅ 5. Testar resolução localmente no Infoblox

dig @127.0.0.1 nome-do-lbdn.exemplo.local

• Verifique se há resposta e qual membro responde.

✅ 6. Verificar serviço DNS do membro

• Acesse: Grid > Members > Services > DNS
• Garanta que o serviço DNS está ativo.
• Reinicie o serviço, se necessário.

✅ 7. Conferir replicação e sincronização

• Verifique o status de sincronização do grid.
• Confirme se há falhas na propagação das configurações.

✅ 8. Verificar políticas de firewall e segurança

• Confirme que o tráfego DNS está permitido entre clientes e os membros do Grid.
• Reveja as regras de firewall e segmentações de rede.

✅ 9. Verificar o cliente

• Verifique se o cliente está apontando para o DNS correto.
• Utilize ferramentas como nslookup ou dig.

✅ 10. Testar fallback e redundância

• Valide se outro Grid Member responde ao LBDN.
• Teste HA e failover, se aplicável.

🛠️ Comandos úteis via SSH (Infoblox Appliance)

dig nome-do-lbdn.exemplo.com @127.0.0.1 +short
tail -f /var/log/named/query.log
tail -f /var/log/messages
grep 'LBDN' /var/log/messages