Feeds:
Posts
Comentários

Essa é uma dica rápida para os violeiros de plantão que ainda não têm o ouvido preparado para afinar um violão sem uma mãozinha de programas de computador ou afinadores. Eu não me consideraria um “violeiro”, mas as vezes eu tento e confesso que já passei várias horas tentando afinar o violão até que ficasse no ponto. Mas isso foi com ajuda de arquivos .mid com as notas das cordas afinadas, ou seja, bem chatinho.

Vamos ao que interessa.

Primeiro você precisa ter instalado o pacote SOX. Se ainda não tem, é muito simples.

Ubuntu:

$ sudo aptitude install sox

Fedora:

# yum install sox

Agora, com uma simples linha, o nosso amigo Pinguim vai tocar a nota afinada de todas as cordas do seu violão. Basta você ouvir e afinar a corda do seu, de acordo com a nota tocada no computador. Eis a tal linha:

$ for n in E2 A2 D3 G3 B3 E4; do play -n synth 4 pluck $n repeat 1; done

Explicando os parâmetros do comando:

  • synth – Durante quantos segundos a “corda deve vibrar”.
  • pluck – Representação da corda, no caso seria um dos valores E2, A2, D3, G3, B3, E4.
  • repeat – Quantas vezes a mais a nota deve ser tocada. No exemplo acima o valor 1 define que será tocada 2 vezes.

È isso Penguins.

[]s.

Essa é uma rapidinha, só pra acalmar a galera que instalou o Skype no Ubuntu 9.10+ 64 bits e tá vendo a imagem da webcam toda verde… portanto, para os Shreks de plantão, aqui vai a dica para virar príncipe… 😛

Shrek

No atalho do seu skype altere o campo command (comando) de skype para:

env LD_PRELOAD=/usr/lib32/libv4l/v4l2convert.so skype

Pronto, agora a Fiona vai ficar feliz. 😉

[]’s Penguins.

Quem trabalha com TI, mais especificamente na área de Administração de Redes e Sistemas, tem que lidar diariamente com situações críticas e emergenciais para se atender um SLA e manter toda a parafernalha computacional de forma operacional. Para isso, todo Administrador precisa de uma ferramenta de monitoramento. E é aí que entra o Zabbix, na minha opinião, a melhor ferramenta de monitoramento Open Source da atualidade (melhor até do que o também excelente Nagios).

Zabbix Logo

Esse post não vai falar sobre o Zabbix especificamente e sim sobre seu plugin de monitoramento para o Firefox v3.5.0+ (ou superior) chamado Zabbix Bar. Quem sabe em um post futuro eu me aprofunde na ferramenta em si.

O plugin Zabbix Bar original não suporta as versões do Firefox superiores a 3.0, o que acaba sendo incompatível com a grande maioria das máquinas que hoje utilizam o Firefox 3.5 como browser. Foi a partir daí que eu comecei a estudar uma forma de torná-lo compatível com as versões mais recentes do Firefox. E é como diz o velho ditado “A necessidade faz o ladrão”, ou seja, consegui tornar o plugin compatível com as versões 3.5.0+ do Firefox.

Portanto, eis aqui o Plugin Zabbix Bar tão sonhado e esperado por todos.

Zabbix Bar - Configuração

Zabbix Bar - Configuração

Zabbix Bar - Alerta

Zabbix Bar - Alerta

P.S: Já enviei um e-mail para o criador do Zabbix Bar com as alterações. Em breve deve aparecer na página de addos do Firefox.

Abraços Penguins.

Se você é fã da ferramenta de criptografia de dados chamada TrueCrypt e usa o Fedora, você devia sentir falta do pacote compilado disponivel nos repositórios para uma instalação simples e rápida. Isso mesmo, você DEVIA, do verbo não deve mais… agora todos os seus “póbremas se acabaram-se-se”. 😛

O conjunto de repositórios RPMFUSION, largamente utilizado pela comunidade Fedora / CentOS / Red Hat, já possui o TrueCrypt compilado e pronto para usar. Porém, devido aos termos da licença utilizada pelo TrueCrypt, os mantenedores do pacote tiveram que mudar o seu nome e tirar qualquer referência ao nome TrueCrypt do mesmo. Por isso, o correlativo ao TrueCrypt no Fedora fica como RealCrypt, herdando todos os recursos e funcionalidades do original TrueCrypt.

Para instalá-lo no seu Fedora / CentOS / Red Hat, basta adicionar os repositórios RPMFUSION e instalar o pacote com o comando abaixo:

yum install realcrypt

Abraços Penguins

Oi pessoas…

Aqui vai uma dica para quem está utilizando o Fedora 11 e está tendo problemas para utilizar recursos como saída de vídeo para TV, como por exemplo, S-VIDEO. Hoje, ao tentar ligar meu notebook na TV para assistir Fringe, me deparei com um “bug” do novissimo KMS (Kernel Mode Setting), que ainda não tem suporte a placa com saída para TV.

Fedora 11 - Leonidas

Fedora 11 - Leonidas

Bem, depois de muito fuçar, descobri que existe um parâmetro que é passado na string de inicialização do kernel na hora do boot que desabilita o KMS, dessa forma você poderá assistir suas séries, vídeos, etc na sua TV.

