Fazendo as pazes com o proxy chato da Microsoft

Boa parte dos aplicativos hoje em dia possuem suporte a conexão à Internet, seja para verificar atualizações, permitir o download de novas funcionalidades ou simplesmente porque eles dependem de acesso à Internet para funcionarem direito.

Para quem trabalha dentro de uma rede Microsoft, a vida pode ser mais difícil com isso: o que fazer quando você se depara com um servidor proxy da Microsoft que possui autenticação via Active Directory?  Não são muitos os aplicativos que suportam este tipo de autenticação e nestes casos você fica ver navios se o acesso a Internet depende exclusivamente do proxy.

Eu já havia tentando no passado algumas soluções mas todas elas eram insatisfatórias, seja porque não funcionavam mesmo ou porque eram complicadas demais.

A alguns meses atrás eu conheci o programa de código aberto CNTLM que resolveu todos estes meus problemas de forma muito elegante.

O CNTLM é um proxy escrito em C que se encarrega das seguintes funções:

1. Fazer a autenticação no Active Directory com seu login para todas as suas aplicações que o utilizarem para acessar à internet;
2. Realizar a comunicação com os proxies internos da rede Microsoft para obter dados via HTTP/HTTPS.

Para fazer isto, basta realizar o download do aplicativo em http://sourceforge.net/projects/cntlm/files/cntlm/e instalar no seu computador. Repare que o CNTLM está disponível para os sistemas operacionais Windows e Linux (sendo que para este existem pacotes RPM e DEB). Eu vou utilizar a versão disponível para Windows para demonstrar o aplicativo, instalando o mesmo em um Windows XP.

Depois de instalar o aplicativo é necessário configurá-lo. Um dos passos é gerar um hash com seu login e senha para armazenar isto no arquivo de configuração. Isto é muito mais seguro do que você guardar a senha descriptografada.

Em um prompt do cmd.exe, digite:

C:\Program Files\Cntlm>cntlm.exe -H -u alceu-d foobar

cygwin warning:

  MS-DOS style path detected: C:\Program Files\Cntlm\cntlm.ini

  Preferred POSIX equivalent is: /Cntlm/cntlm.ini

  CYGWIN environment variable option "nodosfilewarning" turns off this warning.

  Consult the user's guide for more details about POSIX paths:

    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

Password:

PassLM          BDD3947C2A2F7A7FCDEB7B279523CCD5

PassNT          4957D58E48C9BEDF850B8FA8CEDFFED6

PassNTLMv2      FC8E3B7326F4FD313FA6D1A5E550614F    # Only for user 'alceu', domain 'foobar'

São três os hashes gerados, mas o mais recomendável é utilizar o PassNTLMv2 por ter criptografia mais forte. Pode ser que seu proxy não aceite este método, então você deverá tentar os outros.

Apenas copie a linha toda para seu arquivo de configuração (cntlm.ini) conforme é mostrado abaixo:

# NOTE: Use plaintext password only at your own risk

# Use hashes instead. You can use a "cntlm -M" and "cntlm -H"

# command sequence to get the right config for your environment.

# See cntlm man page

# Example secure config shown below.

# PassLM          1AD35398BE6565DDB5C4EF70C0593492

# PassNT          77B9081511704EE852F94227CF48A793

### Only for user 'testuser', domain 'corp-uk'

# PassNTLMv2      D5826E9C665C37C80B53397D5C07BBCB

#PassLM          D3D468DBC2224BD737E9981628C73A26

#PassNT          9C9672B7DAB8012768F515C2DCE69C2E

PassNTLMv2      FC8E3B7326F4FD313FA6D1A5E550614F    # Only for user 'alceu', domain 'foobar'

Após isso, configure os proxies da rede que o CNTLM deverá utilizar para comunicação com a Internet.

# List of parent proxies to use. More proxies can be defined

# one per line in format <proxy_ip>:<proxy_port>

#

#Proxy        10.0.0.41:8080

