procself

vmware-tools vs. linux kernel

Antes de mais, o disclaimer: este artigo refere-se a uma versão antiga do VMware ESX, a 2.5.4. Nada disto se passa na série 3.*

Recentemente tive que actualizar uma máquina virtual ESX de Debian 3.1 para Debian 4.0. Apesar de não ser obrigatório, quis aproveitar a oportunidade para actualizar o kernel da versão 2.6.8 para a versão 2.6.18. Aqui começaram os problemas.

UTS_RELEASE
O symbol UTS_RELEASE contém a versão da source de um determinado kernel, no formato a que a maioria das pessoas está habituada, ou seja, A.B.C[.D]. Por esta razão, é frequentemente usado em scripts cuja execução depende da versão do kernel.

Até à versão 2.6.18 do kernel, este símbolo estava definido em:

./include/linux/version.h

mas a partir da versão 2.6.18 passou a estar num header file separado:

./include/linux/uts_release.h

Como consequência, o script vmware-config-tools.pl não conseguia detectar correctamente a versão da source contra a qual estava a tentar compilar as vmware tools e, para dificultar as coisas, limitou-se a queixar-se que a versão da source não correspondia à do kernel que estava a correr. Cheguei ao cúmulo de compilar um kernel novo e arrancar a máquina virtual com ele para ter a certeza absoluta que correspondia à source em questão!

Acabei por cheguar à origem do problema por sorte, graças a um comentário a esta entrada do kerneltrap, escrito por alguém que passou pelas mesmas dificuldades ao tentar compilar o módulo para as placas ATI.

Nesta caso a solução era trivial, bastava copiar a seguinte linha do utsrelease.h para o version.h:

#define UTS_RELEASE 2.6.18

e a detecção já funcionava devidamente.

Primeiro problema resolvido, vamos em frente.

VMW_HAVE_EPOLL
O primeiro módulo que o script vmware-config-tools.pl tenta compilar é o vmmon, responsável por melhorar a gestão de memória e cpu dentro da máquina virtual, e por funcionalidades como o memory ballooning (PDF). Durante a compilação surgiram warnings como este:

warning: "VMW_HAVE_EPOLL" is not defined

Que mais à frente acabam por degenerar em erros que impedem a compilação.

Confesso que não percebi exactamente qual o efeito desta alteração ao Makefile das vmware-tools, mas confirmo que funciona.

Com esta alteração o módulo vmmon já compila e carrega sem problemas.

HgfsGetsb()
O próximo módulo, vmhgfs, também não compila sem alterações. Apesar de não ser crítico para o funcionamento da máquina virtual (só fornece a funcionalidade de shared folders), acabei por gastar algum tempo e acabei por descobrir que alterações fazer e porquê.

A função get_sb_nodev que é invocada a partir da rotina HgfsGetsb() passou a ter mais um parâmetro a partir da versão 2.6.18 do kernel.

O fix não é trivial, mas está bem descrito no comentário de Jim Bachesta a este thread nos fóruns da vmware.

A partir daqui o módulo já compila e carrega sem problemas.

MODULE_PARM
E, para serem três em três, o módulo vmxnet - o terceiro e último componente das vmware tools e provavelmente o mais essencial de todos (fornece o driver para a placa de rede virtual) - também não compila à primeira.

Desta vez foi a macro MODULE_PARM que passou de deprecated a obsolete e foi, consequentemente, abandonada. No seu lugar ficou um substituto: module_param. Este artigo fez-me perceber o que tinha acontecido, agora só faltava descobrir como resolver.

Este mail da mailing-list da malta do pcmcia serviu-me de exemplo e bastou corrigir as duas ocorrências na source do vmxnet para que passasse, também, a compilar e carregar sem problemas.

No final de contas foram umas horitas de hack atrás de hack como há muito tempo já não me acontecia, mas acabou por valer a pena, nem que seja só pela satisfação de ter resolvido um problema que o pessoal da VMware ainda não se deu ao trabalho de corrigr e publicar.

