Arquivo da tag: Ubuntu

Xvfb: Como usar o Selenium sem ter um X Server

Escrever testes com Selenium geralmente é uma tarefa que, ou é amada ou é odiada com todas as forças do indivíduo que a executa. Isso acontece principalmente devido às inúmeras formas e ferramentas disponíveis para escrever os seus testes de aceitação. Por exemplo, em Rails quem usa o Cucumber com certeza deve gostar muito de escrever tais testes, já quem usa o Selenium IDE não deve ficar muito feliz depois de algumas semanas repetindo várias e várias coisas.

Executar os testes é outra tarefa muito legal e motivante, ver as coisas acontecendo de forma automática é lindo, mas com o tempo isso começa a ficar muito chato, cansativo e a levar tempo de mais, tempo que você não pode esperar toda vez que quiser fazer um commit ou um push ou até mesmo uma integração para build. Com isso vem a idéia de um servidor de integração contínua onde todos os testes serão executados automaticamente do jeito que você desejar: a cada commit/push, tantas vezes por dia, etc.

Novamente tudo fica muito bom quando o servidor de integração contínua está executando tudo e dando conta do recado, mas e se o servidor disponibilizado não tiver um ambiente gráfico? Ou melhor, e se você questionar a razão de ter um ambiente gráfico num servidor como esse? Bom, há de pensar que sem interface gráfica não é possível executar o browser (exceto o lynx, eu sei), então o que fazer? Para resolver este problema existe o Xvfb, um projeto que serve exatamente para máquinas sem display.

O Xvfb cria um buffer virtual em memória e executa o X Server a partir daí, redirecionando o que deveria ser a saída VGA para a memória, e com isso você consegue um X Server virtual rodando sem display, apenas em memória. Com isso já é possível rodar o browser (e qualquer outra coisa que precisa de um X Server), logo, é possível executar todos os seus testes do Selenium. Um detalhe interessante é a possibilidade de ter qualquer resolução disponível agora, mesmo aquelas que um monitor não poderia te proporcionar.

Vamos agora a instalação e execução do Xvfb:

Instalando o Xvfb

jeveaux@valakas ~ $ sudo apt-get install xvfb

Executando o Xvfb

jeveaux@valakas ~ $ Xvfb :1 -screen 0 1600x1200x32

Com o comando acima vamos iniciar um novo servidor X (:1), screen 0 (-screen 0), resolução de tela de 1600×1200 e 32bits de cores. Agora para abrir o firefox neste servidor:

jeveaux@valakas ~ $ DISPLAY=:1 firefox

E se você quiser acessar visualmente a saída criada pelo Xvfb pode usar algum cliente VNC como o x11vnc e conectar-se no display criado:

jeveaux@valakas ~ $ sudo apt-get install x11vnc
jeveaux@valakas ~ $ x11vnc -display :1

E pronto! Obviamente o Xvfb não deve ser usado exclusivamente para o Firefox/Selenium, este post foi apenas uma abordagem dentre as milhares de soluções que podem se beneficiar de um X Server virtual.

Intel 4965AGN e Ubuntu Intrepid == Kernel Panic

Este final de semana fiz a atualização do meu Ubuntu para o Intrepid beta, tudo correu bem na atualização, reiniciei já com o kernel 2.6.27-7 e tudo continuou como antes, até que de repente tudo travou, congelou completamente. Foi bem estranho pois a luz de força (power) se apagou e as luzes do caps lock e scroll lock ficaram piscando.

Bad smell, pensei comigo. Reiniciei e continuei a fazer o que estava fazendo. Mais uma vez travou da mesma forma, caps e scroll lock piscando e luz do power apagada. Fiz isso mais umas quatro ou cinco vezes pra tentar identificar o que estava fazendo o sistema travar completamente mas não consegui identificar nenhum padrão que pudesse ser a causa do problema.

