Transcrição

1 1

2 2 Cartas dos leitores: E mais uma vez a comunidade agradece José Carlos Cirqueira Júnior ( OmegaB1te ) Analista de Desenvolvimento jccirqueira@microsigarp.com.br Sr. Renato, Sem dúvidas a comunidade de administradores de redes, analistas de segurança e fuçadores de plantão estão muito gratos mais uma vez, agora pela criação desse excelente veículo de informação. Seria excelente que esse material fosse mensal e impresso. Sou cadastrado no site, e apesar de nunca ter contribuido com nada, sou muito grato por toda a informação disponibilizada. Resposta: Muito obrigado José, faremos o possível para torná-la mensal assim que os esforços forem suficientes. Muito obrigado por suas palavras de incentivo e espero que goste dessa nova edição! Não se esqueça também que essa revista não é minha, mas de toda a comunidade! Os agradecimentos são todos direcionados a esses excelentes profissionais que nos ajudaram. Revista para venda Rodrigo Trevisan Analista de Sistemas Jr (Letti Tecnologia S/C Ltda.) rodrigo@letti.com.br Gostaria de saber se existe essa revista para venda (pois pra mim e complicado imprimir aqui na empresa). Gostei muito do conteudo, Voces estao de parabens pela revista!!! Resposta: Obrigado por suas palavras Rodrigo. Por enquanto a revista está disponível apenas online, para que não haja custos ao usuário final, já que o objetivo aqui é apenas disseminar conhecimento ok? Parabéns pela Revista eletrônica Andrey R. Freitas Profissional de Análise/desenvolvimento em Internet andreyn@bol.com.br Parabéns pela iniciativa de criar uma revista especialmente dedicada a segurança. Gostaria de saber como posso participar da elaboração da Revista LinuxSecurity Magazine através de artigos? De quanto em quanto tempo será lançado um novo número e quantos artigos deverão serem enviados? Resposta: Obrigado Andrey, espero que tenha gostado! Para participar da LinuxSecurity Magazine, basta querer dividir seu conhecimento com a comunidade enviando seu trabalho ou artigo que tenha relação com segurança ou administração em geral para o revista@linuxsecurity.com.br. A respeito da periodicidade da revista, ela será sempre lançada conforme o número de contribuições e o tempo livre dos colaboradores. Feliz Notícia Ernesto Paulo dos Santos tito@turnet.psi.br Este não é pra mandar um artigo, mas sim pra agradecer e muito mesmo pelo lançamento da revista online. É um projeto simplesmente muito bom, corajoso e abnegado, de um pessoal de alta credibilidade como vocês. Acredito estar agradecendo por mim e por todos os entusiastas deste sistema maravilhoso. Resposta: Ernesto, não tenho palavras para agradecer seu de incentivo e acredito que são justamente palavras como as suas que nos incentivam a continuar com esse projeto. Falo em meu nome, em nome da revista e, com certeza, em nome de todos esses profissionais que contribuiram com artigos excelentes. Parabéns e oferecimento de colaboração Claudio Pereira cpereira@websistemas.com.br Já há algum tempo acompanho seu trabalho e acho fantástico. A base de conhecimento gerada por você através do é fantástica, tanto já tendo me tirado de muitas enrascadas quanto serviu de inspiração para novos aprendizados. Recebi com festa o primeiro exemplar da Revista. Mais uma vez, parabéns. Por outro lado, gostaria de, humildemente, oferecer a você ajuda na revisão ortográfica e gramatical dos textos. Tenho certa experiência com redação e o fato de parte de meus clientes ser constituída de editoras e pessoal ligado à educação me força a uma atualização constante neste sentido. Resposta: Claudio, fico contente em saber que o projeto LinuxSecurity Brasil e seus sub projetos sejam úteis ao amigo. Fico mais contente ainda em ler o oferecimento de ajuda para a revisão dos textos, ela será muito bem vinda!

