procself

Http vs Sftp

Upload do mesmo ficheiro binário não-comprimível, primeiro por HTTP e depois por SFTP.

… como diria alguém conhecido, é por isso que “uma coisa é uma coisa e outra coisa é outra coisa”.

Partilhar

JDBC e Reverse DNS Lookups

Se alguma vez ouvirem alguém queixar-se que uma aplicação Java client/server que funciona exclusivamente em rede local fica extraordinariamente lenta cada vez que o acesso à Internet cai, lembrem-se deste post.

Com uma descrição destas a primeira coisa que me ocorre é DNS. Como a aplicação não deixa de funcionar, fica simplesmente mais lenta, provavelmente o problema estará numa resolução inversa de DNS, que são frequentemente feitas pelas aplicações / middleware apenas para efeitos de logging.

Para não restarem dúvidas que o problema se relacionava com DNS, o servidor em causa tinha a configuração de DNS a apontar para o servidores do ISP, que obviamente ficam inacessíveis cada vez que se perde o acesso à Internet.

Comecei por procurar na aplicação, mas não encontrei nada que justificasse um lookup inverso de DNS. No tomcat encontrei um parâmetro que parecia promissor:

enableLookups - Set to true if you want calls to request.getRemoteHost() to perform DNS lookups in order to return the actual host name of the remote client. Set to false to skip the DNS lookup and return the IP address in String form instead (thereby improving performance). By default, DNS lookups are enabled.

Mas mesmo depois de desactivar o problema persistia. Descendo ainda mais na stack aplicacional descobri este bug no Java, já antiguinho, mas ainda aplicável à versão que estava a ser usada:

There is a call to InetSocketAddress.getHostName() in the ProxySelector code. This will trigger a reverse lookup when the hostname is not already known. If DNS is not configured correctly on the machine, this will generate a long timeout.

Foi este post na mailling list do Postgres que me conduziu ao bug em si e a descrição que fazem do problema é mais fácil de entender (e mais assustadora):

I can confirm that this is an issue in JDK 1.5 (a/k/a Java5) in Windows.  This is not the fault of postgres, but like others have suggested, it is with reverse DNS lookup.  It affects all TCP connections.
If you connect to an IP address it attempts to look up the name, resulting in these delays.

Se actualizar a versão de Java não for uma hipótese viável (como não era no meu caso), e se a resolução inversa ocorrer sempre para o mesmo endereço IP ou conjunto restrito de endereços, a solução pode ser mesmo adicioná-los ao ficheiro de hosts (C:\windows\system32\drivers\etc\hosts ou /etc/hosts).

Pelo caminho ainda descobri uma forma fácil de ver o conteúdo da cache de DNS num sistema windows:

ipconfig /displaydns

Se ficaram curiosos sobre como fazer a mesma coisa em Linux, a resposta não é fácil. Sem software adicional o kernel Linux não inclui uma cache de DNS, cada pedido é um pedido. Existe o nscd (Name Server Cache Daemon) que é bastante comum mas não vem pré-instalado em todas as distribuições (por exemplo não vinha no último Debian que instalei).

Partilhar

OpenWRT - DNSMasq forwarding

Troquei recentemente o router lá de casa por um Asus WL-500G Premium.

Pretendia usá-lo como router/access point convencional, mas também como:

• print server - para uma HP com interface USB;
• file server - usando como dispositivo de armazenamento uma pen ou disco usb externo;
• ipsec gateway - para estabelecer uma VPN com a firewall corporativa e permitir acesso aos PCs lá de casa;

Tudo isto podia ser conseguido com o firmware original do router, excepto a parte do ipsec. Como também tinha alguma curiosidade em instalar Linux em sistemas “embedded”, resolvi  experimentar.

A primeira tentativa foi com o DD-WRT, mas não gostei do sistema de ficheiros read-only, nem do feel da coisa. A segunda tentativa foi com o OpenWRT, e desta vez fiquei satisfeito. A documentação existente no wiki é francamente boa, tanto no que diz respeito aos procedimentos de instalação, como também à configuração e afinação final.

