Arquivo para Categoria 'sysadmin'

11/maio/2008

pfsense: firewall enterprise baseado no FreeBSD

pfsense[1] é um projeto de firewall baseado no FreeBSD que tem mais de um milhão de downloads. Nasceu em 2004 como um fork do projeto m0n0wall[2] com foco na utilização do filtro de pacotes pf,  baseado em uma versão mais atual do FreeBSD e instalável em plataforma PC e não somente em sistemas embarcados.

Com uma imagem de apenas 60MB você queima um livecd e tem todas as opções e configurações através de uma interface web. O pfsense suporta a grande maioria de serviços necessários a qualquer firewall e/ou gateway de rede, alguns exemplos são DHCP, DNS, firewall, traffic shaper, VPN, NAT, Proxy, Captive Portal, balanceamento de links e muitas outras características[3]. O pfsense possui ainda a capacidade de receber novos pacotes e funcionalidades tudo instalado pelo navegador. Toda a configuração é armazenada em um arquivo único no formato XML . A visualização de gráficos do tráfego da rede e arquivos de logs do sistema também são visualizado pela web, tudo pré-configurado e muito amigável.

Realmente vale muito conhecê-lo e utilizá-lo. Descobri esta preciosidade procurando uma distribuição Linux especializada. Fiz testes básico com o ipcop[4] e o smoothwall[5], mas quando encontrei o pfsense não acreditei que poderia existir uma distro com um nível de especialização tão grande e com  tantas funcionalidades se comparado a outras distros do segmento. Como eu já estava planejando iniciar o uso do FreeBSD em minha rede e não conseguia tempo para estudos e testes, foi a mesma coisa de “juntar a fome com a vontade de comer”.

Em breve pretendo compartilhar umas dicas e experiências com pfsense.

[1] - http://www.pfsense.com/
[2] - http://m0n0.ch/wall/
[3] - Características do pfsense
[4] - http://www.ipcop.org/
[5] - http://www.smoothwall.org/

Deixe um comentário »

10/março/2008

mod_gnutls: domínios virtuais com SSL baseados em nome no Apache

Um recurso muito desejado durante algum tempo por muitos administradores de servidores era a possibilidade de hospedar domíninos virtuais baseados em nome no Apache e habilitar o SSL (Secure Sockets Layer) de forma independente para cada domínio sem a necessidade de dedicar um IP exclusivo aos mesmos. Contudo uma extensão à TLS denominada SNI (Server Name Indication) descrita na RFC3546 possibilita a implementação do SSL em servidores baseados em nome. O grande problema é que a biblioteca OpenSSL em sua versão atual 0.98 ainda não suporta SNI, sendo este recurso prometido para a versão 0.99. Mas como no universo Open Source encontramos excelentes alternativas para quase tudo que existe, contamos também com um módulo experimental para o Apache chamado mod_gnutls. Apesar de ser experimental o mod_gnutls já tem mais de dois anos de estrada e segundo relatos e experiências o módulo é bem estável e não efeta a performace do servidor fora do esperado.

 

Dentre as nuances de uma implementação desta deve-se considerar a compatibilidade do navegadores com SNI, atualmente só navegadores mais modernos funcionam (Firefox 2, IE 7 on Vista, Opera 7.6+). Ainda existe a opção de utilizar versões snapshot do OpenSSL ou até mesmo patches que habilitam o suporte a SNI.

 

Siga as referências abaixo para obter mais informações e implementar esta solução:

 

http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

http://gentoo-wiki.com/HOWTO_Apache_with_Name_Based_Hosting_and_SSL

http://www.outoforder.cc/projects/apache/mod_gnutls/

http://weblogs.mozillazine.org/gerv/archives/2007/08/virtual_hosting_ssl_and_sni.html

https://sni.velox.ch/

 

 

 

Deixe um comentário »

10/março/2008

HTB-Tools: exemplos práticos de configuração

Posts na série Controle de Banda com HTB-Tools

  1. Controle de Banda Descomplicado com HTB Tools
  2. HTB-Tools: exemplos práticos de configuração