3 3 Linux Security Magazine Arthur César Oreana Te escrevo este para parabenizar pela edição de Julho da LinuxSecurity Magazine, em formato PDF. Ótimos artigos, com pessoas competentes falando sobre ferramentas e segurança. Agora, só falta fazer a publicação impressa! Estou aguardando as próximas edições e espero que a qualidade seja a mesma apresentada nesta edição.parabéns e muito sucesso! Resposta: Muito obrigado Arthur, espero que goste das próximas edições tanto quanto gostou da primeira! Magazine Wagner Stabolito - PSI wagners@psinfo.com.br Existe a intenção de publicar a revista pelos meios tradicionais? Se já é publicada, como faço para adiquirila? Resposta: Wagner, como a revista não tem fins lucrativos, nosso objetivo é distribuí-la da forma mais rápida e ampla possível. Há sim o desejo de publicá-la impressa, mas ainda não é algo imediato ok? Espero que goste das próximas edições! Felicitaciones Maurício Oliveira mauricio.oliveira@embrapa.br Gostaria de parabelizá-los pelo importante trabalho e pela iniciativa de conduzir a informação gerada a toda comunidade da informática. AOS CRIADORES, OS MEUS PARABÉNS PELA REVISTA. Resposta: Obrigado Maurício! Os criadores da revista (toda a comunidade de profissionais que participou e tornou a mesma possível) agradecem! Revista LinuxSecurity Adriano Filippin - SDCNet e-solutions adriano@sdcnet.com.br Resposta: Obrigado Adriano, contamos com o amigo não apenas como leitor mas como crítico nos enviando sempre sugestões ok? Obrigado mais uma vez por suas palavras de incentivo. Revista João Alexandre Voss de Oliveira joaoalex@via-rs.net Parabéns pela revista linuxsecurity. Acabo de baixála, uma excelente iniciativaa de vcs. Ainda não li toda, mas até onde eu vi, está uma beleza. Continuem assim! Resposta: Esperamos poder continuar mantendo a qualidade da revista da melhor forma que pudermos. Muito obrigado! Agradecimento Gostaria de agradecer a todos pelos mais de 450 s recebidos com parabenizações pela revista, sugestões, dicas, e me desculpar pela relativa demora para responder cada um deles. Como já disse anteriormente, essa revista pertence a todos vocês, então retribuo a todos com um grande e sincero MUITO OBRIGADO! Elogie, critique e dê sugestões. Este espaço é seu, leitor. Envie sua carta através do abaixo. revista@linuxsecurity.com.br Gostaria de parabenizar todos os responsáveis pela criação da LinuxSecurity Magazine, achei as materias bem interessantes, estávamos mesmo precisando de uma publicação desse tipo, principalmente para nós que adotamos o ambiente Linux como nosso principal sistema operacional, e pode ter certeza que vou ser leitor assíduo dessa revista. Parabéns a todos.

4 4 Índice 07 - Como obter melhor performance do Apache no Unix Fabio Wakim Trentini 14 - As 1001 utilidades do FreeBSD LiveCD Edson Brandi 23 - slocate (Secure Locate) Rubens Queiroz de Almeida 26 - Monitorando tráfego de rede interna utilizando SASacct/RRDtool Diogo Florenzano Avelino colabaração de Marcus Maciel 30 - Monitoração com RRDTool Rodrigo P. Telles 35 - Construindo filtros para o qmail Diego Linke - Gamk 39 - Enriquecendo os Logs do seu sistema Unix e Facilitando a Auditoria Parte 2 Renato Murilo Langona 46 - RAID via Software em GNU/Linux - Recursos, Possibilidades e Apliações José Roberto Kerne 58 - Guia rápido para a configuração do Amavis com Postfix no Conectiva Linux 8.0 Emerson Reis 63 - Criptografia de disco Jair Valmor Basso Júnior 68 - (In)Segurança Básica no MySQL Glaudson Ocampos 76 - Introdução à Análise Forense - Parte II Leonardo Alcântara Moreira 79 - Sniffers - Básico e Detecção Sumit Dhar 87 - Corridas e chegadas Izar Tarandach 91 - Vitaminando o velho Syslogd Sandro Melo Usando o jail no FreeBSD Jean Milanez Melo