Comecei então com a saga de analisar logs e pesquisar sobre o problema na internet google, até que descobri que a poderia ser algo com a mudança do driver do wireless, que até o Hardy era o iwlwifi e no Intrepid é o iwlagn. Encontrei algumas referências de pessoas com o mesmo problema no Bug Tracker do Ubuntu, e nos relatos achei uma semelhança com o meu problema: o sistema só congelava quando eu estava usando rede N e fazendo alguma coisa que aumentasse o tráfego na rede.

Basicamente a solução é: baixe a última versão do driver, compile e instale. Aparentemente o driver que está saindo com o Intrepid não está legal. Certamente isso será corrigido até o final do mês, no lançamento oficial do Intrepid, até porque esta é uma versão beta, então alguns bugs são esperados, é mais do que normal. Mas para quem não consegue esperar, segue:

Atualizando o iwlagn no Ubuntu Intrepid

1) Faça o download do último driver em: http://www.orbit-lab.org/kernel/compat-wireless-2.6/2008/10/

2) Instalando

[code]jeveaux@keltir ~ $ sudo apt-get install -y build-essential
jeveaux@keltir ~ $ tar jxvf compat-wireless-2008-10-10.tar.bz2
jeveaux@keltir ~ $ cd compat-wireless-2008-10-10/
jeveaux@keltir ~/compat-wireless-2008-10-10 $ make
jeveaux@keltir ~/compat-wireless-2008-10-10 $ sudo make install[/code]

3) Reinicie e pronto =) (eu tentei recarregar o módulo sem reiniciar mais não deu certo, então reinicia que é mais garantido)

Starling: Trabalhando com Filas em Ruby

Quem nunca ouviu a grande falácia de que Rails não escala? Isso foi moda durante algumas semanas enquanto o Twitter passava por problemas de escalabilidade, não necessariamente por culpa do Rails ou de Ruby, mas quem quer por lenha na fogueira não está muito preocupado com isso e quer mesmo é semear a discórdia. Muita água já passou por baixo da ponte, o Twitter agora está estável e as coisasfluem bem.

No começo deste ano o pessoal do Twitter anunciou e tornou open source o projeto Starling, criado por Blaine Cook. O Starling é o core do Twitter, ele é o servidor de filas responsável por manter em pé o Twitter. E agora como um projeto open source está disponível como gem e pode ser usado por qualquer outro projeto.

Indo direto ao ponto, o Starling é, basicamente, um servidor de filas implementado sob o protocolo do MemCache. O MemCache é um servidor de cache distribuído de altíssima performance e é largamente usado, principalmente em clusters de aplicações web.

Para usar o Starling é muito simples. Os primeiros passos são

Instalação

1) Instalar o servidor MemCache

[code]jeveaux@kamael ~ $ sudo apt-get -y install memcached[/code]

2) Instalar a gem do MemCache e

[code]jeveaux@kamael ~ $ sudo gem install memcache-client[/code]

3) Instalar a gem do Starling.

[code]jeveaux@kamael ~ $ sudo gem install starling[/code]

E pronto, isso é tudo para começarmos a usar o Starling. Se você achou a instalação simples se prepare, pois a utilização é ainda mais simples.

Usando o Starling

Se você já usou o MemCache vai sentir-se familiarizado com o Starling. A diferença é apenas na implementação do protocolo, ou seja, a utilização em código será igual a do MemCache, só que ao fazer set e get as coisas acontecerão de uma forma um pouco diferente. Por enquanto a diferença maior que percebi foi em relação do método get, que quando usado no MemCache apenas retorna um valor do cache e o mantém lá, já no caso do Starling o get retorna o valor e o remove da memória. Analisando com calma isso faz sentido, afinal não estamos mais falando de cache e sim de filas, mesmo que a implementação da fila seja feita usando cache.

Mas antes de irmos para os exemplos de código, precisamos fazer com o que o servidor de filas – duh, Starling – esteja disponível e rodando. Vamos iniciar o Starling na porta 22122 (-p) e como um daemon (-d):