Originalmente publicado em http://wasare.net em 19/01/2007

O HTB-Tools é uma excelente ferramenta de auxílio na configuração do HTB (Hierarchical Token Bucket) para limitação de uso de banda. Como o primeiro artigo sobre o HTB-Tools explicando o uso da ferramenta gerou muitas consultas e dúvidas dos leitores resolvi escrever uma pequena complementação. Agora vou dar exemplos mais concretos de configurações específicas de uso cotidiano.

SE VOCÊ NÃO SABE O QUE É HTB OU HTB-TOOLS LEIA O PRIMEIRO ARTIGO ANTES!

OS EXEMPLOS A BAIXO SÃO MERAMENTE ILUSTRATIVOS!

1. Download e Upload com taxas diferentes

Partindo do exemplo do próprio artigo vamos supor que os cliente deveriam ter a mesma taxa de download do exemplo, mas que o upload seria limitado à metade ou seja 96kbps e 128kbps para upload, garantidos e máximo,repectivamente.

Supondo que a sua interface LAN seja a mesma eth0 vamos controlar o upload/download criando o arquivo /etc/htb/eth0-qos.cfg com o seguinte conteúdo:

class eth1-WAN {
        bandwidth 100000;
        limit 100000;
        burst 64;
        priority 1;
        client WAN {
                bandwidth 100000;
                limit 100000;
                burst 64;
                priority 1;
                dst { X.X.X.X/X; # ip/máscara da sua rede WAN
                };
                src { X.X.X.X/X; # ip/máscara da sua rede WAN
                };
       };

};

class eth1-WAN-cliente {
        bandwidth 360;
        limit 360;
        burst 8;
        priority 1;
        client DEDICADO_1 {
                bandwidth 360;
                limit 360;
                burst 8;
                priority 1;
                src { 0.0.0.0/0; };
                dst { 0.0.0.0/0; };
       };

};
class default { bandwidth 8; };

Entendendo: Dentro do arquivo eth1-qos.cfg temos duas classes especiais: eth1-WAN (client WAN) e eth1-WAN-cliente (client DEDICADO_1). A classe eth1-WAN estipula um limite de 100.000 kbps para tráfego para a sua própria rede (src e dst). A outra classe eth1-WAN-cliente vai limitar o tráfego para o “mundo externo” em 360kbps tanto para download (dst) quanto para upload (src). O que deve ser observado é que a classe eth1-WAN dá prioridade e libera a sua rede WAN para qualquer velocidade de tráfego enquanto a classe eth1-WAN-cliente limite todo o resto à 360kbps. O problema ocorre quando na LAN você tem diversos clientes concorrentes entre si pelos 360kpbs e ainda . Este caso é tratado em seguida.

2. Compartilhando conexão a uma taxa fixa

Um caso comum que pode ocorrer é você ter uma boa conexão e um cliente quer um link mais dedicado com servidor próprio. Supondo que você tenha um link de 1Mbps e o cliente contrate 360kbps que deve ser compartilhados através de um servidor próprio do cliente (qualquer pentium 100 já serve). Vamos considerar que a interface WAN seja a eth1 e a LAN a eth0. Na LAN não será preciso nenhuma limitação, contudo para a interface WAN (eth1) criamos o seguinte arquivo de configuração - /etc/htb/eth1-qos.cfg :

class eth1-WAN {
        bandwidth 100000;
        limit 100000;
        burst 64;
        priority 1;
        client WAN {
                bandwidth 100000;
                limit 100000;
                burst 64;
                priority 1;
                dst {
                        X.X.X.X/X; # ip/máscara da sua rede WAN
                };
                src {
                       X.X.X.X/X; # ip/máscara da sua rede WAN
                };
       };
 
};
 