Proxy        proxy1.foobar.com:80

Proxy        proxy2.foobar.com:80

Você pode optar por excluir endereços e nomes de máquinas que não deseja que utilizar o proxy para acessar:

# List addresses you do not want to pass to parent proxies

# * and ? wildcards can be used

#

#NoProxy        localhost, 127.0.0.*, 10.*, 192.168.*

NoProxy        localhost, 127.0.0.*

Defina também a porta que o CNTLM deverá utilizar para escutar. Eu utilize a porta abaixo para evitar conflitos mas você pode utilizar a porta que achar melhor:

# Specify the port cntlm will listen on

# You can bind cntlm to specific interface by specifying

# the appropriate IP address also in format <local_ip>:<local_port>

# Cntlm listens on 127.0.0.1:3128 by default

#

Listen        60000

Se você quiser usar uma máquina virtual na sua máquina, essa opção abaixo será necessária mas não se esqueça também de limitar por IP quem poderá acessar o seu proxy por questões de segurança.

# Enable to allow access from other computers

#

Gateway    yes

# Useful in Gateway mode to allow/restrict certain IPs

# Specifiy individual IPs or subnets one rule per line.

#

#Allow        127.0.0.1

#Deny        0/0

#Allow        172.19.0.95

Por último, e não menos importante, especifique qual cabeçalho HTTP User-Agent o CNTLM deverá usar. Se o administrador da rede for especialmente paranóico, você poderá evitar questionamentos ocultando seus clientes web "não oficiais" da forma mostrada abaixo:

# Headers which should be replaced if present in the request

#

Header        User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Por último, será necessário configurar seus programas para que utilizem o CNTLM. Eu, por exemplo, faço uso extensivo do programa ppm do ActivePerl para instalar módulos na máquina. A maneira de fazer o ppm utilizar o CNTLM é configurar uma variável de ambiente chamada HTTP_PROXY tendo como valor o endereço do CNTLM e a porta aonde ele escuta as requisições. A figura abaixo ilustra a configuração disto no Windows.

