Arquivo

Textos com Etiquetas ‘Linux’

Monitorando a temperatura do CPD com Digitemp

28 de abril de 2010

Em CPD's com muitos servidores existe a necessidade de constante refrigeração da sala de equipamentos, visto que eles produzem grande quantidade de calor.

Como qualquer outro equipamento, o sistema de refrigeração também podem apresentar problemas, deixando de refrigerar a sala de servidores, o que pode ocasionar o superaquecimento dos mesmos levando-os a falhar e deixar de prestar os serviços de um CPD.

Para estes casos é necessário estar prevenido com, no mínimo, um sistema de controle de temperatura da sala, para que sejam tomadas as providências antes do superaquecimento. Com um sistema de controle também é possível fazer o levantamento estatístico e histórico das falhas de refrigeração, para verificar se é necessário melhorias ou exigir da empresa terceirizada melhor qualidade no serviço de refrigeração.

Em tempos de recessão, programas de redução de custos, e demora na compra de equipamentos novos, fica inviável solicitar à empresa a compra de um sistema monitor de temperatura de ambientes. Nestas horas é necessário se utilizar da criatividade e procurar soluções alternativas.

Nestas condições a Internet é a nossa principal fonte de informação e pesquisa, e o Software Livre a solução para a maioria dos problemas envolvendo custos.

Sensor Dallas DS1820Muitos sites dão informações completas de como construir um sistema de monitoramento de temperatura baseado no sensor Dallas DS18S20  e um software chamado DIGITEMP, e tentarei aqui reproduzir algumas destas informações e instruções de como montar este sistema.

O DIGITEMP é um software desenvolvido para Linux que se comunica com o sensor de temperatura Dallas DS18S20 através da porta serial do computador. Para fazer esta comunicação, é necessário uma interface, que pode ser construída com poucos componentes.

 

Construindo o sensor

 

Existem vários modos de construir a interface, variando de acordo com a distância do cabo e a forma de energizar o circuito. A forma mais simples é o modo parasita, em que a energização do componente se dá através da linha de dados da porta serial.

Para construir a interface serial são necessários os seguintes componentes:

Componentes

A 1 Conector DB9 fêmea com capa
B 1 Placa fenolite de tamanho suficiente para acoplar na capa do conector DB9
C 1 Conector RCA macho
D 1 Conector RCA fêmea
E 1 Resistor 1K5 - 1/4W 
F 1 Sensor Dallas DS18S20
G 1 Diodo Zener 3V9 - 1/4W
H 1 Diodo Zener 6V2 - 1/4W 
I 2 Diodos 1N5819 - 1/4W de alta velocidade

Para o cabo foi utilizado um cabo telefônico comun de duas vias.

Os componentes devem ser montados conforme o esquema abaixo:

Circuito

No modo parasita, é necessário unir os pinos GND e Vdd. Os números no lado da porta serial representam os pinos do conector DB9.

É possível utilizar vários sensores em paralelo, pois cada componente utiliza um identificador único de 64bits, formando um barramento chamada 1-Wire Bus. O esquema abaixo representa vários sensores ligados em paralelo:

Circuito com vários sensores

Antes de soldar os componentes na placa, é interessante montá-los em uma protoboard:

Protoboard

Para montar os componentes na placa, peguei a dica no site Pontas da Madrugada. O desenho na placa de fenolite ficou assim:

Desenho na placa de fenolite

Após soldar os componentes na placa e encaixá-lo no conector DB9, o resultado ficou assim:

Componentes soldados

Componentes soldados lado solda

A solda não ficou esteticamente perfeita, mas o mais importante é não ter nenhum curto-circuito e nenhuma solda fria. O conector RCA fêmea teve que ser reduzido para caber na capa do DB9. A parte externa do conector RCA ficou como GND, e a parte interna, os dados.

O sensor foi soldado em uma extremidade do cabo, e na outra, o conector RCA macho:

Sensor soldado no cabo  Conector RCA soldado no cabo

O resultado final ficou assim:

Kit completo

 

Software para comunicação com o sensor

 

O Digitemp pode ser baixado do site http://www.digitemp.com ou do repositório oficial da distribuição. No debian pode ser baixado com o comando:

#apt-get install digitemp

O próximo passo é criar o arquivo de configuração com o identificador do sensor:

#digitemp_ds9097 -s /dev/ttyUSB0 -i
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Turning off all DS2409 Couplers
.
Searching the 1-Wire LAN
10F2EFF0010800FE : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10F2EFF0010800FE
Wrote .digitemprc

Para obter a temperatura do sensor usa-se o comando:

#digitemp_ds9097 -t0 -c .digitemprc
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Apr 27 22:33:02 Sensor 0 C: 24.25 F: 75.65

 

Traçando gráficos de acompanhamento

 

O pacote do Digitemp fornece alguns scripts para gerar gráficos armazenados em um banco de dados RRD. Utilizando vários sensores pode-se conseguir um resultado como este:

Gráfico RRD

Note que no gráfico os valores estão em Fahrenheit (F), mas pode-se configurar o Digitemp para exibir em Celcius (C).

O Nagios possui alguns plugins para o monitoramento de temperatura, como o check_temperature e o check_digitemp

 

Dificuldades e problemas

 

Para desenvolver este projeto encontrei algumas dificuldades. A primeira delas foi encontrar o sensor Dallas DS18S20 em lojas de eletrônica. As principais lojas em Porto Alegre (Severo Roth, RF, etc) nem sequer tinham este componente no cadastro, ou seja, nunca foi vendido por eles.