class eth1-WAN-cliente {
        bandwidth 360;
        limit 360;
        burst 8;
        priority 1;
        client DEDICADO_1 {
                bandwidth 360;
                limit 360;
                burst 8;
                priority 1;
                src {
                        0.0.0.0/0;
                };
                dst {
                        0.0.0.0/0;
                };
       };
 
};
class default { bandwidth 8; };

Entendendo: Dentro do arquivo eth1-qos.cfg temos duas classes especiais: eth1-WAN (client WAN) e eth1-WAN-cliente (client DEDICADO_1). A classe eth1-WAN estipula um limite de 100.000 kbps para tráfego para a sua própria rede (src e dst). A outra classe eth1-WAN-cliente vai limitar o tráfego para o “mundo externo” em 360kbps tanto para download (dst) quanto para upload (src). O que deve ser observado é que a classe eth1-WAN dá prioridade e libera a sua rede WAN para qualquer velocidade de tráfego enquanto a classe eth1-WAN-cliente limite todo o resto à 360kbps. O problema ocorre quando na LAN você tem diversos clientes concorrentes entre si pelos 360kpbs e ainda . Este caso é tratado em seguida.

3. Limitando apenas as conexões para a Internet

Uma caso muito frequente é quanto temos um gateway em nossa rede que além de compartilhar a Internet fornece aos usuários de nossa WAN/LAN outros serviços como servidor de arquivo, ftp, etc. Se limitarmos o tráfego de acordo com o primeiro exemplo conseguimos controlar o uso do link da Internet, contudo todos os outros serviços fornecidos pelo gateway também serão “estrangulados”, tornado o uso da rede insuportável! O que fazer então? O segundo exemplo consegue resolver em parte nosso problema pois limita o tráfego globalmente apenas para conexões externas (WAN) e as conexões da LAN fluirão livremente. Mas por outro lado se tivermos qualquer serviço rodando pelo lado externo / WAN e que deve ser utilizado a partir de outra rede externa será limitado à 360kbps. Para resolver este problema existe duas alternativas: 1ª incluir as redes de onde serão acessados os serviços no “client WAN” da classe eth1-WAN (exemplo 2) ou 2ª limitar o tráfego apartir da interface da LAN (eth0), sem limitar o tráfego interno. A primeira alternativa pode se tornar um pouco inconveniente se os clientes/usuários externos acessarem de redes diversas. A segunda solução é a mais usual para a maioria dos casos. Então vamos deixar a WAN (eth1) com o tráfego liberado e faremos o controle de banda pela LAN (eth0), devemos criar o seguite arquivo /etc/htb/eth0-qos.cfg:

class eth0-LAN {
        bandwidth 100000;
        limit 100000;
        burst 32;
        priority 1;
        client LAN-LAN {
                bandwidth 100000;
                limit 100000;
                burst 32;
                priority 1;
                src {
                        X.X.X.X/X; # ip/máscara da sua rede WAN
                        192.168.0.0/24; # ip/máscara da sua rede LAN
                };
                dst {
                        X.X.X.X/X; # ip/máscara da sua rede WAN
                        192.168.0.0/24; # ip/máscara da sua rede LAN
                };
       };
 
       client LAN0-WAN {
                bandwidth 360;
                limit 360;
                burst 8;
                priority 1;
                dst {
                        0.0.0.0/0;
                };
                src {
                        0.0.0.0/0;
                };
       };
 
};
 
class default { bandwidth 8; };

Entendendo: Sempre que o destino ou a origem do tráfego for a nossa própria rede teremos uma taxa de 100.000kbps. Para todos os outros destinos e origens (0.0.0.0/0) estaremos limitando o tráfego à 360kbps.

4. Conclusão

A dupla HTB e HTB-Tools fazem a alegria de qualquer administrador de redes! @;)

4 Comentários »

10/março/2008

Controle de Banda Descomplicado com HTB Tools

Posts na série Controle de Banda com HTB-Tools

  1. Controle de Banda Descomplicado com HTB Tools
  2. HTB-Tools: exemplos práticos de configuração