Partilhar

ip_conntrack_ftp vs. ip_nat_ftp

Uma das funções que o Linux desempenha bem há já vários anos é a de gateway para a Internet numa rede empresarial. Para desempenhar esta tarefa é indispensável recorrer - directa ou indirectamente - às capacidades de NAT do iptables.

O NAT é, provavelmente, o maior hack alguma vez feito ao protocolo IPv4 conforme foi originalmente definido. É um hack muitíssimo bem sucedido e com múltiplas virtudes, mas ainda assim um hack criado essencialmente para ultrapassar a escassez de IPs disponíveis num espaço de endereçamento de 32 bits.

Isto nota-se em portocolos como o FTP ou o PPTP, que são muitas vezes usados para aceder do interior de uma rede empresarial, através de um gateway, a recursos na Internet. No caso concreto do FTP o problema tem duas facetas que explico de seguida.

Connection Tracking
Por um lado, o protocolo usa dois canais de comunicação, um para controlo e outro para dados, o que obriga o iptables a portar-se como uma firewall stateful e a relacionar os dois streams. Este tipo de funcionalidade é normalmente conhecido como connection-tracking e é implementado no iptables através de módulos auxiliares (helpers). Resumidamente, para que funcione de forma correcta é preciso carregar o módulo ip_conntrack_ftp:

modprobe ip_conntrack_ftp

Active Mode
Outra das particulares do FTP é que tem dois modos de funcionamento, o passivo e o activo. Em modo passivo tanto as ligações de controlo como as ligações de dados são originadas no cliente com destino ao servidor. Este modo de funcionamento não traz nenhum problema às redes empresarias que se escondem atrás de um NAT porque ambas as ligações são outbound e correctamente traduzidas.
O outro modo de funcionamento, que em algumas plataformas é o único que está implementado, funciona ao contrário. A ligação de controlo é estabelecida do cliente para o servidor (outbound) e na fase final é especificado um par IP,Porta ao qual o servidor se deverá ligar para estabelecer a ligação de dados (inbound). Isto dificulta bastante a vida a uma firewall que esteja a esconder o cliente de FTP da Internet através de um NAT. Para ultrapassar o problema há um outro helper para o iptables que pode ser carregado, o ip_nat_ftp:

modprobe ip_nat_ftp

O artigo da Wikipedia sobre o FTP explica razoavelmente bem as debilidades do protocolo e tem uma secção só sobre as interacções NAT/FTP.

Partilhar

JConsole

O JConsole é um utilitário (infelizmente apenas disponível para Windows) que vem incluído no JDK da Sun a partir da versão 1.5.0 e que permite monitorizar uma JVM local ou remota através de JMX.

A ferramenta é muito útil para monitorizar application servers como o Tomcat ou o JBoss e já me permitiu identificar situações de memory leak e deadlock que de outra forma teriam passado indetectadas.

No caso em que se pretende monitorizar JVMs remotas, estas devem ter sido inicializadas com alguns parâmetros especiais:

-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false


As opções são auto-explicativas. Pode ligar-se a autenticação e o SSL em ambientes mais agressivos, mas para monitorização em “tempo real” mantê-las desligadas acelera significativamente o refrescamento.

A comunicação entre o utilitário e a JVM é feita por RMI. Isto não teria particular relevância, não fosse o facto de o RMI se portar mal através de NAT’s, mais concretamente através de DNAT’s. Esta semana fui “mordido” por esta característica e se não fosse a FAQ sobre RMI e estes dois artigos, não me safava… A solução é simples, é preciso dar um hint à JVM sobre qual o hostname ou endereço ip que vai ser usado para lhe aceder:

-Djava.rmi.server.hostname=[fqdn or dnated ip]

Nota: o utilitário apenas existe para Windows, mas podem ser monitorizadas JVMs a correr em qualquer plataforma…

Partilhar