Atualizando o Zabbix 4 para o Zabbix 5 no CentOS 7

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

Atualizando o Zabbix 4 para o Zabbix 5 no CentOS 7

Guia completo para atualizar o Zabbix de forma segura no CentOS 7, incluindo configuração posterior de autenticação LDAP via AD sem acesso à interface web.

🚧 Passo 0: Verifique pré-requisitos

• Sistema: CentOS 7
• Zabbix atual: 4.x
• Banco: MariaDB/MySQL
• Backup completo

📅 1. Backup completo

mysqldump -u root -p zabbix > /root/zabbix_backup.sql

❌ 2. Remova o repositório antigo

yum remove zabbix-release -y

📂 3. Adicione o repositório do Zabbix 5

rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/7/x86_64/zabbix-release-5.0-1.el7.noarch.rpm
yum clean all

↑ 4. Atualize os pacotes Zabbix

yum install --enablerepo=zabbix
  zabbix-server-mysql
  zabbix-web-mysql
  zabbix-agent
  zabbix-apache-conf -y

⚙️ 5. Atualização do schema

systemctl start zabbix-server
tail -f /var/log/zabbix/zabbix_server.log

⏰ 6. Ajuste o timezone do PHP

nano /etc/httpd/conf.d/zabbix.conf

Adicione ou edite a linha:

php_value date.timezone America/Sao_Paulo

▶️ 7. Reinicie os serviços

systemctl restart zabbix-server zabbix-agent httpd
systemctl enable zabbix-server zabbix-agent httpd

🔍 8. Configure autenticação LDAP via banco

mysql -u root -p zabbix

Atualize o tipo de autenticação:

UPDATE config SET authentication_type = 2 WHERE configid = 1;

Configure os parâmetros do LDAP:

UPDATE config SET
  ldap_host = 'ldap://AD.DOMINIO.LOCAL',
  ldap_port = 389,
  ldap_base_dn = 'DC=dominio,DC=local',
  ldap_bind_dn = 'CN=zabbix_bind,CN=Users,DC=dominio,DC=local',
  ldap_bind_password = 'SENHA',
  ldap_search_attribute = 'sAMAccountName',
  ldap_case_sensitive = 0
WHERE configid = 1;

🔑 9. Criar usuário LDAP no banco

INSERT INTO users (alias, name, surname, passwd, autologin, autologout, lang, refresh, rows_per_page, theme, attempt_failed, attempt_ip, attempt_clock, rows_per_page_mobile, auth_type, type)
VALUES ('usuario_ldap', 'Nome', 'Sobrenome', '', 1, 900, 'en_GB', 30, 50, 'default', 0, '', 0, 10, 2, 1);

🔸 10. Adicionar o usuário a um grupo

Verifique o ID do grupo:

SELECT usrgrpid, name FROM usrgrp;

Adicione o usuário:

INSERT INTO users_groups (usrid, usrgrpid) VALUES (ID_DO_USUARIO, ID_DO_GRUPO);

🚫 11. Resetar senha do Admin (local)

Gere o hash da senha temporária:

echo -n 'NovaSenha123!' | md5sum

Atualize o campo passwd do Admin:

UPDATE users SET passwd = 'HASH_MD5', attempt_failed = 0, attempt_ip = '', attempt_clock = 0 WHERE alias = 'Admin';

---

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

Boas práticas para uso de Alias em DNS (e armadilhas a evitar) | Sysadmin Urbano 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.

Boas práticas para uso de Alias em DNS (e armadilhas a evitar)

Alias em DNS — normalmente implementados via registros CNAME — são ferramentas extremamente úteis para a gestão de domínios e subdomínios. No entanto, seu uso inadequado pode gerar atrasos, falhas de resolução e até vulnerabilidades operacionais.

Neste artigo, vamos falar sobre boas práticas no uso de alias em DNS e, tão importante quanto, sobre o que **não** se deve fazer.

1. Entendendo o que é um Alias no DNS

Um alias, geralmente configurado como um registro do tipo CNAME, é uma maneira de dizer: "este nome de domínio é apenas um apelido para outro nome existente".

Exemplo típico:

app.example.com → www.example.com

O objetivo é simplificar a manutenção de domínios. Atualizando o destino do CNAME, todos os aliases apontam corretamente sem precisar alterar múltiplos registros A.

2. Quando usar um Alias é uma boa ideia

• 🔹 Para subdomínios que dependem de serviços externos (ex: plataformas SaaS, clouds públicas).
• 🔹 Para criar "atalhos" internos em ambientes complexos de múltiplos servidores.
• 🔹 Para abstrair o endereço real de serviços que podem mudar de IP frequentemente.

