expediente editorial - linuxmag.com.br · bricantes de celulares equipados com a distribuição...

http://lnm.com.br/article/5681









3Linux Magazine #82 | Setembro de 2011

ED

ITO

RIA

L

Gostou do título? Foi mesmo para chamar sua atenção para o quebra-quebra que está ocorrendo entre as grandes empresas rivais do mercado de celula-res – encrenca cujas dimensões podem realmente ser caracterizadas como “super-hiper-ultra-mega-blaster”. De um lado do ringue, Apple; do outro, fa-bricantes de celulares equipados com a distribuição Linux Android (Samsung, Motorola – agora Google –, HTC e quem mais se aventurar). Na prática, entretanto, os canhões jurídicos da empresa de Steve Jobs estão apontados atualmente para a Samsung e o seu Galaxy Tab, Motorola e HTC, apesar de (ainda) não estarem na linha de frente no que se refere às acusações da Apple, já estão recebendo mensagens “sutis” de que haverá encrenca pela frente. Em miúdos, a Apple acusa a Samsung de ter copiado o iPad no Galaxy Tab, bem como ter violado direitos autorais da empresa de Cupertino. Neste caso, estamos falando apenas do “design” e do desenho externo do tablet, e não de violação de patentes da empresa da maçã. Como resultado, a corte alemã proibiu a comercialização do Galaxy Tab, a priori, em toda a União Europeia – à exceção da Holanda, onde corre outro processo em paralelo –, proibição essa que fi cou limitada posteriormente “apenas” à Alemanha. E, correndo por fora, encontramos uma acuada Microsoft, tentando extorquir de fabricantes de smartphones equipados com Android a bagatela de US$ 15 por aparelho vendido, sob o pretenso argumento de que seria dona de vá-rias tecnologias usadas pelo sistema operacional desenvolvido pelo Google.