Originalmente publicado em http://wasare.net em 12/08/2006 e na SlackwareZine Nº 9

 

  1. Introdução
  2. Instalação
  3. Configuração
  4. Ativando o HTB
  5. Monitorando o Controle de Banda

 

1. Introdução

O HTB (Hierarchical Token Bucket) é uma boa alternativa em substituição ao CBQ (Class Based Queueing) pois este é mais preciso e fácil de utilizar (será? Para mim foi). A diferença para o CBQ é que ele aloca banda para uma ou mais classes (”links virtuais”) e toma emprestada temporariamente a banda de outra classe que não esteja sendo utilizada completamente. Ainda diferentemente do CBQ você pode alocar diversos clientes em uma mesma classe. Para utilizar o HTB você precisa de um kernel maior ou igual 2.4.20 e da ferramenta tc (Traffic Control) incluída no pacote iproute2 sendo requerido o pacote iproute2 >= 2.6.10-ss050124. Eu utilizei apenas o Slackware 10.2 (kernel 2.4.31 ou kernel 2.6.13) com o pacote iproute2-2.6.11_050330 (série n do slackware) instalado.

Para configurarmos o HTB temos basicamente três alternativas:

  • Criar um script com todos os comandos (se você souber quais é claro);
  • Utilizar o utilitário htb.init script semelhante ao cbq.init e que demanda uma série de configurações, bem familiar para quem já utiliza o CBQ; ou
  • Utilizar a ferramenta HTB Tools. Como eu quero simplificar e não tenho experiência com o CBQ optei pelo HTB Tools criada dentro da filosofia do Slackware.

Faça o download do HTB-tools-0.2.7.tar.gz em: http://htb-tools.arny.ro/download.php

Caso não goste de instalar manualmente e queira pular para a configuração baixe o pacote no formato .tgz no mesmo link acima ou em: http://www.linuxpackages.net/pkg_details.php?id=8121

Descompacte o pacote com os fontes e execute:

root@ice:~# cd  HTB-tools-0.2.7 ; make ; make install

Para completar a instalação, execute os seguintes comandos:

root@ice:~/HTB-tools-0.2.7# mkdir -p /etc/htb
root@ice:~/HTB-tools-0.2.7# cp sys/scripts/rc.htb /etc/rc.d/rc.htb
root@ice:~/HTB-tools-0.2.7# cp sys/cfg/eth0-qos.cfg /etc/htb/eth0-qos.cfg
root@ice:~/HTB-tools-0.2.7# cp sys/cfg/eth1-qos.cfg /etc/htb/eth1-qos.cfg

Acima copiamos os arquivos de configuração de exemplo para as interfaces eth0 e eth1 e o script de inicialização rc.htb.

Para o formato .tgz , execute apenas:

root@ice:~# installpkg HTB-tools-0.2.7-i486-1wsa.tgz

3. Configuração

Instalado o HTB Tools seu Slackware terá os executáveis:

  • q_parser - lê o arquivo de configuração onde os clientes, as
    classes, e a banda alocada é definida e gera um script conforme as
    configurações estabelecidas;
  • q_show - exibe em tempo real a banda usada/alocada para cada
    classe/cliente de acordo com a configuração;
  • q_checkcfg - verifica a sintaxe do arquivo de configuração;
  • htb - script que executa rotinas com os binários q_show,
    q_parser, q_checkcfg;
  • htbgen - utilitário para gerar arquivos de configuração para
    redes classes C.

Os arquivos de configuração ficam em /etc/htb. Utilizando o HTB Tools conseguimos simplificar bastante a configuração e monitoramento de alocação de banda tanto para upload como para download.

A grande sacada do criador do HTB Tools foi definir uma configuração semelhante a do arquivo named.conf (quem nunca deu uma espiada?). Vamos ao exemplo: você possue um link de 512kpbs compartilhado entre dois clientes , teoricamente cada um deveria ter 256kpbs garantidos (QOS), contudo você deixou a coisa frouxa e um dos clientes começa a reclamar que o link está muito lento e que não consegue realizar transações importantes. Não precisa dizer mais nada, o outro cliente está “abusando” do link. A culpa não é dele, pois você deixou, não é mesmo? Para resolver este problema vamos de fato distribuir o link da seguinte forma: cada cliente terá 192kpbs garantidos e no máximo 256kps para upload/download.

