Meu pequeno servidor doméstico (Parte 3 - Sistema Operacional e Serviços)

Estimados leitores, nesta postagem darei prosseguimento ao assunto do meu servidor doméstico, que pode ser de grande interesse para aqueles que pretendem se aventurar na área de redes e servidores. Na primeira parte abordei o hardware do servidor, enquanto que na segunda mostrei a infraestrutura física e lógica da rede.

No presente texto vou trocar umas idéias a respeito da definição do sistema operacional e consequentemente dos serviços que um servidor pode realizar. Espero que curtam!

Atualizado no dia 29/04/2014: o sistema operacional foi substituído pelo Windows Server 2012 R2.



Definindo o Sistema Operacional

É o princípio de tudo, o ponto de partida que definirá alguns tipos de serviços especializados que a sua rede local terá. Atualmente não seria exagero dizer que em 99% dos casos a opção fica entre alguma versão do Windows Server e alguma distribuição Linux. Ambos possuem os seus pontos fortes e a escolha é basicamente sobre qual será o foco da rede bem como para qual tipo de tecnologia há o interesse de se enveredar. Vou citar as escolhas que fiz e a motivação que tive para fazê-las - e você, caro leitor, poderá associar ao seu caso e às suas próprias motivações.

Iniciando com o Debian Linux



A primeira encarnação do meu servidor doméstico surgiu em 2007 com uma simples necessidade: compartilhar a conexão com a Internet. Para tanto, era uma máquina antiga (até para os padrões da época): processador AMD Athlon XP 2500+, 1 GB de RAM DDR-400 e disco rígido IDE de apenas 20 GB. O sistema operacional era o Debian Linux então na versão 4.0. As atribuições básicas da máquina eram as seguintes (entre parênteses estão o nome dos pacotes no Linux):

  • Proxy com cache (Squid);
  • Firewall (regras do Iptables);
  • Servidor DHCP (dhcp3-server).

Há, porém, um requisito importante para aqueles que montam servidores Linux: a vontade de aprender, pesquisar, recorrer a fóruns e listas de discussão. Eu já tinha uma certa experiência com Linux em desktops - comecei em 1998 com o antigo Conectiva 2.0 Marumbi, mas em servidores o desafio é completamente diferente. Na época tive duas motivações pela opção pelo Linux: a vontade de aprender e o fato de ser um software livre.

Com o tempo o equipamento foi sendo melhorado para agregar mais funcionalidades (como um servidor de arquivos com o samba e de backup incremental com o rsync) bem como também para acompanhar as novas versões do Debian que surgiram, a 5.0 e a 6.0 - e o Debian seguia atendendo muito bem. Porém, em 2011, dois acontecimentos me forçaram a mudar a plataforma do meu pequeno servidor doméstico.

O primeiro deles, que até hoje classifico como algo esotérico (sim, informática é uma ciência esotérica e não exata), foi um erro que ocorreu após uma atualização de kernel (núcleo de qualquer sistema operacional) oficial do Debian: por algum motivo o módulo (um módulo é o equivalente no mundo Linux a um driver de dispositivo) de uma das minhas placas de rede (uso duas, uma para rede local e outra para conexão com a Internet) não era mais carregado pelo kernel, aliás, ele até era carregado mas por alguma força oculta era quase instantaneamente encerrado logo depois. Desta forma, sem o módulo carregado a placa de rede ficava inoperante. Com a placa inoperante o servidor ficava fora da rede, com o servidor fora todos os serviços ficavam indisponíveis. E, pelo menos a princípio, não se tratava de problema de hardware.

Correndo contra o tempo, com queixas dos demais utilizadores (sim, apesar de ser um servidor doméstico também tinha alguns "clientes" rs) e com trabalhos a concluir que necessitavam do servidor funcional, varri o Google atrás de soluções (entre várias outras tentativas, tentei voltar ao kernel anterior e forçar o carregamento do módulo nos arquivos de inicialização) mas não obtive sucesso. E isto coincidiu com uma nova necessidade profissional: aprender o conceito do Active Directory, serviço de diretório de redes da Microsoft.

Não me entendam mal: o Linux e o Debian não caíram no meu conceito por este episódio. Sem dúvida foi um fato isolado, relacionado à minha combinação específica de hardware, que é algo sempre difícil para os mantenedores preverem pois existem literalmente bilhões de combinações possíveis - afinal das contas, o PC é um padrão aberto!

Migrando para o Windows Server

