Servidor Linux com Gerenciador Web – Zentyal

Recentemente adotamos Zentyal Community Edition como solução de servidor Linux para clientes que não têm equipe própria de TI.

Administrar servidores Linux/Unix tem sido domínio de quase-nerds. Executar comandos em terminal de texto, múltiplos arquivos de configuração com dezenas ou centenas de parâmetros, mensagens de erro obscuros assustam a maioria das pessoas, inclusive profissionais de TI experientes.

Zentyal é uma das alternativas para facilitar o uso de Linux como servidor. Construído sobre Ubuntu Server, apresenta uma interface web muito atraente e polida, e empacota funções pré-definidas de servidor (arquivos, proxy, firewall, email, etc.). Ao esconder detalhes de configuração de pouca utilidade na maioria das situações, torna o servidor Linux muito mais simples de administrar.

No entanto, a opção pela simplicidade tem seu preço: Zentyal é um aplicativo fechado, e não permite intervenções por administrador Linux/Unix em configurações geradas por ele. Nestes casos, nossa opção recai no Webmin.

Novo Cliente: Log Express

Após um processo rigoroso de seleção de empresas de tecnologia Linux e avaliação da solução proposta, a Intercom foi escolhida como empresa parceira para fornecimento de solução Linux da Log Express, cuja matriz está localizada na cidade de São José dos Campos, SP.

Além da matriz, a Log Express possui diversas filiais localizadas no Vale do Paraíba e litoral norte do Estado de São Paulo, e tem uma lista de necessidades não-triviais: autenticação centralizada na matriz; controle de acesso centralizado no acesso Internet; interligação de filiais à matriz via VPN para execução de aplicações corporativas; sistemas centralizados de chamados (este integrado ao sistema de email) e inventário; e facilidade de gerenciamento.

A solução proposta pela Intercom, vencedora no processo de avaliação tecnológica, está baseada em servidor Linux Ubuntu, interface Webmin, OpenVPN com firewall iptables, autenticação winbind integrada ao MS Active Directory, Request Tracker e OCS Inventory.

Além da solução tecnológica, a Intercom propôs transferir “know-how” especializado à equipe de TI da Log Express, para operação própria pós-implantação, assim demonstrando total transparência na parceria formada.

Linux e câmeras IP

Desenvolvemos recentemente um projeto de monitoração patrimonial distribuída baseada em câmeras IP e Linux.

Os pré-requisitos foram:

  • Transmissão de imagens para Internet, para permitir sua visualização por várias pessoas em vários locais distintos.
  • Gravação de imagens por eventos. Os eventos de gravação devem ser definidos de forma flexível.
  • As câmeras estão espalhados em vários bairros de São Paulo e cidades do Interior de SP; suas imagens devem ser centralizadas em uma única interface. Novas câmeras serão adicionadas com frequência.

A solução implementada está baseada no uso de câmeras IP wireless Foscam FI8905W, uma câmera em cada localidade, usando links de banda larga existentes para transmitir suas imagens para um servidor Linux executando o software Zoneminder.

Zoneminder é um conjunto integrado de aplicativos que fazem a captura, análise, gravação e monitoração de qualquer câmera IP, USB ou CFTV (via placa de captura Geovision). É construído sobre Video For Linux (V4L), e possui vários “daemons” que fazem a captura e análise de imagens. Sua interface web, baseada em Apache, PHP e MySQL, permite a monitoração das câmeras em tempo real e a organização e visualização de eventos gravados.

Zoneminder foi instalado em uma instância m1.small de servidor Ubuntu Lucid 64-bits,  criada na Amazon Web Services São Paulo, com armazenamento EBS inicial de 50GB que poderá ser expandido incorporando novos volumes EBS conforme necessidade. As câmeras IP foram configuradas para transmitir suas imagens a 4 quadros por segundo, um compromisso entre o tráfego de vídeo gerado e a banda disponível para upload Internet.

Este projeto foi executado em 2 semanas e contou com a flexibilidade da Amazon Web Services. O custo mensal de operação é da ordem de R$ 250,00, para 7 câmeras IP.

Amazon Web Services – Novidades EC2

A Amazon Web Services anunciou neste começo de Março/2012 três novidades bem-vindas para EC2 (“Elastic Compute Cloud”):

  1. Todas as instâncias EC2 podem rodar imagens de sistemas operacionais de 64 bits. Isto facilita o crescimento linear dos recursos computacionais para aplicações baseadas em “cloud computing”, pois a mesma imagem de 64 bits pode ser usada desde instâncias pequenas até as super-instâncias conforme sua evolução.
  2. Foi introduzida a instância m1.medium, preenchendo uma lacuna que existia entre a instância m1.small e m1.large. A instância m1.medium tem como recursos 2 ECUs (EC2 Compute Units), 3,75GB de RAM e 410GB de storage temporário. A listagem completa de tipos de instâncias EC2 está aqui.
  3. Os usuários agora podem conectar às instâncias EC2 diretamente a partir do browser, a partir de aplicativos Java, sem necessidade de instalar programas de emulação de terminal ou acesso remoto Windows.

Estas novidades indicam o rápido amadurecimento dos produtos da Amazon Web Services, adequados a uma grande gama de projetos “cloud computing”.

Nagios e SMS

Com a popularização de serviços de mensagem 3G e seu barateamento, faz todo o sentido integrar o envio de SMS com monitoração Nagios.

O sistema Nagios da Intercom utiliza SMSTools3 e um modem 3G Huawei E160 da TIM para envio de avisos. SMSTools3 é uma ferramenta sofisticada e suporta múltiplos modens (para múltiplas operadoras) e enfileiramento de mensagens, e tanto envia quanto recebe mensagens SMS, permitindo sua fácil integração com sistema de email e outras ferramentas. Uma detalhada descrição do SMSTools3 está aqui.