5 5 Colaboradores Diretor Executivo: Renato M. Langona Diretor de Operações: Renato M. Langona Diretor de Marketing: Renato M. Langona Colaboradores especiais: Luiz Gustavo M. Nozella Editorial É com grande honra que o projeto LinuxSecurity Brasil apresenta à comunidade nacional mais uma edição de nossa revista eletrônica. Tivemos alguns contratempos e um grande atraso para o lançamento da mesma, porém acredito que toda a espera será recompensada pelas mais de 100 páginasde informações dessa edição. Infelizmente não pudemos incluir muitos trabalhos enviados devido à falta de espaço e também ao curto tempo disponível para a revisão e diagramação de todos os textos. Esses trabalhos que não foram incluídos na segunda edição já tem lugar garantido no terceiro número de nossa revista. Gostaria mais uma vez de agradecer a comunidade por todo o apoio, todos os s com sugestões, parabenizações, além de todos os excelentes profissionais que colaboraram e continuam colaborando conosco para que esse projeto possa continuar em pleno desenvolvimento. Como disse no primeiro número, a LinuxSecurity Magazine é resultado do esforço conjunto da comunidade e a LinuxSecurity Brasil apenas é responsável por unir esses esforços e apresentar a revista, portanto ela pertence um pouco a cada um de vocês. Espero sinceramente que essa seja a segunda de diversas próximas edições e que possamos entregar ao público Brasileiro cada vez mais qualidade em conteúdo livre e que esse conteúdo seja disseminado entre profissionais da comunidade da melhor forma possível. Mais uma vez deixo a todos os membros e leitores o convite para participarem desse trabalho conjunto enviando seus artigos para próximas edições da revista. Webmaster: Renato M. Langona Assessoria Gráfica e Design: Luiz Gustavo M. Nozella Diagramação: Luiz Gustavo M. Nozella Capa: Luiz Gustavo M. Nozella Revisão: Renato M. Langona Gerente Administrativo: Renato M. Langona LinuxSecurity Magazine é uma publicaçã LinuxSecurity Brasil Solutions S/C Ltda. Distribuição Exclusiva: On-line Fax para contato: SAC (Serviço de Atendimento ao Cliente) Problemas de qualidade na entrega e/ou exemplares. O SAC presta atendimento aos leitores por revista@linuxsecurity.com.br A LinuxSecurity Magazine não se responsabiliza por conceitos emitidos nos artigos assinados de colaboradores. A LinuxSecurity Magazine não se responsabiliza por eventual quebra de links fornecidos por colaboradores, nem pelo material exposto neste(s) link(s). Problemas com quebra de links devem ser reportados para revista@linuxsecurity.com.br. Utilize o subject: "Link Quebrado", indicando a edição e o artigo. A fim de proteger todos os interessados e ainda estipular a divulgação de material referente ao Linux e a LinuxSecurity Magazine, convencionou-se que reproduções de texto da LinuxSecurity Magazine são permitidos, desde que se inclua a frase "Reproduzido com a permissão da LinuxSecurity Magazine ()". da

6 6

7 Como obter melhor performance do Apache no Unix por Fabio Wakim Trentini 7 Qual administrador de sistemas não deseja obter mais performance dos seus servidores web? Não que existam problemas de performance na configuração padrão do Apache, mas várias otimizações podem ser feitas no intuito de melhorar seu desempenho. Este texto mostra algumas dicas de como melhorar sua configuração para obter o máximo de performance. O começo de tudo Ao rever o processo de compilação do Apache podemos deixá-lo menor e mais eficiente. Nesta fase, existem basicamente três itens com os quais é necessário preocupar-se: de usar ou não suporte a DSO (Módulos dinâmicos), quais regras são realmente necessárias e o limite hardcoded de 256 clientes simultâneos. Se pesquisarmos pela rede, existem vários textos contraditórios a respeito de utilizar ou não suporte a módulos dinâmicos no Apache, mas o que realmente faz a diferença é saber exatamente quais módulos são necessários carregar na memória para rodar seu servidor web. Basicamente, se algum módulo não é estritamente necessário em sua configuração, não o carregue. Isso vale para as regras do Apache também. O problema de compilar o Apache estático, sem suporte aos módulos dinâmicos, é que ele funciona para aquele exato tipo de aplicação, ou seja, se você tem centenas de servidores web, que rodam configurações distintas, provavelmente você vai preferir compilá-lo com suporte a módulos e vai carregá-los conforme a necessidade de cada servidor web. As sensíveis diferenças de utilizar ou não o suporte a módulos dinâmicos é no startup do webserver, que demora aproximadamente 20% a mais de tempo do que o Apache compilado estático. Dizem também que em algumas plataformas a versão compilada com suporte a DSO fica até 5% mais lento, mas realizando testes em servidores Unix não foi notada esta diferença. O Apache vem com algumas regras especiais que podemos habilitar ou desabilitar, dependendo das necessidades de cada servidor web. Aqui estão as mais relevantes: DEV_RANDOM: Habilita suporte para o device /dev/random nas famílias de Unix que suportam tal dispositivo. A regra serve para módulos que necessitam de números aleatórios, mas o único módulo que vem junto com o Apache e utiliza desse recurso Ficha do Autor Nome: Fabio Wakim Trentini Idade: Profissão: Consultor de Sistemas trentas@uol.com.br Informações Adicionais É consultor de sistemas do UOLInc e mantém o site Apache Brasil. Site:

