Entendendo (e quebrando) a segurança em redes Wireless

Um dos grandes problemas em uma redes wireless é que os sinais são transmitidos pelo ar. Os pontos de acesso e placas utilizam por padrão antenas baratas, que proporcionam um alcance reduzido, fazendo com que o sinal da sua rede possa ser capturado de muito mais longe por alguém com uma antena de alto ganho.

Não existe como impedir que o sinal se propague livremente pelas redondezas (a menos que você pretenda ir morar em um bunker, com paredes reforçadas com placas de aço), de forma que a única forma eficaz de proteção é encriptar toda a transmissão, fazendo com que as informações capturadas não tenham serventia.

Como esta questão da segurança em redes wireless é muito divulgada, a maior parte das redes já utiliza algum tipo de proteção, seja ativando o WEP ou WPA, seja bloqueando os micros que podem se conectar ao ponto de acesso com base no endereço MAC.

Este tópico se destina a mostrar como é fácil burlar a maioria destas proteções e quebrar a encriptação do WEP (inclusive do WEP de 128 bits), usando ferramentas simples.

É melhor que você conheça os ataques mais usados e veja você mesmo como é possível derrubar cada uma das proteções que utilizamos em uma rede típica, do que ficar com um falso senso de segurança, achando que o WEP de 128 é inquebrável, que não é possível detectar um ponto de acesso com o SSID broadcast desativado, ou que não é possível burlar a restrição de acesso baseada no endereço MAC usada em muitas redes.

Usando o Kismet

O Kismet é uma ferramenta poderosa, que pode ser usada tanto para checar a segurança de sua própria rede wireless, quanto para checar a presença de outras redes próximas e assim descobrir os canais que estão mais congestionados (e assim configurar sua rede para usar um que esteja livre) ou, até mesmo, invadir redes. O Kismet em sí não impõe restrições ao que você pode fazer. Assim como qualquer outra ferramenta, ele pode ser usado de forma produtiva ou destrutiva, de acordo com a índole de quem usa. A página do projeto é a: http://www.kismetwireless.net/.

A principal característica do Kismet é que ele é uma ferramenta passiva. Ao ser ativado, ele coloca a placa wireless em modo de monitoramento (rfmon) e passa a escutar todos os sinais que cheguem até sua antena. Mesmo pontos de acesso configurados para não divulgar o ESSID ou com a encriptação ativa são detectados.

Como ele não transmite pacotes, apenas escuta as transmissões, todo o processo é feito sem prejudicar as redes vizinhas, de forma praticamente indetectável. A principal limitação é que, enquanto está em modo de monitoramento, a placa não pode ser usada para outros fins. Para conectar-se a uma rede, você precisa primeiro parar a varredura.

Esta questão da detecção dos pontos de acesso com o ESSID desativado é interessante. Não é possível detectá-los diretamente, pois eles não respondem a pacotes de broadcast (por isso eles não são detectados por programas como o Netstumbler), mas o Kismet é capaz de detectá-los quando um cliente qualquer se associa a eles, pois o ESSID da rede é transmitido de forma não encriptada durante o processo de associação do cliente.

A partir daí, o Kismet passa a capturar todos os pacotes transmitidos. Caso a rede esteja encriptada, é possível descobrir a chave de encriptação usando o aircrack (que veremos a seguir), permitindo tanto escutar as conexões, quanto ingressar na rede.

Como o Kismet é uma das ferramentas mais usadas pelos crackers, é sempre interessante usá-lo para verificar a segurança da sua própria rede. Tente agir como algum vizinho obstinado agiria, capturando os pacotes ao longo de alguns dias. Verifique a distância de onde consegue pegar o sinal de sua rede e quais informações consegue descobrir. Depois, procure meios de reforçar a segurança da rede e anular o ataque.

Por ser uma ferramenta popular, ele está disponível na maioria as distribuições. Algumas, como o Knoppix (a partir da versão 3.7), já o trazem instalado por padrão.

Nas distribuições derivadas do Debian, você pode instalá-lo via apt-get:

# apt-get install kismet

Antes de ser usar, é preciso configurar o arquivo “/etc/kismet/kismet.conf“, especificando a placa wireless e o driver usado por ela, substituindo a linha:

source=none,none,addme

Por algo como:

source=madwifi_ag,ath0,atheros

… onde o “madwifi_ag” é o driver usado pela placa (você pode verificar o chipset da placa instada usando o comando lspci). Na documentação do Kismet, o driver é chamado de “capture source”, pois é a partir dele que o Kismet obtém os pacotes recebidos.

o “ath0″ é a interface (que você vê através do comando ifconfig) e o “atheros” é um apelido para a placa (que você escolhe), com o qual ela será identificada dentro da tela de varredura.

Isso é necessário, pois o Kismet precisa de acesso de baixo nível ao hardware, mas, por outro lado, faz com que a compatibilidade esteja longe de ser perfeita. Diversas placas não funcionam em conjunto com o Kismet, com destaque para as placas que não possuem drivers nativos e precisam ser configurados através do ndiswrapper. Se você pretende usar o Kismet, o ideal é pesquisar antes de comprar a placa.

Naturalmente, para que possa ser usada no Kismet, a placa precisa ter sido detectada pelo sistema, com a ativação dos módulos de Kernel necessários. Por isso, prefira sempre usar uma distribuição recente, que traga um conjunto atualizado de drivers. O Kurumin e o Kanotix estão entre os melhores neste caso, pois trazem muitos drivers que não vem pré instalados em muitas distribuições.

Você pode ver uma lista detalhada dos drivers de placas wireless disponíveis e como instalar manualmente cada um deles no meu livro Linux Ferramentas Técnicas.

Veja uma pequena lista dos drivers e placas suportados no Kismet 2006-04-R1:

acx100: O chipset ACX100 foi utilizado em placas de diversos fabricantes, entre eles a DLink, sendo depois substituído pelo ACX111. O ACX100 original é bem suportado pelo Kismet, o problema é que ele trabalha a 11 megabits, de forma que não é possível testar redes 802.11g.

admtek: O ADM8211 é um chipset de baixo custo, encontrado em muitas placas baratas. Ele é suportado no Kismet, mas possui alguns problemas. O principal é que ele envia pacotes de broadcast quando em modo monitor, fazendo com que sua varredura seja detectável em toda a área de alcance do sinal. Qualquer administrador esperto vai perceber que você está capturando pacotes.