Já escrevi alhures (http://migre.me/5vIWR) o que penso a respeito de paten-tes de software (e de patentes em geral), mas os desdobramentos da guerra de patentes defl agradas nesse segmento, além de confi rmarem minha opi-nião a respeito desse câncer da inovação, merecem algumas considerações.

A meu ver, o jogo todo tem por função a manutenção do monopólio das ideias e, com isso, a instauração de monopólios no mercado. Dane-se o con-sumidor, que não pode ter o melhor produto possível, uma vez que a empresa X, que teria o melhor produto, não poderá comercializá-lo com o recurso Y, pois o mesmo foi patenteado pela empresa W, e a empresa X é muito pequena e não tem como pagar à empresa W pela licença ou pelos royalties que lhe garantiriam o direito de usar uma ideia que ela já havia tido antes para um determinado recurso, mas que não protegeu a tempo, usando o “maravilhoso” sistema de concessão de patentes. Ou, se a empresa tiver condições de pagar pelos royalties, o preço do produto fi cará 10% mais caro, o que prejudicará a sua competitividade, deixando-o em desvantagem frente a concorrência.

Já pararam para analisar o absurdo disso tudo? Quer coisa mais an-ticapitalista? Trata-se da institucionalização do monopólio de ideias, pura e simplesmente, o que deixa alijados do mundo uma série de em-preendedores que não têm cacife para bancar esse jogo. A brincadeira toda acontece no Olimpo das megacorporações, que podem se dar ao luxo de gastar somas incalculáveis em ações judiciais monumentais. E, no caso do Android, praticamente todas as vantagens que lhe confere o fato de o sistema ser em grande parte de código aberto, acabam escor-rendo pelo ralo do esgoto das patentes, que terminam por encarecer o produto, difi cultando a sua adoção por diversos fabricantes.

Sou só eu, ou mais alguém acredita que há algo de muito podre em tudo isso? ■

Rafael Peregrino da SilvaDiretor de Redação

Super-hiper-ultra-mega-blasterExpediente editorialDiretor Geral Rafael Peregrino da Silva [email protected]

Editores Flávia Jobstraibizer [email protected]

Kemel Zaidan [email protected]

Editora de Arte Larissa Lima Zanini [email protected]

Estagiário Felipe Brumatti Sentelhas [email protected]

Colaboradores Andrej Radonic, Alexandre Borges, Alexandre Santos,

Augusto Campos, Ben Martin, Charly Kühnast, Chris Binnie, Dan Frost, Jon ‘maddog’ Hall, Klaus Knopper, Kurt Seifried, Ludger Schmitz, Mike Adolphs, Ralf Spenneberg, Thorsten Scherf, Timo Dreger, Zack Brown.

Tradução Rodrigo Afonso Garcia

Revisão Ana Hunger

Editores internacionais Uli Bantle, Andreas Bohle, Jens-Christoph Brendel, Hans-Georg Eßer, Markus Feilner, Oliver Frommel, Marcel Hilzinger, Mathias Huber, Anika Kehrer, Kristian Kißling, Jan Kleinert, Daniel Kottmair, Thomas Leichtenstern, Jörg Luther, Nils Magnus.

Anúncios: Rafael Peregrino da Silva (Brasil) [email protected] Tel.: +55 (0)11 3675-2600

Penny Wilby (Reino Unido e Irlanda) [email protected]

Amy Phalen (América do Norte) [email protected]

Hubert Wiest (Outros países) [email protected]

Diretor de operações

Claudio Bazzoli [email protected]

Na Internet: www.linuxmagazine.com.br – Brasil www.linux-magazin.de – Alemanha www.linux-magazine.com – Portal Mundial www.linuxmagazine.com.au – Austrália www.linux-magazine.es – Espanha www.linux-magazine.pl – Polônia www.linux-magazine.co.uk – Reino Unido www.linuxpromagazine.com – América do Norte

Apesar de todos os cuidados possíveis terem sido tomados durante a produção desta revista, a editora não é responsável por eventuais imprecisões nela contidas ou por consequências que advenham de seu uso. A utilização de qualquer material da revista ocorre por conta e risco do leitor.

Nenhum material pode ser reproduzido em qualquer meio, em parte ou no todo, sem permissão expressa da editora. Assu-me-se que qualquer correspondência recebida, tal como car-tas, emails, faxes, fotografi as, artigos e desenhos, sejam for-necidos para publicação ou licenciamento a terceiros de forma mundial não-exclusiva pela Linux New Media do Brasil, a me-nos que explicitamente indicado.

Linux é uma marca registrada de Linus Torvalds.

Linux Magazine é publicada mensalmente por:

Linux New Media do Brasil Editora Ltda. Rua São Bento, 500 Conj. 802 – Sé 01010-001 – São Paulo – SP – Brasil Tel.: +55 (0)11 3675-2600

Direitos Autorais e Marcas Registradas © 2004 - 2011–:Linux New Media do Brasil Editora Ltda.Impressão e Acabamento: RR Donnelley Distribuída em todo o país pela Dinap S.A., Distribuidora Nacional de Publicações, São Paulo.

Atendimento Assinante

www.linuxnewmedia.com.br/atendimentoSão Paulo: +55 (0)11 3675-2600 Rio de Janeiro: +55 (0)21 3512 0888 Belo Horizonte: +55 (0)31 3516 1280

ISSN 1806-9428 Impresso no Brasil

4 www.linuxmagazine.com.br

CAPA

Sempre disponível 31

Cada vez mais acessíveis, as tecnologias utilizadas por data centers

espalhados pelo mundo, hoje estão disponíveis para usuários domésticos.

Pulp: a sensação dos administradores 32

Se você usa software livre, provavelmente precisa gerenciar múltiplos

repositórios de software e manter todas as informações atualizadas. O

Pulp dá a você uma abordagem centralizada da gestão de repositórios .

Xen automatizado 36

Algumas técnicas básicas ajudam os administradores a alcançar

um bom nível de instalação do hypervisor comercial XenServer.

Gerenciamento centralizado 41

Se você gerencia muitos computadores idênticos em um parque

computacional, não gostaria de ter que atualizar cada um deles

individualmente somente para instalar uma atualização de segurança.

O Citrix Provisioning Services 5.0 oferece uma alternativa conveniente.

Cruzamento de nuvens 44

Ao confi gurar hospedagem em múltiplas infraestruturas de nuvem, você

evita aprisionamento ao fornecedor e ainda ganha benefícios adicionais.

ÍND

ICE





5

ANÁLISECostura dupla 48

Por mais de 10 anos, especialistas vêm prevendo a inevitável mudança do IPv4 para IPv6. NAT e CIDR mantiveram o IPv4 no topo desde então, mas isso irá mudar no fi nal deste ano. Para onde devemos ir?

Hardware sob controle 52O Udev executa e gerencia seu hardware no Linux. Explore o poderoso sistema e saiba como customizar a confi guração de seu hardware dentro das regras de udev.

Valor agregado 60

A ferramenta Opsi permite que administradores gerenciem clientes Windows a partir de um servidor Linux. A versão 4.0.1 ganhou novos recursos.

REDESOlhar atento 64

É claro que você tem um fi rewall, mas e se um intruso começar o seu trabalho de dentro da rede? As ferramentas de monitoramento ARP fi scalizam mudanças súbitas que podem indicar um ataque local.

SERVIÇOSEditorial 03Emails 06Linux.local 78Preview 82

Linux Magazine #82 | Setembro de 2011

| ÍNDICELinux Magazine 82

COLUNASKlaus Knopper 08

Charly Kühnast 10

Zack Brown 12

Augusto Campos 14

Kurt Seifried 16

Alexandre Borges 18

NOTÍCIASGeral 20

➧ Google e Mozilla trabalham juntos para que aplicativos web se integrem

➧ Nova versão do Ruby traz mudanças em sua licença

➧ Uma nova linguagem para consultas NoSQL

➧ Twitter irá liberar o código fonte do Storm

CORPORATENotícias 22

➧ Google compra patentes da IBM

➧ Dell abre código de sua solução para o OpenStack

➧ Red Hat lança o JBoss Application Server 7

➧ Canonical anuncia um novo programa de parcerias

Entrevista: Jon Melamut 26Em sua primeira participação no FISL , o vice-presidente de operações e produtos da Canonical nos concedeu uma entrevista exclusiva onde falou dos planos da empresa para o Brasil.

Coluna: Jon “maddog” Hall 28

Coluna: Alexandre Santos 30

TUTORIALHipergerenciamento 67

A inovadora ferramenta de gerenciamento Archipel usa o protocolo Jabber para conversar com servidores Xen, KVM , openvZ e VMware.

PROGRAMAÇÃO

Mistura de códigos 72

A mistura de linguagens de programação não deve restringir seu projeto de software. Aprenda a expor objetos e templates C++ ao código PHP e como registrar chamadas PHP que o código C++ possa utilizar.













31Linux Magazine #XX | Mês de 200X

Tecnologia para data centers

Sempre disponível Cada vez mais acessíveis, as tecnologias utilizadas por data centers espalhados

pelo mundo, hoje estão disponíveis para usuários domésticos.

por Flávia Jobstraibizer

Você estranharia saber que pode possuir em sua rede doméstica os mesmos recursos e ferramentas utili-zadas por grandes data centers? Se a sua resposta

é sim, então saiba que isso é uma realidade cada vez mais presente no dia a dia dos usuários domésticos.

Atualmente, as empresas que provêem serviços de cloud computing (computação em nuvem), segurança de infor-mação, e outros segmentos, estão cada vez mais atualiza-das com o mercado e utilizando ferramentas que, uma vez sendo softwares livres, estão acessíveis para que você, usuá-rio e leitor da Linux Magazine possa testá-las, aprender a utilizá-las e com isso, atestar a segurança do que você poderá potencialmente utilizar e contratar em um futuro próximo.

Nesta edição da Linux Magazine , você vai conhecer al-gumas das ferramentas utilizadas por data centers, como é o caso do Archipel, inovadora ferramenta de gerenciamento que trabalha em conjunto com Xen, KVM, openVZ e VMware.

Outro destaque desta edição, e que interessará muito aos profi ssionais de virtualização, é o artigo sobre XenServer, no qual são abordadas técnicas para realizar a instalação em larga escala – e de forma automatizada – da ferramenta.

Um aplicativo popular e muito útil, é o Arpwatch. Co-nhecida e utilizada há muitos anos, a ferramenta possui diversas e melhoradas versões desenvolvidas por diversos desenvolvedores ao longo dos anos e é imprescindível no arsenal de armas de monitoramento de rede. E se você pre-cisa checar e manter sistemas sempre disponíveis, estude-a e verá todo o potencial que terá nas mãos.

Os fãs de programação, também não precisam mais reclamar. Nesta edição, trouxemos um completo tutorial de PHP com C++. A mistura de códigos é uma realidade em diversas empresas que possuem sistemas legados e isso não deve ser um fator limi-tante para a continuidade de um projeto. Aprenda como obter o máximo das duas linguagens trabalhando conjuntamente.

Com a facilidade de acesso às ferramentas utilizadas por empresas e líderes do segmento de tecnologia, os usuários atualmente possuem maiores chances de tornarem-se es-pecialistas e utilizar melhor os recursos oferecidos pelos provedores. Aproveite esta facilidade e especialize-se! ■

CA

PA

Matérias de capaPulp: a sensação dos administradores 32

AutomatiXendo 36

Gerenciamento centralizado 41

Cruzamento de nuvens 44






ANÁLISE | IPv4/IPv6 em dual-stack

IPv4/IPv6 em dual-stack

Costura duplaCostura dupla Por mais de 10 anos, especialistas vêm prevendo a inevitável mudança do IPv4 para IPv6. NAT e CIDR

mantiveram o IPv4 no topo desde então, mas isso irá mudar no fi nal deste ano. Para onde devemos ir?

por Ralf Spenneberg

Muitos administradores de sistemas não terão que en-frentar o assunto IPv6 du-

rante os próximos dois anos, porque eles têm endereços IPv4 sufi cientes para garantir o seu acesso à Internet 4, graças a tradução de endereços de rede (NAT). O acesso à Internet 6 não é necessário para esses administrado-res, porque eles não oferecem serviços críticos para os negócios no momento.

No entanto, esse não é o caso de todos os administradores em todas as redes. Em alguns casos, faria sentido para um administrador se familiarizar com o IPv6 e adotá-lo, mas algo que deve fi car claro para todo administra-dor é que uma migração completa do IPv4 para o IPv6 é algo improvável de acontecer nos próximos 10 anos.

Posto isso, alguns novos serviços devem ser oferecidos na Internet 6 somente em alguns anos e os adminis-tradores vão precisar deles. Eles não têm alternativa senão introduzir IPv6 nas suas redes. E por quais razões?

1. Sua empresa quer oferecer mais serviços na rede e necessita de en-dereços IPv4 adicionais para tanto. Solicitar novos endereços não tem sido um problema até agora, mas a organização European IP Networks (RIPE), em particular, só emite en-dereços IPv4 para provedores em

considerável necessidade até que os estoques sejam completamente fi nalizados – o que deve acontecer em breve. Nesse caso, empresas não têm alternativa se não usar endereços IPv6. No momento, essa não é uma solução muito boa porque apenas um pequeno percentual de usuários com acesso a IPv6 pode ter acesso às ofertas de sua empresa.

2. A empresa trabalha com clien-tes e parceiros na Ásia. Em muitos casos, corporações asiáticas introdu-ziram uma solução de duplo NAT há muitos anos. E por muitos anos, alguns fornecedores na região asi-ática atribuíram somente endere-ços IP privados para seus clientes e mascararam esses endereços. Os clientes, por outro lado, usam rote-adores para converter os endereços IP privados usados internamente, o que frequentemente causa proble-mas. VPN e VoIP, em particular, são dois serviços que causam grandes problemas para administradores.

Com IPv6, clientes têm acesso glo-bal a todos os sistemas, o que garante conectividade descomplicada. Mas para acessar os serviços da empresa, o com-putador deve executar em dual stack (pilha dupla). Os sistemas, que antes só eram acessíveis via IPv4, precisam receber um endereço IPv6 também.

Simplicidade é tudo Os administradores devem estar se perguntando onde conseguir endere-ços IPv6. As pessoas com as quais você conversa são fornecedores de endereços IPv4. No entanto, apenas alguns ofere-cem acesso nativo a IPv6. No momento, esta é uma questão a ser resolvida atra-vés de um túnel: usar o IPv4 para criar um túnel para um provedor de túnel IPV6, que oferece acesso à Internet 6 por meio dele. Eles também oferecem endereços IPv6 (tipicamente na forma de um prefi xo /48) e os roteiam por meio do túnel. A SixX [1] e a Hurrica-ne Electric [2] servem principalmente a consumidores corporativos.

Após o registro, irão lhe oferecer o túnel e alguns endereços IPv6 de for-ma gratuita (até o presente momento). Então eles inserem esses endereços em seus servidores whois, mantendo a atribuição dos endereços detectá-veis para terceiros. As maneiras de se confi gurar os túneis mudam prin-cipalmente de acordo com a ponta do túnel no lado do cliente, caso esta possua endereço IPv4 estático, dinâ-mico ou mascarado de forma privada.

No primeiro caso, tudo o que você precisa fazer no Debian é criar um dispositivo de túnel adicional ao criar a seguinte entrada para seu /etc/network/interfaces :

AN

ÁLIS

E

49

| ANÁLISEIPv4/IPv6 em dual-stack


iface ipv6tunnel inet6 v4tunnelendpoint <EndIPv4doProvTunel>local <EndIPv4Local>address <EndIPv6Local>netmask 64mtu 1480gateway <EndIPv6doProvTunel>ttl 255

Essas linhas dão ao sistema acesso à Internet 6 por meio do túnel. Se o pro-vedor do túnel roteia um prefi xo IPv6 através do túnel, o administrador pode usar um daemon de anúncio de rotea-mento ou um DHCPv6 em sua rede.

Uma alternativa é vincular en-dereços IPv6 estáticos. Já que os hosts agora têm conectividade IPv4 e IPv6, a solução recebe o nome de operação em dual-stack.

Dual-Stack Lite ou NAT64? Apesar da escassez de endereços IPv4, os métodos Dual-Stack Lite (DS-Lite) e NAT64 precisam garantir a possibilidade de os clientes acessa-rem a Internet 4. Nos dois casos, o provedor fornece a seus clientes um endereço IPv6 global para o roteador e um prefi xo para os sistemas que estiverem por trás dele. No caso do DS-Lite ( fi gura 1 ), o provedor atribui um endereço IPv4 privado adicional para o roteador do cliente.

O roteador, em si, usa DHCP para distribuir endereços IPv4 privados na rede interna. O sistema agora tem um endereço IPv6 global e um IPv4 privado, cada um com seus gateways que apontam para o roteador. Quan-do um usuário acessa um website, o sistema primeiro desempenha uma resolução de nome. Se a resposta contém somente um endereço IPv6, o host usa o endereço IPv6 global para acessar o sistema-alvo. Se a resposta do DNS contém tanto um endere-ço IPv4 quanto um IPv6, o sistema operacional atual prefere IPv6 e, de novo, utiliza-o para acessar o sistema--alvo. O DS-Lite entra na jogada no caso de alvos somente com IPv4. O

cliente envia um pacote IPv4 com seu endereço privado de origem. O roteador então encapsula o pacote em um pacote IPv6, utilizando a conexão IPv6 para enviá-lo a um sis-tema especial no lado do provedor, que extrai o pacote IPv4 e usa NAT44 para convertê-lo em um endereço IPv4 global. Para que isso aconteça, o fornecedor precisa implementar componentes Carrier-Grade NAT (CGN) extremamente poderosos.

O sistema também costuma ser chamado de Address Family Transition Router (AFTR). Um administrador que trabalhe no provedor pode implemen-tar ATFR usando Linux e um pacote de software AFTR do Internet Soft-ware Consortium [3] . Uma vez que o roteador do lado do cliente não mais tem posse de endereços IPv4 globais, não posso utilizar serviços como o DynDNS ou port folding ; no entanto, quem cuida disso tudo é o IPv6, mas de uma forma bem superior.

No caso da segunda variante, NAT64, um fornecedor usa uma abordagem diferente para dar aos clientes acesso à Internet 4. O clien-te só ganha endereços IPv6 globais

para seu roteador e os sistemas que residem nele. A questão importante é que esses sistemas só usam o servidor DNS do provedor para a resolução de nomes, de três maneiras: • A resolução de nomes atribui apenas

um endereço IPV6: clientes usam seus endereços IPv6 globais para acessar o sistema-alvo;

• A resolução de nomes retorna tan-to um endereço IPv4 quanto um endereço IPv6: o cliente prefere o endereço IPv6 e o utiliza para acessar o sistema-alvo;

• A resolução de nome retorna apenas um endereço IPv4: nesse caso, o ser-vidor DNS do provedor intervém: ele faz o spoof de um endereço IPv6 adicional e acrescenta ele à resposta. Para que isso aconteça, o servidor

depende de uma representação hexa-decimal do endereço IPv4 e do prefi xo IPv6 previamente defi nido. O admi-nistrador do servidor DNS pode usar tanto o prefi xo reservado 64:FF9B::/96 ou um espectro livre de seu próprio estoque de endereços IPv6. O cliente recebe os dois endereços na resposta DNS e preferirá o endereço IPV6. O cliente manda os pacotes corres-

Figura 1 No Dual-Stack Lite, o fornecedor economiza endereços IPv4 globais

ao manipular NAT de endereços IPv4 privados, para endereços IPv4

globais (NAT44).


ANÁLISE | IPv4/IPv6 em dual-stack

pondentes para o gateway padrão do lado do provedor, quando o roteador identifi ca o endereço IPv6 que pas-sou pelo spoof ao analisar o prefi xo.

O sistema extrai o endereço IPv4 encapsulado e desempenha NAT ao efetuar a tradução do protocolo de IPv6 para IPv4. Os desenvolvedores se referem a esse método como NAT64 ( fi gura 2 ) e a camada necessária de aplicação de um gateway DNS como DNS64. Várias implementa-ções desse tipo existem para Linux. Um exemplo é a última versão do BIND, que já suporta o uso como um servidor DNS64. O componente NAT64 pode ser manipulado tanto pelo aplicativo que é executado no espaço do usuário ( userspace ) Tay-ga [4] , quanto pelo componente do kernel Ecdysis [5] .

Um dos problemas com a imple-mentação de NAT64 é a crescente po-pularidade do DNSSEC, que detecta qualquer modifi cação e falsifi cação nas respostas DNS, ignorando-as.

NAT-PT O documento RFC 2766 defi -

niu um NAT/tradutor de protocolo (NAT-PT) em 2000. Ao contrário do NAT64, ele também suporta NAT46, o que torna possível que não apenas sistemas IPv6 acessem quaisquer alvos IPv4, mas também que sistemas IPv4 acessem quais-quer endereços IPv6. Uma vez que o IPv4 pode ser facilmente embarca-do em endereços IPv6 com spoof, o NAT64 é bem simples de implemen-

tar, mas o sentido oposto pode ser bem mais complicado.

Os endereços IPv4 não possuem espaço sufi ciente para encapsular endereços IPV6 em endereços IPv4 com spoof, evitando que o DNS46 e NAT46 funcionem independentes um do outro porque eles precisam trocar informações constantemente. Embora algumas implementações vi-áveis existam, o RFC 2766 NAT-PT foi alterado em 2007 (sendo mantido apenas por razões históricas) por con-ta de vários problemas (RFC 4966).

Para um sistema somente em IPV4, não há atualmente uma solução dis-ponível para o acesso a hosts disponí-veis somente via IPv6. Um proxy em dual-stack pode oferecer uma forma de contornar isso: os clientes usariam IPv4 para contatar o proxy e acessar o sistema IPv6 alvo. No entanto, essa técnica suporta somente protocolos que permitem o uso de gateways na camada de aplicação, como DNS, SMTP, HTTP ou HTTPS.

O futuro Já que somente uma pequena por-centagem dos roteadores DSL exis-tentes suportam IPv6, os provedores precisam substituir os dispositivos terminais do lado dos consumidores antes de poder introduzir o IPv6 de forma abrangente – um processo caro o qual os consumidores não querem pagar. Por essa razão, provedores atrasarão a substituição o quanto for possível, o que levará muitos provedores de acesso a evitar a dor

de cabeça administrativa que será oferecer seus serviços também via IPv6. Apesar do bem-sucedido dia do IPv6, em junho, no qual muitos provedores ofereceram seus serviços em IPv6 por um dia, participantes proeminentes como Facebook, Goo-gle e YouTube descontinuaram suas operações em dual-stack.

Conclusão Enquanto os maiores provedores de serviço se recusarem a suportar o acesso IPv6 a seus serviços, o formato continuará desinteressante para os consumidores. Até que isso mude, provedores DSL provavelmente co-meçarão a emitir endereços IPv4 privados para seus clientes, como aconteceu na Ásia. ■

Figura 2 No NAT64, o provedor faz a intermediação de um endereço IPv6

para mascará-lo para IPv4.

Mais informações

[1] SixXs: http://www.sixxs.net/

[2] Hurricane Electric:

http://www.he.net/

[3] AFTR: http://www.isc.org/software/aftr

[4] Tayga: http://www.litech.org/tayga/

[5] Ecdysis: http://ecdysis.viagenie.ca/

O autor

Ralf Spenneberg é instrutor free-

lancer de Unix/Linux, consultor, au-

tor e CEO de sua própria empresa de

treinamento. Ralf publicou diversos

livros sobre detecção de invasão,

SELinux, fi rewall e VPNs. A segunda

edição de seu último livro, VPN on Li-

nux , foi publicada recentemente.

Gostou do artigo?Queremos ouvir sua opinião.

Fale conosco em

[email protected]

Este artigo no nosso site:


osso s

r/artic

m

zine.com

:

569

igo?opinião.

r


ANÁLISE | Gerenciamento de hardware com Udev

Entenda o Udev

Hardware sob controle O Udev executa e gerencia seu hardware no Linux. Explore o poderoso sistema e saiba

como customizar a confi guração de seu hardware dentro das regras de udev.

por Klaus Knopper

Nos velhos tempos, drivers de hardware faziam com que os dispositivos se tornassem

operacionais e acessíveis aos usuários. Embora eles ainda estejam presentes, hoje em dia pensamos neles como módulos – partes do kernel que po-dem tanto ser compilados em uma parte estática do sistema, executados durante a inicialização ou quando um novo componente é adicionado. O udev [1] é a ponte entre o supor-te ao hardware crítico do kernel e o espaço do usuário ( userspace ).

Neste artigo, exploro o sistema udev e mostro como adicionar re-gras para customizar o processo de confi guração de hardware.

Dispositivos e sistemas de arquivos “Tudo é um arquivo”, no Linux. Essa fi losofi a se aplica especialmente ao acesso a hardware por meio de arquivos de dispositivos, normalmente locali-zados dentro do diretório /dev ou em

seus subdiretórios. Os dois tipos prin-cipais de arquivos de dispositivos são os block devices e os character devices .

Block devices (b) permitem acesso arbitrário de leitura e escrita no espa-ço do endereço do hardware, orga-nizados em unidades como “blocos” (1024 bytes é o tamanho comum de um bloco). Os exemplos mais co-muns são discos rígidos e memórias.

Character devices (c) originalmente oferecem acesso de leitura e escrita caractere a caractere para o disposi-tivo, como os de dados em fi ta, entre outros. Mas também são usados para controlar recursos de hardware.

O kernel do Linux mantém con-trole sobre qual hardware pertence a qual dispositivo, por número ao invés de nome. Esses números são os “ major device ID ” e “ minor device ID ”, os quais podem ser descobertos por meio do comando:

ls -l /dev/devicename

No exemplo da listagem 1 , 8 é o “ma-jor device ID” do primeiro HD SATA

( sda ), que tem 0 (zero) como “minor device ID” para todo o disco. Os núme-ros 1 e 2 são os identifi cadores “minor” das duas primeiras partições do disco.

A próxima entrada de disco (o se-gundo disco SATA – sdb ) começa com o identifi cador “minor” 16 . O grupo floppy indica que o segundo disco é um dispositivo de mídia removível, tal-vez um drive USB de memória fl ash.

Em vez de suportar acesso direto de leitura e escrita para o hardware, arquivos de dispositivos suportam controles I/O (entrada e saída), que são comandos que você pode enviar para o driver do dispositivo enquanto abre o arquivo do dispositivo por meio de uma requisição do sistema ioctl() . Você pode usar controles de I/O para operações como particionar e apagar blocos, ou reconfi gurar um dispositivo.

As chamadas read/write e ioctl já foram os únicos meios de acessar hard-ware via dispositivos, mas a situação foi

AN

ÁLIS

E

Listagem 1: IDs dos dispositivos 01 $ ls -l /dev/sd[ab] /dev/sd[ab][1-2]02 brw-rw---- 1 root disk 8, 0 24. Apr 21:50 /dev/sda03 brw-rw---- 1 root disk 8, 1 24. Apr 21:50 /dev/sda104 brw-rw---- 1 root disk 8, 2 24. Apr 21:50 /dev/sda205 brw-rw---- 1 root floppy 8, 16 24. Apr 21:50 /dev/sdb06 brw-rw---- 1 root floppy 8, 17 24. Apr 21:50 /dev/sdb107 brw-rw---- 1 root floppy 8, 18 24. Apr 21:50 /dev/sdb2

Listagem 2: cpuinfo 01 $ cat /proc/cpuinfo02 processor : 003 vendor_id : GenuineIntel04 cpu family : 605 model : 2806 model name : Intel(R) Atom(TM) CPU Z520 @ 1.33GHz

07 stepping : 208 cpu MHz : 800.00009 cache size : 512 KB10 ...

53

| ANÁLISEGerenciamento de hardware com Udev


aprimorada com a chegada de sistemas de arquivos virtuais de confi guração, como o procfs e devfs. Sistemas de arquivos virtuais como esses contêm informações mais verbais e amigáveis sobre as confi gurações do hardware.

O procfs, que é padrão em todos os sistemas Linux modernos, per-mite que você veja informações de processos, sistema e hardware em tempo quase real, somente ao ler o conteúdo dos arquivos residentes no diretório /proc ( listagem 2 ).

Ele também permite a confi gura-ção de opções diferentes, não neces-sariamente relacionadas ao hardware, enquanto o sistema está em opera-ção, como direcionamento de IP ou gerenciamento de cache do drive.

# Enable IP-forwarding (routing)$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Tell drive cache management to only sync every 30 seconds

$ echo 3000 > /proc/sys/vm/ dirty_writeback_centisecs

O sistema de arquivos virtual ainda mais novo, sysfs, suporta um nível de interação com o hardware que vai muito além de simples controles I/O. Todos os dispositivos de hardware e componentes da placa principal do computador têm diretórios sysfs com informações e arquivos de controle, os quais permitem que se escrevam scritps em Shell para controlar o hardware. O udev é a ponte entre a parte do kernel (como os módulos e hardware que suportam os recursos do mesmo) e o userpace (programas para acessar e trabalhar com os hardwares).

Além disso, o udev tem alguns plugins que permitem interação com a sessão do desktop do usuário e pro-gramas de ajuda que exigem caixas de diálogo e pop-ups sempre que o status do hardware mudar.

Detecção de hardware Detectar hardware é relativamente fácil no Linux, porque todo dispositivo de hardware tem um número de identifi -

cação de dispositivo PCI real ou virtual, que abrange uma identifi cação do forne-cedor e uma identifi cação do dispositivo . O kernel Linux lê essas informações e exibe-as nos subdiretórios /sys :

$ cat /sys/devices/pci0000:00/ 0000:00:1c.1/0000:01:00.0/vendor

0x168c$ cat /sys/devices/pci0000:00/ 0000:00:1c.1/0000:01:00.0/device

0x002b

A parte ambiciosa é identifi car um driver que funcione com o dispositivo. Se você sabe o ID (número identifi ca-dor) do fornecedor e do dispositivo, pode usar o comando lspci com o banco de dados pci.ids para procurar por nomes de dispositivos “legíveis para humanos”, além do driver do dispositivo que deve colocá-lo em estado operacional.

$ lspci -k -d 0x168c:0x002b01:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)