Com esta nova necessidade em vista, senti que era o momento ideal de testar o Windows Server, afinal das contas, o servidor estava parado mesmo. Nada que uma madrugada (e muita Coca-Cola) não resolvesse! Comecei baixando (plugando o meu PC principal diretamente na Internet) do site da Microsoft a edição de avaliação de 180 dias do Windows Server 2008 R2, que era a última versão disponível em 2011.

O que levou mais tempo na migração, sem dúvida nenhuma, foi a cópia dos arquivos que estavam nas partições formatadas no sistema de arquivos ext4 (o mais utilizado no Linux - estas partições teriam que ser reformatadas no formato NTFS da Microsoft), o que fiz com a ajuda de um disco rígido externo antes da instalação do Windows. Nesta época, o meu servidor doméstico já havia evoluído para um Celeron Dual Core E3300, 2 GB de RAM DDR2-800 e 1 TB de armazenamento em disco - foi apenas em 2013 que o atualizei para a configuração atual. A instalação do Windows Server é praticamente idêntica às versões desktop do Windows, sem grandes complicações. E após a instalação, pude felizmente constatar que ambas as placas de rede estavam funcionais sem precisar instalar qualquer driver avulso.

Em pouco tempo, restabeleci o serviço de compartilhamento básico da Internet, o firewall (usando o nativo do próprio Windows que é bem razoável) e o servidor de DHCP, cuja configuração é bastante simples no Windows (aliás, caso queiram, posso em futuras postagens mostrar diversas configurações do Windows Server). O serviço de compartilhamento de arquivos foi restabelecido após o final da cópia dos arquivos que estavam no HD externo para as partições agora formatadas em NTFS. Ufa, agora eu já podia ir dormir tranquilo, afinal o dia estava quase amanhecendo! :-)

Nas semanas seguintes fui incluindo novos serviços no Windows Server. O Active Directory foi o primeiro deles, e cabe aqui um espaço para falar sobre ele, que é um serviço de diretório fantástico! Basicamente, ele permite centralizar no servidor as configurações referentes aos equipamentos, configurações do sistema operacional e dos usuários. A grosso modo, em todas as máquinas pertencentes ao domínio que eu logar com o meu nome de usuário eu obtenho as mesmas configurações do Windows, incluindo permissões de acesso. Para aqueles que usam plataforma Microsoft, é um must have!

Outro serviço que eu incluí foi o Windows Server Update Services (conhecido pela sigla WSUS), que é uma interface de gerenciamento que concentra no servidor as atualizações de várias versões do Windows e de outros produtos da Microsoft, como o Office. É muito útil para ambientes com múltiplos equipamentos, visto que eles não necessitarão um a um baixar da Internet as atualizações do sistema operacional, economizando banda - ao invés de baixarem do site Microsoft Update, as atualizações são baixadas do próprio servidor WSUS pela rede interna. No meu caso é algo útil pois, além dos vários equipamentos que tenho, também posso manter atualizadas as minhas máquinas virtuais e equipamentos de clientes que eventualmente faço manutenção, poupando a minha escassa conexão à Internet.

A grande lacuna que eu sentia no Windows Server, em comparação com o Linux, era a falta de um proxy web com cache disponível de forma nativa.  Um proxy com cache armazena no disco do servidor uma imagem das páginas acessadas, baixando da Internet apenas se houverem atualizações, o que também ajuda a economizar a banda de conexão. Pesquisando, encontrei o Squid for Windows, que é um Squid compilado para o Windows. Pude, inclusive, aproveitar o mesmo arquivo de configuração (squid.conf) que usava no Debian, muito bom!

No Debian eu também rodava o rsync, que é um serviço de backups incrementais de pastas e arquivos individuais. Um backup incremental permite copiar apenas os arquivos que foram incluídos e modificados desde a última sincronização, o que reduz o tempo de processamento das cópias de segurança devido ao menor volume de dados sendo transmitidos pela rede. Para o mundo Windows descobri o utilitário DeltaCopy que implementa o serviço rsync de forma idêntica.

Desta forma, o meu Windows Server 2008 R2 atualmente provê os seguintes serviços:

  • Proxy com cache (Squid for Windows);
  • Firewall;
  • Servidor DHCP;
  • Servidor de arquivos;
  • Backup incremental (DeltaCopy);
  • Active Directory;
  • Windows Server Update Services (WSUS).

E vem rodando maravilhosamente bem até a data em que escrevo, sem qualquer problema digno de nota.