bcm43xx: As placas com chipset Broadcom podiam até recentemente ser usadas apenas no ndiswrapper. Recentemente, surgiu um driver nativo (http://bcm43xx.berlios.de) que passou a ser suportado no Kismet. O driver vem incluído por padrão a partir do Kernel 2.6.17, mas a compatibilidade no Kismet ainda está em estágio experimental.

ipw2100, ipw2200, ipw2915 e ipw3945: Estes são os drivers para as placas Intel, encontrados nos notebooks Intel Centrino. O Kismet suporta toda a turma, mas você precisa indicar o driver correto para a sua placa, entre os quatro.
O ipw2100 é o chipset mais antigo, que opera a 11 megabits; o ipw2200 é a segunda versão, que suporta tanto o 802.11b, quanto o 802.11g; o ipw2915 é quase idêntico ao ipw2200, mas suporta também o 802.11a, enquanto o ipw3945 é uma versão atualizada, que é encontrada nos notebooks com processadores Core Duo.

madwifi_a, madwifi_b, madwifi_g, madwifi_ab e madwifi_ag: Estes drivers representam diferentes modos de operação suportados pelo driver madwifi (http://sourceforge.net/projects/madwifi/), usado nas placas com chipset Atheros. Suportam tanto o driver madwifi antigo, quanto o madwifi-ng.
Usando os drivers madwifi_a, madwifi_b ou madwifi_g, a placa captura pacotes apenas dentro do padrão selecionado (o madwifi_a captura apenas pacotes de redes 802.11a, por exemplo). O madwifi_g é o mais usado, pois captura simultaneamente os pacotes de redes 802.11b e 802.11g. O madwifi_ag, por sua vez, chaveia entre os modos “a” e “g”, permitido capturar pacotes de redes que operam em qualquer um dos três padrões, apesar de em um ritmo mais lento, devido ao chaveamento.

rt2400 e rt2500: Estes dois drivers dão suporte às placas com chipset Ralink, outro exemplo de chipset de baixo custo que está se tornando bastante comum. Apesar de não serem exatamente “placas de alta qualidade”, as Ralink possuem um bom suporte no Linux, graças em parte aos esforços do próprio fabricante, que abriu as especificações e fornece placas de teste para os desenvolvedores. Isto contrasta com a atitude hostil de alguns fabricantes, como a Broadcom e a Texas (que fabrica os chipsets ACX).

rt8180: Este é o driver que oferece suporte às placas Realtek 8180. Muita gente usa estas placas em conjunto com o ndiswrapper, mas elas possuem um driver nativo, disponível no http://rtl8180-sa2400.sourceforge.net/. Naturalmente, o Kismet só funciona caso seja usado o driver nativo.

prism54g: Este driver dá suporte às placas com o chipset Prism54, encontradas tanto em versão PCI ou PCMCIA, quanto em versão USB. Estas placas são caras e por isso relativamente incomuns no Brasil, mas são muito procuradas entre os grupos que fazem wardriving, pois as placas PCMCIA são geralmente de boa qualidade e quase sempre possuem conectores para antenas externas, um pré-requisito para usar uma antena de alto ganho e assim conseguir detectar redes distantes.

orinoco: Os drivers para as placas com chipset Orinoco (como as antigas Orinoco Gold e Orinoco Silver) precisam de um conjunto de patches para funcionar em conjunto com o Kismet, por isso acabam não sendo placas recomendáveis. Você pode ver detalhes sobre a instalação dos patches no http://www.kismetwireless.net/HOWTO-26_Orinoco_Rfmon.txt.

Depois de definir o driver, a interface e o nome no “/etc/kismet/kismet.conf“, você pode abrir o Kismet chamando-o como root:

# kismet

Inicialmente, o Kismet mostra as redes sem uma ordem definida, atualizando a lista conforme vai descobrindo novas informações. Pressione a tecla “s” para abrir o menu de organização, onde você pode definir a forma como a lista é organizada, de acordo com a qualidade do canal, volume de dados capturados, nome, etc. Uma opção comum (dentro do menu sort) é a “c”, que organiza a lista baseado no canal usado por cada rede.

Por padrão, o Kismet chaveia entre todos os canais, tentando detectar todas as redes disponíveis. Neste modo, ele captura apenas uma pequena parte do tráfego de cada rede, assim como você só assiste parte de cada programa ao ficar zapiando entre vários canais da TV.

Selecione a rede que quer testar usando as setas e pressione “shift + L” (L maiúsculo) para travá-lo no canal da rede especificada. A partir daí, ele passa a concentrar a atenção em uma única rede, capturando todos os pacotes transmitidos:

Você pode também ver informações detalhadas sobre cada rede selecionando-a na lista e pressionando enter. Pressione “q” para sair do menu de detalhes e voltar à tela principal.

Outro recurso interessante é que o Kismet avisa sobre “clientes suspeitos”, micros que enviam pacotes de conexão para os pontos de acesso, mas nunca se conectam a nenhuma rede, indício de que provavelmente são pessoas fazendo wardriving ou tentando invadir redes. Este é o comportamento de programas como o Netstumbler (do Windows). Micros rodando o Kismet não disparam este alerta, pois fazem o scan de forma passiva:

ALERT: Suspicious client 00:12:F0:99:71:D1 – probing networks but never participating.

O Kismet gera um dump contendo todos os pacotes capturados, que vai por padrão para a pasta “/var/log/kismet/“. A idéia é que você possa examinar o tráfego capturado posteriormente usando o Wireshark (Ethereal), que permite abrir o arquivo e examinar os dados capturados. O problema é que, ao sniffar uma rede movimentada, o dump pode se transformar rapidamente em um arquivo com vários GB, exigindo que você reserve bastante espaço no HD.

Um dos maiores perigos em uma rede wireless é que qualquer pessoa pode capturar o tráfego da sua rede e depois examiná-lo calmamente em busca de senhas e outros dados confidenciais transmitidos de forma não encriptada. O uso do WEP ou outro sistema de encriptação minimiza este risco, pois antes de chegar aos dados, é necessário quebrar a encriptação.

Evite usar chaves WEP de 64 bits, pois ele pode ser quebrado via força bruta caso seja possível capturar uma quantidade razoável de pacotes da rede. As chaves de 128 bits são um pouco mais seguras, embora também estejam longe de ser inquebráveis. Em termos se segurança, o WPA está bem à frente, mas usá-lo traz problemas de compatibilidade com algumas placas e drivers.

Sempre que possível, use o SSH, SSL ou outro sistema de encriptação na hora de acessar outras máquinas da rede ou baixar seus e-mails. No capítulo sobre acesso remoto, veremos como é possível criar um túnel seguro entre seu micro e o gateway da rede (usando o SSH), permitindo assim encriptar todo o tráfego.

Quebrando Chaves WEP

Para você entender a importância de usar o SSH o outros protocolos seguros ao usar uma rede wireless, vou falar um pouco mais sobre como quebrar chaves de encriptação, para que você possa entender os ataques usados pelos que estão do outro lado.

Alguns pontos de acesso utilizam versões vulneráveis do WEP, que são muito rápidas de quebrar (em muitos casos você pode corrigir através de uma atualização de firmware) mas, mesmo as versões “não vulneráveis” do WEP podem ser quebradas via força bruta, sempre que seja possível capturar um volume suficiente de tráfego da rede.

Você pode simular uma invasão na sua própria rede, para verificar qual seria o volume de trabalho necessário para invadi-la. Para isso, você vai precisar de pelo menos dois micros ou notebooks. Um deles vai ser usado como um cliente de rede normal e pode usar qualquer placa de rede, enquanto o segundo (que usaremos para simular o ataque) precisa ter uma placa compatível com o Kismet.

Configure o seu ponto de acesso ativando o WEP e desativando o Broadcast do SSID. Ou seja, faça uma configuração relativamente segura, mas depois faça de conta que esqueceu tudo .

Comece abrindo o Kismet no notebook “invasor”. Deixe que ele detecte as redes próximas, pressione “s” para ajustar a ordem dos nomes na lista, selecione sua rede e pressione “shift + L” para que ele trave a varredura na sua rede e deixe de bisbilhotar nas redes dos vizinhos.

Inicialmente, sua rede será detectada como “no ssid”, já que o broadcast do SSID foi desativado no ponto de acesso. Mas, assim que qualquer micro se conecta ao ponto de acesso, o Kismet descobre o SSID correto. Pressione “i” para ver os detalhes da rede e anote o endereço MAC do ponto de acesso (BSSID), que precisaremos para iniciar o passo seguinte.

Agora que já sabemos o SSID e o MAC do ponto de acesso, falta quebrar o WEP. Para isso precisaremos do Aircrack, uma suíte de aplicativos para verificação de redes wireless, que pode ser encontrada no http://freshmeat.net/projects/aircrack/. Nos derivados do Debian, ele pode ser instalado via apt-get:

# apt-get install aircrack

Outra opção é baixar o Back Track, um Live-CD baseado no Slax, que já vem com o Aircrack, Kismet e outras ferramentas úteis pré-instaladas.

O primeiro passo é capturar pacotes da rede usando o airodump (que faz parte da suíte aircrack). A sintaxe do comando é “airodump interface arquivo-de-log mac-do-ponto-de-acesso”, como em:

# airodump ath0 logrede 00:50:50:81:41:56

Você pode também indicar um canal (neste caso, ele escuta todas as redes que estejam transmitindo no canal indicado), como em:

# airodump ath0 logrede 14

Isto gerará o arquivo “logrede.cap”, que contém um dump de todos os pacotes capturados. Neste ponto você precisa esperar algum tempo até conseguir um volume razoável de pacotes. Para acelerar isso, faca com que o micro isca baixe alguns arquivos grandes a partir de outro micro da rede.

Abra outro terminal e use o aircrack para tentar quebrar a chave de encriptação. Você pode fazer isso sem interromper a captura do airodump, daí a idéia de usar dois terminais separados.

Ao usar o aircrack, é preciso especificar o comprimento da chave WEP (64 ou 128 bits) e o arquivo gerado pelo airodump, como em:

# aircrack-n 64 logrede.cap
ou:
# aircrack -n 128 logrede.cap

Caso o arquivo contenha pacotes destinados a mais de um ponto de acesso, ele pergunta qual verificar. No caso, indique sua rede.

O aircrack usa um ataque de força bruta para tentar descobrir a chave de encriptação da rede. A base do ataque são os IV’s (vetores de inicialização), a parte de 24 bits da chave de encriptação, que é trocada periodicamente. O volume de IV’s gerados varia de acordo com a rede (por isso existem redes mais vulneráveis que outras) mas, em teoria, é possível quebrar a encriptação de uma rede de 128 bits caso você consiga capturar de 500 mil a um milhão de IV’s, enquanto uma chave de 64 bits pode ser quebrada com pouco mais de 200 mil. Caso seja usada uma chave fácil de adivinhar, os números são drasticamente reduzidos, permitindo em muitos casos que a chave seja quebrada com a captura de alguns poucos milhares de IV’s.

Como todo processo de força bruta, o tempo necessário é aleatório. O aircrack pode descobrir a chave correta tanto logo no início da captura, quanto só depois de capturar mais de um milhão de IV’s. Por isso é interessante deixar o terminal de captura do airodump aberto e ir executando o aircrack periodicamente, até que ele descubra a chave. Quanto maior o volume de dados capturados, maior a possibilidade dele descobrir a chave.

Uma forma de aumentar a eficiência do ataque, ou seja, aumentar a chance de descobrir a chave, usando o mesmo número de IV’s, é aumentar o “fudge factor”, o que faz com que o aircrack teste um número maior de combinações. Isso, naturalmente, aumenta proporcionalmente o tempo necessário para o teste.

O default do aircrack é um fudge factor 2. Você pode alterar o valor usando a opção “-f”, como em:

# aircrack -f 4 -n 128 logrede.cap

É comum começar fazendo um teste com o valor default, depois com fudge 4 (como no exemplo) e a partir daí ir dobrando até descobrir a chave, ou a demora se tornar inviável.

Com um grande volume de IV’s, uma chave WEP de 64 bits é um alvo fácil. Neste caso a quebra demorou apenas 21 segundos:

Como é necessário capturar um grande volume de dados e muitas redes são usadas apenas para acessar a Internet e outras tarefas leves, capturar o volume de pacotes necessário poderia demorar dias.

Um invasor com um nível mediano de conhecimento, provavelmente não se contentaria em esperar tanto tempo. Ao invés disso, ele poderia usar um ataque de flood para induzir tráfego na sua rede, de forma a acelerar o processo, transformando os muitos dias em apenas alguns minutos.

Um exemplo de ferramenta usada para este tipo de ataque é o aireplay, mais um integrante da equipe do aircrack. O comando abaixo lança um “chopchop atack” (o tipo de ataque mais eficiente para quebrar chaves WEP) contra o ponto de acesso referente ao endereço MAC especificado, através da interface ath0:

# aireplay -b 00:50:50:81:81:01 -x 512 ath0 -4

Neste ataque, o aireplay captura um weak packet emitido por algum dos outros micros conectados ao ponto de acesso e o repete indefinidamente, obrigando o ponto de acesso a responder e assim aumentar rapidamente a contagem de IV’s, permitindo quebrar a chave WEP muito mais rapidamente. Este é o tipo de ataque mais efetivo, pois derruba a última grande barreira contra a quebra do WEP, que era justamente a demora em capturar um grande volume de pacotes.

O “-x 512″ especifica o número de pacotes que serão enviados por segundo. Aumentar o número permite quebrar a chave mais rapidamente, mas, por outro lado, vai reduzir o desempenho da rede, o que pode levar o administrador a perceber o ataque (a menos que ele seja feito em um momento de ociosidade da rede).

Como pode ver, o WEP dificulta o acesso à rede, mas quebrá-lo é apenas questão de tempo. Para melhorar a segurança da sua rede, o ideal é combinar várias camadas de segurança e monitorar os acessos, fazendo com que o tempo e trabalho necessário para invadir a rede seja maior (o que vai afastar os curiosos e invasores casuais) e vai lhe dar tempo para detectar e investigar casos mais graves.

Ao usar o WEP, o ideal é trocar a chave de encriptação regularmente, de forma que, mesmo que alguém consiga descobrir a chave, não consiga usar a rede por muito tempo antes que ela seja trocada. Se possível, utilize o WPA, que, apesar dos problemas de compatibilidade, é muito mais seguro.

O WPA também usa 128 bits de encriptação. A principal diferença é que ele usa vetores de inicialização de 48 bits (o WEP usa vetores de 24 bits), juntamente com um conjunto de proteções contra possíveis ataques. É possível descobrir a chave de encriptação em uma rede WPA-PSK via força bruta, depois de capturar uma pequena quantidade de dados da rede, mas isso só é viável para chaves com poucos caracteres, ou que são baseadas em palavras encontradas no dicionário.

Por exemplo, uma chave como “supercampeao” pode ser descoberta rapidamente, enquanto outra baseada em caracteres aleatórios, como “ErGCDtv8i9S3″ demoraria muito tempo para ser quebrada, fazendo com que o invasor desistisse. A dica geral ao usar WPA é escolher uma senha de pelo menos 12 caracteres, misturando letras, números, e caracteres maiúsculos e minúsculos.

Caso a rede seja usada apenas dentro de um pequeno espaço, como uma única sala, apartamento ou escritório, você pode também reduzir a potência do transmissor no ponto de acesso, o que acaba sendo uma medida muito efetiva, pois realmente impede que o sinal da rede seja captado de longe.

Procure pela opção “Antenna transmit power” ou similar (dentro da configuração do ponto de acesso) e veja qual é o menor valor com que a rede funciona corretamente dentro da área necessária:

Outra dica que dificulta, é habilitar a restrição de acesso à rede com base no endereço MAC, geralmente disponível através da opção “Access Control” do ponto de acesso. Ao ativar esta opção, você cria uma lista com os endereços MAC das placas autorizadas e o ponto de acesso restringe o acesso de qualquer outra.

Programas como o airodump e o próprio Kismet permitem descobrir o endereço MAC dos micros que estão acessando determinada rede muito facilmente, e o endereço MAC da placa de rede pode ser forjado (no Linux, por exemplo, você pode falsear usando o comando “ifconfig wlan0 hw ether 00:11:D8:76:59:2E”, onde você substitui o “wlan0″ pela interface e o “00:11:D8:76:59:2E” pelo endereço MAC desejado). A questão é que, ao forjar o endereço, o invasor vai derrubar o micro com a placa que foi clonada, de forma que você perceba que algo está errado.

O próximo passo seria isolar sua rede wireless do restante da rede, fazendo com que o invasor possa acessar a Internet, mas não tenha como acessar compartilhamentos e outros recursos da rede.

O mais simples neste caso é instalar uma placa de rede adicional no servidor da rede (ou em qualquer outro micro na ausência dele), onde é conectado o ponto de acesso. Compartilhe a conexão com a placa do AP, mas utilize duas faixas de IP’s separados, com um firewall ativo, configurado para bloquear tentativas de conexão provenientes dos micros dentro da rede wireless.

Usando o HFNetChk

Embora muitos torçam o nariz para os Service Packs e outras atualizações, que por vezes causam problemas diversos ao serem instalados, no mundo Windows as atualizações de segurança para as máquinas Windows da rede são um remédio inevitável. Uma instalação limpa do Windows XP, sem atualizações, conectada à Internet é infectada em questão de minutos, primeiro por worms diversos e depois por crackers.

Mesmo dentro da rede local, estas máquinas sem atualizações são um risco, pois uma máquina infectada indiretamente (infectada ao acessar uma página maliciosa através do IE, ou ao executar um arquivo recebido por e-mail, por exemplo) pode infectar rapidamente todas as demais, fazendo com que você perca o dia atualizando os antivírus e reinstalando o sistema.

Apesar disso, manter todas as máquinas da rede atualizadas pode não ser uma tarefa simples. O Windows não dispõe de uma interface robusta de linha de comando, ou outra ferramenta que permita automatizar tarefas de forma eficiente. Devido a isso, mesmo os administradores mais experientes acabam perdendo suas tardes atualizando cada máquina individualmente. Outro problema que surge com o tempo é saber quais atualizações cada máquina já recebeu, a fim de não precisar ficar repetindo o trabalho.

Uma ferramenta que pode ajudar no segundo problema é o HFNetChk. Para baixa-lo, faça uma busca por “HFNetChk” no http://download.microsoft.com/. Você baixará o arquivo “mbsasetup.msi”.

O mais interessante nesta ferramenta é que ele não se limita a escanear apenas a sua máquina local, ele pode escanear toda a rede local, dando o status de atualização de todas as máquinas Windows na rede. Este report remoto funciona apenas em máquinas que não estão protegidas por firewall. O report gerado por ele inclui também informações sobre os compartilhamentos e serviços ativos em cada máquina, o que o torna útil também como uma ferramenta preventiva.

A função dele é apenas avisar das atualizações que precisam ser aplicadas em cada máquina, as atualizações propriamente ditas precisam ser aplicadas manualmente por você. Para funcionar, ele precisa que você tenha privilégios de administrador, tanto localmente, quanto nas outras máquinas da rede que forem ser escaneadas.

Note que na terceira coluna de cada report consta um link para o artigo correspondente dentro da Knowledge Base da Microsoft, que permite ver mais detalhes sobre o problema.

Fonte: Livro Redes e Servidores Linux – C. E. Morimoto

Usando o VMware Server

Em versões anteriores, o VMware era um produto caro. Com a concorrência de outros produtos, a VMware passou a disponibilizar gratuitamente o VMware Player, seguido do VMware Server. O VMware Server é tão completo e flexível que atende não apenas a quem quer usá-lo em um servidor, mas também aos usuários normais, que querem rodar diversos sistemas operacionais no mesmo micro. Se você já é usuário do VMware Workstion, ou do VMware Player, pode muito bem migrar para ele.

Com o lançamento de processadores cada vez mais rápidos e o uso de volumes cada vez maiores de memória RAM, passou a fazer cada vez mais sentido agrupar diversos servidores em uma única máquina, utilizando algum sistema de virtualização.

A virtualização é obtida inserindo uma camada intermediária entre o sistema rodando dentro da máquina virtual e o hardware da máquina, simulando uma máquina completa. O software de virtualização fica então responsável por gerenciar todos os recursos do hardware, incluindo interrupções e endereços de memória, de forma que os sistemas dentro das máquinas virtuais possam trabalhar como se cada um tivesse uma máquina inteira reservada para si.

O sistema principal neste caso passa a ser chamado de host (hospedeiro) e os sistemas que estão rodando dentro da máquina virtual são chamados de “guests” (convidados). Cada um deles acha que tem um PC completo para si, enquanto na verdade está rodando dentro de uma “matrix”, na máquina virtual:

Um sistema de virtualização permite dividir um único PC em diversas máquinas virtuais independentes, sendo que cada uma pode rodar um sistema operacional diferente. As máquinas virtuais compartilham os recursos da máquina real, dentro dos limites de uso de memória e de espaço em disco estabelecidos por você.

Em versões anteriores, o VMware era um produto caro. A versão destinada a estações de trabalho (o VMware Workstation) custava US$ 79 e o VMware GSX (a versão para servidores) custava algumas centenas de dólares.

Com a concorrência de outros produtos, a VMware passou a disponibilizar gratuitamente o VMware Player, uma versão reduzida do VMware Workstation. Em 2006 foi disponibilizado o VMware Server, uma versão surpreendentemente completa, que permite não apenas executar as máquinas virtuais, mas também criá-las, configurá-las e fazer toda a administração, sem limitações.

O VMware Server é tão completo e flexível que atende não apenas a quem quer usá-lo em um servidor, mas também aos usuários normais, que querem rodar diversos sistemas operacionais no mesmo micro. Se você já é usuário do VMware Workstion, ou do VMware Player, pode muito bem migrar para ele.

Você pode encontrar as dicas gerais de como instalá-lo e criar as máquinas virtuais no meu tutorial anterior: http://www.guiadohardware.net/tutoriais/vmware-server/

A dica de hoje é sobre o VMware Server 2.0, que já está na versão Beta 2. Embora ainda esteja em desenvolvimento, ele já é bastante estável.

A principal novidade é uma nova interface de administração, batizada de VMware Infrastructure (VI). Ela permite que todas as funções das máquinas virtuais, incluindo a configuração das máquinas virtuais e o acesso ao console sejam acessadas através do próprio navegador, combinando as funções do VMware Mui e do VMware Server Console, usados nas versões anteriores:

A interface pode ser tanto acessada via HTTP quanto via HTTPS, usando o próprio navegador. Se você está usando o VMware Server em sua máquina local, acesse através do “http://127.0.0.1“, caso contrário use o HTTPS para ativar o uso da encriptação, como em “https://gdhn.com.br“. Assim como na versão 1.4, o login pode ser feito usando qualquer conta no servidor que tenha acesso às máquinas virtuais. Para ter acesso irrestrito, use o root:

Para acessar o console usando o navegador é necessário instalar um plugin, que é oferecido da primeira vez que você tenta acessá-lo. Diferente dos antigos plug-ins em Active-X, que foram tão usados na época do IE 6, o plug-in do VMware está disponível também na forma de uma extensão para o Firefox, que pode ser usada também em clientes Linux.

O plug-in é na verdade uma versão completa do Server Console, modificada de forma a facilitar a instalação. Clicando sobre a janela dentro da interface de gerenciamento, o console é aberto em uma nova janela. Como ele continua utilizando a mesma interface de acesso a vídeo do VMware Server Console, o desempenho é similar:

O acesso via navegador pode não fazer muito sentido se você usa o VMware Server localmente, mas é uma grande melhoria para quem o instala em um servidor central e acessa as máquinas virtuais remotamente. Em vez de precisar instalar o VMware Server Console em cada máquina de onde for acessar o servidor, você precisa apenas instalar o plug-in.

Como de praxe, você pode utilizar diversas máquinas virtuais simultaneamente, limitado apenas aos recursos da máquina e ao limite “físico” de 64 VMs simultâneas do VMware Server.

Se você está utilizando o VMware Server 1.4, pode remover a versão antiga usando o comado “vmware-uninstall.pl”, que se encarrega de parar o serviço e remover os componentes:

# vmware-uninstall.pl

Os arquivos do VMware Server 2.0 Beta estão disponíveis no: http://www.vmware.com/beta/server/. Quando a versão final estiver disponível, a página será movida para o http://www.vmware.com/download/server/. Na página estão disponíveis tanto a versão para sistemas de 32 bits quanto a de 64 bits:

Em vez de três pacotes separados, temos agora apenas dois componentes. O pacote “VMware-server”, que é o componente principal e o “VMware-vix”, que contém a engine da interface de administração.

Estão disponíveis também versões para o Windows quanto para Linux, atendendo a usuários de ambos os sistemas. A versão Windows é instalada da forma tradicional, no estilo “next, next, finish”, mas a versão Linux exige alguns passos adicionais, já que é desenvolvida de forma a ser instalável em qualquer distribuição e para permitir o uso em servidores sem interface gráfica instalada, daí o instalador em modo texto e o processo de instalação relativamente manual.

Baixe os dois arquivos para a mesma pasta e descompacte-os, como em:

# tar -zxvf VMware-server-e.x.p-84186.i386.tar.gz
# tar -zxvf VMware-vix-e.x.p-84186.i386.tar.gz

Acesse a pasta “vmware-server-distrib/” e rode o script “vmware-install.pl”. Desde que você tenha descompactado os dois arquivos no mesmo diretório, o script de encarregará de instalar também o VMware-vix automaticamente.

# vmware-server-distrib/
# ./vmware-install.pl

Uma das preocupações dos desenvolvedores foi ampliar o volume de módulos pré-compilados incluídos no pacotes principal, que correspondem à maior parte dos 400 MB do download. Mesmo assim, ainda é necessário ter os headers do Kernel e os compiladores para conseguir instalá-lo nas distribuições não atendidas pelos módulos pré-compilados. Além do vmmon, o instalador agora gera dois novos módulos, o vmci e o vsock.

Perto do final da instalação, o instalador pergunta sobre as portas que serão usadas para o acesso web, via HTTP e HTTPS. Se você está instalando o VMware Server em sua máquina de trabalho, pode simplesmente usar as portas padrão (80 e 443) para facilitar o acesso, mas se você o está instalando em um servidor dedicado, que já possui um servidor web ativo, é importante alterar as portas usadas, caso contrário o servidor web usado pelo VMware irá conflitar com o servidor web já existente, com resultados variados:

Please specify a port for standard http connections to use [80]: 8080
Please specify a port for secure http (https) connections to use [443]: 40443

Como de praxe, ao especificar portas diferentes do padrão, você deve incluir a porta no endereço de acesso ao servidor, como em “https://gdhn.com.br:404433“

Uma observação é que as versões beta do VMware Server 2.0 vem com as extensões de debug ativadas. Elas permitem gerar relatórios detalhados sobre o status do software, que podem ser incluídos em bug reports, mas reduzem substancialmente o desempenho das máquinas virtuais (a perda chega a mais de 50% em diversas operações).

O debug pode ser desativado dentro das configurações de cada máquina virtual (você precisa desativá-lo uma por uma), desmarcando a opção “Record runtime information”, dentro da seção “Summay > Commands > Configure VM > Advanced”:

Os betas possuem também um sistema de expiração, que bloqueia o uso das versões antigas conforme atualizações vão sendo disponibilizadas, de forma a evitar que os usuários continuem a utilizar versões beta antigas, cujos problemas já foram solucionados.

Concluindo, temos a questão da compatibilidade entre as máquinas virtuais criadas em outras versões do VMware. Por ser a versão mais recente, o VMware Server é compatível com máquinas virtuais criadas em qualquer versão anterior. Entretanto, elas não se beneficiam das melhorias introduzidas na nova versão, como o suporte a mais memória RAM e suporte a dispositivos USB 2.0. Para tirar proveito das melhorias, você tem a opção de atualizar as máquinas virtuais, usando a opção “Upgrade Virtual Machine”, disponível na aba “Summary”:

Note que ao fazer isso a máquina virtual deixa de ser compatível com as versões anteriores (o upgrade é de mão única), mas nada impede que você mantenha uma cópia de backup da máquina virtual original, antes de atualização.

Ao atualizar uma máquina virtual com o Windows, use também a opção “Upgrade VMware Tools”. Os novos drivers virtuais oferecem pequenos ganhos de desempenho em diversas áreas, além de serem necessários para que o sistema guest tenha acesso aos novos recursos.

Fonte: www.guiadohardware.net

O VMware Server

Usando o VMware Server, você pode transformar um único servidor dedicado em vários servidores virtuais, cada um se comportando como se fosse uma máquina separada. Além da possibilidade de combinar os diversos servidores da sua rede local em uma única máquina, ele permite dividir um único servidor dedicado em diversos servidores virtuais, que podem desempenhar funções secundárias ou até mesmo serem sublocados. Você pode também utilizá-lo no seu desktop, pois ele substitui o VMware Player e o VMware Workstation com vantagens. O melhor de tudo é que ele é gratuito.

Quase tudo pode ser simulado via software. É possível até mesmo simular um computador de arquitetura diferente, para que os softwares escritos pare ele rodem da mesma forma que rodam dentro do seu sistema nativo.

Um dos exemplos mais conhecidos são os emuladores de videogames antigos, que permitem rodar jogos de Atari, Nintendo 8 bits, Mega-Drive, Super-Nes, Playstation e outros.

Assim como é possível emular um videogame para rodar os jogos escritos para ele, é possível simular um PC completo dentro de uma máquina virtual e até mesmo executar diversos sistemas operacionais simultaneamente.

O sistema principal neste caso passa a ser chamado de host (hospedeiro) e o sistema operacional que está rodando dentro da máquina virtual é chamado de “guest” (convidado). Ele acha que tem um PC completo para si, enquanto na verdade está rodando dentro de uma “matrix”, na máquina virtual.

Naturalmente, este trabalho de simular um PC completo e ainda por cima com um bom desempenho não é simples, veja o caso dos emuladores de videogame, que, de uma forma geral, precisam de um PC muito mais poderoso do que o sistema original. É preciso um Pentium 200 para emular um Super Nes (que usa um processador de 3.5 MHz e 128 KB de RAM) com qualidade.

Existem atualmente três softwares que se destacam nesta categoria, o VMware, Qemu e o Xen, que trabalham de forma ligeiramente diferente, mas com grandes diferenças práticas.

O VMware usa um conceito de virtualização. Ele tenta sempre que possível converter os comandos usados pelo sistema dentro da máquina virtual em comandos que o sistema host entenda e execute diretamente. Isso se aplica quando é necessário transmitir dados através da placa de rede, tocar sons na placa de som, ou executar instruções do processador. O VMware interpreta e converte instruções o mínimo possível, o que faz com que o sistema dentro da máquina virtual rode com um desempenho muito similar ao desempenho real da máquina.

O Qemu, por sua vez, é um emulador. Ele tenta processar todas as instruções, o que acaba demorando mais tempo e fazendo com que a performance seja menor. Em geral, o VMware (nas versões recentes) consegue fazer com que o sistema guest rode com de 70 a 90% do desempenho que teria se estivesse rodando diretamente, enquanto que o Qemu obtém de 5 a 10%. O Qemu possui um módulo adicional, o Kqemu, que faz com que ele passe a funcionar de forma mais similar ao VMware, virtualizando as instruções básicas do processador, ao invés de emular tudo. O Kqemu melhora consideravelmente o desempenho do Qemu, mas ainda assim o deixa bem atrás do VMware em questão de desempenho. Inicialmente, o Qemu era apenas um projeto menor, mas recentemente ele passou a ganhar mais destaque, com o desenvolvimento do KVM, um sistema de virtualização incluído diretamente no Kernel, disponível a partir do 2.6.20, que trabalha em conjunto com ele.

Temos ainda o Xen, que embora relativamente desconhecido entre os usuários de desktops, já é bastante utilizado nos servidores. Ele utiliza uma idéia diferente, a paravirtualização, que consiste em dividir de forma transparente os recursos do hardware, permitindo que o sistema guest rode com uma redução de performance muito pequena (menos de 5%, na maioria dos casos). O maior problema é que para rodar dentro do Xen é necessário que o sistema guest seja modificado. Não é possível rodar qualquer sistema diretamente, como no caso do VMware e do Qemu. Isto não é um grande problema no caso das distribuições Linux, mas é no caso do Windows e outros sistemas de código fechado.

O Xen é muito mais complicado de configurar que o VMware, o que limita um pouco seu público-alvo, mesmo quando falamos em servidores. Mesmo assim, é possível que o Xen evolua em termos de facilidade de uso e, graças ao bom desempenho, comece a disputar diretamente com o VMware. A página do Xen é a http://www.xensource.com/.

Por enquanto, o vamos estudar sobre o uso do VMware Server, que é atualmente a solução que melhor combina desempenho e facilidade de uso.

O VMware Player, VMware Workstation e o Qemu são os mais usados nos desktops, onde o uso mais comum é usar uma máquina virtual para rodar o Windows dentro do Linux, ou vice-versa. A principal utilidade da máquina virtual é rodar programas gráficos, de forma que você fica com a janela aberta continuamente.

Entretanto, num servidor dedicado as coisas são um pouco diferentes. Ao invés de você ficar o tempo todo na frente da máquina, como faria num desktop, espera-se que o servidor funcione continuamente, sem precisar de muita manutenção. Embora (com um pouco de malabarismo), seja até possível instalar o VMware Player no servidor e deixá-lo ativo, rodando outro sistema numa máquina virtual, ele não é a solução mais prática para a tarefa, sem falar que não é possível usá-lo em servidores sem o ambiente gráfico instalado.

Entendendo o VMware Server

Em um PC desktop, o uso mais comum de um software de virtualização é rodar um segundo sistema operacional, de forma a fazer testes ou rodar algum software específico. Muita gente usa o VMware Player ou o Virtual Box para rodar uma cópia do Windows dentro do Linux ou vice-versa. A principal utilidade da máquina virtual é rodar programas gráficos, de forma que você fica com a janela aberta continuamente:

Entretanto, em um servidor dedicado as coisas são um pouco diferentes. Ao invés de você ficar o tempo todo na frente da máquina, como faria num desktop, espera-se que o servidor funcione continuamente, sem precisar de muita manutenção. Embora (com um pouco de malabarismo), seja até possível instalar o VMware Player no servidor e deixá-lo ativo, rodando outro sistema numa máquina virtual, ele não é a solução mais prática para a tarefa, sem falar que não é possível usá-lo em servidores sem o ambiente gráfico instalado.

Chegamos então ao VMware Server, que vamos ver em detalhes ao longo deste tutorial. Ele é uma versão adaptada e otimizada para uso em servidores dedicados, sem monitor nem ambiente gráfico. A principal diferença é que o VMware Server roda remotamente, e é acessado através de uma interface de administração via web (chamada de VMware Management Interface, ou MUI), onde você pode ativar, desativar e monitorar o status das máquinas virtuais remotamente. A idéia é que cada máquina virtual seja configurada como um novo servidor dedicado, que você administra usando o SSH ou outro software de acesso remoto.

Usando o VMware Server, você pode transformar um único servidor dedicado em vários servidores virtuais, cada um se comportando como se fosse uma máquina separada. Em geral, ao locar um servidor dedicado você recebe uma faixa de IPs com máscara 255.255.255.248, com 5 endereços IPs utilizáveis. Isso significa que você pode usar um endereço para o servidor principal e ainda ficar com mais 4 endereços para as máquinas virtuais (sendo que uma delas pode acumular a função de servidor DNS secundário).

Para emergências, onde você precise ver as mensagens de inicialização ou quando precisar alterar as configurações da máquina virtual (quantidade de memória RAM reservada, CD-ROM ou imagem ISO de boot, etc.) você pode usar o VMware Server Console, uma interface de administração, através da qual você pode se conectar remotamente a qualquer uma das máquinas virtuais disponíveis, obtendo a imagem que seria enviada para o monitor. Ele pode também ser usado para criar novas VMs e instalar ou reinstalar o sistema:

Como um servidor dedicado pode custar menos de US$ 100 por mês, dependendo do datacenter escolhido, existe até mesmo uma boa possibilidade de ganhar algum dinheiro alugando os servidores virtuais e, ainda assim (embora com menos recursos de hardware disponíveis), continuar dispondo do sistema principal.

Até junho de 2006, a VMware oferecia o VMware GSX Server, que era um produto caro, assim como o VMware Workstation. Ele vinha perdendo terreno devido à concorrência do Xen, do Virtuozzo e do Virtual PC (da Microsoft), de forma que a VMware decidiu disponibilizá-lo gratuitamente, como uma solução “entry-level” para a virtualização de servidores. Nasceu assim o VMware Server. O resultado é que temos disponível uma solução de virtualização para servidores muito prática, ao custo de um download.

As limitações do VMware Server são o suporte a até 3.6 GB de memória RAM (na versão 2.0 o limite foi ampliado para 8 GB, desde que você o utilize sobre um sistema operacional de 64 bits) e o suporte a um máximo de 64 máquinas virtuais ativas simultaneamente. Ou seja, embora existam, as limitações não afetam a grande maioria dos usuários.

A VMware ganha dinheiro vendendo o ESX Server, uma solução de virtualização para grandes empresas, que suporta o uso de servidores muito mais robustos e oferece mais opções de gerenciamento e integração entre diversos servidores. Diferente do VMware Server, que é instalado sobre um sistema operacional já existente, o ESX Server roda diretamente sobre o hardware, substituindo o sistema operacional inteiramente.

Preparando o terreno

O VMware Server possui versões para Linux e Windows. No caso da versão Linux, é necessário instalar dois módulos de Kernel (vmmon e vmnet), que permitem que o VMware tenha acesso direto ao hardware. O pacote de instalação inclui módulos pré-compilados para diversas distribuições, mas em muitos casos os módulos precisam ser compilados durante a instalação, o que torna necessário ter instalados os headers do Kernel e um conjunto de compiladores. Eles não são instalados por padrão na maioria das distribuições, o que demanda uma preparação adicional.

O primeiro passo é baixar os arquivos de instalação do VMware Server, disponíveis no:
http://www.vmware.com/download/server/

É necessário fazer um cadastro gratuito para receber o código de registro solicitado durante a instalação. O procedimento é bastante amigável e é possível inclusive solicitar vários números de registro (gratuitamente), caso pretenda instalar em vários servidores.

Estão disponíveis três componentes, o VMware Server propriamente dito, a interface de gerenciamento via web (Management Interface) e o “VMware Server Linux client package”, um arquivo compactado contendo o VMware Server Console. Os dois primeiros são instalados no servidor, enquanto o último (o Server Console) é instalado no seu desktop, a partir de onde você administrará o servidor:

Tanto as versões em .rpm quanto em .tar.gz contém os mesmos componentes, o que muda é apenas o formato do pacote. Nos exemplos vou utilizar as versões .tar.gz, que podem ser usadas em qualquer distribuição.

Enquanto baixa os pacotes, aproveite para ir adiantando o serviço, verificando a instalação dos headers, compiladores e das bibliotecas do X.

Comece verificando a versão do Kernel instalada, usando o comando “uname -a”, como em:

# uname -a

Linux server 2.6.18-4 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux

Em seguida, instale a versão correspondente dos headers do Kernel, usando o gerenciador de pacotes. Procure pelo pacote “linux-headers”, seguido pela versão do Kernel usada. No caso do Debian ou do Ubuntu você pode fazer a instalação usando o apt-get, como em:

# apt-get install linux-headers-2.6.18-4

Além dos headers, é necessário instalar um conjunto básico de compiladores, incluindo o gcc, make, libc6-dev e o binutils. No Debian e no Ubuntu você pode instalá-los através do pacote “build-essential”, um metapacote que instala toda a turma:

# apt-get install build-essential

No OpenSuSE, abra o Yast e, na seção Software Management, instale os pacotes “gcc” e o pacote “kernel-source” da mesma versão do Kernel instalado.

No Fedora, você precisa instalar também o pacote “xinetd”, que é necessário para que os scripts de inicialização utilizados pelo VMware Server funcionem corretamente.

No Mandriva a lista de pacotes é um pouco maior, similar ao que precisamos instalar no Debian. Abra o mcc e instale os pacotes autoconf, automake, gcc, gcc-cpp, xinetd, perl-devel e kernel-source, lembrando de instalar a versão do pacote kernels-source correspondente à versão do kernel atualmente instalada.

Muitas distribuições incluem estes componentes por padrão, dispensando estes passos. No caso do Ubuntu, você pode precisar criar manualmente o link “/usr/src/linux”, apontando para a pasta referente à versão instalada. Para isso, acesse a pasta “/usr/src” e rode o comando “sudo ln -sf linux-headers-2.6.*-* linux”, como em:

# sudo ln -sf linux-headers-2.6.20-15-server linux

Se mesmo depois de criar o link o instalador do VMware continuar parando na pergunta sobre a localização dos headers do Kernel, significa que você não instalou a versão correta do pacote “linux-headers”. Verifique e tente novamente.

Embora o VMware Server não precise da interface gráfica para funcionar, ele precisa que um conjunto básico de bibliotecas esteja disponível. Quando você faz uma instalação em modo servidor do Ubuntu, ou uma instalação mínima do Debian, estas bibliotecas precisam ser instaladas manualmente:

# apt-get install libx11-6 libxtst-dev libxt-dev libxrender-dev libxtst6 libxt6 libxrender1 libxi6 libdb3

Note que a instalação destas bibliotecas não implica na instalação do ambiente gráfico propriamente dito. Somados, os pacotes totalizam pouco mais de 14 MB, enquanto uma instalação completa do ambiente gráfico, incluindo o KDE (ou o Gnome) e alguns aplicativos somaria mais de 300 MB em pacotes.

Sem as bibliotecas do X, você receberá um erro similar a esse no final da instalação, quando o instalador pedir o serial. Ele surge justamente quando o instalador tenta carregar as bibliotecas utilizadas pelo programa a fim de concluir a instalação e se repete indefinidamente até que elas sejam instaladas:

Type XXXXX-XXXXX-XXXXX-XXXXX or ‘Enter’ to cancel: xxxxx-xxxxx-xxxxx-xxxxx
/usr/lib/vmware/bin/vmware-vmx: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

Uma dica é que você pode fazer a instalação dos pacotes usando um segundo terminal, sem precisar abortar a instalação do VMware. Depois que os pacotes forem instalados, o instalador aceita o serial e a instalação é concluída.

Como comentei no início, o pacote do VMware-Server inclui um grande conjunto de módulos pré-compilados, de forma que em muitos casos você sequer precisará se preocupar com os headers do Kernel ou com ferramentas de compilação. De qualquer forma, é interessante ter esses componentes instalados, já que eles são necessários para instalar diversos softwares e drivers. Mesmo em um servidor, mais cedo ou mais tarde você acaba precisando instalar alguma coisa que precisa deles.

Instalando

Para instalar o pacote principal do VMware Server, descompacte o arquivo .tar.gz e execute o arquivo “vmware-install.pl” dentro da pasta criada, como em:

$ tar -zxvf VMware-server-1.0.5-80187.tar.gz
$ cd vmware-server-distrib
# ./vmware-install.pl

O instalador é um script perl que roda em modo texto, o que permite a instalação em servidores sem o ambiente gráfico instalado. Não existe muito mistério, desde que os headers e os compiladores estejam em ordem, você vai acabar com uma instalação utilizável mesmo que simplesmente pressione Enter em todas as opções. Algumas perguntas que precisam de um pouco mais de atenção são:

Trying to find a suitable vmmon module for your running kernel.

None of the pre-built vmmon modules for VMware Server is suitable for your
running kernel. Do you want this program to try to build the vmmon module for
your system (you need to have a C compiler installed on your system)? [yes]

Using compiler “/usr/bin/gcc”. Use environment variable CC to override.

What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.8-2-386/build/include]

Aqui ele pergunta sobre o os módulos do Kernel, confirmando a localização dos headers. Este arquivo “/lib/modules/2.6.8-2-386/build/include” é, na verdade, um link para a pasta “/usr/src/kernel-headers-2.6.8-2-386″, onde estão os headers do kernel. Em caso de erros neste ponto, verifique a instalação dos headers e a presença do link. Outra dica é que você precisa ter instalados os pacotes “gcc” e “g++” da mesma versão usada para compilar o Kernel.

As próximas perguntas são sobre as interfaces de rede virtuais:

Do you want networking for your virtual machines? (yes/no/help) [yes]

Do you want to be able to use NAT networking in your virtual machines? (yes/no) [no]

Do you want to be able to use host-only networking in your virtual machines? [no]

Naturalmente, você deve responder sempre “yes” na primeira pergunta, caso contrário as máquinas virtuais ficarão desconectadas da rede, mas as duas seguintes precisam de uma inspeção mais cuidadosa. Por padrão, o VMware oferece uma rede virtual em modo bridge (bridged network), onde as máquinas virtuais simplesmente acessam a rede, como se fossem máquinas separadas. Cada uma tem seu próprio IP, como se fossem vários servidores distintos.

As opções para criar uma rede NAT e host-only permitem que as máquinas virtuais sejam configuradas com endereços internos, e acessem a rede através do host. Esta configuração é útil no VMware Player (onde você geralmente quer que o sistema dentro da máquina virtual apenas acesse a internet, sem compartilhar nada), mas não é tão interessante no VMware Server, onde a idéia é justamente criar servidores virtuais. Veja que no exemplo anterior desativei ambas as opções.

Caso seu servidor tenha mais de uma placa de rede, o instalador pergunta:

Your computer has multiple ethernet network interfaces available: eth0, eth1.

Which one do you want to bridge to vmnet0? [eth0]

Ou seja, ao detectar que existe mais de uma placa de rede disponível, ele pergunta a qual delas as máquinas virtuais devem ser ligadas. É importante indicar a placa correta, referente à rede onde as máquinas virtuais ficarão disponíveis, seja a placa da rede local, ou seja a placa com o link de internet.

Embora a mesma placa física seja compartilhada por todas as máquinas virtuais, o VMware se encarrega de encaminhar corretamente os pacotes recebidos. Ele simula inclusive a existência de diversos endereços MAC, um para cada placa de rede virtual. Imagine que ele cria uma espécie de “hub virtual”, onde as máquinas virtuais são conectadas.

Em seguida, temos:

Please specify a port for remote console connections to use [902]

Esta é a porta que será usada para a conexão do cliente, o vmware-server-console. Você pode alterar a porta por outra menos visada (e indicá-la manualmente ao conectar). O ponto principal é que a porta precisa ficar aberta no firewall. Se você é paranóico e prefere não correr o risco de manter a porta 902 aberta, pode ainda utilizar um túnel para se conectar a ela através da porta utilizada pelo SSH. Veja a dica mais adiante.

Em seguida, você deve definir a pasta onde as máquinas virtuais serão armazenadas. Aqui escolhi a pasta “/var/vms” (a pasta “/var” é usada por padrão para armazenar os sites do apache, bases de dados do MySQL, etc.), mas a escolha fica por sua conta. Naturalmente, as máquinas virtuais podem ocupar bastante espaço, por isso é importante checar o espaço livre dentro da partição destino.

In which directory do you want to keep your virtual machine files?
[/var/lib/vmware/Virtual Machines] /var/vms/

Depois de fornecer o código de registro, que você recebe via e-mail, a instalação está completa:

The configuration of VMware Server 1.0.5 build-80187 for Linux for this running
kernel completed successfully.

Depois de instalado, o VMware pode ser iniciado e parado através do serviço “vmware”, como em “/etc/init.d/vmware start” ou “/etc/init.d/vmware stop”. Sempre que tiver problemas, experimente, antes de mais nada, reiniciar o serviço.

O próximo passo é instalar o VMware Server Console, na sua estação de trabalho. A instalação é bem similar à do servidor, com a diferença de não serem necessários os headers e os compiladores. Basta descompactar o arquivo (ele usa uma dupla compactação, em .tar.gz e depois em .zip), acessar a pasta que será criada e executar o script “vmware-install.pl”, como em:

$ unzip VMware-server-linux-client-1.0.5-80187.zip
$ tar -zxvf VMware-server-console-1.0.5-80187.tar.gz
$ cd vmware-server-console-distrib
# ./vmware-install.pl

Depois de instalado, chame-o usando o comando:

$ vmware-server-console

Ao abrir a conexão com o servidor, você pode logar usando qualquer conta de usuário. De início, você pode se logar como root, para testar e fazer a configuração, mas depois é interessante criar uma conta de usuário separada, que tenha acesso à pasta das VMs. O VMware utiliza SSL de 128 bits para garantir a segurança da conexão, mas sempre é bom evitar utilizar o root para tarefas rotineiras.

O vmware-server-console possui uma interface muito similar à do VMware Workstation, onde você pode criar e editar as configurações das máquinas virtuais. Como disse, o VMware Server é uma versão adaptada para uso em servidores, onde a interface é separada do restante do software, permitindo que você faça tudo remotamente.

Ele utiliza um protocolo próprio para comprimir e transmitir a imagem da tela via rede, exibindo-a no seu desktop. O maior problema é que o VMware utiliza um protocolo de atualização de tela sem perda, que acaba sendo bastante ineficiente para uso via rede.

Ao acessar uma máquina virtual que está rodando num servidor remoto, o desempenho de atualização da tela é bastante inferior ao que você teria acessando a máquina remota usando o NX Server ou o VNC, por exemplo. Mesmo acessando via banda larga, usar aplicativos gráficos acaba sendo desconfortável. Isso faz o sistema dentro da VM parecer lento enquanto está sendo acessado (remotamente) através do Console, mas, na verdade, o desempenho não é muito diferente do obtido nas outras versões do VMware. Em geral, você obtém de 70 a 90% do processamento real do servidor dentro das máquinas virtuais.

Uma dica é que você pode utilizar o vmware-server-console para se conectar a uma cópia local do VMware Server. Neste caso, a atualização de tela é tão rápida quanto ao usar o VMware Workstation ou o VMware Player, de forma que muita gente prefere utilizar o VMware Server mesmo ao rodar máquinas virtuais localmente. Para isso, basta usar a opção “Local host” na tela inicial. Você pode aproveitar para ir treinando na sua máquina, antes de começar a criar VMs para servidores importantes.

É possível (e bastante simples) fazer a instalação do sistema dentro da máquina virtual usando sua máquina local e depois transferir o sistema já instalado para o servidor remoto. Desta forma, você não perde tempo tentando realizar todo o processo de instalação do sistema remotamente. Você pode inclusive criar várias cópias independentes da mesma máquina virtual, aproveitando a instalação inicial.

Vamos começar do básico, vendo os detalhes sobre a criação e configuração das máquinas virtuais. Uma vez conectado (seja a um servidor remoto, seja localmente), use a opção “Create a new virtual machine” na tela inicial:

A primeira opção determina as opções que serão mostradas daqui em diante. Na opção “Typical” são mostradas apenas as opções mais simples, deixando o wizard definir os detalhes. No nosso caso, estamos mesmo interessados em decifrar as opções mais avançadas, então vamos de “Custom”:

O VMware inclui uma série de otimizações que melhoram o desempenho e a compatibilidade do sistema dentro da máquina virtual. São melhorias relacionadas à operação interna do programa, de forma que não temos muitos detalhes sobre elas, mas a diferença é realmente mensurável. Para que elas entrem em ação, é importante indicar corretamente o sistema operacional que você irá instalar dentro da VM. Dentro da opção “Linux”, você encontra versões do Red Hat, SuSE, Mandriva e Ubuntu, que são suportadas oficialmente pela equipe do VMware. Para as demais distribuições, use as opções “Other Linux 2.6.x kernel”, ou “Other Linux 2.6.x kernel 64-bit” (ao instalar as versões de 64 bits das distribuições). Existe também a opção “Other Linux 2.4.x kernel”, que pode ser usada ao instalar distribuições antigas, que ainda utilizam Kernels da série 2.4:

Em seguida, chegamos à fase das apresentações, onde você define um nome para a máquina virtual e (mais importante), define a pasta onde os arquivos referentes a ela ficarão armazenados.

As máquinas virtuais nada mais são do que um conjunto de arquivos dentro de uma pasta. O mais importante deles é o disco virtual, onde são armazenados todos os dados salvos no “HD” da máquina virtual. Ao escolher a pasta, é importante verificar o espaço disponível, já que o arquivo do disco virtual armazenará o sistema operacional e todos os arquivos colocados dentro da VM:

A próxima pergunta é relacionada ao suporte a SMP. Ao instalar o VMware Server em uma máquina com um processador dual-core, quad-core (ou com dois processadores em SMP), você tem a opção de ativar o suporte a SMP também para a máquina virtual, permitindo que o sistema instalado enxergue os dois processadores e possa dividir a carga entre eles (opção “Two”)

Na prática, você pode usar a opção “Two” mesmo ao instalar em uma máquina com apenas um processador, mas neste caso (obviamente) não existe qualquer ganho de performance:

Existe ainda uma opção de segurança, que permite restringir o acesso às máquinas virtuais no caso de um servidor compartilhado por vários usuários. Imagine o caso de um servidor dedicado, onde você instalou 4 máquinas virtuais, que serão sublocadas a 4 clientes diferentes. Para dar acesso às VMs criadas usando o vmware-server-console, permitindo que cada um possa acessar apenas sua própria VM (sem ter acesso às demais), você criaria 4 usuários de sistema separados (joao, maria, jose e manuel, por exemplo) e usaria cada um dos usuários para criar uma das VMs, marcando sempre a opção “Make this machine private”. Dessa forma, cada usuário teria acesso a apenas uma das VMs:

Os recursos do servidor são compartilhados entre as máquinas virtuais, com destaque para a memória RAM. A opção seguinte permite limitar a quantidade de memória disponível para cada máquina virtual.

Embora a conta pareça simples (afinal, se temos 1 GB de memória e estamos instalando 4 VMs, teríamos 256 MB para cada uma, certo? , encontrar o melhor valor é um pouco mais complicado do que parece.

Em primeiro lugar, o valor definido aqui não é diretamente atribuído, nem fica fisicamente reservado para a VM, pois o vmware é capaz de gerenciar a memória RAM e swap disponível, de acordo com o volume de memória utilizado por cada VM e pelo próprio sistema host em um dado momento. Apesar disso, o VMware reserva cerca de 160 MB de memória para o sistema host e não permite que você inicialize mais VMs do que o comportado pela memória excedente. Se você tem 1 GB de memória instalada no servidor, todas as VMs somadas poderiam utilizar pouco mais de 840 MB. Se você tiver 4 VMs, configuradas para consumir 256 MB cada uma, o VMware exibiria uma mensagem de erro ao tentar inicializar a quarta. Você pode ter um número quase ilimitado de máquinas virtuais no mesmo servidor, desde que não fiquem todas ativas simultaneamente.

É possível fazer com que o VMware faça swap de parte da memória reservada às máquinas virtuais, o que permite que você ative um número um pouco maior de máquinas virtuais simultaneamente, às custas de uma redução no desempenho. Para isso, configure a opção Host > Settings > Memory > Additional Memory (na tela principal) com o valor “Allow most virtual machine memory to be swapped”:

Outra exceção ocorre quando você usa uma única máquina virtual de cada vez. Neste caso, o VMware permite que você reserve um volume de memória muito maior do que a memória física disponível, pois ele é capaz de utilizar também a memória swap. Veja que no meu caso, o VMware permite reservar até 1764 MB, muito embora o servidor onde ele está instalado tenha apenas 1 GB:

Um bom cálculo é subtrair 192 MB da memória total disponível (para uso do sistema host) e dividir o excedente entre as VMs que você pretender manter ativas simultaneamente. Se o servidor tem 1 GB de memória e você pretende manter 4 VMs ativas, poderia reservar 208 MB para cada uma.

Ao instalar o sistema dentro de cada VM, você pode criar uma partição swap dentro do disco virtual. Embora o desempenho de acesso a essa partição swap virtual seja mais baixo, ela poderá ser usada normalmente pelo sistema guest quando necessário, como complemento à memória “física” reservada à VM.

Chegamos então à configuração da rede virtual, que é outro passo importante. Como vimos anteriormente, o VMware oferece 3 tipos de rede virtual. No primeiro, o modo bridge, a máquina virtual tem acesso completo à rede, pode receber um IP próprio e fica com todas as portas de entrada disponíveis, como se fosse um PC independente conectado à rede. Sempre que falamos em servidores, falamos no uso do modo bridge.

As outras duas opções podem ser interessantes para uso em desktop, onde você simplesmente instala uma VM e a usa em conjunto com o sistema principal, mas não são muito relevantes no nosso caso. No modo NAT, a máquina virtual tem acesso à rede e pode acessar a Internet, mas não possui portas de entrada, de forma que não é possível rodar servidores. No modo host-only a VM é conectada a um cabo cross-over virtual e tem acesso apenas ao próprio servidor, ficando desconectada do restante da rede.

Como disse, ao configurar servidores virtuais (e em diversas outras situações), o modo bridge é o único que interessa, por isso escolhemos a opção “Use bridged networking”:

Independentemente do tipo de HD que está instalado no host, o VMware utiliza internamente rotinas de acesso do padrão SCSI para os discos virtuais. O padrão SCSI é o preferido pelos desenvolvedores, pois as funções são bastante organizadas e o padrão é aberto e fácil de entender. Isso explica porque, no Linux, o suporte a gravadores de CD e (a partir do Kernel 2.6.20) o próprio suporte a HDs IDE foi incorporado ao sub-sistema SCSI, que já existia previamente.

Graças a isso, o sistema operacional instalado dentro da VM reconhecerá o HD como sendo SCSI, mesmo que ele seja IDE ou SATA. Durante a criação da máquina virtual, o VMware permite que você escolha qual modelo de controladora SCSI será simulada dentro da máquina virtual. Você pode escolher entre uma controladora BusLogic ou LSI Logic. O desempenho de ambas as opções é rigorosamente o mesmo, muda apenas o driver que o sistema operacional instalado dentro da máquina virtual irá utilizar:

É possível criar uma máquina virtual e aproveitar o disco virtual de uma anterior (opção “Use an existing virtual disk”), assim como você pode montar outro micro e aproveitar o HD antigo. Esta opção pode ser útil caso você queira aproveitar uma instalação antiga de um sistema operacional instalado em outra VM. Neste caso, bastaria indicar a pasta com a VM antiga. Entretanto, na maioria dos casos, você vai querer simplesmente criar um novo disco virtual, zerado. Para isso, escolha a opção “Create a new virtual disk”.

Ainda dentro da questão da controladora SCSI virtual, existe a opção de utilizar um modo de compatibilidade, onde o VMware faz com que o disco virtual apareça para o sistema dentro da VM como um HD IDE. Esta opção permite resolver problemas de compatibilidade, casos onde, por um motivo ou outro, o sistema dentro da máquina virtual não possui suporte a HDs SCSI, ou não consegue detectar corretamente a controladora SCSI virtual.

Se a instalação do sistema dentro da máquina virtual falhar, com um erro de “não é possível acessar o disco”, ou similar (sintoma de que o sistema operacional dentro da VM não conseguiu acessar o disco virtual), escolha a opção “IDE”, do contrário mantenha o “SCSI (Recommended)”:

Assim como no caso da memória, você deve definir um limite para o espaço em disco utilizado pela VM, através da opção “Disk size (GB)”:

O valor definido é o tamanho do “HD” que será visto pelo sistema dentro da máquina virtual. Reservando 8 GB, por exemplo, o sistema enxergará um HD de apenas 8 GB e, naturalmente, não poderá ocupar mais espaço do que isso.

A opção “Allocate disk space now” faz com que o VMware realmente reserve os 8 GB para uso da máquina virtual, criando um enorme arquivo vazio. Esta opção é a melhor do ponto de vista do desempenho, pois evita a fragmentação e permite o uso de otimizações adicionais, mas, por outro lado, aumenta bastante o espaço ocupado pelas máquinas virtuais, já que, 4 VMs com HDs virtuais de 8 GB, ocuparão 32 GB de espaço no HD do servidor.

Desmarcando a opção, o espaço é alocado de forma dinâmica. O disco virtual começa como um arquivo vazio, que ocupa poucos Kbytes. Dentro da máquina virtual, o sistema guest pensa que está formatando e usando um HD de verdade, mas todas as mudanças são mascaradas e feitas dentro do arquivo. Conforme você instala o sistema e outros programas, o arquivo vai aumentando de tamanho, até o limite definido. Enquanto ele não é atingido, o arquivo do disco virtual ocupa um espaço equivalente à quantidade de espaço realmente ocupado. Se você criou um disco virtual de 20 GB, mas apenas 2 GB estão em uso, você verá um arquivo de apenas 2 GB dentro da pasta da máquina virtual.

Concluindo, a opção “Split disk into 2 GB files” permite burlar as limitações de tamanho de arquivos em partições FAT e em diversos protocolos de transferência de arquivos (incluindo o próprio SFTP), que só suportam arquivos de até 2 GB. Mantendo a opção ativada, o disco virtual é dividido em arquivos de até 2 GB, o que facilita as transferências.

Concluindo, você precisa apenas indicar o nome e a localização do arquivo com o disco virtual. Por padrão ele é criado dentro da pasta com os outros arquivos da VM e com o mesmo nome desta. É possível também usar nomes como “C” e “D”, ou “sda” e “sdb” ou mesmo armazenar os arquivos em outras pastas. Para isso, bastaria indicar a localização na opção “Specify Disk File”:

Com isto a criação da máquina virtual está completa . Como você pode ver, o processo é simples. O principal objetivo dessa longa explicação foi explicar os detalhes e mostrar as opções escondidas.

Configurando a VM

Estamos agora de volta à tela inicial do vmware-server-console. As máquinas virtuais são abertas em abas, o que permite que você mantenha várias delas abertas ao mesmo tempo, limitado apenas aos recursos disponíveis no servidor. Não é incomum ter notícias de servidores rodando 100 máquinas virtuais ou mais, cada uma com um servidor completo. Muitas empresas de hospedagem oferecem a opção de locar um VPS, que é justamente uma máquina virtual. Eles são uma boa opção aos planos de hospedagem compartilhada (onde você recebe apenas um virtual host do Apache), pois a máquina virtual se comporta como um servidor real, permitindo que você instale aplicativos e modifique a configuração como quiser.

Clicando no “Edit virtual machine settings” você tem acesso às configurações da VM e pode alterar muitas das opções definidas durante a criação, além de muitas outras que estão disponíveis apenas aqui. Você pode inclusive fazer “upgrades” na sua VM, adicionando um segundo HD, mais memória, ou até mesmo uma segunda placa de rede. Tudo virtual.

O VMware permite que você utilize uma imagem ISO de um CD (ou DVD) como mídia de instalação. Em um desktop, isso lhe salvaria de ter que queimar os CDs, mas, em um servidor remoto, acaba sendo a única forma de instalar o sistema, já que você não teria como ir pessoalmente colocar o CD no drive de qualquer maneira. Você poderia se conectar ao servidor via SSH, aproveitar a conexão rápida para baixar o CD ou DVD de instalação da distribuição que pretende instalar diretamente para ele (use o “wget -c”, seguido do link de download) e, em seguida, usar o VMware para instalar o sistema dentro da VM diretamente a partir do ISO que acabou de baixar.

Para isso, acesse a opção “CD-ROM” dentro do menu de configurações da VM e marque a opção “Use ISO image”. Indique o arquivo ISO que será utilizado e estamos conversados. Depois de concluir a instalação do sistema, você pode voltar nesta mesma tela e desmarcar a opção “Connect at power on” para desabilitar o CD-ROM virtual:

Continuando, você pode ajustar a quantidade de memória atribuída à máquina virtual na opção “Memory”. Isso permite que você teste várias configurações, até chegar na ideal:

Assim como no caso do CD-ROM, a máquina virtual pode utilizar também disquetes de boot, incluindo a possibilidade de usar uma imagem de disquete salva em um arquivo. Hoje em dia é incomum que você precise usar disquetes de boot para instalar o sistema, de forma que você pode remover o floppy virtual, selecionando o dispositivo na lista e usando a opção “Remover”.

Você pode adicionar novos discos virtuais através da opção “Add > Hard Disk”. Assim como em um PC, a VM pode ter diversos HDs, que são reconhecidos pelo sistema da forma usual. É possível adicionar também uma segunda placa de rede (esta opção é muito boa para fins didáticos, pois você pode simular uma rede inteira, com vários PCs) e até mesmo adicionar suporte à placa de som, USB e outros periféricos, embora estas opções não sejam tão úteis no caso de um servidor.

Uma dica para melhorar o desempenho é desmarcar a opção “Disable write caching” nas propriedades do disco virtual. Ela fica ativada por padrão, fazendo com que as alterações feitas nos HDs das VMs precisem ser gravadas de forma síncrona no HD do servidor. Esta opção melhora a segurança contra perda de dados caso o servidor seja desligado incorretamente, mas reduz bastante o desempenho. Em um servidor que fica ligado continuamente, desativá-la representa um risco aceitável.

Dentro das opções do disco virtual, você encontra também a função para desfragmentar o arquivo, o que ajuda a melhorar o desempenho da VM e reduzir a utilização de espaço no HD do host:

Depois de tudo configurado, falta apenas fazer as honras, clicando no “Power on virtual machine”. Você pode voltar ao menu de configuração a qualquer momento através da opção “VM > Settings” no menu principal, mas a maior parte das opções ficam inativas enquanto a VM está rodando. Para modificá-las, você precisa primeiro finalizar o sistema e desligar a VM, usando a opção “Power Off”:

Uma vez inicializada a máquina virtual, o sistema dá boot a partir do CD, DVD ou disquete virtual contendo o sistema. Você é saudado com a tela de boot e prossegue a instalação do sistema da forma usual, como se estivesse instalando o sistema em um PC real:

Você pode encontrar dicas para a instalação de diversas distribuições Linux e para as várias versões do Windows e outros sistemas dentro de máquinas virtuais no:
http://pubs.vmware.com/guestnotes/wwhelp/wwhimpl/js/html/wwhelp.htm

Uma dica é que, ao instalar um sistema distribuído na forma de vários CDs ou DVDs, é possível trocar os arquivos ISO durante a instalação, simulando a troca dos CDs no drive.

Para isso, dê um boot normal utilizando a primeira mídia e, no ponto da instalação onde o sistema pede para trocar a mídia, clique no “VM > Removable devices > CD-ROM 1 > Disconect”. Isso simula a remoção do CD-ROM. Clique agora no “VM > Removable devices > CD-ROM 1 > Edit…”, para indicar o arquivo ISO do segundo CD e, em seguida, em “VM > Removable devices > CD-ROM 1 > Connect” para simular a reinserção do CD:

Se você está usando uma cópia local do VMware Server e está com os CDs de instalação em mãos, pode também configurar a máquina virtual para utilizar o drive de CD físico e ir trocando os CDs durante a instalação, da forma tradicional.

Se, por outro lado, você não quer se dar ao trabalho de fazer nenhuma das duas coisas, pode baixar a versão em DVD (quando estiver disponível), fazer uma instalação via rede (como no caso do Debian, onde você pode utilizar a versão “netinst”) ou ainda fazer uma instalação mais enxuta, de forma que o instalador consiga instalar o sistema utilizando apenas os pacotes disponíveis no primeiro CD.

Como disse anteriormente, a máquina virtual é na verdade um conjunto de arquivos, salvos dentro da pasta indicada durante sua criação. Dando uma espiada dentro dela, você encontra os arquivos do disco virtual, criado com a extensão “.vmdk” (como selecionei a opção de quebrar em arquivos de 2.0 GB, tenho no meu caso um conjunto de vários arquivos), o arquivo .vmsd, que é usado para gravar uma cópia do conteúdo da memória da máquina virtual quando você utiliza a opção “Suspend” (de forma que ela possa ser restaurada no ponto onde estava posteriormente) e também o arquivo .vmx, um arquivo de texto legível que armazena a configuração da máquina virtual:

Dentro do arquivo, a quantidade de memória RAM reservada à máquina virtual vai na opção “memsize =” e o arquivo ISO que será utilizado vai na opção “ide1:0.fileName =”. Ao desativar algum dos dispositivos virtuais, a opção referente a ele fica com a opção “FALSE”, como no caso do drive de disquetes, que fica desativado por causa da opção floppy0.present -”FALSE”.

Com um pouco de prática, você pode até mesmo alterar as configurações da VM diretamente dentro do arquivo, sem sequer precisar das opções gráficas, o que pode ser bastante prático para fazer alterações rápidas em um servidor com muitas VMs:

Há algum tempo, escrevi um script para o VMware Player no Kurumin 7, que permitia criar e editar as opções das máquinas virtuais, aplicando as mudanças diretamente no arquivo. É o tipo de coisa que não faria muito sentido no VMware Server, que oferece todas as opções de configuração, mas foi bastante útil para quem usava o VMware Player, que é a versão castrada. Mostrou também que as máquinas virtuais podem ser criadas e configuradas até mesmo via shell script.

Continuando, o arquivo “nvram” dentro da pasta serve para armazenar as configurações do Setup. Sim, a máquina virtual possui até mesmo um BIOS virtual, com direito a Setup e tudo mais. Para acessá-lo, pressione a tecla “F2″ na tela inicial, logo depois de iniciar a VM.

Nele você pode escolher entre dar boot pelo CD-ROM ou pelo HD e até mesmo acertar a hora do setup. A máquina virtual tem até mesmo um relógio de CMOS próprio, vinculado ao horário do relógio da placa-mãe:

Um bug conhecido, que afeta diversas distribuições, é a tecla “/” do teclado não funcionar dentro das VMs. Ele pode ser resolvido rapidamente adicionado a linha “xkeymap.keycode.211 = 0×073″ no final do arquivo “/usr/lib/vmware/config” e, em seguida, reiniciando o serviço “vmware”. Você pode fazer isso rapidamente usando os dois comandos abaixo:

# echo ‘xkeymap.keycode.211 = 0×073′ >> /usr/lib/vmware/config
# /etc/init.d/vmware restart

Já que a máquina virtual é na verdade apenas uma pasta com arquivos, você pode perfeitamente tirar cópias e transportá-las para outras máquinas. Se você precisa de 10 máquinas virtuais com servidores Debian, por exemplo, você não precisa fazer a instalação 10 vezes; pode instalar uma vez, tirar 10 cópias e depois apenas modificar as configurações de rede e acertar as peculiaridades de cada servidor.

Para tirar cópias locais de uma máquina virtual, basta copiar a pasta de instalação. Você poderia, por exemplo, usar o comando:

$ cp -a Debian-Etch/ Debian-Etch2

… gerando uma pasta de nome diferente para cada cópia.

Para abrir as VMs copiadas no vmware-server-console, clique em “File > Open” e indique o arquivo .vmx dentro de cada pasta copiada:

Ao inicializar as máquinas virtuais copiadas pela primeira vez, o VMware exibe um aviso sobre o número de identificação. Cada VM possui um número de identificação e, por motivos óbvios, não é recomendável utilizar várias VMs com a mesma identificação. Para evitar isso, use a opção “Always Create”, que faz com que o VMware passe a atribuir novos números de identificação conforme as cópias forem sendo inicializadas:

Naturalmente, é possível também copiar as máquinas virtuais para outras máquinas. Neste caso, a melhor opção é compactar a pasta. Como os arquivos da VM são salvos no disco virtual sem compactação, você pode reduzir o tamanho da pasta em duas vezes ou mais ao compactá-la.

Compactar a pasta antes de transferí-la também evita problemas relacionados à mudanças nas permissões dos arquivos. Para comprimir a pasta no Linux, use o comando “tar -zcvf”, seguido pelo arquivo .tar.gz que será gerado e a pasta que será compactada, como em:

$ tar -zcvf Debian-Etch.tar.gz Debian-Etch/

Depois de transferir o arquivo para a outra máquina, descompacte-o usando o “tar -zxvf”, como em:

$ tar -zxvf Debian-Etch.tar.gz

Ao invés de fazer toda a instalação do sistema na VM remotamente, tendo que lidar com a lentidão de atualização da tela, você pode criar a VM e fazer a instalação e configuração na sua máquina e transferir a VM para o servidor quando estiver tudo pronto. Fazendo uma instalação enxuta do Debian ou uma instalação do Ubuntu em modo servidor e compactando a pasta antes de transferir, o upload ficará com pouco mais de 200 MB.

Como disse a pouco, você pode utilizar o SSH, NX, VNC e outras opções de acesso remoto para administrar as máquinas virtuais remotamente, deixando o vmware-server-console apenas para emergências. A vantagem dele é permitir que você acompanhe todo o processo de boot do sistema, identificando e corrigindo problemas em casos onde o sistema passa a travar no boot ou não sobe a rede, por exemplo.

Configuração da rede

Ao instalar o VMware Server em um servidor da sua rede interna, a configuração dos endereços de rede para as máquinas virtuais precisa apenas seguir o padrão normal da sua rede, como se você estivesse adicionando novos micros ou servidores. A principal dúvida reside em como configurar os endereços das máquinas virtuais ao utilizar um servidor dedicado, hospedado externamente.

Na grande maioria dos casos, ao locar um servidor dedicado você recebe uma faixa de 8 endereços, onde 5 deles são utilizáveis, já que o primeiro e o último endereços ficam reservados aos pacotes de broadcast e ao endereço da rede e um deles fica sendo o endereço do gateway. Na maioria dos casos, as empresas de hospedagem utilizam faixas de endereços de classe A ou B, divididas em uma grande quantidade de redes menores, utilizando máscaras de tamanho variável, baseadas no sistema CIDR. A máscara mais comum é a “255.255.255.248″ (/29), que permite criar as redes de 8 endereços que comentei.

Seu servidor pode, por exemplo, utilizar o endereço 72.232.194.138, sendo que:

72.232.194.136: Endereço da rede
72.232.194.137: Gateway
72.232.194.138 a 72.232.194.141: Endereços utilizáveis
72.232.194.142: Endereço de broadcast

Nesta situação, você ainda teria vagos os endereços de 72.232.194.138 a 72.232.194.141. Os endereços ociosos podem ser usados para colocar no ar servidores virtuais, que podem desempenhar funções secundárias, serem usados como honeypots, ou até mesmo serem sublocados. Basta usar a imaginação.

Você poderia colocar no ar 4 máquinas virtuais diferentes, cada uma utilizando um dos endereços disponíveis. Você notará que cada uma realmente responderá e se comportará como um servidor completo. Como disse anteriormente, é como se fosse criado um “hub” virtual”, onde todas as máquinas virtuais são ligadas.

Cada VM seria então configurada para utilizar um dos endereços vagos dentro da faixa. Se você não tem um segundo servidor dedicado para assumir a função de servidor DNS secundário, pode delegar essa função a uma das VMs, evitando assim precisar sacrificar um dos endereços IP para o alias da placa de rede no servidor principal. Aqui temos um exemplo de configuração de rede para uma VM dentro de uma faixa de 8 endereços:

Aproveite para adicionar as máquinas virtuais à configuração do DNS. Aqui temos um exemplo de configuração onde três VMs foram incluídas como subdomínios de um domínio já configurado:

@ IN SOA servidor.gdhn.com.br. hostmaster.gdhn.com.br. (
2008061645 3H 15M 1W 1D )
NS servidor.gdhn.com.br.
NS vm1.gdhn.com.br.
IN MX 10 servidor.gdhn.com.br.
gdhn.com.br. A 64.234.23.12
www A 64.234.23.12
vm1 A 64.234.23.13
vm2 A 64.234.23.14
vm3 A 64.234.23.15
vm4 A 64.234.23.16

Naturalmente, você pode também registrar novos domínios para as máquinas virtuais, adicionando as zonas na configuração do DNS do servidor principal (nada impediria que as próprias máquinas virtuais abrigassem servidores DNS próprios, mas isso só complicaria a configuração).

Em casos onde você precisa criar mais do que 4 máquinas virtuais (e a configuração de hardware do servidor permita), você pode pagar por endereços IP adicionais, opção que está disponível por um pequeno extra em grande parte dos planos de hospedagem. Veja, por exemplo, esta tela de seleção do The Planet:

Por apenas 8 dólares (mensais) adicionais é possível fazer um “upgrade” para uma faixa de 13 endereços (máscara 255.255.255.240) e por 56 dólares é possível colocar as mãos em uma faixa de 61 endereços utilizáveis (máscara 255.255.255.192).

Aumentando a mensalidade em mais 45 dólares, seria possível atualizar o servidor para 2 GB de RAM e adicionar um HD secundário de 500 GB, o que permitiria rodar tranquilamente 8 ou mesmo 16 VMs simultaneamente.

Interface de gerenciamento via web

Concluindo, falta apenas instalar o VMware Management Interface (no servidor), de forma que você possa monitorar o status das máquinas virtuais já configuradas usando o navegador.

Assim como nos passos anteriores, você deve baixar o arquivo “VMware-mui”, descompactá-lo, acessar a pasta “vmware-mui-distrib/” que será criada e rodar o comando “vmware-install.pl“, para abrir o script de instalação, como em:

# tar -zxvf VMware-mui-1.0.5-80187.tar.gz
# cd vmware-mui-distrib/
# ./vmware-install.pl

Ao contrário do script de instalação do VMware Server, o script não pergunta sobre compiladores ou sobre os headers do Kernel, apenas confirma os diretórios de instalação. Embora seja uma interface de administração via web, o VMware-mui não precisa que o Apache (ou outro servidor web) esteja instalado, pois ele inclui um mini-servidor próprio, que inclui todas as funções necessárias. Ele também não conflita com o Apache caso instalado no mesmo servidor, já que utiliza uma porta diferente.

Para se conectar à interface de gerenciamento, acesse (no seu desktop) o endereço “https://seuservidor.com.br:8333” e logue-se usando o mesmo login e senha do vmware-server-console. Esta interface de gerenciamento é muito prática, pois você pode se conectar ao servidor para reiniciar uma máquina virtual até mesmo usando o celular, quando estiver preso no trânsito. Note que é necessário manter a porta “8333″ aberta no firewall do servidor:

Aqui temos duas máquinas virtuais ativas, uma com o SuSE e outra com o Ubuntu. A grande diferença de uso de memória entre os dois (29 MB para o Ubuntu e 159 MB para o SuSE) é porque o SuSE está rodando com a interface gráfica e um conjunto de outros serviços ativos, enquanto o Ubuntu foi instalado em modo servidor e está rodando apenas o SSH e o Apache.

Em geral, um servidor bem configurado e com apenas os serviços necessários ativos, consome bem menos memória RAM que um desktop (com exceção dos casos de servidores de alta demanda, naturalmente), por isso é mais fácil manter várias VMs ativas. O consumo de RAM do servidor cresce conforme aumenta o número de usuários e, consequentemente, de requisições simultâneas.

Naturalmente, nada lhe impede de configurar também máquinas virtuais rodando outros sistemas operacionais. Também estão disponíveis versões do VMware Server e do vmware-server-console para Windows, tornando a escolha da plataforma algo bem democrático.

Voltando ao VMware-mui, muita gente torce o nariz para a idéia de manter abertas as portas 902 (utilizada pelo vmware-server-console) e 8333. Se você for paranóico, é possível manter as portas fechadas e acessar a interface de gerenciamento e o console usando um túnel do SSH. Neste caso, você precisa manter aberta apenas a porta 22.

Para criar os túneis, use o comando “ssh -f -N -L porta:IPservidor:porta -l user IPservidor”. É preciso executar o comando duas vezes, uma para a porta 902 e outra para a porta 8333. Se você deseja se conectar no servidor “gdhn.com.br” usando o login “gdh”, por exemplo, os comandos seriam:

# ssh -f -N -L902:gdhn.com.br:902 -l gdh gdhn.com.br
# ssh -f -N -L8333:gdhn.com.br:8333 -l gdh gdhn.com.br

Uma observação é que o primeiro comando (que redireciona a porta 902) precisa ser executado na sua máquina (no cliente) como root, pois as permissões do SSH não permitem criar túneis para portas abaixo da 1024 utilizando um login de usuário.

Com os túneis criados, ao invés de se conectar ao endereço IP ou domínio do servidor, você passa a se conectar ao endereço “127.0.0.1″, ou seja, você se conecta ao localhost. O SSH se encarrega de redirecionar todos os dados através do túnel, enviando-os para as portas corretas no servidor remoto, mesmo que elas estejam fechadas no firewall (pois os dados trafegam na verdade através da porta 22, do SSH).

Os túneis são bem transparentes. A única dificuldade é que você precisa executar novamente os comandos cada vez que reiniciar o cliente ou caso ele seja desconectado da rede.

VMware Tools

Embora não seja obrigatório, é interessante instalar o VMware-Tools após terminar de instalar o sistema dentro da máquina virtual. Ele é um conjunto de drivers que faz o sistema guest rodar com um melhor desempenho e de forma mais transparente, sobretudo com relação à interface de rede virtual e ao vídeo.

Dentro da máquina virtual, o sistema guest não enxerga o hardware real do servidor, mas sim um conjunto de dispositivos virtuais criados elo VMware. É por isso que você pode usar a mesma VM em vários servidores diferentes, sem precisar ficar instalando drivers nem modificando o sistema guest.

Para instalar o VMware Tools dentro da máquina virtual, use (com o sistema carregado) a opção “VM > Install VMware Tools” disponível no menu principal:

A opção simula a inserção de um segundo drive de CD-ROM, contendo a mídia de instalação do VMware-Tools dentro da máquina virtual. Ao instalar em uma VM rodando Linux, o primeiro passo é montar o drive de CD-ROM, usando o comando “mount /media/cdrom0″ ou “mount /mnt/cdrom”.

Acessando a pasta correspondente, você encontra dois arquivos do VMware-Tools, um compactado em .tar.gz (a versão genérica) e outro em .rpm (a versão destinada ao Fedora e outras distribuições derivadas do Red Hat).

Copie a versão que vai instalar para a pasta “/tmp”. Para instalar o arquivo .tar.gz, descompacte o arquivo, acesse a pasta que será criada e execute o comando “./vmware-install.pl” (como root). Para o pacote em RPM, basta instalá-lo utilizando o comando “rpm -Uvh”

A instalação do VMware-Tools implica na instalação de diversos módulos de kernel que precisam ser compilados sob medida para o kernel em uso. O pacote inclui pacotes pré-compilados para muitas distribuições, mas, ao instalar uma distribuição menos comum, ou instalar uma versão recente, você vai precisar ter instalados os compiladores e os headers do kernel (no sistema guest, dentro da máquina virtual), para que o instalador possa compilar os módulos, assim como ao instalar o pacote principal do VMware Server.

Ao usar a opção em uma VM com o Windows, a instalação é mais simples, pois a inserção do CD-ROM virtual dispara o programa de instalação automaticamente (usando o autorun) e o instalador segue o tradicional modelo “Next > Next > Finish”:

Graças a todos os recursos que vimos, o VMware Server acaba sendo uma opção quase que ideal, já que é gratuito, flexível e fácil de instalar. Além de usá-lo em seus servidores para otimizar o uso dos recursos disponíveis, essencialmente transformando um único servidor em vários, você pode até mesmo usá-lo no seu desktop, no lugar do VMware workstation ou VMware Player.

Atualmente estamos assistindo a uma popularização muito grande do Xen, mas ele ainda perde no quesito da facilidade de uso. Outro concorrente que tem crescido é o KVM, que também citei anteriormente. Ou seja, mantenha um olho no VMware Server, e outro nas demais soluções. Como o mercado é muito volátil, não podemos dizer qual deles estará por cima daqui a 5 anos.

Fonte: www.guiadohardware.net

Gerenciando processos no Linux

Introdução

A partir do momento em que inicializamos qualquer sistema Linux, temos processos rodando na memória. Basicamente tudo que um sistema operacional executa é um processo, se o servidor Apache está rodando, ele é um processo, se estamos com o OpenOffice aberto é outro processo, e por aí vai.

Aprender a lidar com processos é de extrema importância para um administrador de sistemas, pois ao manipula-los podemos através de sinais (comandos) fechá-los corretamente, fechá-los bruscamente, reiniciá-los e muitas outras coisas. É fato, que a tarefa mais básica no que se refere a processos é o que chamamos de “matar o processo”, fazemos isso quando uma aplicação está travada por algum motivo qualquer, assim fechamos ela na “força”, querendo ou não ela será fechada e permitirá que o utilizador continue utilizando o sistema normalmente e tente descobrir o que ocasionou o travamento.

Aprenderemos neste tutorial de uma forma simples como lidar com processos. Lembramos apenas que este é um assunto bastante extenso e que tem algumas variações (algumas bem significativas) com relação à outros sistemas derivados do Unix.

Na Prática

Como foi falado, tudo que está sendo executado na máquina é um processo, cada processo recebe um número de identificação aleatório, este número é exclusivo para o processo em questão enquanto ele existir, isso quer dizer que se eu abro o Firefox por exemplo, o processo que o representa receberá um número no momento em que ele é criado, enquanto o Firefox não for fechado este número não será utilizado por nenhum outro processo e mesmo que o Firefox seja aberto novamente o processo dele receberá um novo número, este número é chamado de PID que é a sigla para Process ID, ou seja, identificação do processo. O PID é fornecido automaticamente pelo Kernel.

Utilizamos o PID do processo para podermos trabalhar com ele, funciona mais ou menos como um número de RG ou CPF, podemos ter duas pessoas com o mesmo nome, porém por terem uma identificação única podemos lidar com cada uma delas sem ao menos pensarmos na possibilidade de confundir, a não ser que sejam gêmeas e tenham o mesmo nome, ué isso existe? OK, viagem pura, voltemos ao assunto. Ah, já ia esquecendo, você entendeu o raciocínio da coisa né? Podemos ter processos com nomes muito parecidos no entanto cada um terá o seu número de identificação que permitirá que o administrador trabalhe com eles sem se confundir.

Para finalizarmos o parte mais chata que é a parte teórica vamos aprender mais um conceito: Todo processo é derivado de um outro processo, exceto um, que é o primeiro processo… lógico! Então este primeiro processo é um processo chamado init, quando ligamos o computador e o sistema começa a ser carregado a primeira coisa que é carregada é o Kernel, ele vai inteiramente para a memória RAM, depois disso o Kernel carrega o init que tem o PID 1 (Um), todos os outros processos do sistema são no mínimo derivados do init. Portanto, temos aqui um conceito de processo pai, ou PPID. PPID é o PID do processo que “chamou” um determinado processo, complicado? Nem tanto. Imaginemos o seguinte: Temos o apache sendo executado em nosso servidor, o apache tem portanto um PID, fora isso, só foi possível abrir o apache porque o sistema já estava sendo executado, portanto já tinha no mínimo um processo em execução, que é o init. Neste caso o apache é um processo filho do processo init. Da mesma forma se temos um ambiente desktop instalado, como o KDE, para utiliza-lo precisamos do servidor gráfico, portanto ao inicializar o sistema temos o init que abrirá o servidor gráfico que por sua vez abrirá o KDE, e através do KDE podemos abrir o K3B por exemplo. Veja abaixo uma representação disso:

(Pai do Servidor Gráfico)

Processo Init \

(Filho do init e pai do KDE)

Servidor Gráfico \

(Filho do Servidor Gráfico e Pai do K3B)

KDE \

(Filho do KDE)

K3b

Você pode usar o comando pstree para ver os processos em forma de árvore e saber quem é “pai” de quem:

$ pstree

Porque precisamos falar sobre isso? Basicamente para deixar claro que o que você faz em um processo pai pode interferir no processo filho, principalmente se fecharmos um processo pai, saiba que neste caso o processo filho será fechado também.

Eu falei que a história do PPID será a última coisa para fechar a parte teórica? Mas não será , mas não fiquem bravos, vamos pelo menos aprender um comando para continuarmos com a parte teórica, trata-se do comando ps e sua forma de utilização mais comum é utilizando os argumentos aux, como em:

# ps aux

• ps é o comando em si que utilizamos para listar os processos atuais. Sem parâmetro ele mostra apenas os processos da sessão atual (terminal atual).
• A letra a serve para mostrar os processos de todos os usuários e não apenas do usuário que executou o comando ps.
• A letra u indica ao ps que ele deve mostrar o nome do usuário dono do processo em questão (quem o executou).
• E por último, mas não menos importante, a letra x que diz ao ps para listar inclusive os processos da parte gráfica e de outros terminais.

Vamos pegar uma linha do resultado para analisar:

USER PID %CPU %MEM VSZ  RSS TTY STAT START TIME COMMAND
root 1   0.0  0.1  2044 988 ?   Ss   19:15 0:01 /sbin/init

Podemos visualizar facilmente acima o nome do usuário dono do processo (USER) que é o root, o número de PID do processo que é 1 e o nome do processo que é /sbin/init (na verdade o cominho completo do executável, o processo em si se chama apenas init)

As outras informações não são tão comuns de se utilizar, no entanto segue uma descrição de cada uma delas:

• %CPU: Porcentagem de uso do processo pelo processo.
• %MEM: Porcentagem de uso de memória RAM pelo processo.
• VSZ e RSS: Páginação (Tamanho do processo).
• TTY: Terminal que originou o processo.
• STAT: R, S, D, Z e T

• • R – Running (Rodando)
  • S – Sleep (Esperando)
  • D – Died (Morto)
  • Z – Zumbie (Erro)
  • T – Stopped (Parado)

• Variações:

• • • < – Prioridade maior que a padrão
    • N – Prioridade menor que a padrão
    • T – Processo em foreground
    • s – Dono da sessão (Pai)
    • w – Usando recurso swap

• TIME: Tempo de CPU que o processo utilizou até o momento

Agora que já sabemos como visualizar os processos ativos na máquina com o comando ps, podemos aprender que todos os processos estão em uma espécie de fila, ou seja, os processos não estão sendo executados ao mesmo tempo como parece, eles só podem ser executados um de cada vez, mas quem manipula isso é o Kernel e ocorre de forma tão rápida que é imperceptível durante a utilização normal do sistema. Só conseguimos ter uma idéia visual que trata-se realmente de uma fila se utilizarmos um programa que mostra em tempo real e constantemente na tela cada um dos processos, para isso podemos usar o comando top:

Repare (e decore se possível) que cada sinal tem um número que o corresponde, isso pode ser observado nos números que estão entre parenteses, apesar de podemos enviar sinais utilizando seus nomes, não é muito usual fazer sso, por isso vamos usar nos exemplos sempre os números.Vamos usar o processo do vim novamente como exemplo e enviar inicialmente um SIGKILL (9) para ele, assim forçaremos seu fechamento:

$ vim teste

$ ps aux | grep vim

USER    PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
leandro 9820 0.0  0.1  3932 1476 pts/0 S+   20:48 0:00 vim teste

$ kill -9 9820

$ ps aux | grep vim

Atenção: Ao abrir o vim em um determinado terminal você ficará impossibilitado de executar os próximos comandos mostrados acima, portanto, você deve abrir o vim (primeiro comando) em um terminal e depois alternar para outro terminal com a combinação de teclas Ctrl + Alt + F2 (Ou F3, F4 e assim por diante até o F6), ou caso esteja utilizando um terminal no modo gráfico procure pela opção que permita abrir uma nova aba e fique alternando entre os dois terminais. Por último você terá que voltar para o terminal que estava anteriormente para ver o resultado. Trabalhe um pouco com isso pois utilizaremos muito neste capítulo.

Na seqüência acima, nós fizemos o seguinte:

• Abrimos o vim dizendo que o nome do arquivo a ser aberto é teste.
• Executamos o ps aux e filtramos o resultado dele com o grep para retornar somente as linhas que contenham a palavra vim.
• Achamos o número de PID do vim no resultado do ps aux e enviamos um sinal 9 (SIGKILL) para ele.
• Executados novamente o ps aux para verificar se o processo ainda existe.

Atenção: O sinal de menos (-) antes do número correspondente ao sinal em nada tem haver com o esquema de prioridades que vimos anteriormente, ele é apenas parte da sintaxe de utilização do comando kill, sem o sinal de menos (-), no caso do Linux, o sinal não será interpretado corretamente.

No exemplo acima nós matamos o vim como foi falado, caso ele estivesse travado ou não estivesse fechando por vias normais ao enviar um sinal 9 para ele, com certeza este seria fechado, em casos normais então nem se fala, como podemos constatar, matamos o processo dele mesmo sem ter nenhum problema relacionado, apenas para fins didáticos.

A utilização do vim como exemplo não foi por acaso, ele é um programa bom para demonstrar sinais, pois ele se comporta de forma esperada na maioria dos sinais que enviamos, diferente de outros programas mal escritos que não sabem lidar com “todos” os sinais e por isso apresentam comportamento estranho ao enviarmos certos tipos de sinais.

Ainda com o vim, vamos enviar um sinal 15 dessa vez pedindo para que o ele feche ao invés de fecha-lo bruscamente:

$ vim

$ ps aux | grep vim

USER    PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
leandro 6650 0.0  0.1  3932 1432 pts/0 S+   20:37 0:00 vim

$ kill -15 6650

$ ps aux | grep vim

Atenção: A primeira impressão que temos é que o sinal 15 funcionou exatamente como o sinal 9, porém se formos comparar, ao enviar um sinal 9 para o vim e voltar para o terminal que ele estava aberto, vamos perceber que ele fechou sem aviso nenhum, ou seja, foi pego de surpresa e fechado bruscamente. Ao enviarmos o sinal 15 e voltar ao terminal que o vim estava aberto nos deparamos com a mensagem “Finalizado”, indicando que o fechamento ocorreu normalmente, como se tivéssemos fechado ele manualmente.

Ficou claro a diferença entre o sinal 9 e 15? Um matará o processo e o outro fechará, respectivamente, a diferença você entende melhor ao ler o parte “Atenção” acima.

Vamos agora utilizar o sinal SIGHUP (1) que faz com que um processo releia seu arquivo de configuração caso isso seja possível, como assim se for possível? Bem, não são todos os processos que sabem ou devem lidar com todos os sinais, no caso do SIGHUP se for enviado para um processo que não saiba interpreta-lo, este será fechado ao invés de reler seu arquivo de configuração e continuar executando. Este sinal é muito útil quando o processo em questão trata-se de uma aplicação servidora de algum serviço, como um servidor web, de e-mail, proxy e etc, pois temos a possibilidade de alterar sua configuração e fazer com que ela entre em vigor sem que o serviço fique fora do ar (nem mesmo por um segundo).

Como o vim fecha ao enviamos um sinal SIGHUP vamos utilizar como exemplo o processo do squid, dessa forma:

$ ps aux | grep squid

USER  PID   %CPU %MEM VSZ   RSS   TTY STAT START TIME COMMAND
proxy 15116 1.4  22.4 19372 17608 ?   S    09:14 1:12 (squid) -D -sYC

# kill -1 15116

$ ps aux | grep squid

USER  PID   %CPU %MEM VSZ   RSS   TTY STAT START TIME COMMAND
proxy 15116 1.4  22.4 19372 17608 ?   S    09:14 1:12 (squid) -D -sYC

Na seqüência acima achamos o processo do squid, identificamos o seu PID e enviamos um sinal 1 que corresponde ao SIGHUP. Por último verificamos que o processo continua existindo e com o mesmo número PID, portanto, não foi fechado e aberto novamente, pois caso isso tivesse ocorrido o número de PID seria diferente. O fato de o processo ter recebido sinal 1 e não ter renovado o seu número PID já caracteriza que o mesmo se comportou como o esperado, pois caso contrário ou o processo não existiria mais ou estaria com um novo número de identificação.

Fica difícil ilustrar o SIGHUP na prática via escrita neste curso, já que não tem foco em servidores, mas se você já configurou ou vai configurar algum tipo de servidor, provavelmente vai alterar as configurações dele e querer que elas entrem em ação, neste caso você tem duas possibilidades consideradas “normais”, uma é reiniciar o serviço como vimos no capítulo de serviços:

# /etc/init.d/squid restart

A outra é ao invés de reiniciar o serviço (que deixará o serviço fora do ar) , usar o parâmetro reload:

# /etc/init.d/squid reload

Assim o serviço não ficará fora do ar, apenas lerá o arquivo de configuração novamente em tempo real. Mas porque é que voltamos a falar de serviços se este capítulo já passou? Apenas para mostrar que ao usarmos o parâmetro reload o script do serviço irá na verdade enviar um SIGHUP para o processo correspondente a ele. Agora as coisas começam a se encaixar….

Antes de falarmos dos sinais 18 e 19 vamos facilitar as coisas já que você deve ter percebido que apesar do comando ps aux nos trazer informações valiosas, muitas vezes apenas nos interessa número de identificação de um determinado processo. Quando este for o caso, podemos substituir o ps aux pelo comando piof ou pgrep:

$ pidof firefox

11252

$ pgrep firefox

11252

Como visto acima os dois funcionam da mesma forma e tem o mesmo propósito, exibir o número PID de um determinado processo ao informarmos via parâmetro o nome deste. O pidof costuma ser mais preciso no resultado, pois o pgrep em muitos casos se confunde no resultado e acabada trazendo outros processos que por um motivo ou outro também contém a string especificada via parâmetro.

Vamos ao SIGSTOP (19) e SIGCONT (18). Falaremos deles em conjunto pois um complementa a funcionalidade do outro, enquanto o SIGSTOP nos permite dar uma “pausa” em um processo, o SIGCONT faz com que possamos continuar um processo que está parado. Ao enviarmos um sinal 19 para um processo, este deixa de consumir recursos da máquina, mas não perde seu estado atual, ou seja, pode continuar de onde parou quando for da vontade do administrador.

Atenção: O processo que recebe um sinal SIGSTOP não perde seu estado atual somente se o processo em questão não for “morto” em seguida. Isso quer dizer que você não pode pausar um processo, desligar a máquina e restaura-lo depois de inicializar, pois quando desligamos ou reinicializamos o sistema todos os processos recebem um SIGTERM ou SIGKILL.

Imagina a cena. Você tem um determinado diretório com uma quantidade absurda de arquivos, como você é uma pessoa atenta, já que tem tantos arquivos, decide fazer um backup deles para evitar problemas futuros, para isso irá utilizar o tar e compressão bzip2, deve demorar um pouco, já que são muitos arquivos, certo? Não é só o fato de demorar que pode incomodar fazer backup, muitas vezes consume uma quantidade boa de recursos da máquina, principalmente porque o acesso ao HD fica a todo vapor, tornando a máquina muitas vezes inútil enquanto o backup está ocorrendo. Dentro deste cenário, com o backup já em andamento, seu chefe te pede um determinada documento o mais rápido possível, na linguagem que estamos acostumados a ouvir, seria “Pra ontem”, para piorar a situação você não faz idéia de onde guardou o arquivo em questão e terá que procurar.

E aí? Você pára o backup para recomeçar depois e perde o que já foi feito ou espera terminar e corre o risco de ter a atenção chamada? Usando os sinais você pode simplesmente pausar o tar e continuar depois, assim enquanto ele estiver parado você terá liberdade e conforto para trabalhar com outras coisas, como procurar o arquivo e abri-lo no OpenOffice por exemplo.

É claro que o conto acima é apenas uma ilustração para podermos trabalhar em cima do assunto, a idéia é que você desenvolva o conteúdo e aplique nas suas próprias necessidades.

Simularemos um backup de toda nossa partição raiz em um arquivo que será gerado na própria partição, apenas para fins didáticos já que o correto seria gera-lo em outro HD, partição, Pen Drive, ou qualquer outra mídia removível. Em seguida iremos enviar um SIGSTOP, checar o seu estado, enviar um SIGCONT e checar seu estado novamente:

# tar cjvf /backup.tar.bz2 /

# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.6  0.1  3544 1156 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /

# kill -19 6835

# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.0  0.1  3544 1220 pts/0 T    19:13 0:00 tar cjvf /backup.tar.bz2 /

Atenção: Ao executar o comando tar em um determinado terminal você ficará impossibilitado de executar os próximos comandos mostrados acima, portanto, você deve executar o tar (primeiro comando) em um terminal e depois alternar para outro terminal com a combinação de teclas Ctrl + Alt + F2 (Ou F3, F4 e assim por diante até o F6), ou caso esteja utilizando um terminal no modo gráfico procure pela opção que permita abrir uma nova aba e fique alternando entre os dois terminais. Por último você terá que voltar para o terminal que estava anteriormente para ver o resultado.

É bom darmos uma pausa por aqui antes de enviarmos um SIGCONT para o processo que acabamos de parar para falar que a informação mais importante neste momento é o conteúdo da coluna STAT pois ela que nos dirá o estado atual do processo, como visto anteriormente a letra S significa que o processo está em execução mas está em espera, ou seja, não está neste exato momento consumindo recursos do processador, mas pode começar a qualquer momento. A letra T por outro lado nos informa que o processo está parado, como esperávamos que estivesse realmente, afinal enviamos um SIGSTOP para ele.

Outra observação é que conforme você deve ter percebido ao paramos um processo com o sinal 19 o processo ficará em background, isso quer dizer que as informações que o tar fornece na tela não serão mais exibidas e poderemos utilizar o terminal que estava preso pelo processo do tar.

# kill -18 6835

# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.0  0.1  3544 1220 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /

Ao enviarmos o sinal 18 o processo volta a ser executado conforme observado na coluna STAT, mas fora isso, se voltarmos ao terminal onde o tar estava sendo executados podemos observar seu funcionamento novamente.

Por enquanto é isso, espero que tenham gostado.

Fonte: www.guiadohardware.net

VirtualBox: WindowsXP e Ubuntu Juntos. Guia de Instalação

Vamos fazer uma máquina virtual Windows XP rodar em um sistema Ubuntu.

Não sabe o que é uma Máquina Virtual? Então veja a figura abaixo:

clique para ampliar

Trata-se de uma máquina comum rodando o sistema operacional Ubuntu 8.04. Porém em uma janela temos o Windows XP. Não é acesso remoto, é um sistema operacional completo rodando em uma simulação de computador. Este programa simulador engana o sistema operacional da máquina virtual fazendo ele acreditar que está rodando em um computador real.

O principal objetivo é permitir executar mais de um sistema operacional em uma mesma máquina (normalmente sistemas diferentes). Assim é possível rodar um programa somente para Windows em uma máquina virtual hospedado no Ubuntu.

Diferente do duplo boot, não é precisar reiniciar a máquina para usar outro sistema. Dá para usar os dois simultaneamente. Exatamente como vemos na imagem.

Outro uso de máquinas virtuais é a virtualização de servidores para facilitar a escalabilidade.

Eu Já tinha utilizado o VmWare para usar máquinas virtuais por muitos anos, porém tenho tido diversos problemas com ele, deste as últimas versões do Ubuntu. Os problemas eram de performance e atualizações que causavam uma dor de cabeça para reinstalar o vmWare.

Resolvi então testar o VirtualBox. E não me arrependi. Performance similar com mais facilidade para instalação. Mas principalmente por causa do recurso especial do final do artigo. Se é usuário do vmware, vai lá dar uma olhada antes de desistir deste artigo.

Instalando Virtual Box

Instalação do Virtual Box:

sudo apt-get install virtualbox-ose

Nada mais simples.

Criando a Máquina Virtual

Entre no Virtualbox (Aplicações/Ferramentas do Sistema/VirtualBox OSE)

Escolha Novo (ou ctrl+N):

Defina o nome e o tipo do sistema a ser instalado:

Escolha o tamanho da memória virtual a ser utilizado pela máquina virtual:

Lembre-se que o XP, para ficar ligeiramente confortável, deve ter disponível pelo menos 256MB de memória. Dependendo do que for rodar é preciso mais.

Agora é preciso criar um disco rígido virtual. Isso nada mais é que um arquivo simples na máquina hospedeira que será montado como um disco na máquina virtual.

Clique em Novo e Siga o novo Wizard:

Os passos mais importantes são:

• Se o arquivo é dinamicamente expansível ou tamanho fixo (sendo o segundo caso mais rápido, porém poderá haver desperdício de espaço)
• Tamanho do Disco. Para o Windows XP recomenda-se no mínimo 10GB.

Depois do criar o disco virtual, basta confirmar e teremos nossa máquina virtual criada.

Instalação do Windows XP

A seguir vamos instalar o Windows XP. Para isso coloque o CD do Windows no drive e entre nas configurações da máquina virtual (Ctrl+S). Clique em Cd/Dvd-rom:

Escolha montar drive de CD/DVD e escolha o drive do hospedeiro conforme a figura acima. Isso fará com que a máquina virtual tenha acesso ao drive de CDROM real.

Clique no botão Iniciar para dar o primeiro boot da máquina.

Siga o procedimento comum de instalação de uma máquina Windows Xp.

Pós Instalação

Na máquina virtual pronta, escolha a opção “Dispositivos/Instalar adicionais para convidado”. Isso é essencial para uma melhor performance do Windows. Irá instalar os drivers necessários para pleno funcionamento da máquina virtual.

Por padrão a máquina virtual tem acesso pela rede via NAT, o que pode apresentar problemas para alguns programas ou configurações de rede.

Vamos ver a solução:

Configuração de acesso a rede via Bridge

Esta configuração permite o acesso direto da máquina virtual a rede da máquina hospedeira. O bridge funciona na camada 2 da rede e portanto não influencia nos protocolos de internet (camada 3).

Para funcionar com hospedeiro Ubuntu é preciso executar os seguintes passos:

1. Instalar o pacote de utilitários bridge (bridge-utils). Na linha de comando:
   

   sudo apt-get install bridge-utils

2. Edite o arquivo /etc/netword/interfaces e acrescente as seguintes linhas para criar um bridge chamado br0:
   

   auto br0
   iface br0 inet dhcp
   bridge_ports eth0

3. Reinicie a rede no hospedeiro:
   

   sudo /etc/init.d/networking restart

   Isso irá criar um bridge automaticamente a cada boot do hospedeiro.

4. Criar um interface permanente no host chamada vbox0 (vbox1, vbox2 uma para cada máquina virtual criada):
   

   sudo VBoxAddIF vbox0 <user> br0

   Troque o user pelo usuário do hospedeiro que irá utilizar a máquina virtual.

5. Entre novamente na configuração da máquina virtual e escolha a opção Rede modificando conforme a figura:
   
   Ligado à = interface do hospedeiro e Nome da placa de rede=vbox0 (a interface criada no item 4)

O site do VirtualBox foi fonte de informações para este artigo. Com certeza lá você poderá encontrar outras informações e roteiros mais sofisticados.

Recurso Especial

Para terminar o artigo uma dica sensacional: integre a janela do Windows com o Ubuntu. Na menu principal do VirtualBox clique em “Máquina/Modo Seamless”. Veja o resultado:

clique para ampliar

Como pode ver, a Barra de Tarefas do Windows embaixo e a do Ubuntu acima; e vários programas windows e Linux rodando, tudo junto!
Use Ctrl direito+L para voltar ao normal.

Fonte: www.tecnoclasta.com