Subsystem: AzureWave Device 1089Kernel driver in use: ath9k

No Linux, o nome do dispositivo é irrelevante. É importante selecionar o módulo do kernel que lida com o dis-positivo. Cada módulo tem uma tabela

embutida contendo os IDs de dispo-sitivo conhecidos. O comando acima identifi cou corretamente o driver do kernel (ath9k) associado ao par com-posto pelo ID do fornecedor e pelo ID do dispositivo (0x168c:0x002b), como o comando modinfo mostra ( listagem 3 ).

Um importante papel do udev, quan-do ele encontra um novo hardware, é ler a assinatura do dispositivo (PCI ID) e procurar por um módulo que contenha o ID. O udev executa, então, o módulo via modprobe , a menos que ele esteja na blacklist (lista negra) em /etc/modprobe.d/*.conf . O mecanismo hotplug notifi ca que o udev tem um novo dispositivo adicionado ao sistema, mas sem um script especial para lidar com os eventos (o diretório /proc/sys/kernel/hotplug deve estar vazio).

Pré-requisitos Apesar de não ser essencial, a maioria das distribuições envolvem serviços do sistema udev em scripts que subs-tituem o /dev com um pequeno disco de memória. O disco de memória cria e remove nós de dispositivo rapidamen-te; essa técnica requer que um certo arquivo seja criado (como o /dev/null , /dev/zero , /dev/console ) sem que sejam

Listagem 3: modinfo 01 $ modinfo ath9k02 filename: /lib/modules/2.6.39-rc4/kernel/drivers/net/03 wireless/ ath/ ath9k/ ath9k.ko04 license: Dual BSD/GPL05 description: Support for Atheros 802.11n wireless LAN cards.06 author: Atheros Communications07 alias: pci:v0000168Cd00000032sv*sd*bc*sc*i*08 alias: pci:v0000168Cd00000030sv*sd*bc*sc*i*09 alias: pci:v0000168Cd0000002Esv*sd*bc*sc*i*10 alias: pci:v0000168Cd0000002Dsv*sd*bc*sc*i*11 alias: pci:v0000168Cd0000002Csv*sd*bc*sc*i*12 alias: pci:v0000168Cd0000002Bsv*sd*bc*sc*i*13 alias: pci:v0000168Cd0000002Asv*sd*bc*sc*i*14 alias: pci:v0000168Cd00000029sv*sd*bc*sc*i*15 alias: pci:v0000168Cd00000027sv*sd*bc*sc*i*16 alias: pci:v0000168Cd00000024sv*sd*bc*sc*i*17 alias: pci:v0000168Cd00000023sv*sd*bc*sc*i*18 depends: ath9k_hw,mac80211,ath9k_common,ath,cfg8021119 vermagic: 2.6.39-rc4 SMP preempt mod_unload modversions ATOM20 parm: debug:Debugging mask (uint)21 parm: nohwcrypt:Disable hardware encryption (int)22 parm: blink:Enable LED blink on activity (int)23 parm: btcoex_enable:Enable wifi-BT coexistence (int)



disparados por detecção de hardware. Se o /dev/null ou dispositivos virtuais de console ou terminal, principalmen-te, estão faltando, os scripts tendem a criar diversos erros porque a saída padrão e as mensagens de erros não podem ser redirecionadas. Portanto, os scripts de init do udev mantêm uma cópia dos arquivos de dispositivos que são copiados tão logo o disco de me-mória /dev é montado. O udev precisa manter controle sobre seus próprios arquivos de confi guração e mudanças no sistema de arquivos virtuais, o que requer opções do kernel no tempo de compilação para programar o inotify .

Para interagir com outros programas do userspace relacionados a informa-ções e acesso de hardware, o udev vem com a biblioteca de sistema libudev .

Ação! As três principais ações das quais o udev é responsável são adicionar hardware ( add ), remover hardware ( remove ) e alterar ou notifi car sobre hardware existente ( change ). Para mo-nitorar os resultados desses comandos, use o comando udevadm monitor . As opções --property , --kernel e --udev produzem uma quantidade impres-sionante de informações cada vez que algo acontece no seu conjunto de hardware. Filtrei um exemplo para mostrar as partes mais interessantes sobre o que acontece quando um dri-ve de memória fl ash USB é plugado.

O retorno do udevadm monitor ( lis-tagem 4 ) mostra o caminho de dis-positivo do sistema a partir do sysfs, números ID major e minor e nomes de dispositivos sob os quais encontra-se a primeira partição do drive USB, /dev/sdb1 . Alguns dos pares de valor keyword = value mostrados na lista-gem 4 são variáveis de ambiente que são exportadas para Shells de scripts e programas chamados pelo udev.

Com a informação pronta, o udev começa a conferir as regras ( rules ). As regras oferecem uma camada para que o usuário atribua nomes

Listagem 4: udevadm monitor 01 $ udevadm monitor --property --kernel --udev02 o monitor retornará os eventos recebidos para:03 DEV - o evento no qual udev envia após o processamento da regra04 KERNEL - o uevent do kernel05 UDEV [1303690744.003838] add /devices/pci0000:00/0000:00:1d.7/ usb1/1-2 (usb)

06 UDEV_LOG=307 ACTION=add08 DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-209 SUBSYSTEM=usb10 DEVNAME=/dev/bus/usb/001/00311 DEVTYPE=usb_device12 PRODUCT=1221/3234/013 TYPE=0/0/014 BUSNUM=00115 DEVNUM=00316 SEQNUM=227217 ID_VENDOR=USB2.018 ID_VENDOR_ENC=USB2.019 ID_VENDOR_ID=122120 ID_MODEL=Flash_Disk21 ID_MODEL_ENC=Flash\x20Disk22 ID_MODEL_ID=323423 ID_REVISION=000024 ID_SERIAL=USB2.0_Flash_Disk_1000000000000D8A25 ID_SERIAL_SHORT=1000000000000D8A26 ID_BUS=usb27 ID_USB_INTERFACES=:080650:28 MAJOR=18929 MINOR=230 KERNEL[1303690745.279285] add /devices/pci0000:00/0000:00:1d.7/ usb1/1-2/1-2:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)

31 UDEV_LOG=332 ACTION=add33 DEVPATH= /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/ host2/target2:0:0/2:0:0:0/block/sdb

34 SUBSYSTEM=block35 DEVNAME=sdb36 DEVTYPE=disk37 SEQNUM=228538 MAJOR=839 MINOR=1640 KERNEL [1303690745.279497] add /devices/pci0000:00/0000:00:1d.7/ usb1/1-2/1-2:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb1 (block)

41 UDEV_LOG=342 ACTION=add43 DEVPATH= /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/ host2/target2:0:0/2:0:0:0/block/sdb/sdb1

44 SUBSYSTEM=block45 DEVNAME=sdb146 DEVTYPE=partition47 SEQNUM=228648 MAJOR=849 MINOR=1750 KERNEL [1303690745.281684] add /devices/pci0000:00/0000:00:1d.7/ usb1/1-2/1-2:1.0/host2/target2:0:0/2:0:0:0/scsi_generic/sg1 (scsi_generic)

51 UDEV_LOG=352 ACTION=add53 DEVPATH= /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/ host2/target2:0:0/2:0:0:0/scsi_generic/sg1

54 SUBSYSTEM=scsi_generic55 DEVNAME=sg156 SEQNUM=228757 MAJOR=21

55



representativos a cada dispositivo no /dev , permitindo sua manipulação.

Elas são especificadas por meio dos arquivos residentes em /lib/udev/rules.d para os padrões pré-defi nidos do sistema (as quais você pode mudar, claro) e no /etc/udev/rules.d para opções adicio-nais defi nidas pelo administrador. O udev executa esses arquivos de regras em ordem alfabética, mesclando os dois caminhos citados. Nomes de arquivo para regras geralmente começam com um número de dois dígitos, e a maioria termina com a extensão .rules .

As regras Nos últimos dois anos, a sintaxe dos arquivos .rules do udev passou por várias modifi cações no que diz res-peito a nomes de objetos e variáveis de ambiente. Neste artigo, cubro a versão 167 do udev.

Se os arquivos *.rules fossem sim-ples como scripts Shell, dirigidos por variáveis de ambientes, seria fácil demais. Infelizmente, essa aborda-gem seria inefi ciente porque muitos eventos podem ser disparados cada vez que algo muda, o que pode acon-tecer centenas de vezes por segundo.

Os arquivos de regras, portanto, têm uma sintaxe rígida, específi ca do udev. Essas regras são pré-compiladas na inicialização do udev, em vez de avaliadas em cada evento.

Em um arquivo de regras, uma linha de código (que pode ser dividida em várias com o uso da barra invertida ( \ ), tal como nos scripts Shell) lida com uma regra. A regra é defi nida por dois tipos de declarações: matches ( tabela 1 ) e actions ( tabela 2 ), separadas por vírgulas, que são checadas e executa-das desde que a declaração anterior retorne o valor verdadeiro (true).

Combinação* Contém

ACTION=="valor"Valores “add” para dispositivos removíveis recentemente plugados;

“change” para dispositivos já ligados, mas ainda não reportados ou

reconfi gurados; “remove” para dispositivos removidos ou desativados.

DRIVER=="valor" O driver (ou módulo de kernel) em uso para a condução do dispositivo.

KERNEL=="valor"O nome interno do kernel para o dispositivo (normalmente o mesmo

nome do dispositivo no diretório /dev). Wildcards Shell como ? (caracter

arbitrário) ou * (sequência arbitrária de caracteres) são suportados.

SUBSYSTEM=="valor" “block”, “pmcia”, “tty”, “usb” e outros, reportados no campo

SUBSYSTEM no monitor udevadm ou comando info.

SYSFS{keyword}=="valor" Lê o nome do arquivo chave do diretório sysfs do dispositivo.

Caiu em desuso com as versões ATTR e ATTRS do udev.

ATTR{keyword}=="valor" Atributo de palavra-chave reportado pelo udev (normalmente lido do

/proc ou /sys) para o dispositivo atualmente detectado ou identifi cado.

ATTRS{keyword}=="valor" Similar ao ATTR, mas para um “dispositivo pai” (parent device), que pode ser,

por exemplo, um disco, controlador ou sistema bus contendo partições.

KERNELS, SUBSYSTEMS, DRIVERS O mesmo que KERNEL, SUSBSYSTEM e DRIVER relacionados ao dispositivo

detectado, mas criado para dispositivos pai (parent devices).

ENV{keyword}=="valor" Uma variável de ambiente.

* Use != ao invés de == se você quiser verifi car se o dispositivo é diferente.

Tabela 1: Combinações nas regras do udev.

Ação Resultado

ENV{keyword}="valor"Confi gura e exporta uma variável de ambiente para o uso nas

próximas regras ou comandos. Variáveis de ambiente podem ser lidas

novamente em arquivos de rules udev por $env{keyworkd}.

MODE="permissões" Modo de permissão numérica para o arquivo de dispositivo criado em /dev.

GROUP="grupo" Confi gura o grupo para o arquivo de dispositivo criado em /dev.

Owner="nome_do_usuario" Confi gura o dono do arquivo de dispositivo criado em /dev.

SYMLIN="nome_arquivo" Cria um único arquivo simbólico de ligação para o arquivo de dispositivo

adicional, associado com o dispositivo no diretório /dev.

SYMLIN+="nome_arquivo" Similar ao anterior, com a diferença de que adiciona um link a

mais, em vez de substituir todos os links por um.

RUN="linha_comando" Executa um comando Shell único.

RUN+="linha_comando" Como o anterior, mas eventualmente adiciona outro comando após o

defi nido anteriormente, em vez de substituir todos os outros comandos.

ATTR{keyword}="valor" Sobrescreve um atributo udev para as combinações subsequentes de rules udev.

Tabela 2: Ações nas regras do udev.



A sintaxe, de forma geral, em uma linha de regras, é: MATCH (match) == "texto", MATCH=="texto", ... , ações

Ao olhar para os vários arquivos de regras na biblioteca /lib/udev/rules.d , você pode se perguntar como desco-brir todos os atributos dos dispositivos ( ATTR/ATTRS ) necessários para criar uma regra correspondente. O comando udevadm dá acesso a informações so-bre dispositivos específi cos ligados ao sistema, as quais você pode encontrar usando o nome do dispositivo corrente – nesse exemplo, a primeira partição do segundo disco SATA/SCSI/USB /dev/sdb1 . O comando mostra o resul-tado da listagem 5 ; abreviei a listagem para as partes mais relevantes da cria-ção de regras udev.

Os atributos ATTR da listagem 5 estão diretamente associados com o “block device” que consultei, en-quanto os valores ATTRS são tirados dos dispositivos do hardware de origem – o disco SCSI e o subsistema de ar-mazenamento USB. O udev confere todas essas combinações ao avaliar um arquivo de regra, de forma que você possa usar combinações diferentes para chegar à melhor combinação.

As ações do udev na tabela 2 po-dem ocorrer no momento em que o hardware é identifi cado (outras ações são possíveis, mas raramente usadas). Para arquivos de regras, o udev su-porta um esquema de substituição para os valores de strings, como pode ser visto na tabela 3 .

Você encontrará um conjunto completo de combinações, ações e opções de confi guração do udev no Linux Archieve [2] .

Escreva suas próprias regras Se quiser personalizar a forma com que seu sistema trata um dispositivo de hard-ware, você pode escrever sua própria regra de udev. O seguinte exemplo é uma simples regra udev para memó-ria fl ash USB examinada neste artigo.

Neste caso, eu quero montar a memória fl ash no ponto /backup quando ela é plugada:

# /etc/udev/rules.d/99 -mount-backup-disk.rules

ACTION=="add", SUBSYSTEM=="block", ATTR{partition}=="1", \ATTRS{serial}=="07A21A006E442637", \RUN+="/bin/bash -c 'mkdir -p /backup; mount -o umask=000 /dev/%k /backup'"

ACTION=="remove", SUBSYSTEM=="block", ATTR{partition}=="1", \ATTRS{serial}=="07A21A006E442637", \RUN+="/bin/umount -l /backup'"

Essa regra confere se a primeira par-tição do dispositivo recentemente adi-cionado possui um número serial único como 07A21A006E442637 . Se encontrada, a partição é montada como /backup .

O parâmetro umask para o mount li-bera as permissões de um sistema de arquivos VFAT ou NTFS para leitura e escrita, de forma que você não precisa ser usuário root para criar arquivos no /backup . Se você usa um sistema de arquivos que suporta permissões de arquivo, deve remover -o umask=000 e programar as permissões do diretório montado para um valor conveniente para um usuário sem privilégios no sistema. A regra de amostra para a ação remove irá desmontar o diretó-rio /backup , caso ele não tenha sido desmontado pelo usuário, de forma que o dispositivo possa ser realocado.

Você pode começar um backup imediatamente com a ação add ao estender o primeiro comando RUN depois da montagem com algo como:

... && tar -zcPf /backup/ backup-'date +'%Y-%m-%d'' .tar.gz /home/work

e desmontando ( umount ) a partição depois disso.

O próximo exemplo adicionará um link simbólico chamado cdrom e outro chamado dvd , se o dispositivo detectado for identifi cado como um drive de CD ou DVD, possivelmente substituindo um link prévio para o arquivo de dis-positivo, de forma que o link simbólico sempre aponte para o dispositivo adi-cionado mais recentemente.

Listagem 5: udevadm info 01 $ udevadm info --query=all --attribute-walk -name=/dev/sdb 102 looking at device ‘/devices/ pci0000:00/0000:00:1d.7/ usb1/1-1/1-1:1.0/host8/ target8:0:0/8:0:0 :0/block/ sdb/sdb1’:

03 KERNEL=="sdb1"04 SUBSYSTEM=="block"05 DRIVER==""06 ATTR{partition}=="1"07 ATTR{start}=="8064"08 ATTR{size}=="15638656"09 ATTR{ro}=="0"10 [...]11 [...]12 looking at device ‘/devices/ pci0000:00/0000:00:1d.7/ usb1/1-1/1-1:1.0/host8/ target8:0:0/8:0:0:0/block/sdb’:

13 KERNEL=="sdb"14 SUBSYSTEM=="block"15 [...]16 ATTRS{removable}=="1"17 ATTRS{ro}=="0"18 ATTRS{size}=="15646720"19 ATTRS{events}== "media_change"

20 looking at parent device ‘/devices/ pci0000:00/0000:00:1d.7/ usb1/1-1/1-1:1.0/host8/ target8:0:0/8:0:0:0’:

21 KERNELS=="8:0:0:0"22 SUBSYSTEMS=="scsi"23 DRIVERS=="sd"24 ATTRS{vendor}==" "25 ATTRS{model}=="USB DISK 2.0 "

26 ATTRS{rev}=="PMAP"27 ATTRS{state}=="running"28 [...]29 looking at parent device ‘/devices/ pci0000:00/0000:00:1d.7/ usb1/1-1’:

30 KERNELS=="1-1"31 SUBSYSTEMS=="usb"32 DRIVERS=="usb"33 ATTRS{bMaxPower}=="200mA"34 ATTRS{urbnum}=="412"35 ATTRS{idVendor}=="13fe"36 ATTRS{idProduct}=="3600"37 ATTRS{bcdDevice}=="0100"38 [...]39 ATTRS{manufacturer}==" "40 ATTRS{product}== "USB DISK 2.0"

41 ATTRS{serial}== "07A21A006E442637

57



A linha END{ID_CDROM}==”?*” busca uma variável de ambiente ID_CDROM que não esteja vazia, o que signifi -ca que o dispositivo foi identifi cado como drive de CD ou DVD.

# /etc/udev/rules.d/ 99-cdrom-link.rules

SUBSYSTEM=="block", ACTION=="change|add", ENV{ID_CDROM}=="?*", \

SYMLINK+="cdrom", SYMLINK+="dvd"

O próximo exemplo inicia o daemon do bluetooth quando um dispositivo bluetooth é plugado, e interrompe o dae-mon quando o dispositivo é removido.

Adicionalmente, o modem se-rial do dispositivo bluetooth con-fi gurado como /dev/rfcomm3 em /etc/bluetooth/rfcomm.conf é vinculado a /dev/modem , de forma que programas como o wvdial encontrem-no facilmente:

# /etc/udev/rules.d/99 -bluetooth-modem.rules

# Start/stop bluetooth daemon on detection of bluetooth host adapter

ACTION=="add|change", \SUBSYSTEM=="bluetooth", \KERNEL=="hci*", \RUN+="/etc/init.d/bluetooth start" ACTION=="remove", \SUBSYSTEM=="bluetooth", \KERNEL=="hci*", \RUN+="/etc/init.d/bluetooth stop"

# Set modem link to bluetooth serial device rfcomm3 only

ACTION=="add|change", SUBSYSTEM=="tty", \KERNEL=="rfcomm3", SYMLINK+="modem"

O exemplo fi nal adiciona uma regra para criar logs de tempo e va-riáveis de ambiente exportadas para o /tmp/udev-env.log , as quais podem ser úteis no desenvolvimento de shell scripts que usam essas variáveis.

# /etc/udev/rules.d/99 -log-env.rules

ACTION=="add|change|remove", \RUN+="/bin/bash -c '(date; env; echo) >>/tmp/udev-env.log'"

Após adicionar novos arquivos de regras, ou alterar velhos arqui-vos, o udev deve notifi car sobre as

mudanças [3] . Mesmo que a página do manual diga que esse passo não é necessário – porque o udev moni-tora os diretórios de confi gurações regularmente – achei útil durante meus experimentos, reiniciar o udev:

sudo /etc/init.d/udev reload

ou sudo udevadm control --reload-rules

Testes e debug O comando udevadm test executa uma simulação em seus arquivos de con-fi guração com o caminho completo do dispositivo como um parâmetro.

$ udevadm info --query=path --name=/dev/sdb1 /devices/ pci0000:00/0000:00:1d.7/ usb1/1-1/1-1:1.0/host7/ target7:0:0/7:0:0:0/block/sdb/sdb1

Use o caminho para o udevadm test : $ udevadm test --action=add /devices/pci0000:00/0000:00:1d.7/ usb1/1-1/1-1:1.0/host7/ target7:0:0/7:0:0:0/block/sdb/sdb1

run_command: calling: testudevadm_test: version 167

Esse teste é somente para debug. Ele não executa o programa e pode dar re-sultados incorretos porque alguns valores podem ser diferentes ou não disponíveis em uma simulação ( listagem 6 ).

O teste revela quais scripts seriam executados para esse dispositivo e mostra quais variáveis estão progra-madas para a execução.

Interação com o usuário do desktop O udev inicia todas as suas ações como usuário root por padrão, en-tão você não deve se preocupar com privilégios insufi cientes ao lidar com dispositivos. No entanto, o usuário root não tem acesso ao desktop grá-fi co ao ser executado pelo usuário sem privilégios, por duas boas razões:

➧ O servidor Xorg tem suas pró-prias permissões de sistema, habili-tando ou desabilitando acesso à tela com “cookies”, de forma a recusar que outro usuário root inicie um programa gráfi co em uma sessão já iniciada por outro usuário.

Listagem 6: udevadm test 01 parse_file: reading '/lib/udev/rules.d/40-hplip.rules' as rules file02 (checagem de montes de outros arquivos de regras ...)03 util_run_program: '/sbin/blkid -o udev -p /dev/sdb1' started04 util_run_program: '/sbin/blkid' (stdout) 'ID_FS_TYPE=vfat'05 util_run_program: '/sbin/blkid' (stdout)06 'ID_FS_USAGE=filesystem'07 util_run_program: '/sbin/blkid -o udev -p /dev/sdb1'08 returned with exitcode 009 (outros programas de auxílio que investigam o dispositivo ...)10 udevadm_test: ID_FS_VERSION=FAT3211 udevadm_test: ID_FS_TYPE=vfat12 udevadm_test: ID_FS_USAGE=filesystem13 (outras saídas de debug do udev)14 udevadm_test: run: '/usr/local/bin/askmount /dev/sdb1'15 udev adm_test: run: '/bin/sh -c '/usr/sbin/rebuildfstab -u knopper -i''

16 (mais programas definidos por RUN+=”programa” ...)

Tabela 3: Substituições de valores nas regras do udev.

Substituição Se expande para

%k O nome de kernel do dispositivo (como

sda1 ou video0 sem o prefi xo /dev).

$env{keyword} A variável de ambiente keyword.

$attr{keyword} Ao valor contido no atributo do udev ATTR{keyword}.



➧ Em um ambiente multiusuário, é aparentemente difícil saber qual u-suário, usando qual display remoto, é responsável pela inclusão de um novo dispositivo.

A forma correta para um geren-ciamento de hardware amigável no desktop do usuário é por meio de programas individuais que acessam informações do udev via libudev, parte da distribuição do udev. Pro-gramas que usam o libudev podem ser facilmente conferidos para even-tos relacionados a hardware, e então notifi cados caso algo mude.

Para tornar as coisas mais complexas, você tem o dbus, um “barramento de sistema virtual” que recebe informa-ções de udisks e upower (ambos usando o libudev como clientes para o udev) sempre que algo acontece relacionado ao disco ou à gestão de energia. Progra-mas de desktop, como o gerenciador de arquivos, podem se comunicar com o dbus para saber se qualquer dispositivo de interesse aparece ou desaparece sem se conectar ao udev diretamente. Esse método é, atualmente, a forma recomendada de acessar informações de hardware do sistema udev. Do ponto de vista do desenvolvedor, isso irá subs-tituir completamente o HAL (camada de abstração de hardware, em inglês). Você ainda pode encontrar uma in-terface para o Hal ao examinar seu /lib/udev/rules.d/90-hal.rules :

# pass all events to the HAL daemonRUN+="socket:@/org/freedesktop/ hal/udev_event"

Se o HAL estiver em execução, o udev enviará as informações de todos os hardwares para o socket associado e o HAL notifi cará todos os programas compatíveis com ele. Aparentemente, no Debian Testing, o HAL sequer é um programa neces-sário, e você pode removê-lo com segurança. Programas de desktop ainda conseguirão processar infor-mações relacionadas ao hardware via dbus ou diretamente do libudev.

A fi losofi a “multiusuário” pre-vê que os usuários e o sistema não devem interferir nos processos de outro usuário. Se quiser es-crever scripts para iniciar progra-mas gráfi cos por meio do udev, você pode “trapacear” ao conquis-

tar acesso ao display local para o usuário root . O script na listagem 7 é um diálogo interativo que pede permissão para montar a partição de um pen drive USB recente-mente plugado. O chamarei com /usr/local/bin/askmount .

Listagem 7: askmount 01 #!/bin/bash02 # /usr/local/bin/askmount05 # (C) Klaus Knopper 201106 # License: GPL V20708 # $DEVNAME (caminho absoluto), $ID_MODEL (product name)09 # and $ID_FS_TYPE (sistema de arquivos) are environment variables10 # exported by udev.1112 [ -n "$DEVNAME" ] || DEVNAME="$1"1314 if [ -z "$DEVNAME" ]; then15 echo " $0 deve ser chamado com partição como argumento, saindo." >&216 exit 117 fi1819 # Conseguir acesso ao primeiro display que executar X2021 export DISPLAY=":0"22 export XAUTHORITY=" $(ps f -C xinit -C Xorg -C X | sed -n ‘s/.*-auth $.*$/\1/p’ | head -1)"

2324 # Checar se possui $XAUTHORITY antes de continuar.25 if [ ! -r "$XAUTHORITY" ]; then26 echo "Sem acesso ao display local, saindo." >&227 exit 128 fi2930 # Solicitando permissão do usuário para montar o dispositivo.3132 if zenity --question --title="Novo dispositivo encontrado" --text="$ID_MODEL\n

33 Would you like to mount $DEVNAME?" ; then3435 # Ponto de montagem criado, substituindo no /dev/ por /media/ no $DEVNAME

36 mountpoint="${DEVNAME/\/dev\///media/}"37 mkdir -p "$mountpoint"3840 options="users"4142 # Se o sistema não suportar permissões,43 # setar o padrão para leitura e escrita para todos.44 case "$ID_FS_TYPE" in45 *fat|msdos|ntfs) options="$options,umask=000" ;;46 esac4748 # Feita a montagem, informar ao usuário sobre sucesso ou falha.49 if mount -o "$options" "$DEVNAME" "$mountpoint"; then50 zenity --info --timeout=5 --title="Dispositivo montado" --text="Feito, agora você tem acesso ao dispositivo. Não esqueça de desmontá-lo antes de desconectar."

53 else54 zenity --info --timeout=5 --title="Error" --text="Desculpe, não foi possível montar $DEVNAME."

55 fi

59



O script usa uma variável de am-biente que é programada pelo blkid , ferramenta auxiliar do udev, ID_FS_TYPE (contendo o tipo de sistema de arqui-vos da partição) e uma variável DEVNA-ME exportada pelo udev que contém o caminho completo do dispositivo.

A listagem 7 , que está disponível para download no website da Linux Magazine [4] , usa o Zenity para ofe-recer caixas gráfi cas de diálogo. Você pode ainda executar o script de forma independente do udev e testá-lo, mas ele só consegue montar um dispositivo de forma bem sucedida quando execu-tado como root . Nesse caso, as variáveis de informação ID_MODEL e ID_FS_TYPE não estarão disponíveis, a menos que você as confi gure manualmente.

Agora, crie o arquivo de regras:

# /etc/udev/rules.d/99- askmount.rules

ACTION=="add", SUBSYSTEM=="block", \ENV{ID_FS_USAGE}=="filesystem", \RUN+="/usr/local/bin/askmount $env{DEVNAME}"

Se tudo funcionar (diga ao udev para recarregar as regras), as caixas de diálogos exibidas pelo Zenity, ao

plugar na entrada USB uma memória fl ash com partições que contenham sistemas de arquivos, serão parecidas com as caixas da fi gura 1 .

Persistência Um caso de uso interessante de regras udev, as quais estão ativadas por padrão na maioria das distri-buições, é atribuir nomes persis-tentes para dispositivos específi cos, uma vez que eles foram detectados pela primeira vez. Durante a de-tecção do dispositivo, as regras em /lib/udev/rules.d/*generator.rules criam e atualizam outro arquivo de regras contendo um número serial único de dispositivos como interfaces de rede, drives de CD e DVD e discos rígidos. Ao usar os arquivos gerados, o udev "lembra", por exemplo, como o disco foi no-meado, quando ele foi encontrado pela primeira vez e sobrescreve o nome do dispositivo de forma a restaurar seu nome anterior. Pode ser reconfortante saber que um disco sempre será encontrado sob o mesmo nome de dispositivo, sem o impacto de outros hardwares. Por outro lado, a numeração consecuti-va de discos ou dispositivos de rede pode levar a números muito eleva-dos dependendo da quantidade de dispositivos com a qual se está tra-balhando. Se você perder ou que-brar um dispositivo, o nome nunca mais será reutilizado, a menos que você edite o arquivo persistente( /etc/udev/rules.d/*persistent.rules ) manualmente.

Um dispositivo de rede per-sistente fi ca assim no /etc/udev/rules.d/70-persistent-net.rules :

# USB device (rt73usb)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ATTR{address}== "00:23:cd:fd:4d:95", \KERNEL=="wlan*", NAME="wlan1"

Se você ousar mudar o endereço de hardware do dispositivo (usando

ifconfig debice hw ether new_mac ), o udev adicionará outra entrada para ele.

Conclusão Embora o udev ainda esteja em de-senvolvimento, ele já emergiu como uma ferramenta bem defi nida de especifi cações de confi guração, que permite aos usuários obter informa-ções sobre o hardware e criar scripts para tarefas relacionadas a ele.

A interface libudev para programas C/C++ torna possível a escrita de códi-go que pode reagir diretamente a mu-danças na confi guração do hardware.

Com o udev, os usuários podem manipular confi gurações – indepen-dentemente do desktop – por meio do dbus a partir da sessão do usuário gráfi co, acessando várias ferramentas administrativas para gerenciamento de dispositivos que dependem do udev e do dbus. ■

Mais informações

[1] Página do udev no kernel.

org: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

[2] Lista completa das

combinações e ações do

udev: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html

[3] Dicas e truques udev

no wiki do Archlinux:

https://wiki.archlinux.org/index.php/udev

[4] Códigos para este artigo:

http://lnm.com.br/issues/82/askmount.zip


Fale conosco em

[email protected]



osso s

r/artic

m

zine.com

:

566

igo?opinião.

r Figura 1: O udev permite que você

acrescente caixas de diálogo

para personalizar o processo

de inicialização do hardware.


ANÁLISE | Gerenciamento de clientes Windows com Opsi

Interoperabilidade

Valor agregado A ferramenta Opsi permite que administradores gerenciem clientes Windows

a partir de um servidor Linux. A versão 4.0.1 ganhou novos recursos.

por Ludger Schmitz

Quando a versão 4.0.1 do Opsi foi lançada, após um grande lançamento do 4.0, não se

esperava nada de especial de um complemento. Mas quem pensava assim foi surpreendido pelo gerenciador de clientes Windows de código aberto [1] . As melhorias na versão nova agora atendem ambientes com um grande número de clientes. As mudanças na versão 4.0.1 estão re-lacionadas a ambientes distribuídos.

Conexões lentas A mudança mais importante certa-mente é o recurso de integrar clientes em conexões lentas. Um cliente Opsi típico na rede local contacta o servi-dor Opsi depois do boot para conferir se existe algo para ser instalado e, se for o caso, ele monta um canal de compartilhamento para poder insta-lar o software. A tentativa de instalar algo banal, como o Adobe Reader,

de um protocolo SMB (Samba) na ponta errada de uma linha DSL, ou pior, de uma conexão UMTS (rede de celulares 3G), levaria a erros e instalações extremamente longas, caso a conexão fosse interrompida. Além disso, o laptop de quem viaja muito a trabalho nunca teria a possi-bilidade de alcançar o servidor Opsi pela falta de conexão de rede. Em outras palavras, uma solução com-pletamente diferente era necessária.

O Opsi usa cache local ou arquivos de instalação com dados de confi gu-ração. Se um cliente Opsi – em uma rede sem fi o – instala algum software, ele primeiro usa os protocolos CIFS/HTTPS para executar os arquivos re-quisitados e dados em um disco local. Para evitar a interrupção dos usuários durante seu trabalho, isso acontece em segundo plano com uso dinâmico da largura de banda disponível. Isso signifi ca que o cliente Opsi reduzi-

rá a velocidade de download caso alguém esteja usando a interface de rede ativamente.

Se a conexão for interrompida, o download é retomado em uma pró-xima oportunidade. Esse processo continua até que todos os arquivos requisitados estejam disponíveis local-mente e só aí o usuário é informado da instalação eminente e convidado a reiniciar a máquina. A instalação acontece à moda típica do Opsi an-tes do login; nesse caso, nenhuma conexão de rede é necessária porque todos os dados estão disponíveis local-mente. Os resultados da instalação são armazenados em cache local e transferidos ao servidor em uma pró-xima oportunidade (na próxima vez que houver conexão de rede dispo-nível). O software é iniciado na hora do boot (isso pode ser desabilitado), assim como um conjunto de outros eventos que tentam abrir uma cone-

AN

ÁLIS

E


ANÁLISE | Gerenciamento de clientes Windows com Opsi

xão – quando a interface de rede é ativada, por exemplo.

Segurança na nuvem? A abordagem coberta neste artigo permite que os administradores não somente cuidem dos laptops de uma força de vendas externas, por exemplo, como também integrem escritórios, matrizes e fi liais com apenas alguns computadores na outra ponta da rede sem fi o, tudo com o gerenciador centralizado Opsi. Isso signifi ca que você pode agora gerenciar e manter localizações que poderiam repre-sentar problemas de segurança por falta de atualizações centralizadas. Considerando essas novas opções, parece lógico usar o servidor Opsi para gerenciar um grande número de computadores distribuídos, e o servidor poderia fi car na nuvem para servir a esse propósito. A tecnologia permite essa abordagem e o Opsi também ganhou melhorias na sea-ra da segurança. A autenticação de servidores e clientes, introduzida recentemente, melhorou esse ponto para casos em que um invasor tenta realizar um spoof (técnica maliciosa) no servidor Opsi e comprometer os clientes Opsi. Apesar disso, o forne-cedor ainda alerta aos administra-dores para manterem as medidas de seguranças adicionais, como VPNs, além do uso de serviços de consulto-ria no caso de aplicativos na nuvem. Afi nal, se um invasor comprometer o servidor Opsi, ele passa a ter acesso a todos os clientes conectados a ele.

Aqui e lá Suporte gratuito para múltiplos lugares é um recurso usado frequentemente no Opsi. Localizações externas e um grande número de clientes tendem a usar seus próprios repositórios des-centralizados de software. Os clientes nessas localizações podem ser vincu-lados a um repositório específi co em uma interface de gerenciamento. Após fazer isso, o cliente então atualiza o

software de um repositório – ao invés de usar toda a rede. Mas, se o cliente é um laptop e pertence a equipe de vendas de rua? Novamente, o lap-top pegará o software do repositório vinculado, mesmo que aconteça de estar geografi camente mais perto de outro repositório.

O próximo recurso que entra em cena nesse momento é a vinculação dinâmica de repositórios. Embora o cliente permaneça vinculado para seu repositório principal, você pode também fornecer uma lista de repo-sitórios que contêm o software requi-sitado. Por meio de um algoritmo, o cliente pode agora decidir qual repositório de uma lista é o melhor para ele. Uma vez que o algoritmo pode ser defi nido livremente, você tem condições de basear sua escolha, por exemplo, no endereço de rede ou nas taxas de latência.

Trabalho facilitado Decidir qual software implementar em clientes corporativos é frequen-temente o dilema de administrado-res de sistemas: o problema é que normalmente eles não querem ins-talar softwares desnecessários, mas também não querem correr o risco

de sofrer com usuários acionando o suporte a cada vez que precisa-rem de uma ferramenta trivial que está faltando. Uma forma legal de responder a isso é usar um sistema de software sob demanda. Os ad-ministradores podem vincular uma seleção de produtos dentro do grupo de software sob demanda, do qual os usuários podem requisitar a instala-ção em seus computadores. Os soft-wares são instalados com privilégios de administrador pelo cliente Opsi, como defi nido pelo administrador no pacote.

Detalhes Os novos recursos pelos quais passei até agora são baseados em projetos fi nanciados através de taxas, o que signifi ca que eles não se tornarão gra-tuitos e de código aberto até que os desenvolvedores tenham recuperado seus custos. Além dessas extensões comerciais, algumas melhorias me-nores foram adicionadas diretamente ao núcleo de código aberto do Opsi. Para resumir, só abordarei as melho-rias mais importantes.

Começarei com a mais notável, que é a interface de gerenciamento. Você agora pode armazenar as sele-

Figura 1: A janela DaemonInfo oferece ao administrador uma visão geral útil

sobre a sequência de atividades de um cliente Opsi .

63

| ANÁLISEGerenciamento de clientes Windows com Opsi


que você não invista em extensões comerciais, o cliente Opsi permite uma confi guração mais granular da interação do usuário.

Tudo isso dito, o Opsi claramente traz avanços como uma ferramenta de gerenciamento profi ssional de clientes, tanto no que diz respeito a detalhes, quanto ao escopo de apli-cativos. E faz você pensar o que os desenvolvedores têm em mente para a próxima versão – talvez suporte para clientes Linux? ■

Quadro 1: Mostre seu trabalho

O cliente Opsi abrange componentes múltiplos que são executados ao mes-

mo tempo. Embora todos os componentes escrevam no mesmo arquivo de

log usando o horário da gravação para diferenciação, é muito fácil perder o

controle sobre quem fez o quê. A introdução da extensão WAN para Opsi

não tornou isso muito fácil; no entanto, o lado cliente agora oferece a visu-

alização das atividades. A tarefa desempenhada por vários componentes é

exibida coletivamente em uma linha de tempo, dando ao administrador uma

visão geral útil sobre o que tem acontecido ( fi gura 1 ).

Mais informações [1] Site do Opsi: http://

www.opsi.org/


Fale conosco em

[email protected]



osso s

r/artic

m

zine.com

:

565

igo?opinião.

r

ções de colunas de dados a serem exibidos para clientes ou produtos, ao invés de ter que confi gurar isso cada vez que se reinicia o sistema. A ferramenta também pode identi-fi car e exibir facilmente os clientes que estão online, com o pressionar de um botão. Formas de busca aju-dam o administrador a encontrar os clientes mais facilmente e as ins-talações que falharam são exibidas em um grupo separado. Uma busca separada também ajuda a encontrar clientes que precisam de atualizações de um produto específi co ( quadro 1 ).

Outras melhorias que valem a pena destacar, no lado do servidor: se você quer usar o Opsi Wake-on--LAN em um ambiente distribuído, irá gostar dos suportes para broadcasts diretos na rede. As opções de con-fi guração para resolução de nomes foram aprimoradas para manter os clientes sob alcance, apesar das di-ferentes confi gurações de DHCP e DNS. Você também pode atribuir senhas livremente para as imagens de boot, o que não era possível an-tes, sendo este um recurso que me-lhora a segurança. Por fi m, mesmo

PHISHING

FLEXÍVEL E CUSTOMIZÁVEL

CLIENTES 100% SATISFEITOS

FILTRO DE ENTRADA E SAÍDA

BASEADO EM SOFTWARE LIVRE

EL

EITOS

AÍDA

RE LIVRE

AntiSpam SaaS UNODATA

Você está com a cabeça nas nuvens? Nós também.

Disponível em Software, nuvem e Appliance3 em 1 - AntiSpam, AntiVírus e AntiFraudeInstalação em menos de 15 minutos

Para empresas que não querem ou não podem administrar sua infra-estrutura de e-mail o AntiSpam SaaS UNODATA é uma ótima opção.

(11) 3522-3011 Acesse www.unodata.com.br e veja nossos casos de sucesso.

30 DIASGRÁTIS!

30 DIASGRÁTIS!

ENVIE UM E-MAIL [email protected]

E GANHE + 1 MÊS GRÁTIS DE ANTISPAM

http://www.unodata.com.br


REDES | Monitoramento APR

Ferramentas de monitoramento ARP

Olhar atento

É claro que você tem um fi rewall, mas

e se um intruso começar o seu trabalho

de dentro da rede? As ferramentas de

monitoramento ARP fi scalizam mudanças

súbitas que podem indicar um ataque local.

por Chris Binnie

Um time dedicado trabalha duro para aplicar os patches de segurança desenvolvidos

para os softwares no seu sistema. O fi rewall mantém longe os invasores que tentam invadir a rede pela In-ternet. Mas, você tem um sistema equivalente para descobrir ataques que começam de dentro da rede?

Por sorte, um pré-requisito para quase qualquer ataque de rede é a aquisição de um endereço IP. Para se comunicar com sua rede de forma útil (em vez de, por exemplo, pegar toneladas de dados criptografados de uma conexão sem fi o), um invasor precisa vincular um endereço IP na rede primeiro. Isso se aplica tanto a conexões com fi o quanto sem fi o. O

endereço IP pode ser um endereço não utilizado ou até um que já está em uso por outro dispositivo.

Se o invasor pega um endereço IP já em uso, o objetivo normalmente é desempenhar algum tipo de intercep-tação ou redirecionamento de servi-ço. Sob algumas circunstâncias, um invasor pode tentar convencer o resto da rede de que seu dispositivo tem a mesma identidade que um de seus computadores (em outras palavras, copiar o endereço MAC devidamen-te codifi cado na placa de rede pelo fabricante e que, por acaso, é fácil de ser alterado temporariamente).

Um ataque onde o invasor vincula um endereço de IP existente, de for-ma a cuidadosamente fi ltrar e fazer

spoof das comunicações é normal-mente conhecido como Man-In-The--Middle (da sigla MITM, homem no meio, em tradução livre), porque o atacante coloca um dispositivo entre o seu computador e o computador de destino. O redirecionamento do serviço pode ser uma simples questão de alterar o endereço MAC para di-zer ao seu computador para usar um servidor de DNS diferente, de forma que, quando você tenta se conectar ao site do banco, você na verdade visita um site falso e dá seus dados pesso-ais a ele sem perceber. O ideal seria que você fosse avisado não só quando um endereço MAC associado a um endereço IP mudasse, mas também quando qualquer endereços IP que não foi usado fosse vinculado a algum dispositivo de forma inesperada.

Esse artigo introduz algumas ferra-mentas úteis que usam o Address Reso-lution Protocol (ARP), ou protocolo de resolução de endereços, para observar mudanças inesperadas em atribuições de endereços IP na rede local.

Arpwatch O a rpwatch é uma ferramenta sim-ples que observa os endereços IP na sua rede e procura por mudanças sus-

RE

DE

S

Figura 1 Um e-mail do Arpwatch proporciona detalhes simples sobre cada evento.

65

| REDESMonitoramento APR


peitas. O ARP constrói uma tabela mostrando qual endereço IP é usado por qual dispositivo, perguntando efetivamente a todos os dispositivos da rede local (ou domínio broad-cast, mais precisamente) “Quem está usando esse endereço IP?”, até que um dos dispositivos responda “Eu tenho esse endereço IP”. Essa simplicidade torna o protocolo fácil de se utilizar, mas o torna vulnerável a abusos, como no ataque MITM descrito anteriormente.

O Arpwatch monitora mudan-ças nas respostas ARP e manda um e-mail para o administrador do sis-tema quando algo digno de obser-vação acontece. Além de fornecer uma forma fácil de auditar quantos endereços IP estão em uso na rede, é uma forma de obter alertas a partir de diversas interfaces de uma só vez (tanto com ou sem fi o).

Note que algumas redes usam spoofi ng ARP para redirecionar trá-fego de usuários para propósitos legítimos. Imagine, por exemplo, que você está logando na rede de um restaurante pela primeira vez. Enquanto puxa a cadeira com seu prato e, antes que o restaurante per-mita seu acesso à Internet, você é redirecionado para uma página de “política de uso aceitável”, na qual precisa concordar com os termos de uso para ter acesso ao serviço. Ao manter controle de cada interface, usando um arquivo de log do mo-mento e data em que um endereço IP foi vinculado ao endereço MAC, o Arpwatch pode oferecer uma visão inestimável sobre mudanças – antes imperceptíveis na rede.

Os logs do Arpwatch rastreiam os endereços MAC registrados, os endereços IP atribuídos, o horário associado a última atividade cor-respondente, nomes de dispositivo (aliases ou nomes DNS) e a inter-face da qual eles foram observados.

A figura 1 mostra os detalhes em um e-mail gerado pelo Arpwatch.

A notifi cação de e-mail que o Ar-pwatch envia pode alertar o usuá-rio quase instantaneamente. Os relatórios são relativamente sim-ples e poderiam ser formatados em mensagens SMS se necessário. A figura 2 ilustra a brevidade dos logs do Arpwatch.

O primeiro segmento de um ende-reço MAC é normalmente (mas não sempre) alocado para um fabricante ou fornecedor de placa de rede es-pecífi co e é facilmente reconhecível a partir de algum banco de dados existente na Internet. Uma lista mais formal e não tão prática de vínculos está disponível por meio do IEEE [1] . Essa tabela faz a identifi cação de um dispositivo desconhecido mais fácilmente para o usuário e, em troca, mantém os alarmes falsos em níveis mínimos.

Agora que você sabe o endereço MAC do dispositivo de um invasor, e potencialmente se é um laptop ou um smartphone usando dicas do endereço MAC do fornecedor (pre-sumindo que ele não foi alterado), você está a caminho para rastrear as atividades dos dispositivos na LAN (mesmo se ele mudar o endereço MAC, você ao menos será alertado sobre o dispositivo).

Arping A ferramenta mais popular para con-ferir endereços ARP duplicados em uma rede local é o Arping. Como o Ping, que manda ondas sonares e escuta por respostas, quando as ondas colidem com alguma coisa, o Arping grita para a rede local (ou domínio broadcast). Algumas implementações de Arping, ao invés de perguntar somente quais endereços MAC possuem quais

endereços IP, podem questionar de forma inteligente, em reverso, qual endereço IP tem qual ende-reço MAC. Esse recurso é de im-portância fundamental para alguns cenários de ataque.

O seguinte exemplo pede ao Ar-ping para procurar por endereços MAC duplicados pertencentes a um endereço IP:

arping -d 97.98.99.100 -I eth1

Após receber um alerta do Arpwa-tch informando que algo mudou na rede, esse comando deve lançar algu-ma luz sobre os dispositivos que estão compartilhando o mesmo endereço IP (experimentando assim conectivi-dade falha ou tentando algum tipo de ataque MITM).

Por meio da interface eth1, o co-mando envia quatro questões, per-guntando “Quem tem esse endereço IP?” e espera pelas respostas. A fi gura 3 mostra quatro respostas idênticas mostrando que somente um ende-reço MAC possui um endereço IP atribuído, portanto nenhuma entrada duplicada é visível neste momento.

ArpON Agora que você sabe detectar e rece-ber relatórios durante ataques ARP, provavelmente está se perguntando se outra ferramenta pode oferecer uma forma mais sofi sticada e auto-matizada de combater ataques de rede localizados. A ferramenta é o ArpOn, ou Arp Handler Inspection . Enquanto o Arpwatch somente relata problemas e deixa a solução para o administrador, o ArpON é projetado para automatizar a resolução de pro-blemas seguindo algumas políticas predefi nidas. Detalhes completos do pacote, incluindo alguns diagramas

Figura 2 Somente os fatos: o formato do log do Arpwatch.


REDES | Monitoramento APR

úteis para iniciantes, estão disponíveis no website do ArpON [2] .

Além dos recursos básicos de mo-nitoramento ARP, o ArpON vem com poder de fogo adicional em seu arse-nal. Por exemplo, uma sessão ArpON pode também, automaticamente, detectar e resolver uma sessão de interceptação e sequestro de e-mail criptografado e conversas pela web.

Ao criar um novo cache de en-tradas ARP logo no início, o ArpON efetivamente limpa a tabela, elimi-nando assim a possibilidade de que o cache de entradas ARP tenha sido corrompido com informação falsas e incorretas (este tipo de ataque é chamado de ARP Cache Poisoning , ou envenenamento do cache ARP). Ao contrário de outras ferramentas de monitoramento do ARP, o ArpON se recusa ativamente a atualizar no-vas entradas sem uma referência em um cache confi ável, essencialmente ignorando qualquer coisa que não esteja clara, o que acaba com um ataque antes que ele comece.

O ArpOn tem três níveis de ins-talação. Executá-lo em um nó de monitoramento em um dispositivo pode oferecer proteção unidirecio-nal, onde um daemon instalado pode efi cientemente pegar e desafi ar mudanças no cache do ARP. Com proteção bidirecional, pelo menos dois nós de monitoramento são ne-cessários para queseja possível inter-ceptar o tráfego entre os dois nós e, assim, decifrar um ataque para reagir de forma apropriada. Confi gurado com todas as suas armas no modo de proteção distribuído, o ArpON precisa ser instalado e executado em

todos os dispositivos na rede. Vale a pena mencionar que, neste modo, todos os outros dispositivos que não estiverem executando o ArpON não serão protegidos de ataques, o que faz dele mais adequado para uma pequena rede que execute dispo-sitivos homogêneos, por exemplo, um grupo ou cluster de servidores de e-mail em uma pequena rede (ou subrede) própria.

O ArpON tem um projeto não invasivo que não tenta alterar o protocolo ARP, que foi criado para redes de dados a muitos anos atrás e certamente poderia ser aprimorado para se compatibilizar aos ataques de hoje. Não importando os problemas associados com o ARP, ele oferece alto desempenho por conta de sua simplicidade. O ArpON, por outro lado, não impede essa efi ciência, além de lidar competentemente com redes DHCP, onde os dispo-sitivos normalmente são associados a um novo endereço IP toda vez que se conectam. Dado o poder do ArpON, vale a pena lembrar que desabilitar partes do software para criar seu próprio laboratório de teste em uma rede local pode ser também um excelente exercício.

Conclusão O ArpON está atualmente dispo-nível para Linux, Mac OS X, Free-BSD, NetBSD e OpenBSD. Embora ainda não tenha sido portado para Windows, você pode encontrar fer-ramentas similares para este e outros sistemas operacionais.

No Windows, procure por um pro-duto chamado WinARP Watch. Para

Linux, Unix, e BSD, há também o Arpalert. Cada uma das alternativas contém um conjunto diferente de recursos. Embora o Arpwatch seja excelente, nenhuma delas é capaz de alcançar os mesmos recursos e sofi sticação da ArpON.

Quando aplicada em conjunto com o conhecimento de um admi-nistrador de rede experiente, as fer-ramentas de monitoramento ARP são muito poderosas, mesmo com a maioria das ferramentas de bloqueio automático de ataques desabilitada. Com níveis altamente detalhados de relatórios e um grau menor de automação, essas ferramentas defi ni-tivamente agem como uma camada adicional de proteção tanto para re-des domésticas quanto industriais. ■

Mais informações

[1] Mapeamento de endereços

MAC para fornecedores:

http://standards.ieee.org/develop/regauth/oui/oui.txt

[2] ArpON: http://arpon.sourceforge.net/


Fale conosco em

[email protected]



osso

br/arti

m

gazine.com

e:

569

igo?opinião.

br

Figura 3 Respostas idênticas indicam que não há entradas duplicadas visíveis

na rede.

Quadro 1: Desempenho do ArpON O ArpON foi desenvolvido tendo

em mente o desempenho da fer-

ramenta e portanto tem um núme-

ro limitado de recursos. Uma ferra-

menta alternativa chamada S-Arp

( Secure Arp ) acrescenta um nível

de criptografi a que provê seguran-

ça adicional mas deixa o protocolo

ARP mais lento por adicionar mais

cálculos numéricos e injetar mais

dados no fl uxo de tráfego.


PROGRAMAÇÃO | PHP com C++

PHP com C++

Mistura de códigos A mistura de linguagens de

programação não deve restringir seu

projeto de software. Aprenda a expor

objetos e templates C++ ao código

PHP e como registrar chamadas PHP

que o código C++ possa utilizar.

por Ben Martin

A linguagem PHP ganhou po-pularidade por conta dos aplicativos web, já que possui

interfaces para bancos de dados e ser-viços web. Frameworks (ambientes de desenvolvimento) inteiros, como o Zend [1] [2] são escritos em PHP. Embora toda essa popularidade e as muitas interfaces sejam mara-vilhosas, pode acontecer de você ter lógicas de negócios escritas em C ou C++ que gostaria de acessar com o código web PHP. Uma opção seria reescrever o código em PHP e fazer novos testes, mas dessa forma você teria que manter duas versões do mesmo programa. Ao invés dis-so, você pode pegar o código C++ que quer usar e deixar com que o SWIG ( Simplifi ed Wrapper and In-terface Generator ) [3] faça o traba-lho pesado ao criar vinculações de linguagem que permitam o acesso ao código em PHP.

O SWIG é uma ferramenta de desenvolvimento de código aber-to que faz a interface de C e C++ com diversas linguagens de scripts, incluindo PHP, Perl, Python, Tcl e

Ruby. Dependendo de como você usa o SWIG, não será necessário manter nenhum código de ligação para fazer as coisas funcionarem. Por exemplo, o SWIG pode usar o arquivo de cabeçalho C++ para gerar o código de ligação necessário para que o PHP crie objetos naquela classe e chame os métodos naqueles objetos. Se quiser adicionar um novo método ou classe, simplesmente adicione o SWIG ao projeto C++, reconstrua-o, e ele fi cará automati-camente disponível no PHP.

Embora os artigos sobre a vincu-lação de linguagens normalmente discutam o acesso de uma lingua-gem a partir de outra, você frequen-temente perceberá que precisa ir pelos dois caminhos. Os projetos modernos em C++, por exemplo, permitem que objetos mandem “sinais” quando eventos interes-santes ocorrem, possuem functors (funções de objeto para mapear o intervalo entre categorias) que são registrados para serem usados como chamadas durante o proces-samento [4] . Para tirar vantagem

total deste tipo de código em C++ através do PHP, você precisa ter a possibilidade de possuir o código de retorno ( call back ) C++ cha-mado dentro do código PHP (seus functors e slots de sinais). Tudo isso precisa acontecer no código C++, que sequer sabe que está fazendo chamadas dentro de uma imple-mentação PHP dentro do slot ou do functor.

O SWIG é uma ferramenta útil de se conhecer porque pode gerar vínculos para muitas linguagens. Além de PHP, Perl, Python e Ruby, você pode usar SWIG com dialetos LISP, Ocaml e outras linguagens. Partes extensas desse artigo podem ser, então, aplicadas para gerar vín-culos para outras linguagens.

Começar de forma simples Para compilar os exemplos a seguir, você precisa instalar os pacotes de desenvolvimento do PHP. No Fe-dora, por exemplo, ele se chama php-devel .

PR

OG

RA

MA

ÇÃ

O

73

| PROGRAMAÇÃOPHP com C++


O primeiro exemplo é uma classe C++ bastante simples para dar uma noção sobre como opera o SWIG. Depois, vamos observar algumas das coisas que você precisará para um binding mais sério, tal como a exposição de STLs (bibliotecas pa-drão de template, em inglês) como a std::vector , std::map e correlatas; a forma de expor ponteiros inteli-gentes; alguns recursos de geração de linguagem de interface como a renomeação de métodos e funções para a linguagem-alvo e fi nalmente, como ligar sinais C++ e mecanismos de slot para chamar funções PHP a partir de sinais C++.

Cada exemplo utilizará o conheci-mento adquirido nas etapas anterio-res e talvés eu omita alguns detalhes cobertos em exemplos anteriores para economizar espaço. Para manter as coisas simples, evitarei ferramentas automáticas e simplesmente mostrarei os comandos usados para compilar e gerar código em cada passo.

Embora o uso do SWIG requei-ra algum conhecimento adicional, o processo é o mesmo para expor classes maiores e muitas classes ao mesmo tempo. Com o SWIG, você pode expor uma classe única ou centenas de classes de forma igual-mente rápida.

Exposição de uma classe C++ para PHP A declaração da primeira classe, sim-ple1, é exibida no cabeçalho simple1.hh exibido na listagem 1 . Para limpar a interface um pouco, usei a classe std::string para aceitar uma string com o nome do objeto que está ar-mazenado em m_pubB . O método hi-dden não pode ser chamado do PHP porque é protegido. O método shown simplesmente retorna duas vezes o valor dado a ele como o primeiro parâmetro. A implementação é exibi-da na listagem 2 . Tudo isso é código C++ comum.

Dado o cabeçalho e o arquivo de implementação para simple1.hh e simple1.cpp , os comandos g++ -shared -fpic simple1.cpp -o libsimple1.so

sudo install -m 755 libsimple1.so /usr/local/lib

gerarão uma biblioteca comparti-lhada libsimple1.so . Perceba que os comandos forçam o uso de PIC (código independente de posição, em inglês) [5] porque está gerando uma biblioteca compartilhada.

O PIC tem a vantagem de po-der ser carregado em diferentes localizações na memória, o que é útil para bibliotecas compartilhadas porque permite ao link dinâmico movê-las quando múltiplas biblio-tecas quiserem o mesmo endereço. Nesse ponto, presumo que você já tem a libsimple1.so instalado no /usr/local/lib e seu sistema confi -gurado para encontrá-la neste lugar. Outra forma é usar o LD_LIBRARY_PATH e -L se você quiser usar a biblioteca a partir da localização atual.

O arquivo de cabeçalho e a bi-blioteca compartilhada são quase tudo o que você precisa para usar a classe simple1 de um programa C++, embora você possa incluir o cabeça-lho e vincular ao objeto comparti-lhado ( libsimple1.so ) e utilizando o simple1 de muitos aplicativos C++. Até aqui, tudo se resume a puro de-senvolvimento C++.

Agora, é hora de usar o SWIG para gerar os vínculos de lingua-gem de forma que você possa criar objetos simple1 e chamar métodos neles a partir do PHP. O SWIG utiliza um arquivo de defi nição de interface que descreve as classes, funções e assim por diante, que deve ser exposto à linguagem para a qual você quer gerar vínculos. A princípio, isso pode soar como qualquer outro pesadelo de manu-tenção. Você não precisa manter o arquivo de defi nição de interface à medida que muda o código C++?

A defi nição de interface SWIG para simple1 é:

%module simple1module%include stl.i%include "simple1.hh"%{ #include "simple1.hh"%}

as quais não possuem declaração de classe ou alguma coisa que re-meta a duplicação da defi nição do simple1 ( listagem 1 ). A primeira li-nha declara o nome do módulo para este vínculo. Uma das restrições aqui é que o nome do módulo não pode ser usado por uma classe da qual você está expondo, portanto você não pode ter um módulo no-

Listagem 1: Classe simple1 01 #include <string>0203 class simple104 {05 protected:06 int m_prot1;07 int hidden( int a );08 public:0910 sim ple1( const std:: string& name );

1112 int m_pubA;13 std::string m_pubB;14 int shown( int a );15 };

Listagem 2: simple1 01 #include “simple1.hh”0203 int04 simple1::hidden( int a )05 {06 return a;07 }0809 simple1::simple1( const std::string& name )

10 :11 m_pubB( name )12 {13 }1415 int16 simple1::shown( int a )17 {18 return a+a;19 }



meado simple1, porque o mesmo já é usado por uma classe. Para que as coisas fi quem melhores e mais claras, uso o nome simple1module . O único lugar no qual esse nome aparece é no código PHP, quando ele inclui ( include() ) aquele mó-dulo – então você pode criar um nome bem descritivo.

O resto do arquivo parece se re-petir ao incluir simple1.hh duas ve-zes. A razão para essa duplicação é que a diretiva %include diz ao SWIG para examinar outras defi nições de interface ( foo.i ) ou os arquivos de cabeçalho C/C++ para os quais você gostaria de criar vínculos. O SWIG lerá qualquer arquivo de cabeçalho listado com %include , fazendo o parse e gerando o código para encapsulá-lo para a linguagem que você escolheu. O código do

invólucro ( wrapper ) será escrito por padrão no simple1_wrap.cpp .

Esse código wrapper gerado pro-vavelmente precisará de acesso a alguns dos arquivos de cabeçalho para compilar. Por exemplo, você não pode chamar simple1::shown() sem ter a declaração da classe no escopo. Isto é, em um programa C++ normal tal qual simple1.wrap.cpp , você primeiro tem que usar #in-clude “simple1.hh” antes de chamar shown() . O SWIG copiará o bloco de código defi nido por %{ ... %} dentro do arquivo de código do wrapper gerado ( simpe1_wrapp.cpp ), de forma que a compilação dê cer-to. Nesse exemplo, você precisará do simple1.hh no escopo, de forma que ele esteja no #include dentro do código entre chaves.

Em resumo, a linha %include “sim-ple1.hh” diz ao SWIG para gerar código de forma que o PHP possa chamar métodos da classe simple1. A linha também permite que o código gerado ( simple1_wrap.cpp ) seja com-pilado com o gcc porque a defi nição da classe simple1 está no escopo. O SWIG não se importa com o que está escrito dentro das chaves – você pode colocar o que quiser dentro do bloco gerado dentro do arquivo sim-ple1_wrap.cpp .

A linha %include stl.i inclui um arquivo typemap do próprio SWIG. Mais a frente, iremos analisar os type-

maps, mas por enquanto é sufi ciente dizer que o stl.i diz ao SWIG como fazer a classe std::string e outras classes STL se tornarem disponíveis no script PHP.

Agora que você fez a parte difícil e criou simple.i , os dois comandos

swig -c++ -php5 simple1.ig++ -shared -fpic 'php-config --includes' -Dzend_error_ noreturn=zend_error simple1_ wrap.cpp -L'pwd' -lsimple1 -o simple1module.so

geram a vinculação de linguagem PHP e a compilam junto da bi-blioteca compartilhada. A primeira linha gera um simple1.wrap.cpp e um simple1module.php . O primeiro arquivo é o código C++, que permite acesso à classe simple1 do PHP. O segundo arquivo é um script PHP, para o qual você usa o include() em um arquivo PHP para carregar a vinculação da linguagem e esta-belecer acesso. A segunda linha usa GCC para compilar o arquivo fonte simple1_wrapp.cpp – gerado em uma biblioteca compartilhada – e vincu-lá-lo a biblioteca da classe simple1. Dessa forma, o módulo simple1mo-dule contém tanto o código SWIG “de cola”, quanto a implementação do simple1.

A biblioteca compartilhada simple1module.so é uma extensão PHP e deve ser instalada no diretório de extensões da linguagem:

Listagem 4: Uso de containers padrão 01 #include <string>02 #include <vector>03 #include <map>0405 class simple206 {07 ...08 std::pair< std::string, std::string > getPair();

09 std::vector< std::string > getVector();

10 std: :vector< std::string > getMapRange( const std::map< int, std::string >& a );

11 };

Listagem 3: Código PHP usando a classe simple1 01 <?php0203 include_once ("simple1module.php");

04 print "started...\n";0506 $foo = new simple1( "hello" );0708 print "foo.pubB : " . $foo->m_pubB . "\n";

09 print "foo.shown() : " . $foo->shown(181) . "\n";

1011 ?>

Listagem 5: Arquivo de interface SWIG, simple2.i 01 %module simple2module02 %include stl.i03 %include "simple2.hh"0405 %{06 #include "simple2.hh"07 %}0809 namespace std {10 specialize_std_map_on_key(int,CHECK,CONVERT_FROM,CONVERT_TO)11 }12 %template(IntVector) std::vector< int >;13 %template(StringVector) std::vector< std::string >;14 %template(StringPair) std::pair< std::string, std::string >;15 %template(IntStringMap) std::map< int, std::string >;

75



php-config --extension-dirsudo install -m 755 simple1module. so 'php-config --extension-dir'

O primeiro comando diz onde o PHP está procurando extensões, e o segundo instala a biblioteca sim-ple1module.so de forma que o PHP possa encontrá-la automaticamente.

A única coisa que falta ser feita é pegar a classe simple1 em C++ para um spin do PHP. O script simple1_test.php da listagem 3 cria um novo objeto simple1, chama um método e lê uma variável de instância do objeto C++.

Como você pode ver, não faz diferença para o código PHP se a classe simple1 é escrita em C++ ou PHP. O código PHP nem liga para o fato de que o constructor (méto-do construtor) está esperando uma string C++ ( std::string ) em vez de uma string PHP.

Você pode ver o código em ação na listagem 3 , usando o comando:

$ php -d enable_dl=On simple1_ test.php

started...foo.pubB : hellofoo.shown() : 362

Uma vez que o simple1_test.php inclui o simple1module.php , o arqui-vo de extensão simple1module.so será carregado, permitindo que objetos simple1 sejam criados. Dependen-do da sua confi guração, talvez você precise habilitar o carregamento dinâmico de bibliotecas com o pa-râmetro -d . A biblioteca comparti-lhada simple1module.so está vincula-da à biblioteca C++ compartilhada libsimple1.so para trazê-lo na imple-mentação da classe simple1.

Embora um esforço inicial seja requerido para expor uma simples classe PHP, os únicos novos arqui-vos que você realmente criou ma-nualmente foram o arquivo SWIG simple1.i e o script PHP. O arquivo simple1.i é apenas uma inclusão do cabeçalho simple1.hh e algumas inclusões SWIG. No fi nal, você

conseguiu criar um objeto sim-ple1, acessar seus dados e chamar um método bastante natural para PHP. A vantagem de usar o SWIG dessa forma é que, se você modifi -car a classe simple1, o SWIG cuida de atualizar toda a extensão PHP para você.

C++ e PHP: contêineres padrão Agora que você sabe como o SWIG funciona e como utilizá-lo com o PHP, pode usar esse conhecimento para expor código C++ mais com-plexo ao PHP, incluindo código que aceita ou retorna std::vector , std::list , std::map , ou outras cole-ções; códigos que usam ponteiros inteligentes para gestão de recur-sos e códigos que têm classes que emitem sinais, permitindo respostas abertas a eventos.

A classe simple2, mostrada na lis-tagem 4 , se constrói sobre a classe simple1 e adiciona três novos méto-dos, mostrados no fi nal da defi nição de classe. Perceba que o getMapRan-ge leva a referência a um std::map como seu argumento em vez de fa-zer uma cópia. Nenhuma mudança à defi nição de classe C++ foi feita para tornar a vida mais fácil, ao criar vínculos de linguagens ou no uso do SWIG. A defi nição de três novos métodos é padrão e cria somente dados de teste, retornando-o.

O arquivo de interface SWIG, simple2.i , é exibido na listagem 5 . Para descobrir como expor tipos mais complicados, como templa-tes STL, para PHP, o SWIG usa typemap . Por exemplo, algumas lin-guagens têm tipos de classe Integer em vez de usar somente 32/64/N bits de armazenamento, como o C/C++. Um typemap pode distinguir como o SWIG converte tipos C/C++, como int ou std::string , para tipos que a linguagem cliente pode usar, como o PHP nesse caso.

Outro truque que um typemap pode executar é criar novos mé-todos na interface cliente. Você deve estar se perguntando como o SWIG pode injetar novos métodos em classes C++ existentes, o que normalmente não é permitido. O SWIG pode adicionar métodos a classes porque está gerando um wrapper que a linguagem cliente chama. Então, pode criar um outro

Listagem 6: Utilizar o simple2 do PHP 01 <?php0203 include_once("simple2module. php");

0405 $foo = new simple2( "hello" );0607 // blocoA08 $a = new IntVector();09 $a->push(5);10 $a->push(15);11 $a->push(35);12 while( ! $a->is_empty() )13 {14 print "pop: " . $a->pop() . "\n";

15 }1617 // blocoB18 $b = new StringVector();19 echo var_dump($b);20 $b->push("hi manual");21 $b->push("hello");22 print "b.sz:" . $b->size() . "\n";

23 while( ! $b->is_empty() )24 {25 print "pop: " . $b->pop() . "\n";

26 }2728 // blocoE29 print "–– calling simple2:: getMapRange() –––––––––\n";

30 $m = new IntStringMap();31 $m->set( 7, "value" );32 $m->set( 13, "else" );33 $v = $foo->getMapRange( $m );34 echo var_dump($v);35 print "getVec.ret.sz:" . $v->size() . "\n";

36 while( ! $v->is_empty() )37 {38 print "pop: " . $v->pop() . "\n";

39 }40 ?>



método com o código para desem-penhar alguma operação ou pode renomear métodos na classe, mas tudo isso acontece somente no có-digo wrapper.

Você pode querer renomear um método para um formato mais natural para a linguagem cliente. Por exemplo, um programador PHP pode esperar encontrar um método is_empty() para testar se a coleção possui itens ou não, em vez de usar o método empty() que a std::vector oferece. Criar no-vos métodos também pode fazer com que a interface do wrapper fique mais atrativa para os pro-gramadores. Por exemplo, um programador pode procurar um

método pop de uma coleção ao invés da combinação do método back();/pop_back() , que um pro-gramador C++ usaria.

As últimas linhas do arquivo simple2.i dizem ao SWIG quais instâncias de templates devem ser encapsuladas. Normalmente, em C++, você não lista explicita-mente quais types são usadas para instanciar uma classe do template – o compilador faz isso para você automaticamente, porque templates estão sendo usados [6] . O problema com o SWIG é que ele olha somen-te para o cabeçalho que contém a defi nição da classe do template. O SWIG não tem uma forma de sa-ber sozinho a defi nição para quais instâncias da classe template criar wrappers, então você precisa dizer ao SWIG que quer instâncias int e std::string do std::vector e quais instâncias std::map e std::pair ele deve fazer.

A linha specialize_std_map_on_key ( linha 10 , listagem 5 ) é a inclusão mais complicada para o simple2.i . Olhan-do o arquivo PHP std_map.i com o SWIG, você perceberá uma coleção de macros especializadas. Normal-mente, o mapa do arquivo typemap presume que a chave e o valor usado pelo wrapper são ponteiros para ob-jetos C++. Isso funciona bem para coisas como std::string porque o código do wrapper gerado passará em torno dos ponteiros para std::string ao retornar um std::string para o PHP, ou ao aceitar uma como parte da requisição da API.

O problema é que o int é atraves-sado pelo valor entre C++ e o PHP em vez de atravessar um nível do ponteiro, de forma que você precise chamar a specialize_std_map_on_key para que o SWIG saiba que se ele fi zer o wrapper um stc::map com o int como chave, deve esperar que a chave int seja passada por um valor, ao invés de ser passada por meio de um ponteiro.

Embora o SWIG cuide de boa parte das questões, agora você precisa lidar com um pouco mais de complexidade. Por exemplo, você instanciou alguns templates explicitamente e especificou um typemap porque um tipo primiti-vo é passado por valor ao invés de um ponteiro.

O script PHP simple2_test.php exibido na listagem 6 leva a nova extensão para um spin. Como se pode ver no blocoB, você pode criar uma std::vector<std::string> a partir do PHP, além de popular e enumerá-la diretamente. Perceba que o código PHP usa esses no-mes de métodos porque o typemap stc_vector.i renomeou o método empty() para is_empty() e criou um único método pop() de forma que não tenhamos que chamar back() e pop_back() do PHP. No blocoE, um std::map<> é criado e passado para o código C++ para atualizar um std::vector<> como resultado.

Smart pointers: tarefas em tempo real Um grande problema com os exem-plos relativos ao simple1 e simple2 é que objetos da classe não são acessados por meio de ponteiros inteligentes. Para alguns exem-plos simples, isso não importa muito, mas para projetos em C++ maiores, objetos provavelmente serão acessados com o uso de pon-teiros inteligentes, como a classe shared_ptr<> do C++ Technical Report 1 [7] .

A declaração simple3.hh na lista-gem 7 é baseada em simple2.hh , mas adiciona provisões de ponteiros inte-ligentes. A implementação create-Simple cria uma instância de objeto e a retorna como shared_ptr<> .

A interface SWIG é exibida na listagem 8 . Na primeira im-pressão, parece que o template tr1::shared_ptr está sendo decla-

Listagem 8: Arquivo de interface SWIG simple3 01 %{02 #include "simple3.hh"03 %}0405 %include <tr1/memory>06 namespace std {07 namespace tr1 {08 template < class T >09 class shared_ptr10 {11 public:12 shared_ptr( const shared_ptr<T>& );

13 T* operator->();14 };15 };16 };1718 %template(h_simple) std:: tr1::shared_ptr< simple3 >;

19 ...

Listagem 7: Declaração de classe simple3 01 #include <tr1/memory>02 class simple3;03 typedef std::tr1::shared_ ptr< simple3 > h_simple;

0405 class simple306 { ...07 public:08 ~simple3();09 static h_simple createSimple( const std::string& name );

77



rado aqui. Mas como a declara-ção aparece fora do bloco %{...%} , você está se comunicando com o SWIG por meio da declaração tr1::shared_ptr . Ao declarar o mé-todo operator->() , o SWIG ficará ciente de que uma resposta T* pode ser obtida de um shared_ptr<T> , que é, no final das contas, a principal coisa que você quer de um ponteiro inteligente. Você não precisa realmente que o SWIG faça o wrapper das declarações reais e completas do ponteiro. Em vez disso, você só precisa do suficiente para obter o que há no T* . A distinção de mostrar somente parte da declaração de classe para o SWIG pode ser útil quando a declaração C++ real é complexa, mas você não precisa de exposição total. Não há risco aqui, porque a std::tr1::shared_ptr<> real tem um método operator->() compatí-vel com a implementação, então quando compilar o simple3_wrapp.cpp gerado pelo SWIG, o método será encontrado.

O uso de ponteiros inteligentes é bem natural no PHP:

$foo = simple3::createSimple ( "hello" );

print "foo.pubB : " . $foo->m_pubB . "\n";

A principal diferença é usar méto-do estático create-Simple para obter o ponteiro do objeto. Para compilar o simple3, você pode precisar adicionar um -I /usr/include/c++/4.4.4 para a invocação do SWIG.

Modifi cações Já mostrei como o std::vector<> foi encapsulado pelo std_vector.i para renomear o método empty() e incluir o novo método pop() den-tro da classe std::vector , pelo me-nos até onde o PHP pode ver. A parte relevante do php/std_vecotr.ir do SWIG, está na listagem 9 . A palavra-chave %rename leva o novo

nome como um argumento, e o nome de um método existente na classe para o resto da linha.

Primeiro, você deve declarar o verdadeiro método empty() para dizer ao SWIG a assinatura apropriada; então, deverá renomeá-lo. Perceba que você pode usar o %rename com métodos de classes que foram pre-viamente incluídas com %included . O SWIG então gera o código – por exemplo, simple3_wrapp.cpp , que de-pende que a classe std::vector tenha um verdadeiro método empty(0) . A palavra-chave estendida inclui no-vos métodos que você gostaria de classifi car para ter em um vínculo de linguagem. Você deve estar se perguntando como o C++ pode, magicamente, ter métodos adicio-nais. Na verdade, o C++ não muda. O método pop() é o único disponível na classe PHP ou, mais exatamen-te, só existe no código C++ gerado especifi camente para o vínculo da linguagem – no simple3_wrap.cpp , por exemplo.

Como alternativa, você pode usar a palavra-chave %ignore para dizer ao SWIG para não criar o wrapper

de uma classe como método para o binding da linguagem. Essa abor-dagem pode ser prática quando não fi zer muito sentido para a linguagem chamar um método. ■

Listagem 9: Estender o std::vector com SWIG 01 namespace std {0203 template<class T> class vector {

04 public:05 ...06 bool empty() const;07 %rename(is_empty) empty;08 ...09 %extend {10 T pop() throw (std::out_of_range) {

11 if (self->size() == 0)

12 throw std::out_of_ range(“ pop from empty vector”);

13 T x = self->back();14 self->pop_back();15 return x;16 }17 ...

O autor

Ben Martin trabalha com sistemas

de arquivos há mais de dez anos

e, em seu doutorado, pesquisa a

combinação de sistemas de arqui-

vos semânticos com a análise de

conceitos formais para melhorar a

interação entre humanos e siste-

mas de arquivos.

Mais informações

[1] Framework Zend: http://framework.zend.com/Zend/

[2] Interface do Google Web

Services: http://framework.zend.com/manual/en/zend.gdata.html

[3] Página do SWIG: http://www.swig.org/

[4] Biblioteca libsigc++: http://libsigc.sourceforge.net/

[5] Código independente de

posição (PIC): http://en.wikipedia.org/wiki/Position-independent_code

[6] Padrões de template

curiosamente recorrentes:

http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern

[7] Relatório técnico do C++

sobre ponteiros inteligentes:

http://en.wikipedia.org/wiki/Technical_Report_1#Smart_pointers


Fale conosco em

[email protected]



osso s

r/artic

m

zine.com

:

571

igo?opinião.

r


Linux Magazine #83

PR

EVIE

W

Admin Magazine #3

Linux 3.0Na próxima edição da Linux Magazine, você vai conhecer tudo o que acontece por trás do Linux 3.0 e os planos para as futuras versões do sistema operacional. Conheça ainda o Intel Threading Building Blocks, que em sua versão 3.0, traz inúmeras novidades no mundo da paralelização.E para continuar focado no importan-tíssimo assunto que é a migração do protocolo IP para a versão 6, vamos falar sobre segurança em IPv6. Não perca! ■

Conexão seguraQuem precisa conectar computadores com sistemas operacionais diferentes frequentemente precisa procurar por soluções adequadas. O tema de capa da próxima edição da Admin apresenta softwares propiciam uma estreita re-lação entre Windows e Linux e que também servem para conexões com roteadores e fi rewall como os da Cisco, Juniper ou Checkpoint.

http://www.bull.com.br

expediente editorial - linuxmag.com.br · bricantes de celulares equipados com a distribuição...

Documents