8 8 é o mod_auth_digest. EXPAT: Incorpora da biblioteca de parsing de XML Expat, para módulos do Apache que processam XML. Na distribuição do Apache não existe nenhum módulo que necessite dessa regra, mas se, por exemplo, existir a necessidade de utilizar o mod_dav (que é um módulo de terceiros), a Expat será requerida. IRIXN32 e IRIXNIS: Regras específicas para compilar o Apache na plataforma Irix (SGI). SHARED_CHAIN: Algumas plataformas têm problemas em carregar bibliotecas necessárias para certos módulos, como por exemplo, que o mod_ssl precisa carregar a lib do openssl para subir. Essa regra corrige o problema, por isso ela apenas deve ser habilitada caso necessário. WANTHSREGEX: Esta regra habilita um engine interno de processar regular expressions, em vez de utilizar o próprio engine do sistema operacional, que normalmente é suficiente. Quando você compila o Apache ele vem com um limite hardcoded de 256 clientes simultâneos, que obviamente podemos aumentar setando uma simples variável de ambiente, a CFLAGS. Ao juntar todas as otimizações, segue abaixo um exemplo de como compilar o Apache com limite de 2048 clientes simultâneos, todas as regras desabilitadas, suporte a DSO e compilando todos os módulos (inclusive o experimental mod_mmap_static, que será falado adiante): # export CFLAGS= - DHARD_SERVER_LIMIT=2048'; \./configure \ disable-rule=dev_random \ disable-rule=expat \ disable-rule=irixn32 \ disable-rule=irixnis \ disable-rule=shared_chain \ disable-rule=wanthsregex \ enable-module=most \ enable-module=mmap_static \ enable-shared=max \ prefix=/usr/local/apache \ && make && make install Depois de instalar, podemos rodar strip no executável principal e em seus módulos, no intuito de remover as tabelas de símbolos, assim: # cd /usr/local/apache/ ; strip bin/* libexec/* Controle de processos do Apache O Apache roda no Unix com um sistema de pre-forking, ou seja, quando o processo principal sobe, ele cria vários processos filhos para atender as requisições, e mantém uma faixa de processos filho reserva para algum eventual crescimento de carga. Existem cinco diretrizes que controlam isso: StartServers <número> Determina quantos processos filhos serão gerados quando o servidor web sobe. Quanto maior o número aqui, mais rápido o Apache atenderá a demanda de todos os requests por segundo, mas por outro lado ele vai gerar uma carga muito maior no servidor quando subir o webserver. O default é 5, mas em servidores com muito tráfego este número pode crescer bastante.

9 9 MinSpareServers <número> É o número mínimo de processos que ficam abertos sem atender a nenhuma requisição, e se o Apache precisar criar mais processos filhos ele vai aumentando o MinSpareServers num algoritmo de progressão geométrica até atender a nova demanda. O default é 5, e deve ser aumentado em sites de muito tráfego. Nota que se o MinSpareServers for maior que o StartServers, o número de processos filhos criados na inicialização será o número setado no MinSpareServers. MaxSpareServers <número> É o número máximo de processos que ficam abertos sem atender a nenhuma requisição, para garantir que no caso de um crescimento de demanda, já existam processos prontos para atender as requisições. O default é 10, e novamente em servidores com muito tráfego e possíveis picos de audiência, é recomendado aumentar este número. MaxClients <número> Não importa quantas requisições simultâneas o Apache pode atender, ele respeitará o numero máximo de clientes simultâneos fixado nessa diretriz. Esta diretriz é importante para colocar um limite físico de até quanto o processo pai pode gerar filhos, pois a cada filho criado é um pedaço da memória RAM que se vai da máquina em questão. O default é 256, e para aumentar este valor é necessário alterar na hora da compilação, conforme descrito no início do artigo. MaxRequestsPerChild <número> Esta diretriz serve para dizer ao webserver quantas requisições cada processo filho irá atender antes de morrer. Isto é bom para prevenir memory leaks, mas dependendo de sua plataforma e dos módulos que estão carregados no webserver, não há necessidade de terminar os processos, salvando recursos do sistema. A melhor forma de ver se seu servidor web sofre de algum memory leak é deixar este valor ilimitado (setando com valor zero), e análise no início do dia o tamanho dos processos filhos, com top, ps, ou algo do tipo, e aí no final do dia faça o mesmo teste. Se os processos aumentam de tamanho com o passar do tempo é interessante colocar algum número entre e , dependendo da gravidade do leak. Normalmente memory leaks acontecem com módulos externos, como mod_php e mod_perl, que armazenam variáveis, estruturas de dados, etc. Keepalives e Timeouts Quatro diretrizes mais importantes a respeito de timeouts do HTTP, a seguir: TimeOut <número> Este timeout é o tempo corrido desde a conexão estabelecida ate o primeiro GET do cliente, ou desde o último ACK recebido se ainda existem mais dados para vir. O default é 300 segundos, e pode ser reduzido a até 60 segundos. Um tempo menor que esse podem ocorrer alguns problemas servindo arquivos com muitos bytes. KeepAlive <on off>