Supondo que a sua interface LAN seja a eth0 vamos controlar o upload/download criando o arquivo /etc/htb/eth0-qos.cfg com o seguinte conteúdo:

class Wireless {
              bandwidth 480;
              limit 512;
              burst 2;
              priority 1;
 
             client cliente_1 {
                  bandwidth 192;
                  limit 256;
                  burst 2;
                  priority 1;
                  src { 192.168.1.2/24; };
                  dst { 192.168.1.2/24; };
             };
 
           client cliente_2 {
                  bandwidth 192;
                  limit 256;
                  burst 2;
                  priority 1;
                  src { 192.168.2.2/24; };
                  dst { 192.168.2.2/24; };
            };
 
};
 
class default { bandwidth 8; };

Como podemos observar a configuração é auto explicativa. Mas para não deixar dúvidas podemos observar que o src, como devemos suspeitar, é o source ou seja a origem do tráfego, por tando estamos limitando a saída (upload). No caso da diretiva dst controlamos o destino ou seja a entrada (download). A estrutura básica pode ser resumida em uma classe principal que é subdividida dentro de outras classes secundárias. Quando existe mais de uma classe principal estas não compartilham banda entre elas. As classes secundárias (clientes) podem compartilhar banda entre elas de acordo com a configuração (limit maior). Cada classe principal possue uma ou mais classes secundárias (clientes). A classe especial default especifica uma banda para os outros clientes/tráfegos que não estejam contemplados na configuração. A taxa de transferência e dada em kbit por segundo(kpbs).

Para controlar o download/upload na eth1 basta criar um arquivo semelhante ao /etc/htb/eth0-qos.cfg em /etc/htb/eth1-qos.cfg supondo que a sua interface eth1 seja da outra LAN ou a própria WAN. Em /etc/htb/eth1-qos.cfg crie a classe principal e as classes clientes conforme as necessidades.

Em configurações mais complexas você pode especificar diversos IP’s ou redes (rede/máscara) dentro de uma mesma classe secundária entre as chaves do src ou dst, sempre um(a) por linha e finalizado por um ponto-e-vírgula. Agora caso você queira limitar a banda para um serviço específico por exemplo ftp ou http dê um espaço e coloque a porta do serviço (em src ou dst), assim :

...
 
dst {
         192.168.3.0/24 21;
         192.168.4.0/24 80;
};
 
...

Atenção: cuidado ao criar as classes pois estará limitando todo o tráfego para aquele cliente/ip para todos os protocolos. Combine várias classes e configurações até chegar ao controle ideal.

Antes de ativar o controle de banda é recomendável verificar a sintaxe da configuração:

root@ice:~# q_checkcfg  /etc/htb/eth0-qos.cfg
root@ice:~# q_checkcfg  /etc/htb/eth1-qos.cfg

4. Ativando o HTB

Para facilitar as coisas tornamos o rc.htb executável:

root@ice:~# chmod +x /etc/rc.d/rc.htb

Com este script não precisamos executar diretamente os binários do
HTB Tools. Para ativarmos o htb para a eth0 executarmos dentro de
/etc/rc.d:

root@ice:/etc/rc.d# ./rc.htb start_eth0

Faça o mesmo para eth1 obviamente fazendo a substituição necessária de eth0 por eth1. Caso possua mais de duas interfaces altere o rc.htb de acordo com suas necessidades. Estando tudo correto vamos cuidar para que o HTB seja ativado a cada boot, acrescentando os comandos acima no rc.local ou em outro script de inicialização de sua preferência.

Exemplo:

root@ice:/etc/rc.d# echo "/etc/rc.d/rc.htb start_eth0" >> /etc/rc.d/rc.local
root@ice:/etc/rc.d# echo "/etc/rc.d/rc.htb start_eth1" >> /etc/rc.d/rc.local