Consegui completar todos os objectivos traçados recorrendo à documentação existente no wiki, com excepção de um pequeno pormenor. Depois de estabelecida a VPN com a firewall corporativa, dá muito jeito que as queries DNS para o domínio interno da rede corporativa sejam enviadas através da VPN até aos servidores responsáveis pela zona. O DNSMasq tal como vem instalado só permite encaminhar todas as queries para um (ou mais servidores), ou resolvê-las a partir dos root servers. Parecia não haver forma de fazer um encaminhamento selectivo de queries de certos domínios para um (ou mais servidores) de DNS.

Acabei por descobrir a solução na manpage do DNSMasq. Há um switch que permite definir exactamente isso:

-S /private.domain/w.x.y.z

Acrescentando este switch à variável args do script de arranque em /etc/init.d/dnsmasq consegue-se que o router encaminhe todas as queries de DNS para a zona private.domain para o servidor de DNS com o endereço w.x.y.z.

Partilhar

snmpd vs. stg.exe

O SNMP Traffic Grapher (ou STG para abreviar) é uma aplicação muito simples para Windows que desenha gráficos de tráfego de rede em tempo real. Usa SNMP para monitorizar os routers e tem intervalo de monitorização configurável (no limite, 1ms!).

A grande vantagem face aos clássicos mrtg+rrdtool é precisamente o facto de desenhar o gráfico imediatamente, e não usando médias e medições espaçadas. O objectivo desta ferramenta é mostrar uma imagem da evolução “instantânea” do tráfego de rede entre dois segmentos de rede, e não o de permitir uma análise mais do tipo histórico ao longo de um período razoável de tempo.

O snmpd é uma implementação de um daemon SNMP para linux, que permite usar ferramentas como o STG para monitorar, entre muitas outras coisas, o tráfego de cada interface de rede.

O problema é que, se não se fizer nada de especial, a coisa simplesmente não funciona. O STG mostra só uns pontinhos muito espaçados e não se vê nada de conclusivo. Isto acontece porque o snmpd, por motivos de desempenho, guarda em cache os valores lidos do sistema operativo durante 30 segundos.

stash_cache
Caches information returned from the lower level. This greatly help the performance of the agent, at the cost of caching the data such that its no longer “live” for 30 seconds (in this future, this will be configurable). Note that this means snmpd will use more memory as well while the information is cached. (Fonte: penguin-soft)

Como, neste caso, o valor lido do sistema operativo é o total de bytes transmitidos, sendo o tráfego calculado como a diferença entre duas medições consecutivas, o efeito que a cache tem no STG é o de gerar um gráfico com 29 segundos sem tráfego e 1 segundo com o tráfego acumulado dos 30 segundos totais, o que é completamente inútil para o objectivo que se pretende atingir.

Para resolver o problema há duas soluções, mas a mais imediata é mesmo acrescentar o seguinte ao script de arranque do snmpd, imediatamente após o arranque do daemon:

snmpset -Lf /dev/null -c private -v2c localhost nsCacheTimeout.1.3.6.1.2.1.2.2 i 0

Partilhar

netstat-nat

Ou, resumidamente, como listar todos os fluxos tcp/udp que atravessam um router linux que faz SNAT/DNAT.

Esta é daquelas ferramentas indispensáveis para quem administra este tipo de routers. É possível obter o mesmo tipo de informação (e muito, muito mais) usando sondas como o ntop, mas esta é daquelas pérolas que fazem exactamente aquilo que é preciso, da forma que dá mais jeito e com o mínimo de trabalho possível. Fiquei deliciado.

Ah, faz parte dos repositórios debian oficiais; a página do projecto é esta; a do freshmeat está aqui; e a melhor descrição das funcionalidades é mesmo a manpage.

Partilhar