Archive for December, 2008

ifconfig, você ainda usa?

tapeUltimamente venho percebendo que algumas coisas que deveriam ser extintas, não são. Não tenho nada contra se manter coisas depreciadas por compatibilidade, mas definitivamente, as distribuições modernas deveriam abolir ferramentas como o ifconfig. Ok, pode me bater se quizer, mas o por que utilizar uma ferramenta depreciada e limitada, se você pode utilizar algo extremamente mais moderno?

Normalmente as pessoas insistem em se manter na tal da “zona de conforto”. Eu confesso que certamente sou um dos que por comodidade muitas vezes prefiro manter as coisas como estão, só que definitivamente, já há algum tempo aboli duas ferramentas do meu repertório… ifconfig e route. Obviamente, me refiro ao ifconfig do Linux, pois em sistemas BSD, o ifconfig não te obriga a criar uma interface alias, ao invés de somente adicionar um IP alias em sua placa de rede…

Desde 1999 (ainda no kernel 2.2) foi liberado publicamente o iproute2, que nada mais é que uma série de utilitários escritos a fim de modernizar e compatibilizar os sistemas GNU/Linux com os outros sistemas operacionais de rede, como o IOS e outros que habitam diversos ativos de rede por aí. Além disso, o iproute2 traz uma ferramenta específica para controle de tráfego, coisa que (pasmem) muita gente ainda acredita que não exista no Linux.

Talvez você ache inútil trocar de ferramenta, mas fica extremamente claro que você precisa usar algo mais moderno quando vc tiver mais de 2 ips alias na mesma interface de rede. Eu realmente acho idiota, e totalmente ridículo existir os aliases eth0:1, eth0:2, eth0:3 e assim sucessivamente se na realidade, você só está colocando um ip alias na eth0. Não concorda que o comportamento dos BSDs são mais inteligentes, que simplesmente listam os aliases na mesma interface com o nome de alias? Então, já está aí uma boa justificativa para começar a usar o iproute2 pois agrega os endereços em uma mesma interface.

Se você achou que esta justificativa é insuficiente para largar o seu velho e conhecido ifconfig, tudo bem, mas e se eu te disse que a mesma ferramenta que você configura seu IP também configura o roteamento do seu sistema? Ohhhh! incrível! Poisé, o mesmo comando configura sua interface e ainda configura a tabela de roteamento do seu sistema!

Ainda não acha que é uma boa justificativa? Tudo bem, eu compreendo. Mas essa ferramenta apesar de tão simples e intuitiva ainda é capaz de gerenciar o tráfego de sua rede! Complicado de entender? Não acho. Imagine, seu sistema é responsável por gerenciar diversos links diferentes e você precisa priorizar o tráfego de determinado serviço. Sim, você pode criar uma rota e mandar tudo que vem da origem X sair pelo link Y, mas normalmente, depois de alguns dias, ao verificar a tabela de roteamento você não vai entender o que significa aquele amontoado de rotas que parecem não dizer nada. O iproute2 te auxilia bastante nesse sentido. Se você tem conjuntos de servidores por determinados serviços, você pode agrupá-los em rules e definir o tráfego através dessas rules. Depois, quando precisar listá-las, o que você poderá ver é uma lista nomeada de “o quê é o quê” e “pra onde vai o quê”.

Apesar de tudo isso, o maior mérito do iproute2 ainda é a ferramenta tc, que gerencia o controle de banda do Linux. Incrível é o fato de muitos SysAdmins não sabem sobre esta ferramenta. Ouvem muito falar sobre HTB e CBQ, e acreditam que HTB e CBQ sejam comandos ou programas, quando na verdade são qdiscs (Queue Disciplines) gerenciadas através do tc.

Tudo isso é realmente trivial, reconheço, só que acredito que seja importante nos renovarmos e nos compatibilizarmos com as outras ferramentas, que afinal, seguem o mesmo padrão. Talvez muitos SysAdmins não acreditem tanto na necessidade de mudança, pois normalmente a preocupação de um SysAdmin é acima da camada de rede, mas para um profissional de rede, essa mudança é de extrema importância. Apesar de eu ser um SysAdmin, tenho formação específica na área de rede, e talvez por isso seja tendêncioso e acredito na necessidade desta mudança, não só de ferramenta, mas de pensamento.

Se você se concorda com isso, o primeiro passo é ler bastante sobre o que o iproute2 pode fazer. Como esse artigo não tem a finalidade de ensinar nada, eu aconselho a leitura de dois documentos; Linux Advanced Routing & Traffic Control HOWTO e o HTB Manual - Ambos são ótimas fontes de informação sobre em que o iproute2 pode te ajudar.

No Comments

Os atuais MDAs e as linguagens de filtragem de e-mail (parte 2)

email.pngNesta segunda parte, venho mostrar aquele que é na minha opinião, o mais completo MDA para uso geral, O Courier-Maildrop.

À primeira vista, sei que este comentário parece tendencioso, mas independente de minha opinião pessoal, acho importante que se saiba as capacidades deste MDA antes de fazer sua escolha.

Novamente contarei um pouco de história, falando sobre o seu crescimento e amadurecimento. Trago também novos exemplos para mostrar aquilo que é o mínimo que a maildropfilter pode fazer.

Courier-Maildrop, o canivete suiço