10 10 O protocolo HTTP/1.1 possui o suporte de trafegar vários objetos do mesmo webserver para um cliente utilizando apenas uma conexão TCP, reduzindo o overhead do mesmo cliente abrir várias conexões com o servidor web. Dependendo das características do seu servidor web, é interessante ou não deixar o keepalive habilitado. Por exemplo, se seu servidor web serve apenas uma página HTML, feita por alguma aplicação Perl, PHP ou Java, e as imagens e outros objetos estão em outros servidores, não há a menor necessidade de habilitar esta diretriz. Com esta diretriz habilitada, mais processos filhos do Apache você terá em seu servidor. E se esta diretriz de habilitar conexões persistentes for habilitada, existem mais duas diretrizes para configurá-la, a seguir. MaxKeepAliveRequests <número> Esta diretriz impõe o limite de objetos servidos pelo servidor web numa mesma conexão TCP. O default é 100 e normalmente não há necessidade de alterar este valor. KeepAliveTimeout <número> É o tempo máximo de silêncio que o servidor mantém a conexão TCP aberta com o cliente. O default é 15 segundos, mas no caso do servidor ter muito tráfego isso pode ser reduzido em até 5 segundos, ou se o tráfego for baixo existe a possibilidade de aumentar este timeout. Caching Quanto mais, melhor. Imagine um site de notícias, que é atualizado uma vez por hora. Um dia acontece uma queda na bolsa e o dólar sobe assustadoramente. Seus clientes vão acessar sem parar seu site à procura de novas notícias no decorrer do dia. Você acaba servindo, para um único cliente, dezenas e dezenas de cópias da mesma página HTML, devido ao seu tempo de atualização. Porque então não avisar para todos os seus clientes que sua página expira uma vez por hora, para que seu servidor sirva menos páginas por segundo? Existe um módulo no Apache chamado mod_expires, que faz este tipo de negociação de objetos servido com os browsers e proxies afora, quando falamos de HTTP/1.1. Segue como usá-lo: ExpiresActive <on off> Esta diretriz habilita ou desabilita o header de caching dos documentos servidos em HTTP/1.1. Pode ser colocada dentro de um <Directory>, <Location>, <VirtualHost>, etc... ExpiresDefault <código+número> O código citado serve se você quer cachear por data de modificação (mtime) ou de acesso (atime), mais o número de segundos de expiração. Codificando o exemplo do site de notícias acima, chegamos ao seguinte trecho: <Location /noticias> ExpiresActive on ExpiresDefault M3600 </Location> ExpiresByType <mime-type> <código+número>

11 11 Esta diretriz serve para habilitar caching apenas de determinados mime types, como por exemplo, para cachear por um mês apenas as imagens jpeg do servidor em questão: ExpiresByType image/jpeg A CacheNegotiatedDocs Em vez do mod_expires, esta diretriz necessita do mod_negotiation, e serve para habilitar caching em browsers e proxies que falam somente o protocolo HTTP/1.0. Carregando objetos estáticos em RAM Existe um módulo experimental no código do Apache que chama mod_mmap_static, e serve para colocar um ou mais objetos em RAM no servidor no intuito de diminuir o acesso ao disco ou a um servidor NFS onde supostamente ficaria o DocumentRoot. Este módulo é bom quando você serve algum objeto estático que não tem constantes alterações e é amplamente utilizado, como por exemplo a imagem do logotipo de sua empresa, que está em todas as suas páginas. A desvantagem de utilizar este módulo é que se você carrega um objeto em RAM e depois altera o conteúdo do objeto no disco, apenas no próximo restart do webserver será possível ver a alteração do conteúdo. Outro problema também é que se por acaso este objeto que foi cacheado com o mod_mmap_static sumir no disco, normalmente o Apache gera um core e morre por Segmentation Fault. A sintaxe é a seguinte: MMapFile <arquivo> Nota que é aceito apenas um arquivo por vez. Se você quer carregar dez arquivos em RAM, serão dez linhas de MMapFile no seu httpd.conf. Evitar ao máximo as gorduras mod_rewrite O mod_rewrite é sem dúvida o módulo mais poderoso já criado para o Apache. Utilizando regras com regular expressions você pode reconstruir qualquer URL ou objeto a ser servido, entre outras coisas. Mas no quesito performance, ele acaba sendo um grande gargalo para a CPU devido ao processamento on-line de todas as requisições que chegam. Se for inevitável utilizá-lo, prefira regras que fazem stat() no disco em vez de regular expressions complicadas, para reduzir o consumo de CPU. mod_status Este módulo mostra o famoso serverstatus do servidor, com várias informações a respeito dos processos filhos e utilização do Apache, mas como qualquer sistema de análise on-line, este módulo faz o webserver consumir mais recursos da máquina, principalmente se a opção ExtendedStatus estiver habilitada. DirectoryIndex Esta diretriz do mod_dir fala quais arquivos e em que ordem o Apache deve procurar para carregar como página de índice. Normalmente ele vem configurado para abrir a página index.html, mas é permitido colocar vários tipos de páginas, podendo inclusive colocar apenas trechos de arquivos. E é aí que podemos ter problemas de performance. Se você pede pra ele procurar por qualquer