Obtendo o Windows Server de forma legal (nos dois sentidos)

Como já expressei em outra postagem, sou radicalmente contra a utilização de softwares piratas, e sei que muitos devem estar pensando: mas comprar uma caríssima licença do Windows Server para uso doméstico? Estás louco? Concordo que a licença dele é cara para nós, pobres mortais assalariados, mas há alternativas para obtê-lo de forma legal a um custo mais camarada, ou mesmo de graça!

Caso você seja estudante ou professor universitário, a Microsoft tem uma iniciativa chamada DreamSpark, que consiste no fornecimento gratuito de software para alunos e instituições conveniadas. No meu caso, como não sou mais aluno (sou formado em Ciência da Computação há mais de uma década...) e infelizmente ainda não sou professor universitário (quem sabe um dia...) fiz uma assinatura Technet, que por cerca de 300 reais anuais fornece acesso a quase todo o portfólio de softwares da Microsoft. Infelizmente, porém, a Microsoft encerrou o plano Technet no ano passado, não aceitando mais novas assinaturas. Uma pena! Mas mesmo com o plano encerrado, as licenças obtidas através dele continuam válidas.

Outra opção, embora de preço (bem) mais salgado, é comprar uma assinatura MSDN Operating Systems na Microsoft Store, que custa em torno de R$ 1300 anuais porém oferece licenças de todos os sistemas operacionais modernos da Microsoft, tanto para servidores quanto para desktop. Dependendo do número de licenças que você for utilizar pode valer a pena, mas sem dúvida o custo não é nada camarada! Mas sempre é bom lembrar - mesmo que em um determinado momento você não queira mais renovar a assinatura (cuja renovação custa em torno dos 800 reais), as licenças obtidas continuam válidas.

E, é claro, sempre é possível utilizar o Linux e não pagar nada!


Afinal das contas, qual é o melhor?

Não há um produto melhor ou pior. Depende da necessidade, que deve ser avaliada cuidadosamente. A grosso modo, caso você tenha a intenção de trabalhar com Active Directory e/ou seja desenvolvedor em Visual Studio, sem dúvida é melhor optar pela plataforma Microsoft. Nos outros cenários uma distribuição Linux, principalmente as mais profissionais como o Debian ou o CentOS, será capaz de lhe atender de forma bastante satisfatória, principalmente se você fizer uso do trio Apache/PHP/MySQL (que também podem ser instalados no Windows de qualquer modo), além de, é claro, lhe poupar o custo da aquisição de uma licença do Windows Server que dependendo do caso não é exatamente barata.

Anterior:

Meu pequeno servidor doméstico (Parte 2 - Infraestrutura)

Veja também:
Especial Windows Server 2012 R2 (Parte 1 - Planejamento e instalação)
Dica Linux: programando em Shell Script

Comentários

  1. Nem muito lá, nem muito cá, esse povo que só vive de software livre é muito socialistinha, mas o outro lado, os defensores da apple e da microsoft são fags, o esquema é ver as coisas boas de ambos os lados, e as ruins e enumerar, a microsoft evoluiu demais o windows e isso é fato incontenstável...

    ResponderExcluir
    Respostas
    1. Desde a versão 2000 o Windows Server melhorou muito, isto é fato! E eu também não curto extremistas de ambos os lados - cada solução tem as suas vantagens e desvantagens.

      Excluir
  2. Essa compilação do Squid para Windows linkada no post (http://squid.acmeconsulting.it) é pré-histórica (nem HTTP 1.1 suporta) e não deve ser usada. No começo da série 3, muita gente preferiu ficar na série 2 por um tempo, mas hoje em dia não tem mais motivo. Pelo contrário: por não suportar HTTP 1.1, seu cache funcionará abaixo do que poderia com uma versão mais recente, além do perigo das falhas de segurança não consertadas. Outra coisa importante ao atualizar de versões muito antigas é rodar 'squid -k parse' para o programa fazer uma varredura no arquivo de configuração e avisar caso encontre opções obsoletas, prejudiciais ou não mais funcionais (altíssima chance de uma penca delas existir ao migrar do Squid 2 para o 3).

    Versões atuais aqui: http://squid.diladele.com/

    ResponderExcluir
    Respostas
    1. Opa, muito obrigado pelo link! Esta versão além de desatualizada ainda tá com o link quebrado... rsrsrs
      Vou atualizar a postagem, por isso que sempre é bom a gente as vezes revisar as postagens mais antigas.... um forte abraço!

      Excluir

Postar um comentário