Segui a dica de um colega de trabalho (obrigado Ronaldo!) e entrei no site do fabricante Maxim (http://www.maxim-ic.com/) e solicite algumas amostras. Recebi-as em 30 dias. Obrigado Maxim!

Importante: Todos os sites indicavam o sensor DS1820, mas segundo a Maxim ele foi substituido pelo DS18S20, e o que eu recebi foi o DS18S20+, que funcionou perfeitamente.

DS18S20+

A segunda e maior dificuldade foi: O sistema não funcionou no primeiro teste. Nenhuma mensagem de erro era apresentado. Simplesmente o sensor não era lido. Tira componente, testa componente, baixa código fonte, compila código fonte… Muitos sites na internet informam que os notebooks não fornecem a carga necessária de energia na serial para alimentar o sensor, e quase nenhum informa sobre o funcionamento com um adaptador USB-Serial que, no meu caso, tive que utilizar, pois o notebook não tem porta serial. Testei inclusive com uma placa ExpressCard RS232. Nada funcionava. Verifiquei que existem outras formas de construir a interface serial, com componentes extras para gerar alimentação para o circuito, mas não os construí, pois não tinha nenhum desses outros componentes.

Por sorte, testando os componentes na protoboard tive uma surpresa. Notei que quando o pino RXD era plugado na protoboard uns 2 segundo após rodar o programa digitemp, ele conseguia ler os dados. Ótimo sinal!

Após verificar o código-fonte, e incluir uma porção de mensagens de debug, notei que o problema acontecia na inicialização da porta serial, talvez por eu estar utilizando um adaptador USB-Serial.

Procurando novamente por uma solução, encontrei no site http://www.felskowski.pl/ uma correção para um problema de inicialização da porta serial. Testei-o e funcionou. O patch de correção é o seguinte:

--- digitemp-3.6.0.old/userial/ds9097/linuxses.c        2007-06-07 23:25:58.000000000 +0200
+++ digitemp-3.6.0/userial/ds9097/linuxses.c    2009-12-24 04:27:25.000000000 +0100
@@ -55,7 +55,7 @@
SMALLINT owAcquire(int portnum, char *port_zstr)
{
/* Open the serial port */
-   if ((fd[portnum] = open(port_zstr, O_RDWR)) == -1)
+   if ((fd[portnum] = open(port_zstr, O_RDWR|O_NONBLOCK)) == -1)
{
OWERROR(OWERROR_GET_SYSTEM_RESOURCE_FAILED);
perror("owAcquire: failed to open device");

A diretiva 0_NONBLOCK instrui o programa para não ler absolutamente nada da porta serial após abrí-la, como teste de abertura.

 

Informações extras

 

Como informado antes, utilizei um adaptador USB-Serial PL2303 e um cartão ExpressCard RS232 também por coincidência PL2303. Ambos forneciam a porta /dev/ttyUSB0.

 

Referências

 

Muitas sites foram consultados para este projeto. Relaciono-os abaixo:

Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Geral, Linux , , , , , , ,

Erro de segfault ao utilizar arquivo pam_mount.conf.xml de usuário

11 de maio de 2009

O libpam-mount permite que o usuário monte as unidades de rede ao fazer o login, tanto no terminal quando no modo gráfico. Não irei explicar como configurar o serviço ou o arquivo pam_mount.conf.xml, pois uma busca simples no Google fornece vários sites ensinando como fazer isto. Descreverei, portanto, sobre um problema encontrado na versão Lenny (estável) do Debian, e sua solução. Ao utilizar as configurações do arquivo pam_mount.conf.xml do usuário para montar um volume do tipo CIFS, ocorria o seguinte erro no login do usuário:

segfault at 0 ip b7ec29c8 sp bfadf9dc error 4 in libc-2.7.so[b7e50000+13d000]

…e não deixava o usuário completar o login. A versão do libpam-mount que está no repositório do Debian Lenny é a 0.44-1+lenny3, e para corrigir o problema, é necessário utilizar uma versão mais recente do libpam-mount. Não encontrei uma versão compilada para Lenny, mesmo nos backports. Decidi então baixar os fontes de uma versão mais atual e compilar. Utilizei a versão 1.10 disponível nos repositórios do debian (sid ou squeeze). Baixei o arquivo tar.gz, descompactei e executei o comando

./configure --prefix=/usr

Como dependência, precisei instalar o pacote libhx-dev e libssl-dev (do Lenny mesmo). Após isto, foi só executar make; make install. A partir daí não ocorreu mais erro de segfault. Acredito que este problema foi encontrado por poucas pessoas, pois não encontrei nenhuma solução na Internet, somente as reclamações do erro. Fica aí, portanto, uma solução para este problema.

 

Correção em 05/09/2009:

  • É necessário a versão 2.2 da libHX. A versão do lenny é a 1.18. A versão 2.2 está disponível na página do projeto libHX no Sourceforge. Basta baixar o source da versão 2.2 e compilar sem problemas.
  • Também é necessário o pacote libpam0g-dev, mas este está no repositório padrão do Debian.
Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Linux ,

Restringir a pesquisa do Samba/Winbind em domínios locais

11 de maio de 2009

Quando se utiliza o Samba/Winbind para autenticar usuários no AD em ambientes com uma floresta muito grande, a pesquisa pode demorar muito tempo, causando lentidão no serviço e reclamação por parte dos usuários.

Encontrei este cenário na empresa onde trabalho: Quando um usuário quer acessar uma pasta compartilhada em um servidor samba, este servidor procura as credenciais deste usuário em todos os AD’s que possuem relação de confiança na rede inteira, ao invés de procurar somente no servidor AD do domínio que o usuário está cadastrado. Algumas vezes leva mais de um minuto para o usuário acessar o serviço de rede, causando frustração.

Obs.: O comando wbinfo -m lista todos os domínios que possuem relação de confiança na rede.

Quando utilizado o comando wbinfo -u para listar os usuários, aparece uma lista de todos os usuários de todos os domínios da rede. O mesmo acontece para listar os grupos (wbinfo -u).

O desejado é que o winbind busque as credenciais do usuário somente no AD do domínio no qual ele está cadastrado.

Procurei duas possíveis formas de corrigir o problema:

  1. Colocar o AD do domínio do usuário como primeiro na lista de pesquisa
  2. Restringir o domínio de busca.

A primeira opção não trouxe nenhum resultado satisfatório na web, nem nos arquivos de configuração do samba.

Contudo, uma opção no smb.conf chamava a atenção: a opção allow trusted domains. Segundo o man do smb.conf, esta opção serve para restringir a busca pelo usuário somente no domínio onde o serviço está rodando. Por padrão, esta opção é marcada como yes. Contudo, quando configurado para no, nada acontecia, e o comando wbinfo -m continuava listando todos os domínios.

Fazendo mais buscas, encontrei em alguns fórums que a opção allow trusted domains não fazia efeito em algumas versões do Samba.

O servidor da empresa possui instalado a distribuição Centos 5, com a versão 3.0.23 do Samba. Não gosto de utilizar pacotes fora do repositório oficial da distribuição, para não “quebrar” a distribuição e provocar algum “conflito” de pacotes.

Tive duas opções: baixar o fonte do samba e compilar ou então procurar algum repositório com binários do samba atualizados para o Centos 5.

Por uma felicidade, encontrei o repositório SerNet Samba, com binários atualizados do Samba, na versão 3.2.28.

Inseri o repositório na configuração do yum, removi a versão atual do Samba (importante), e instalei a versão do SerNet com suas dependências.

Após iniciar o serviço Samba e Winbind, o comando wbinfo -m passou a listar somente o domínio no qual o servidor estava instalado e configurado, e os comandos wbinfo -u e wbinfo -g retornavam somente os usuários e grupos do domínio local. Os problemas de lentidão acabaram!

Conclusão

Se alguma opção em algum arquivo de configuração não funciona, procure a versão mais atual do programa. Para facilitar a vida do técnico, procure repositórios com pacotes já compilados para sua distribuição, e deixe os gerenciadores tipo Yum e Apt-get fazer o trabalho de resolver e baixar as dependências.

Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Linux , ,

Programando para PalmOS no Linux utilizando o Eclipse

31 de março de 2009

Quando comecei a escrever este post, me perguntei: -Alguém ainda programa para PalmOs??

Não sei, mas descrevo aqui como construir um ambiente de programação para PalmOS no Linux amd64, utilizando o Eclipse. Encarei isto como um desafio, visto que a Access não dispobilizou um PODS para Linux, preferindo “emular” o compilador no windows utilizando o Cygwin (que barbaridade!).

Uma particularidade desta configuração é o fato da versão do Linux ser para processadores amd64. Como não existe prc-tools para amd64, devemos configurar um ambiente “chroot” para abrigar a versão 32bits do prc-tools e compilar os projetos. O ambiente de desenvolvimento permanece 64 bits, com o Eclipse e o Guikachu (criação dos forms).

Primeiro passo: Instalar o Eclipse.

Eu estou usando o Ganymede, versão 3.4, último disponível na data que baixei. Instale como preferir, baixando do site ou via ferramenta de instalação de pacotes da sua distribuição. Baixando pelo site é possível escolher a versão já configurada para programação C/C++ (CDT). Se instalar pelo instalador de pacotes da distribuição, é necessário instalar o ambiente CDT através da opção Software Update no menu Help do Eclipse.

Segundo Passo: Instalar o Guikachu

O Guikachu (http://gergo.erdi.hu/projects/guikachu/) é um programa para criação de formulários (interface visual) das aplicações para PalmOS. Como não encontrei uma versão compilada da minha distribuição (Debian Lenny), baixei os fontes da versão 1.5.11, descompactei e compilei (./configure –prefix=/usr, make, make install). Nesta parte encontrei uma dificuldade que descrevi no post Erros de compilação ao utilizar o gcc-4.3.

Terceiro Passo: Configurar o ambiente chroot 32 bits

Como descrevi no início do post, não encontrei uma versão do prc-tools para 64bits, então tive que configurar um ambiente chroot 32bits para poder compilar os projetos. A solução para este problema eu encontrei no artigo Solution to prc-tools on AMD64 and other 64-bit machines. Não vou descrever todo o processo, mas coloco os comandos para criar o ambiente. Para quem já tem um ambiente chroot, pule direto para a instalação do prc-tools.

#apt-get install chroot schroot
#chroot /var/chroot/debian_32/

dentro do ambiente chroot:

#vi /etc/apt/sources.list

alterar a linha:

deb http://ftp.debian.org/debian/ sarge main

para

deb http://ftp.debian.org/debian/ sarge main contrib non-free

atualizar a fonte de pacotes

#apt-get update

instalar o prc-tools:

#apt-get install apt-file prc-tools pilrc

Poderão aparecer algumas mensagens relacionadas ao Locale. Para corrigir isto, edite o .bashrc do root, inserindo a linha:

export LC_ALL=C

Feito isto, podemos executar um comando 32bits a partir do ambiente 64bits, utilizando o comando schroot:

#schroot -c debian_32 -p /usr/bin/file /bin/bash

É assim que o projeto será compilado dentro do chroot a partir do Eclipse. Veremos como mais adiante, com a criação de um arquivo Makefile.

Eu precisei configurar o schroot para permitir que o meu usuário acessasse o ambiente chroot. Edite o arquivo /etc/schroot/schroot.conf e inclua as linhas:

[debian_32]
description=Debian sarge 32bits (stable)
location=/var/chroot/debian_32bit
priority=2
#groups=sbuild
users=gerson #coloque seu usuario aqui
root-users=gerson #coloque seu usuario aqui
aliases=stable

Quarto Passo: Instalar o PalmOS SDK do site da Access Developer Network

Baixe o SDK deste link (é necessário registrar-se). Baixe os seguintes arquivos:

- Garnet OS SDK (68K) R3 PRC tools Generic UNIX

- Garnet OS 68K API SDK (Fall 2004 Update). Este segundo deve ser copiado por cima do arquivo anterior (após descompactá-los, claro). Importante: este arquivo possui como final de linha <CR><LF>, causando problemas ao compilar. É necessário converter os arquivos para <LF>, com o seguinte comando:

#find . -type f -exec dos2unix {} \;

(O programa dos2unix faz parte do pacote sysutils;)

Coloque o SDK em uma pasta dentro do ambiente chroot. Ex.: /var/chroot/debian_32/var/PalmOS_SDK. Dê as permissões necessárias para que todos os usuários possam ler os arquivos:

#chmod o+r -R /var/chroot/debian_32/var/PalmOS_SDK

Entre no ambiente chroot:

chroot /dev/chroot/debian_32

prepare o ambiente de compilação:

#palmdev-prep /var/PalmOS_sdk/

saia do ambiente chroot:

#exit

Quinto Passo: Configurando o Eclipse

O workspace do eclipse deve ficar em uma pasta visível pelo chroot debian_32. No meu caso, o workspace está em /var/chroot/debian_32/home/gerson/workspace.

Como projeto exemplo, HelloDiesel, criei uma organização de pastas da seguinte maneira:

hellodiesel

A pasta includes aparece após configurar o projeto: Botão direito do mouse no nome do projeto -> Properties -> C/C++ General -> Paths and Symbols -> aba Includes -> botão Add -> inserir o caminho /var/chroot/debian_32bit/var/PalmOS_sdk/sdk-5r4/include, marcar todas as caixas de opção -> Ok -> Ok. Observe que tenho uma pasta sdk-5r4 abaixo da pasta palmOS_SDK. Ajuste na sua configuração.

Sexto passo: O arquivo Makefile

Esse é o cara que irá chamar o compilador dentro do chroot 32bits a partir do ambiente 64 bits. De barbada coloco aqui o Makefile inteiro:

SCHROOT = schroot -c debian_32 -d /home/gerson/workspace/HelloDiesel --
SCHROOT_BUILD = schroot -c debian_32 -d /home/gerson/workspace/HelloDiesel/build --
PROGNAME = AppMain
APPNAME = 'Hello Diesel'
RESOURCES = src/AppResources
APPID = GHDx
OBJS = build/$(PROGNAME).o
#FLAGS = -O2 -Wunused -Wall -palmos3.1
FLAGS = -O2 -Wunused -Wall

all: clean resources grc
$(SCHROOT) build-prc dist/$(PROGNAME).prc $(APPNAME) $(APPID) build/*.grc \
                                                    build/resources/*.bin

grc:
$(SCHROOT) m68k-palmos-gcc $(FLAGS) -c src/$(PROGNAME).c -o $(OBJS)
$(SCHROOT) m68k-palmos-gcc $(FLAGS) $(OBJS) -o build/$(PROGNAME)
$(SCHROOT_BUILD) m68k-palmos-obj-res $(PROGNAME)

resources: forms
pilrc -H src/AppResources.h rsc/$(PROGNAME).rcp build/resources/

forms:
guikachu2rcp rsc/$(PROGNAME).guikachu

clean:
rm -f build/*.[oa]
rm -f build/*.bin
rm -f build/*.grc
rm -f src/*~
rm -f build/$(PROGNAME)
rm -f dist/*
rm -f rsc/*.rcp
rm -f build/resources/*

Após compilar, o arquivo .prc deve aparecer na pasta DIST. Aí é só sincronizar e testar no Palm.

Opção:  Testar em emulador/simulador

Caso queira testar a aplicação em um emulador ou simulador, pode-se utilizar o POSE (Palm OS Emulator), ou então utilizar o PalmOS Simulator através do wine e utilizar a rom do TX disponível pela web.

Conclusão

Acho que com o fim anunciado do PalmOS, a Access não irá liberar uma versão do PODS para Linux. Além do mais, muitos programadores já estão correndo atrás de um SDK para o WebOS, novo sistema da Palm/Access.

Contudo, para aqueles que ainda desejam programar para o PalmOS (que acredito que levará um tempo para se “dissolver”) no Linux, fica aí este guia para construir um ambiente de programação.

Abraços e até a próxima.

Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Geral, Linux, Palm , , , ,

PODS (Palm OS Developer Suite) no Linux

28 de março de 2009

Quando eu quis começar a programar para PalmOS, me deparei com um problema: Todos os kits de desenvolvimento RAD (Rapid Aplication Development) para PalmOs eram para Windows. Não encontrei nenhum para Linux.

Quando eu baixei o PODS (Palm Os Developer Suite) do site da Access (atual desenvolvedora da Palm), vi que o mesmo era baseado no Eclipse para windows, e que utilizava as ferramentas de compilação dentro do Cygwin. A Access comunicava em seu site que um dia iria disponibilizar o PODS para Linux. Fiquei esperando e nada. E com o fim anunciado do PalmOs, acho que nem vão lançar mais.

Então eu pensei: Caramba! Se o Eclipse para Windows e Linux são o mesmo (com uma compilação própria para cada sistema, claro), e o PODS utiliza o Cygwin para rodar o compilador de .prc, então não deve ser muito difícil fazer um PODS para Linux.

O PODS não é nada mais que o prc-tools do Linux rodando no Cygwin, utilizando o Eclipse 3.0.1 com CDT com alguns wizards para criação de aplicações e o SDK para PalmOs também disponível no site da Access.

Para criar um “PODS” para Linux não é muito difícil. Deve-se ter o Eclipse instalado com CDT, baixar o PalmOS SDK do site da Access (deve-se estar registrado no Access Developer Netword) e instalar o prc-tools. Para criação das “telas”, recomendo utilizar o Guikachu, e instalar o pilrc da distribuição (como uso Debian - apt-get install pilrc) para compilar os “resources”.

Não lembro exatamente todos os passos para configurar esta ambiente, pois faz alguns meses que o preparei (quem mandou não anotar), mas como estou refazendo o ambiente novamente, em outro post faço um passo-a-passo para configurar um “PODS” no linux.

Um abraço e até o próximo

Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Geral , , , , ,

Plucker + Linux = jornal diário

16 de março de 2009

Quando comecei a ler e-books no Palm, fiquei imaginando se existiria uma forma de converter páginas HTML em um formato que pudesse ser lido no mesmo, que pudesse buscar páginas na Internet e convertê-las automaticamente, mantendo-me atualizado, mais ou menos como um leitor de RSS. Queria esta praticidade para ter “o que fazer” no ônibus durante a viagem do trabalho para casa.

Durante uma busca, descobri o Plucker, que é capaz de fazer o máximo de esforço para converter uma página HTML em um arquivo .pdb para ser lido no Plucker “viewer” do Palm OS. Comecei testando seu uso na linha de comando e no Plucker Desktop, uma ferramenta gráfica para configuração do mesmo. Percebi que as possibilidades de uso na linha de comando eram muito maiores, então arregacei as mangas e me atirei no bash.

Utilizando “um punhado” de scripts, consegui deixar o Plucker configurado do jeito que eu queria, com os mais variados tipos de conteúdo, entre sites de notícias, diversão, gráficos da bolsa, previsão do tempo e cardápio da empresa (isto mesmo, cardápio), criando assim o meu “jornal diário”.

É possível montar uma página inicial personalizada e apontar as restantes com links, utilizando HTML puro e simples.

Coloquei algumas telas personalizadas, e ao final disponibilizo os scripts que utilizo, para quem quiser incrementar e personalizar o seu próprio “jornal diário”.

Menu principal

Menu principal

Menu principal

Menu principal

Notícias Linux

Notícias Linux

Daily Strips

Daily Strips

Malvados e Níquel Náusea

Malvados e Níquel Náusea

Pagando o Pato

Pagando o Pato

Gráficos da bolsa

Gráficos da bolsa

Previsão do tempo

Previsão do tempo

Cardápio da semana

Cardápio da semana

Instruções para utilizar os scripts:

  1. Descompactar o arquivo plucker no seu diretório $HOME
  2. Renomear o diretório plucker para .plucker
  3. Copiar o arquivo $HOME\.plucker\pluckerrc para $HOME\.pluckerrc
  4. Criar a seguinte entrada no crontab:

16 * * 1-5 /home/<usuario>/.plucker/atualizaPlucker.sh     >/dev/null 2>&1

No exemplo acima, o script roda de segunda à sexta, às 16 horas.

Obs.: Os scripts não possuem mecanismos para ser multiusuários, ou seja, os caminhos das pastas do usuário estão hard coded nos scripts. É necessário editá-los e ajustar os paths.

O processo todo gera o arquivo $HOME\.plucker\Noticias.pdb, com um tamanho de aproximadamente 10mb devido às figuras. Para transferir o arquivo para o Palm, utilize o comando:

/usr/bin/pilot-xfer -p /dev/pilot -i ~/.plucker/Noticias.pdb -D Palm/Programs/Plucker

Obs.: O arquivo deve ser copiado para a pasta Palm/Programs/Plucker no cartão para que o Plucker liste o arquivo em sua biblioteca.

Como funciona:

  1. O script atualizaPlucker.sh chama o “parser” do plucker
  2. O parser lê o arquivo de configuração ~/.pluckerrc
  3. O arquivo de configuração possui a instrução que chama o script formata_noticias.sh
  4. O parser utiliza o arquivo home.html para gerar a página inicial do documento
  5. O arquivo ~/.plucker/Noticias.pdb é gerado

Conclusão:

O Plucker é uma ótima ferramenta para você criar o seu jornal diário, com o conteúdo que você quiser. No começo é um pouco difícil entender o seu funcionamento, mas depois de alguns testes você pega o jeito. Utilizando a linha de comando (bash) para configurar o Plucker, as possibilidades para você criar o documento do jeito que você quiser são muito maiores.

Bom divertimento!

Compartilhe:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitthis
  • blogmarks
  • email
  • Faves
  • Netvibes
  • Reddit
  • Technorati
  • LinkedIn
  • MySpace
  • RSS
  • Slashdot

Gerson Diesel Geral , , , ,

Easy AdSense by Unreal