12 12 arquivo que começa por index, por exemplo, ele terá que procurar todos os arquivos com este nome no disco, para cada requisição que for pedida. O ideal mesmo é colocar o mínimo possível de arquivos nesta diretriz, e nunca utilizar os recursos de trechos de nomes de arquivos para ele escolher. Options O segredo desta diretriz é sempre manter o FollowSymLinks e nunca, nunca utilizar SymLinksIfOwnerMatch. Deixando o FollowSymLinks, algum usuário indevido pode criar um link simbólico para a raiz do servidor, criando um furo enorme de segurança, mas se é impossível um cliente criar um link simbólico em seu filesystem é a opção mais performática que se pode ter. HostNameLookups Esta opção serve para o Apache resolver o DNS reverso de qualquer IP que pede algum objeto, para gravar o hostname (se o DNS conseguir resolver) no log. Isto acaba com a performance do Webserver e não é recomendado. Com essas dicas já é possível melhorar consideravelmente a performance de um servidor Apache, mas o ideal é sempre analisar caso a caso, o tipo de aplicação, o perfil de clientes que acessa, enfim, existem vários conceitos de como otimizar seus servidores. Keep tuning!

13 13

14 14 As 1001 utilidades do FreeBSD LiveCD por Edson Brandi Um pouco de História No próximo dia 18 de setembro o Projeto FreeBSD LiveCD estará completando 1 ano de existência, o projeto nasceu em setembro de 2001 de uma necessidade interna do FUG-BR (Grupo Brasileiro de Usuários FreeBSD) em possuir um repair disk que fosse verdadeiramente útil. Naquela época a comunidade FreeBSD não dispunha de ferramentas adequadas para serem utilizadas em situações de emergência, o repair disk oferecido no set de CDs da distribuição oficial não era 100% funcional e o uso do mesmo para uma operação de disaster recovery deixava muito a desejar. Visando suprir essa necessidade o FUG- BR iniciou uma série de testes com o sistema, com o objetivo de gerar uma versão dos arquivos de inicialização que permitissem a execução a partir de um cd-rom de uma versão 100% funcional do sistema FreeBSD. Os primeiros resultados foram divulgados no início do mês de outubro quando o FUG-BR disponibilizou oficialmente o primeiro ISO do projeto FreeBSD LiveCD. Desde o lançamento a aceitação do projeto por parte da comunidade nacional e internacional foi muito boa e, como esperado, começaram a chegar uma série de pedidos de customização. Diante do enorme número de pedidos para a geração de versões customizadas do LiveCD, o FUG-BR decidiu disponibilizar em janeiro/2002 o conjunto de scripts que foram utilizados para a geração do ISO, de forma que qualquer usuário do sistema poderia criar de maneira extremamente simples a sua própria versão do LiveCD. Liberada a versão 1.0 do FreeBSD LiveCD Toolset, o objetivo do projeto passou a ser a integração do mesmo à árvore do ports do FreeBSD, maximizando desta forma a exposição do projeto perante a comunidade FreeBSD. Este objetivo foi alcançado em junho/ 2002, quando após alguns meses de intenso desenvolvimento, o grupo responsável pelo projeto disponibilizou uma versão totalmente nova dos scripts, contando inclusive com suporte a vários idiomas. Atualmente os scripts do FreeBSD LiveCD ToolSet estão disponíveis a todos os usuários do sistema que utilizam o ports para a instalação dos seus aplicativos (/usr/ports/sysutils/livecd/ ). Ficha do Autor Nome: Edson Brandi Idade: 25 anos Profissão: Gerente de Tecnologia ebrandi.home@uol.com.br Informações Adicionais Trabalha profissionalmente com FreeBSD desde 1995 tendo atuado como consultor junto a várias empresas nos últimos anos. É um membro ativo da comunidade FreeBSD, sendo o responsável pelo site FreeBSD Primeiros Passos ( fundador do Grupo Brasileiro de Usuários FreeBSD ( responsável pelo projeto FreeBSD LiveCD (livecd.sourceforge.net). Atualmente trabalha como Gerente de Tecnologia no ibest ( Site:

15 15 O próximo passo do projeto é aperfeiçoar os scripts e expandir as funcionalidades/ usos do FreeBSD LiveCD. Etapas do processo (resumido) de geração do LiveCD Ao dar boot em um computador com o FreeBSD LiveCD, você terá disponível em poucos segundos, um sistema Unix 100% funcional. Para que isso fosse possível foi necessária uma série de ajustes nos arquivos de inicialização do sistema e uma pequena customização do kernel. No nível dos arquivos de inicialização a maior alteração (se não a mais importante) foi realizada no arquivo /etc/rc. Este arquivo foi alterado de forma a não montar os sistemas de arquivos (necessários ao funcionamento do sistema) a partir do /etc/fstab, mas sim executar algumas operações alternativas. Dentre as possibilidades previstas, estava a criação dinâmica dos FS em memória RAM (MFS), auto detecção das partições existentes no HD do usuário associada a possibilidade de se utilizar arquivos imagem (vnodes) nestas partições para possibilitar salvar de forma permanente as configurações efetuadas ou ainda para instalar novos aplicativos no LiveCD. O fragmento de Shell Script que implementou essas alterações no /etc/rc pode ser visto abaixo, o mesmo está devidamente comentado de forma que você não terão dificuldades para entender seu funcionamento. (qualquer sugestão de melhora nesse script são bem vindas) ############################################ echo Gerando o /dev em MFS... mount_mfs -s c 20 -o noatime swap /dev 2>&1 tar -xzpf /mfs/dev.tgz -C / >/dev/null 2>&1 cd /dev./makedev all >/dev/null 2>&1 # # Detecta os discos IDE e os slices existentes e monta todos os slices que forem # do tipo FAT, NTFS, UFS, EXT2FS # # echo Detectando slices disponiveis... # for i in dmesg egrep ad0: ad1: ad2: ad3: awk -F : {print

16 16 $1} sort uniq do a=1 for x in fdisk /dev/$i grep sysid awk -F, {print $1} awk {print $2} do case ${x} in 5) echo Particao FAT16/32 encontrada em /dev/${i}s${a}, montando em /mnt/dos.${a}... mount -t msdos /dev/${i}s${a} /mnt/dos.${a} ;; 6) echo Particao FAT16/32 encontrada em /dev/${i}s${a}, montando em /mnt/dos.${a}... mount -t msdos /dev/${i}s${a} /mnt/dos.${a} ;; 12) echo Particao FAT16/32 encontrada em /dev/${i}s${a}, montando em /mnt/dos.${a}... mount -t msdos /dev/${i}s${a} /mnt/dos.${a} ;; 7) echo Particao NTFS encontrada em /dev/${i}s${a}, montando em /mnt/ntfs.${a}... mount -t ntfs /dev/${i}s${a} /mnt/ntfs.${a} ;; 131) echo Particao EXT2FS encontrada em /dev/${i}s${a}, montando em /mnt/ext2fs.${a}... mount -t ext2fs /dev/${i}s${a} /mnt/ext2fs.${a} ;; 165) echo Particao UFS encontrada em /dev/${i}s${a}, montando em /mnt/ufs.${a}... mount /dev/${i}s${a} /mnt/ufs.${a} ;; esac a= expr $a + 1 done done #### #### # # Verifica se existe o diretorio FreeBSD em cada slice montado, existindo ele

