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