[code]jeveaux@kamael ~ $ sudo starling -p 22122 -d[/code]

Isso já basta para iniciar o servidor do Starling e deixá-lo disponível para uso. Agora então vamos alimentar a fila, crie o arquivo: alimentar_fila.rb.

[code]#alimentar_fila.rb
require ‘rubygems’
require ‘memcache’
starling = MemCache.new ‘localhost:22122’
starling.set ‘fila’, ‘qualquer objeto'[/code]

Ao executar este arquivo (ruby alimenta_fila.rb) não teremos nenhum resultado visual, mas acredite, a fila chamada de‘fila’ no exemplo está recebendo objetos. Agora o trabalho será para – como dizem – consumir a fila. Vamos ao consumir_fila.rb.

[code]#consumir_fila.rb
require 'rubygems'
require 'memcache'
starling = MemCache.new 'localhost:22122'
loop {
  objeto_fila = starling.get 'fila'
  if !objeto_fila.nil?
    puts 'recuperado da fila:' + objeto_fila
  end
}[/code]

E agora sim estamos prontos para colocar e remover objetos em uma fila. O exemplo para consumir os objetos ficará em loop, então você pode executá-lo numa janela do bash e em outra janela ir executando o exemplo para alimentar a fila com objetos e acompanhar o comportamento dos procedimentos de alimentar e consumir a fila. A recuperação da fila será imediata, instantânea, afinal, assim como o MemCache, o Starling está preparado para receber milhares de operações por segundo.

E é isso, o seu servidor de filas já está rodando e sendo alimentado/consumido. Agora é aplicar para o que você está precisando :D

Problemas

Há um probleminha chato com a gravação de log em disco que o Starling faz das filas. Todo o set feito gera o objeto na memória e também em disco – geralmente em /var/spool/starling/. O problema é que o get somente remove o objeto da memória e não do disco. Aparentemente isso foi feito pra ser assim mesmo e segundo o próprio Blaine Cook este arquivo de log não ficará sendo incrementado para sempre, pois, depois de um certo tamanho (o engraçado é que ele não fala esse certo tamanho) ele será rotacionado, mas por enquanto ainda não descobri este certo tamanho e o arquivo tem crescido infinitamente.

E apenas uma observação quanto ao consumir_fila.rb: Não deixe-o executando por muito tempo e nem muito menos esqueça de finalizá-lo pois como ele fica em loop infinito poderá ocupar o seu processador a toa.

Configurando Sony Ericsson MD300 no Ubuntu

Algum tempo antes de me mudar pro Rio eu fiz um plano de internet 3G da Claro e acabei comprando o modem da Sony Ericsson modelo MD300, na loja mesmo testei no notebook deles e tudo funcionou como eu esperava, velocidade nota 10 e conexão estável, até hoje não tive problemas, a não ser é claro a compatibilidade do modem com o Ubuntu.

Sempre vi muita gente usando 3G no Mac e em Linux com o modem da Huawei – aquele branquinho clássico – e logo pensei: “Vou comprar um desses”. Mas não tinha este modelo disponível no dia em que comprei. Então os problemas começaram, o MD300, ao ser plugado no usb com o Ubuntu é montado como pen drive e não como modem, afinal de contas ele também é um pen drive. Mas este não é um si o problema, se vai montar como pen drive tanto faz, isso não tem problema, desde que também seja montado como dispositivo de modem, mas isso não acontece.

Pesquisei de todas as formas possíveis por algumas semanas e não encontrei nada que realmente fosse funcional. Tentei ndiswrapper, tentei iniciar uma VM com windows pra conectar o modem e fazer um proxy pro linux, tentei configurar o wvdial, tentei promessa, simpatia e raza braba mas nada fazia o bendito modem funcionar.