17 17 # busca os arquivos.flp para atachar como um virtual node # echo Verificando disponibilidade de Virtual Nodes... # for i in df -k egrep ufs dos ntfs ext2fs awk {print $6} do if [ -r ${i}/freebsd ]; then if [ -r ${i}/freebsd/tmp.flp ]; then vnconfig -c /dev/vn1c ${i}/freebsd/tmp.flp sleep 2 mount /tmp fi if [ -r ${i}/freebsd/var.flp ]; then vnconfig -c /dev/vn3c ${i}/freebsd/var.flp sleep 2 mount /var fi if [ -r ${i}/freebsd/etc.flp ]; then vnconfig -c /dev/vn4c ${i}/freebsd/etc.flp sleep 2 mount /etc. /etc/rc.conf fi if [ -r ${i}/freebsd/home.flp ]; then vnconfig -c /dev/vn5c ${i}/freebsd/home.flp sleep 2 mount /home fi if [ -r ${i}/freebsd/root.flp ]; then vnconfig -c /dev/vn6c ${i}/freebsd/root.flp sleep 2 mount /root fi if [ -r ${i}/freebsd/local.flp ]; then vnconfig -c /dev/vn7c ${i}/freebsd/local.flp sleep 2 mount /usr/local

18 18 fi if [ -r ${i}/freebsd/x11r6.flp ]; then vnconfig -c /dev/vn8c ${i}/freebsd/x11r6.flp sleep 2 mount /usr/x11r6 fi fi done # Verifica se os virtual nodes foram montados (atraves de um arquivo de controle) # se encontrar o arquivo da a particao como montada, se nao encontrar gera a particao # em MFS e descompacta os arquivos necessarios. # if [ -r /tmp/xyz123_ ]; then echo O /tmp foi montado via virtual node else mount_mfs -s c 20 -o nodev,noexec,nosuid,noatime swap / tmp 2>&1 echo Gerando /tmp em MFS fi if [ -r /var/xyz123_ ]; then echo O /var foi montado via virtual node else mount_mfs -s c 20 -o noatime swap /var 2>&1 /usr/sbin/mtree -deu -f /etc/mtree/bsd.var.dist -p /var >/dev/ null 2>&1 logs= /usr/bin/awk $1!= # { printf %s, $1 } /etc/ newsyslog.conf if [ -n $logs ]; then /usr/bin/touch $logs fi /usr/bin/touch /var/log/lastlog echo Gerando /var em MFS fi if [ -r /etc/xyz123_ ]; then echo O /etc foi montado via virtual node else mount_mfs -s c 20 -o noatime swap /etc 2>&1 tar -xzpf /mfs/etc.tgz -C / >/dev/null 2>&1