A configuração do SMSTools3 é muito simples, e fica em um único arquivo, /etc/smsd.conf (veja nosso exemplo). A integração com Nagios é igualmente simples, basta alterar o comando de envio de email para o comando sendsms (veja aqui). Há ainda o detalhe do driver do modem 3G: no nosso caso, o driver utilizado é option, que suporta o modem Huawei E160.

 

Quando acionar o plano de contingência?

Recentemente recebemos um pedido de atendimento emergencial: o servidor de arquivos Linux Samba do cliente fora de São Paulo apresentou um erro de hardware durante reboot por falta de energia.

Repassei as orientações por telefone sobre FSCK, seguindo relato do console do servidor. Após um tempo, ficou óbvio que não era mero problema de shutdown desordenado, mas sim profundos erros de hardware dos discos.

Segundo o cliente, o conteúdo do servidor de arquivos era crítico. Questionei sobre backup, e fui informado que o backup era diário e íntegro. Então sugeri que, dada a criticidade em voltar a ter os arquivos disponíveis, o caminho mais rápido era instalar um novo servidor em algum hardware provisório ou em VMWare.

Seguiu-se um longo silêncio na ligação telefônica, e finalmente meu interlocutor agradeceu a ajuda emergencial e disse que preferiria tentar consertar a situação.

Uma pergunta ficou no ar: será que o plano de contingência do cliente realmente identificou a falha catastrófico de hardware como possível cenário, e daí definiu os limites para o acionamento das medidas de contingência? Ou, colocado de outra forma: o plano está claro quanto a “quem deve acionar a contingência sob quais situações”?

Ping e TTL

Todos conhecem ping e sabem como usá-lo para testar conectividade entre computadores e outros dispositivos que usam IP. Mas qual a função do parâmetro TTL que o comando ping mostra?

TTL é um acrônimo para “Time to Live”. Numa rede IP, ele é usado para evitar que um pacote de dados (tecnicamente, um datagrama) vague indefinidamente de um ponto a outro na rede, caso ocorra algum problema de rotas. O computador que envia o datagrama define um valor inicial de TTL (para Linux, é 64); cada roteador que encaminha o datagrama subtrai 1 (TTL-1) antes de transmiti-lo. Quando TTL chegar a zero, o datagrama é descartado.

Deparei recentemente com um mistério, ao ativar um novo firewall Linux corporativo. Conexões TCP com Internet estavam “congelando” a cada 2 a 3 minutos, e voltava a funcionar depois de 30 a 40 segundos – aparente indicação clara de perda de datagramas. Isto, obviamente, inutilizava o firewall na prática. Mas o teste com ping, de um outro ponto da Internet ao novo firewall, não indicava nenhuma queda ou perda de dados. Depois de muitas verificações com o provedor (trocar cabos, trocar porta do roteador/switch, setar velocidade mais baixa para interface de rede, ser questionado se o firewall Linux estava corretamente configurado – rsrs), reparei em algo extremamente incomum:

64 bytes from aaa.bbb.ccc.12: icmp_req=237 ttl=52 time=26.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=238 ttl=52 time=33.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=239 ttl=41 time=27.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=240 ttl=41 time=33.5 ms

Coincidentemente, nos instantes de mudança de valor TTL, as conexões TCP do novo firewall congelavam. Ou seja, o endereço IP designado pelo provedor ao novo firewall estava em uso por algum outro dispositivo obscuro na rede! Mistério resolvido (descobriu-se depois que o IP em questão estava em uso por um dispositivo esquecido numa VLAN da rede interna…).

Conclusão: o ping, mesmo sendo uma ferramenta básica de debug, fornece informações de grande valia quando interpretadas da forma correta.

Alguns pensamentos sobre backup

Há tempos eu li, num post no forum de suporte Gentoo, uma assinatura muito inspiradora, que transcrevo abaixo:

“Existem dois tipos de usuários, aqueles que fazem backups e aqueles que nunca tiveram problemas com HD”

Hoje em dia, em muitas empresas apenas fazer backups não é suficiente: há a necessidade de arquivamento de dados por longos períodos de tempo, para fins de “compliance” e auditoria.

Mídias magnéticas, mesmo as com tecnologias novas como LTO, têm vida útil limitada, e esta limitação é muito influenciada também pelas condições de manuseio e armazenagem (temperatura, umidade). Assim, para ter segurança no processo de backup e arquivamento, sempre é importante ter mais que uma cópia dos dados (por exemplo, ter múltiplas fitas ou ter uma fita e o mesmo dado guardado em discos NLS – “Near Line Storage”) e realizar testes regulares de restore.

 

Linux, o canivete suiço

Nas duas consultorias mencionadas no post anterior (lentidão geral na rede e Internet), Linux foi fundamental.

As duas redes são segmentadas com múltiplos switchs e VLANs, AD Windows com Windows Server 2008R2 localizados no “core”, e firewall estilo “appliance” com gerência web para Internet. Não havia uma ferramenta em lugar adequado para debug: Wireshark no Windows não mostrava tráfego Internet, e a interface web do firewall “appliance” não era de fácil uso para “packet sniffing”.

Solução? Instalamos servidores Linux provisoriamente como firewall, cujas ferramentas (tcpdump, jnettop, ntop, nmap, netflow, etc.) permitiram visão clara sobre o tráfego Internet; habilitamos proxy transparente, para registrar e gerar relatórios de padrão de acesso web; e usamos o recurso de “port mirroring” para investigar segmentos específicos da rede local.

Após o término da consultoria, ambos os clientes decidiram manter os servidores Linux, pois os múltiplos relatórios gerados se tornaram essenciais para melhor gerenciamento.