Este MDA Surgiu em 1998, inicialmente como parte do Courier Mail Server, mas logo teve seu release standalone. Com o passar dos anos, foi se tornando um dos MDAs mais flexíveis e logo tornou-se também um dos mais usados, tendo como concorrente direto o vdeliver (parte do software vmailmgr, o qual não vou abordar) em servidores com Qmail. Com o advento do Postfix, teve um significante aumento em sua difusão, pois trata-se de uma alternativa eficaz para usuários virtuais. Durante uns bons anos foi considerada o melhor para este fim, devido sua flexibilidade. Em relação à sua linguagem para filtros, a maildropfilter é uma linguagem extremamente flexível e poderosa. Possui uma sintaxe muito parecida com Perl ou PHP e também características do POSIX Shell Script, e por isso podemos considerá-la extremamente intuitiva e com uma suave curva de aprendizado.

A maildropfilter não é somente uma linguagem que possibilita criar regras para filtragem de mensagens, mas sim, além dessa que é sua funcionalidade básica, é um processador de regras de negócio. Diferentemente do procmail e o Dovecot LDA (que veremos no próximo artigo), o maildrop é o único que por possuir realmente uma linguagem de programação embutida, pode proporcionar algo assim.

Da mesma forma que os outros MDAs, o maildrop inicia seu trabalho a partir de expressões regulares (PCRE) e finaliza seu trabalho quando encontra a declaração “to”. Inicia com diversas variáveis pré-definidas, e entre elas algumas importantes são: DEFAULT (Mailbox padrão para entrega. Para utilizar maildir, “Maildir/”), FROM, LOGNAME e SENDMAIL. Muitas outras estão disponíveis vide “man maildropfilter”.

Uma feature extremamente útil na minha opinião, é a capacidade de executar comandos de sistema. A maildropfilter o faz de duas formas: Através do comando xfilter ou da forma Unix like de receber saída de comandos, com as aspas invertidas. Ex. DIR=`ls`.

Podemos considerar a maildropfilter é uma linguagem completa, pois ela conta com os condicionais if e else, os laços while, for e foreach, operadores lógicos e bitwise e operadores de comparação, semelhantes ao POSIX Shell e Perl. Além disso, conta com comandos específicos para ajudar na filtragem. Veremos estes comandos nos exemplos à seguir.

Exemplos:

1. Filtrar todas as mensagens com Assunto ***SPAM*** para a pasta Mala Direta:

1
2
3
4
5
6
if ( /^Subject:.*SPAM.*/ )
{
    # Ao processar com sucesso o to o maildrop sai com EX_OK.
    # Em caso de erro EX_TEMPFAIL.
    to “$MAILDIR/.Mala Direta/}

2. Se a mensagem vier de “Grupo Email” verificar o assunto e se caso for “Teste do Maildrop” mover para a pasta “Grupo Email”:

1
2
3
4
5
6
7
if(/^From:.*GruposEmail.*/)
{
    if(/^Subject:.*Teste.do.Maildrop.*/)
    {
        to “$MAILDIR/Grupo Email/”
    }
}

3. Verificar no arquivo .config se o usuário possui o serviço de filtro de mensagens, e caso positivo, executar os filtros deste usuário e logar que será executado o filtro:

1
2
3
4
5
6
7
8
9
10
11
# seta local do logfile. Usuário rodando maildrop
# precisa de permissão de escrita no arquivo.
logfile “/var/log/maildrop.log”
 
# o comando lookup procura por patterns dentro de arquivos.
if(lookup(/^filterpref/, $HOME/.config))
{
    # grava no logfile.
    log “Este login possui filtros, executando”
    include $HOME/.myfilters
}

4. Verifica se o remetente está na blacklist

1
2
3
4
5
6
7
8
9
# a maildropfilter possui pattern matching, sendo assim você
# pode usar o resultado da expressão regular no seu script.
if(/^From:s*(.*)/ && lookup( $MATCH1, “blacklist.txt”) )
{
    # extrai o endereço RFC2822 do resultado da expressão.
    ADDR=getaddr($MATCH1)
    log “maildrop: $ADDR is on blacklist (dropped)”
    exit
}

Muitos outros exemplos e a documentação completa do maildrop e da maildropfilter podem ser conseguidas via o comando “man maildrop” e “man maildropex”, ou na página do Courier-Maildrop.

Como visto nos exemplos, o maildrop é um filtro avançado e o mais indicado quando é necessário colocar regras de negócio no procedimento de entrega dos e-mails. Lógicamente, se a sua única intenção é efetuar filtragens simples, você pode optar por outro MDA menos robusto. Isto também não significa que nestes casos você não deva o usar, pois a escolha também depende da combinação usada na instalação de seu servidor. Normalmente, se você utiliza Courier-IMAP, a melhor escolha é sempre o maildrop.

Espero que este artigo também tenha sido esclarecedor e como é de praxe, se você quiser conhecer mais sobre este MDA, acesse o site do Courier-Maildrop e também leia suas páginas de manual. Te garanto que é a melhor leitura pra quem quer aprender sobre este cara.

No próximo artigo, falarei sobre o Dovecot LDA, esse que é a coqueluxe do momento, e também sobre a história do Sieve. Até lá!

Bibliografia

maildrop documentation: http://www.courier-mta.org/maildrop/documentation.html
Páginas do manual: man maildropfilter, man maildropex

1 Comment