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