Utilizando uma máquina virtual do CentOS no Windows com VMware eu também pude utilizar o yum para instalar novos pacotes RPM de maneira similar exportando a variável de ambiente HTTP_PROXY com o endereço IP da máquina hospedeira. É possível também usar o yum.conf para isto (veja mais em http://www.centos.org/docs/5/html/yum/sn-yum-proxy-server.html).

O CNTLM é instalado no Windows como um serviço, então você poderá pará-lo, iniciá-lo ou reiniciá-lo a qualquer momento da mesma forma como faria com qualquer serviço no Windows.

Também é possível iniciar o CNTLM para realizar debugging das conexões. Para isto, basta executar no prompt o seguinte comando:

cntlm -f -s -v

Com as opções de linha de comando mostradas acima, o CNTLM irá realizar a serialização das requisições (para não fazê-las em paralelo), rodando o aplicativo em modo foreground e imprimindo mensagens detalhadas sobre as requisições e respostas obtidas.

O CNTLM ainda possui mais recursos e eles estão todos bem documentados. Consulte a documentação para mais detalhes do que o aplicativo pode fazer.

Assim, com alguns minutos de trabalho você consegue utilizar seus programas que precisam de algum tipo de acesso à Internet sem muito esforço e respeitando as regras de acesso na rede Microsoft que você utiliza!

Melhorando o desempenho da base local do Siebel

Então está lá você, trabalhando com sua base local do Siebel do Tools e assim que começa a compilar um SRF logo fica pensando em algo melhor para fazer do que escutar o disco rígido trabalhando como uma pipoqueira enquanto a compilação não acaba...

A base local do Siebel é um DBF do Anywhere, um banco de dados móvel da Sybase. Consiste de um único arquivo salvo no diretório de instalação das ferramentas do Siebel.

Conforme linhas são inseridas, removidas ou atualizadas no banco, a tendência é ter fragmentação no arquivo, e depois de algum tempo isso pode começar a se tornar um inconveniente pois quanto mais fragmentada a base pior o desempenho para leitura e escrita na mesma. Levando em consideração que uma base local pode facilmente passar os 700Mb recomendados pela Oracle para tamanho máximo, não é difícil ter sua base local fragmentada.

A fragmentação do disco é bem conhecida em sistemas operacionais da Microsoft (que já dispõe de ferramentas de longa data para resolver este problema) mas e quando a fragmentação está apenas em um arquivo?

O programa Contig, desenvolvido pelos criadores do antigo website Sysinternals, foi criado justamente para resolver este tipo de problema: utilizando as mesmas APIs padrão de desfragmentação de arquivos do Windows, esse programinha consegue colocar todos os setores de alocação de um arquivo em sequência, o que é especialmente útil no caso da base local do Siebel. Veja um exemplo de desfragmentação abaixo:

Eu adoraria ter um benchmark para desmonstrar qual a diferença de trabalhar em uma base local fragmentada ou não, mas não tive tempo hábil de conduzir um teste desses. A realidade é que se a base local estiver realmente fragmentada, você irá sentir a diferença quando tentar repetir uma operação depois da desfragmentação.

Claro, esse truque só irá funcionar se a partição aonde a base local reside está desfragmentada: se não houver espaço contínuo também para alocar o arquivo, o Contig de nada ajudará.

Pensando nisso, é útil criar uma partição separada no disco, exclusivamente para uso da base local. Com discos rígidos a preços bastante convidativos, separar um 1Gb para uma base local deve ser suficiente para a maioria dos casos. Como a partição terá somente um arquivo, a fragmentação ali será bem menor.

Discos mais rápidos obviamente irão ajudar: se você puder dispor de um disco SSD, melhor ainda.

Algum tempo atrás eu tentei encontrar uma solução para utilização de ramdisk, mas além do risco com relação à perda de dados, não encontrei nenhuma ferramenta gratuita para Windows que conseguisse criar um ramdisk de tamanho razoável para armazenar a base local.

E, se tiver você estiver com disposição, ainda de quebra a Sybase tem um white paper em http://www.sybase.com/detail?id=1023801 com mais informações sobre como melhorar o desempenho do banco de dados Anywhere, mas eu mesmo não testei as ferramentas considerando que o que é disponibilizado junto com os instaladores do Siebel é o absolutamente mínimo para trabalhar. Especialmente falando na dica 10 ("Tip 10: Ready, steady, rebuild"), na falta da ferramenta citada sempre é possível fazer um novo database extract e obter uma base local novinha.

Clusters de imagem única no Linux

Já ouviu falar em clusters de imagem única? Não?

Bem, em 2011 eu entreguei meu trabalho de conclusão de curso (TCC) da pós-graduação na FIAP (em Sistemas Corporativos de Alto Desempenho). Me pareceu que o tema era bastante aderente ao currículo do curso... e foi mesmo!

A ideia original partiu do livro "Computação em Cluster" (do Carlos Pitanga) que apresentava o projeto openMosix como um cluster de imagem única para Linux, que juntamente com o Bewoulf, oferecia um suporte robusto para aplicações distribuídas que funcionassem à partir de criação de processos filhos para paralelizar o processamento de uma tarefa qualquer.

Bem, o fato de que o projeto do openMosix foi descontinuado em 2008 (por motivos bastante obscuros por sinal) dificultou um "pouco" o processo, já que meu TCC incluía testes práticos além da referência bibliográfica.

O resultado final pode ser visto no PDF que disponibilizei em http://db.tt/iWxgKThV.

Obviamente os projetos analisados já devem ter evoluído alguma coisa desde a data de publicação do TCC, mas com certeza a dissertação ainda serve como introdução ao assunto, além de ser possível acompanhar alguma escovação de bits com Linux e Perl.

Adoraria receber críticas (construtivas!) sobre o TCC, então fique à vontade para usar o espaço para comentários no final da postagem.