Basta você adicionar ao final da linha correspondente ao kernel no seu /etc/grub/menu.lst, ou diretamente no prompt do grub no momento da inicialização, o parâmetro “nomodeset”.

P.S: Tive problemas com o Compiz Fusion utilizando o parâmetro do kernel acima, onde a tela ficou completamente embaralhada… portanto, antes de ativar o parametro do kernel acima, certifique-se de desativar completamente o Compiz Fusion.

Espero que a dica quebre o galho de vocês.

Pronto, agora é só pegar a pipoca com guaraná e curtir o cineminha em casa. 😉

Abraços Penguins.

Semana passada migrei o Data Center da empresa do grupo onde trabalho todo para ambiente virtualizado com Xen Server. Como todo ambiente virtualizado, se faz necessário o uso de uma Storage para armazenar os discos virtuais das máquinas virtualizadas de forma centralizada. Então montei uma storage com CentOS 5.3 x64 compartilhando os arquivos das máquinas virtuais via NFS para os servidores Xen. Toda a migração ocorreu de forma tranquila, mas quando o ambiente foi para produção e o volume de dados cresceu, um bug da placa Realtek modelo RTL8111/8168B  do servidor em questão veio á tona.

CentOS LogoRealtek Logo

Quando a placa de rede atingia um nivel de uso elevado, o erro abaixo era exibido e placa de rede simplesmente parava de responder, onde a única solução era descarregar e carregar o módulo via modprobe.

kernel: r8169: eth0: link down
NETDEV WATCHDOG: eth0: transmit timed out

E isso passou a ocorrer com muita frequência dias após a migração. Em busca de uma solução encontrei um relatório de bug aberto na Red Hat sobre o módulo padrão utilizado para esse modelo da placa Realtek, que é reconhecido como r8169 de forma incorreta. O módulo correto que deve ser carregado deve ser o r8168, mas ele não existe por padrão nos repositórios. Portanto, compilá-lo-emos… 🙂

Para isso, acesse o site com os fontes atualizados dos drivers das placas Realtek aqui, faça o download do arquivo com os fontes para a máquina onde o módulo será compilado e substituido.

Descompacte o arquivo baixado em uma pasta qualquer.

# tar -xvjf r8168-8.012.00.tar.bz2

Remova o módulo errado do modprobe.

# rmmod r8169

Altere o modprobe.conf para reconhecer o módulo que será compilado.

# vim /etc/modprobe.conf

Onde existir alias eth0 r8169, altere para alias eth0 r8168.

Dentro da pasta onde o arquivo foi descompactado, compilar o novo driver e catalogar na lista de módulos do Linux.

# make clean modules
# make install
# depmod -a

Carregar o novo módulo compilado em memória.

# modprobe r8168

Pronto! Basta você reiniciar o serviço de rede ou reconfigurar sua placa com o ifconfig.

Vale ressaltar que a cada atualização de kernel aplicada nesta máquina, este módulo deverá ser recompilado.

Feito isso, storage rodando feito uma mariola. 😉

Espero que os ajudem.

[]’s

kernel: r8169: eth0: link up

Nas últimas semanas tive a missão de implantar diversos servidores virtuais utilizando o XenServer 5 em outra empresa do grupo que trabalho. Até o momento eu não tinha utilizado storage através de NFS para o pool de servidores XenServer 5, pois estava utilizando iSCSI.

XenSource XenServer
XenSource XenServer

Acontece que existe uma discussão rolando nos fóruns internet afora que questiona as vantages do uso de iSCSI em relação ao NFS relacionando performance, flexibilidade e facilidade de implementação… alguns inclusive com ótimos benchmarks.

Baseado nisso eu tentei utilizar NFS para a storage das máquinas virtuais no XenServer. Porém, por um “bug” na configuração do servidor NFS o XenServer não conseguia criar a storage, gerando o seguinte erro:

Error code: SR_BACKEND_FAILURE_74
Error parameters
: NFS unmount error opterr=umount failed with return code 1

Ou então se o umount for tentado diretamente do terminal, o erro seria este:

umount.nfs: 192.168.0.1:/mnt/bkp: not found / mounted or server not reachable

Após analisar a fundo o problema, descobri que o problema não está no XenServer e sim no servidor NFS. Por algum motivo quando você especifica no arquivo de configuração do servidor NFS de sistemas baseados em RHEL (CentOS, Fedora, etc) a versão do protocolo NFS que você quer usar, o servidor gera erros como os acima no momento de desmontar (umount) o diretório.

Para corrigir o problema, basta fazer o seguinte:

1 – Comente as linhas abaixo no seu /etc/sysconfig/nfs.

#MOUNTD_NFS_V1=”no”
#MOUNTD_NFS_V2=”no”
#MOUNTD_NFS_V3=”yes”

2 – Reinicie o serviço do NFS.

# service nfs restart

Feito isso, tente novamente desmontar o diretório NFS e o erro não deverá mais te importunar. 😀

Depois disso consegui criar a minha storage via NFS no XenServer tranquilamente.

Existe um ticket de bug aberto no forum da Citrix exatamente relatando esse problema. Já mandei esse mesmo procedimento pra lá também.

Citrix Forum: NFS error while attempting to unmount the NFS share

Espero que salve a alma de alguém um dia. 🙂

[]’s Penguins.