5. Monitorando o Controle de Banda

Iniciado o HTB, você pode monitorar o uso do link em tempo real, para monitorar individualmente cada cliente fazendo upload ou download,
respectivamente, execute:

root@ice:/etc/rc.d# ./rc.htb show_eth0
root@ice:/etc/rc.d# ./rc.htb show_eth1

Dê uma olha no pacote HTB Tools e você ainda poderá lançar mão do utilitário htbgen para gerar o arquivo de configuração via assistente e terá uma forma de monitorar a utilização da banda pela web (q_show.php). É mole ou que mais!

Espero que consigam descomplicar o controle de banda com HTB Tools assim como eu consegui.

Deixe um comentário »

24/fevereiro/2008

Protengendo o acesso HTTP com antivírus - HAVP + Clamav + Squid

Posts na série Acesso HTTP com antivírus

  1. Protengendo o acesso HTTP com antivírus - HAVP no Debian “etch”
  2. Protengendo o acesso HTTP com antivírus - HAVP + Clamav + Squid

No post anterior desta série expliquei como instalar o pacote HAVP diretamente do repositório Debian oficial. Comentei sobre as dependências do Clamav, mas me esqueci de dizer que essencialmente precisamos apenas dos pacotes (básicos) clamav, clamav-freshclam e libclamav3, sendo dispensável o pacote clamav-daemon.

 

Nesta implementação considerei utilizar o HAVP como um proxy parente do Squid a melhor solução. A grande vantagem é que você continua com todos os beníficios das ACLs do Squid, ou seja poderá continuar controlando e filtrando todo o tráfego que passar pelo Squid e ainda ter a protenção contra vírus, conforme demostrado no esquema baixo.

HAVP como proxy parente do Squid

Para integramos o HAVP + Clamav + Squid, precisamos alterar alguns arquivos de configuração. Vou considerar que o Squid já esteja configurado e funcionando corretamente. Primeiramente editamos o /etc/havp/havp.config e alteramos algumas de suas seções para que fiquem iguais à:

USER havp
GROUP havp
LOG_OKS false
PORT 8080
BIND_ADDRESS 127.0.0.1
TEMPLATEPATH /etc/havp/templates/br
ENABLECLAMLIB true
ENABLECLAMD false

Penso que seja auto explicativo, mantenha todas as outras opções do arquivo intactas. Agora devemos indicar ao Squid qual é seu proxy parente, neste caso o HAVP, então acrescentamos as seguintes linhas ao /etc/squid.conf:

acl all src 0.0.0.0/0.0.0.0
cache_peer localhost parent 8080 0 no-query no-digest no-netdb-exchange default
cache_peer_access localhost allow all
 
# Todo o tráfego HTTP deve ser enviado ao proxy parente HAVP
acl HTTP proto HTTP
never_direct allow HTTP

Com as opções acima indicamos ao Squid que todo o tráfego HTTP deverá passar obrigatoriamente pelo proxy parente que fará a verificação com o antivírus Clamav. Antes de testar recarregue as novas configurações dos serviços envolvidos:

# invoke-rc.d havp force-reload
# invoke-rc.d squid force-reload

Para testar configure o seu navegador para acessar pelo Squid e visite a página http://www.eicar.org/download/eicar_com.zip, caso tudo esteja funcionando corretamente será exibida a tela abaixo.

HAVP bloqueando acesso ao “vírus” eicar

 

 

Acho que desta forma podemos ter uma boa segurança contra estes vírus espertos que enganam muita gente e causam muitos prejuízos as empresas.

Espero que tenham gostado e o resto fica por conta da imaginação de cada um, ou seja proxy transparente, customização dos templates do HAVP e outros ajustes finos que podenm ser feitos tanto no Squid quanto no HAVP. Como ponto de partida deixo, logo abaixo, algumas referências que utilizei.

 