Até que achei há alguns dias no blog do Petry uma solução que ele usou e funcionou. Fiz a mesma coisa e não funcionou de cara pra mim, tive que fazer algumas coisas diferentes, então por isso vou descrever os passos da solução do Petry com o que eu tive que fazer a mais.

O primeiro e mais importante passo é dizer ao udev como montar o dispositivo corretamente, para isso crie uma regra conforme abaixo. Lembre-se que o nome do arquivo criado deve ser exatamente igual ao exemplo, inclusive o seu conteúdo, nada diferente.

jeveaux@keltir ~ $ sudo vi /etc/udev/rules.d/50-md300modem.rules

Copie o conteúdo abaixo neste arquivo (tome cuidado com as aspas simples e duplas ao copiar e colar, sugiro conferir pra ver se elas foram transportadas corretamente depois de colar, comigo geralmente elas ficam como ´ ao invés de ‘)

ACTION!="add", GOTO="3G_End"
BUS=="usb", SYSFS{idProduct}=="d0cf", SYSFS{idVendor}=="0fce", PROGRAM="/bin/sh -c 'echo 3 > /sys/%p/device/bConfigurationValue'"
LABEL="3G_End"

Feito isso vamos reiniciar o udev

jeveaux@keltir ~ $ sudo /etc/init.d/udev restart

E na seqüência vamos instalar o gnome-ppp e wvdial

jeveaux@keltir ~ $ sudo apt-get -y install gnome-ppp wvdial

E agora vamos editar o .wvdial.conf do home do usuário (mais uma vez cuidado com as aspas, mesmo problema da regra do udev que citei acima)

jeveaux@keltir ~ $ vi .wvdial.conf

E então vamos colar este conteúdo no arquivo:

[Dialer Defaults]
Modem = /dev/ttyACM0
ISDN = off
Modem Type = USB Modem
Baud = 460800
Init = ATZ
Init2 = AT+CFUN=1
Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init4 = AT+CGDCONT=1,"IP","bandalarga.claro.com.br"
Init5 =
Init6 =
Init7 =
Init8 =
Init9 =
Phone = *99***1#
Phone1 =
Phone2 =
Phone3 =
Phone4 =
Dial Prefix =
Dial Attempts = 1
Dial Command = ATM1L3DT
Ask Password = off
Password = claro
Username = claro
Auto Reconnect = off
Abort on Busy = off
Carrier Check = on
Check Def Route = on
Abort on No Dialtone = on
Stupid Mode = off
Idle Seconds = 0
Auto DNS = on
;Minimize = off
;Dock = off
;Do NOT edit this file by hand!

Agora basta plugar o modem, iniciar o gnome-ppp e conectar-se. Você pode fazer isso diretamente pelo console com o comando gnome-ppp ou através do menu Applications > Internet > gnome ppp.

Basicamente até aqui é o mesmo passo a passo descrito no blog do Petry, porém comigo, ao terminar estes passos a conexão simplesmente não era mantida. Mandava conectar, discava, conectava e caía. Para resolver este problema fiz os próximos passos. Não sou exatamente um expert em linux, então não sei explicar exatamente o porquê destes passos, mas foram eles que fizeram o meu gnome-ppp funcionar corretamente.

Aparentemente alguma coisa sobrenatural estava fazendo meu gnome-ppp carregar o arquivo /etc/wvdial.conf ao invés do ~/.wvdial.conf, então precisei colar o conteúdo do ~/.wvdial.conf no /etc/wvdial.conf também.

Depois disso me conectei diretamente com o wvdial.

jeveaux@keltir ~ $ wvdial

Aí sim a conexão foi realizada com sucesso e não caiu. Depois disso fechei o wvdial e voltei a usar o gnome-ppp, que não caiu nenhuma vez depois disso.

Agora é esperar o Ubuntu 8.10, pois segundo as informações no site o network-manager virá com suporte integrado a conexão 3G (GSM e CDMA). Tomara que não precise mais dessa lenga lenga.