Ao usar alias estrategicamente, você reduz erros operacionais e torna a gestão de DNS mais sustentável a longo prazo.

3. O que NÃO fazer com Alias em DNS

• ⚠️ Não use CNAME no domínio raiz (example.com) — a maioria dos provedores e a RFC 1034 desencorajam isso.
• ⚠️ Não empilhe CNAMEs em sequência longa (chaining) — cada salto aumenta a latência de resolução DNS.
• ⚠️ Não aponte para domínios instáveis ou temporários — se o destino cair, seu alias também falha.
• ⚠️ Não use CNAME para serviços críticos internos — preferir IPs fixos ou registros A/AAAA diretos.

Aliases mal utilizados podem tornar seus sistemas vulneráveis a falhas de terceiros, gerar lentidão e aumentar a complexidade desnecessariamente.

4. Alternativas e soluções modernas

Hoje, alguns provedores oferecem registros do tipo "ALIAS" ou "ANAME", que permitem comportamento similar a CNAME no domínio raiz. Vale verificar se sua infraestrutura suporta.

Além disso, integrar DNS dinâmico (DDNS) para IPs variáveis ou usar balanceadores de carga com registros A pode ser mais eficiente em alguns cenários.

Conclusão

Alias em DNS são aliados poderosos — mas precisam ser usados com inteligência.

Evite cadeias de CNAMEs, proteja o domínio raiz e avalie o impacto de dependências externas antes de definir um alias. Boas práticas simples podem salvar horas de troubleshooting e garantir maior estabilidade para seus ambientes.

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

O que é DevOps de verdade (e o que não é) – Guia Sysadmin Urbano 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.

O que é DevOps de verdade (e o que não é)

DevOps é, provavelmente, uma das palavras mais mal interpretadas da TI moderna. Entre slogans de marketing e confusões internas, a essência de DevOps muitas vezes se perde.

Hoje, vamos esclarecer o que DevOps realmente significa — e, tão importante quanto, o que ele definitivamente não é.

1. DevOps é Cultura, Não Cargo

DevOps é um conjunto de práticas que une desenvolvimento e operações, com o objetivo de acelerar entregas de software de forma segura e confiável. Ele é, antes de tudo, uma mudança de mentalidade organizacional.

DevOps não é um "cargo de DevOps Engineer" que trabalha isoladamente. Se apenas uma pessoa carrega o "peso do DevOps", a empresa não entendeu o conceito. DevOps é **cultura compartilhada** — times inteiros operando com responsabilidade mútua pelo ciclo de vida das aplicações.

2. DevOps Não é Ferramenta

Ferramentas são parte da implementação de práticas DevOps — mas elas, por si só, **não são DevOps**.

Jenkins, Kubernetes, Terraform, GitLab CI — todas são ferramentas que ajudam a praticar automação, integração contínua e entrega contínua. Porém, adotar essas tecnologias sem mudanças de processo, comunicação e mentalidade é apenas modernizar o caos.

3. DevOps é Comunicação Eficiente

Se um pipeline automatizado gera uma falha, mas ninguém da equipe de desenvolvimento e operações conversa sobre isso, o DevOps morreu ali.

Comunicação aberta, rápida e objetiva entre times é a fundação para que o ciclo DevOps realmente funcione: planejar, construir, testar, lançar, operar, monitorar e aprender continuamente.

4. DevOps Exige Confiança Mútua

Uma organização que pune experimentação e erro não está pronta para DevOps. Cultura de confiança significa permitir que times falhem rapidamente, aprendam rapidamente e melhorem continuamente sem medo de retaliação.

Quando um sysadmin não confia nos testes automatizados, ou quando o desenvolvedor não confia no time de operações, o ciclo quebra.

5. DevOps Não Substitui o SysOps

Outro mito comum: "Com DevOps, não precisamos mais de times de operações." Errado.

DevOps aumenta a colaboração, mas a necessidade de especialistas em infraestrutura, segurança, redes e sistemas operacionais **não desaparece** — apenas muda de formato.

Infraestrutura continua sendo a base invisível que sustenta o delivery de software. Sem uma base sólida, a automação não salva ninguém.

Conclusão

DevOps não é mágica. Não é apenas ferramenta. Não é título de LinkedIn.

DevOps é prática contínua, é cultura de responsabilidade conjunta, é automação com propósito, é comunicação real entre pessoas técnicas.

Se você quer "fazer DevOps", comece mudando como seus times colaboram — antes de sair instalando novas ferramentas.

DevOps de verdade é humano, difícil, mas profundamente transformador.

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

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.”