http://www.server-side.de/ideas.htm
http://www.opensourcehowto.org/how-to/squid/squid-clamav–havp.html
http://sidux.com/PNphpBB2-viewtopic-t-7162.html

4 Comentários »

11/fevereiro/2008

Protengendo o acesso HTTP com antivírus - HAVP no Debian “etch”

Posts na série Acesso HTTP com antivírus

  1. Protengendo o acesso HTTP com antivírus - HAVP no Debian “etch”
  2. Protengendo o acesso HTTP com antivírus - HAVP + Clamav + Squid

Recentemente implantei uma solução de antivírus no Debian etch para compartilhamento de internet com o Squid integrando-o com HAVP + Clamav. O HAVP (HTTP Anti Virus Proxy) é um proxy HTTP antivírus e foi a solução escolhida pois me pareceu a mais simples e fácil de integrar. Mas o problema é que nos repositórios oficiais do Debian 4.0 “etch” não possue o pacote HAVP. Contudo nos repositórios Debian sid (unstable) o pacote HAVP esta lá e em sua mais recente versão 0.87. Então resolvi baixar o .deb do HAVP e instalar para ver o que acontecia (não custava tentar!). Ao executar o tradicional:

# dpkg -i havp_0.87-1_i386.deb

o sistema de gerenciamento de pacotes “reclama” de algumas dependências principalmente relacionadas ao clamav e à libclamav3, mas estas dependências não podem ser resolvidas pelos repositórios padrão do Debian etch. Neste momento tive a idéia de utilizar o repositório volatile, indispensável pra qualquer administrador de sistemas Debian. (mais sobre o uso do repositório volatile).

Depois de resolvidas as pendências o pacote HAVP instalou numa boa.

Baixe o pacote havp_0.87-1_i386.deb do mirror de sua preferência.

Agora como configurar o Squid, HAVP e Clamav para trabalharem juntos? No próximo post dou todas as dicas! Até lá.

Deixe um comentário »

4/fevereiro/2008

Volatile: Clamav e Spamassassin atualizados no Debian 4.0 “etch”

O Debian é reconhecido por sua estabilidade e por suas inovações em termos de distribuições Linux. Não é por acaso que o Debian é base para mais de 180 distros (incluindo derivadas como Kurumin, Knoppix e Ubuntu), ou seja mais da metade de todas as distros listadas no site DistroWatch.com.

Toda esta popularidade e robustez foram conquistados ao longo de anos de trabalho e rigor no empacotamento e distribuição dos mais de 20.000 pacotes oficialmente disponíveis. Muito bom para o administrador de redes que pode confiar no Debian pra qualquer serviço. Mas em alguns casos como anti-vírus, filtros anti-spam e atualização de fusos horários podem ser trabalhosas, pois na política Debian uma versão estável não recebe atualizações que alterem as características, funcionalidades e/ou a versão (numérica) do pacote. Daí muitos administradores podem recorrer ao repositório do debian backports que fornece pacotes mais atualizado (versões com novas funções) sem quebrar dependências no Debian stable. Mas o uso do backports nem sempre é recomendável, por não ser um projeto oficial.

Mas o projeto Debian identificou a necessidade de atualização mais frequente de certos pacotes que não poderiam acompanhar o ciclo normal de lançamento de novas releases estáveis. Para atender esta demanda foi criado o repositóro Volatile, através deste, todos que trabalham com o Debian estável, conseguem atualizações seguras de pacotes importantes sem gerar nenhum problema de dependências e o mais importante com todo o controle de qualidade dos pacotes Debian estáveis.

Para utilizar o repositório Volatile do Debian basta incluir no seu arquivo /etc/apt/sources.list a linha:

deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free

Depois adicione a chave GPG do repositório Volatile:

# wget -q http://www.debian.org/volatile/etch-volatile.asc -O- | apt-key add -

Depois basta atualizar as lista de pacotes e em seguida os pacotes, automaticamente seus pacotes instalados serão atualizados a partir do repositórito Volatile:

# aptitude update ; aptitude upgrade

1 Comentário »