19 19 fi echo Gerando /etc em MFS if [ -r /home/xyz123_ ]; then echo O /home foi montado via virtual node else mount_mfs -s c 20 -o noatime swap /home 2>&1 echo Gerando /home em MFS fi if [ -r /root/xyz123_ ]; then echo O /root foi montado via virtual node else mount_mfs -s c 20 -o noatime swap /root 2>&1 tar -xzpf /mfs/root.tgz -C / >/dev/null 2>&1 echo Gerando /root em MFS fi if [ -r /usr/local/xyz123_ ]; then echo O /usr/local foi montado via virtual node else mount_mfs -s c 20 -o noatime swap /usr/local/etc 2>&1 tar -xzpf /mfs/local_etc.tgz -C / >/dev/null 2>&1 echo Gerando /usr/local/etc em MFS fi mount proc ############################################ Sem o fragmento acima, uma série funcionalidades do sistema seriam prejudicadas uma vez que 100% dos sistemas de arquivos seriam do tipo read only. O que o script faz é basicamente montar todos os diretórios que precisam ser read write em MFS ou VNODES. Uma vez alterado o arquivo de boot do sistema, era necessário efetuar alguns ajustes no kernel para que o / pudesse ser montado a partir do drive de CD, além de adicionar o suporte aos Vnodes. Desta forma foram adicionadas ao arquivo de configuração do kernel as seguintes linhas: options ROOTDEVNAME=\ cd9660:acd0\ options UNION pseudo-device vn 15 Uma vez feitos esses ajustes bastou gerar um CD bootavel, o que foi feito com o comando mkisofs (as opções exatas podem ser vistas nos scripts do toolset). A maioria das pessoas se surpreende ao saber que foi tão simples resolver um problema que incomodava a comunidade há tanto tempo, mas é a pura verdade. Usamos um pouco de

20 20 Shell script e um pouco de imaginação :-) Atualmente o Toolset é composto por vários scripts shell (Bourne Shell) e caso alguém tenha interesse em conhecer todas as etapas do processo de geração eu sugiro que leiam os scripts que compõem o FreeBSD LiveCD ToolSet. Na medida do possível estão todos muito bem comentados. Possibilidades de uso Essa é, sem duvida, a melhor coisa do FreeBSD LiveCD. As possibilidades de uso são inúmeras, ficando restritas na maior parte das vezes à sua necessidade/ criatividade. A partir do Toolset você pode criar discos customizados paras as mais diversas funções tais como: orepair Disk oinstall Disk ojump Start Install odisaster Recovery ox terminal oroteador obridge ofirewall oetc A maioria dos administradores de sistemas podem se beneficiar de varias dessas funções sendo considerado como sendo as mais interessantes Jump Start Install e Disaster Recovery. Para exemplificar melhor uma das possibilidades de uso do FreeBSD LiveCD, vamos fazer um estudo de caso (verídico) Uma empresa especializada na comercialização de servidores FreeBSD pré configurados precisa fornecer aos seus clientes uma maneira simples e rápida de recuperar o seu servidor ao seu estado inicial, ou seja, deixar o servidor no estado que estava quando saiu da caixa, algo semelhante aos discos de recuperação enviados junto com os equipamentos compaq. A demanda acima é um caso típico de aplicação do LiveCD, pois ele pode ser preparado de forma a espelhar um servidor recém instalado, contendo todas as aplicações e customizações necessárias, e ser utilizado como mídia de instalação em operações de disaster recovery no futuro. Caso o servidor passe por algum problema de hardware que acarrete a perda do sistema, tal como a queima de um HD, o cliente pode simplesmente substituir o HD defeituoso por um novo, dar um boot com o CD criado com o espelho do sistema e em menos de 5 minutos terá recuperado o servidor, de forma que o servidor recém instalado seja idêntico ao que existia antes do problema. Instalado o sistema, basta recuperar o backup dos dados (não existiam no momento da geração do LiveCD), e seu sistema estará de volta à produção em poucos minutos sem a necessidade de um longo downtime e sem a necessidade de que um técnico se desloque até o local para efetuar a recuperação do sistema. Existem outras possibilidades de uso de um disco preparado para essa finalidade, além da situação de emergência descrita acima, imagine que essa mesma empresa venda servidores em escala industrial e todas as máquinas saem pré-instaladas e pré-