[Rio-pm] Configuração de usuário não root no cpan & Perl Roll em Rocks Cluster
Blabos de Blebe
blabos em gmail.com
Quinta Janeiro 30 12:51:17 PST 2014
Mais ou menos...
> Ou melhor, o certo é saber o que você esta fazendo e como as coisas
funcionam!
Se todos os scripts usam o shebang #!/usr/bin/perl, qualquer um que não
invocar um terceiro usando 'perl script.pl' vai cair no shebang do script.
O melhor mesmo é trocar todos os shebangs por #!/usr/bin/env perl
2014-01-30 Renato Santos <renato.cron em gmail.com>
> Se o script perl chamar outro script com `perl foobar` (que vai chamar o
> /bin/sh) vai iniciar executar o proximo script com o perl que esta no env,
> ou seja, o PATH.
>
> Se for `./foobar.pl` isso vai executar o shebang, ou seja, o __melhor é
> sempre__ passar o do env.
>
> Ou melhor, o certo é saber o que você esta fazendo e como as coisas
> funcionam!
>
>
> 2014-01-30 Aureliano Guedes <guedes_1000 em hotmail.com>:
>
> Mas na bioinfo, pelomenos os mais ou menos experientes fazem modulos
>> mesmo. Acontece que eventualmente algumas analises feitas em servidores
>> potentes demoram 2 dias. Entao, ja teve caso de nao ter muita saida e fazer
>> um script para executar outros de acordo com o resultado e progresso da
>> analise. Uma comparacao entre resultados de 5000 individuos com toda
>> biblioteca de miRNA entre miRNAnda e RNAhybrid depois filtrar os resultados
>> e desenhar o sitio de ligacao evidenciando os resultados semelhantes e
>> discriminando os demais, sem saida, foi script executando script. O que foi
>> possivel trabalhar com modulos foi feito.
>>
>>
>> Blabos de Blebe <blabos em gmail.com> escreveu:
>>
>> > e também vem com o CPAN, que o do sistema não vem.
>>
>> Um Perl que vem sem CPAN? WTF? Pode isso Arnado?
>>
>> ...
>>
>> Ok, pode ter algum complicador ou outro...
>>
>> O perlbrew é utilizado para instalar uma versão local do Perl, sem
>> requisitar premissões de usuários, ou seja, o binário do Perl + diretórios
>> de bibliotecas, ficam no home do usuário.
>>
>> Com ele você pode alternar entre várias versões Perl e ele ainda cuida
>> da instalação e localização de libs com o comando cpanm. Tudo isso sem
>> incomodar o administrador.
>>
>> Vocês utilizam scripts de terceiros? ok, veja esse exemplo:
>>
>> Script:
>>
>> #!/usr/bin/perl
>>
>> print 'Foo: ' . $] . $/;
>>
>>
>> Executando:
>>
>> $ ./foo.pl
>> 5.016002
>>
>> $ perl foo.pl
>> 5.018002
>>
>> Notou que a segunda forma executa com o perl do meu ambiente, ignorando
>> o shebang?
>>
>> Só complica se um script executar outro, mas de qualquer forma, você
>> sempre pode trocar o shebang para:
>>
>> #!/usr/bin/env perl
>>
>>
>>
>> ***
>>
>> A recomendação que a gente costuma dar é "nunca mexa no Perl do
>> ambiente", porque entre outras coisas, scripts de inicialização do SO
>> dependem dele e se vc bagunçar aí, seu sistema não boota.
>>
>> Além disso, sistemas Apple e Fedora são famosos por terem uma péssima
>> compilação do Perl, com problemas de performance e bugs que já foram
>> corrigidos mas não aplicados na "versão deles".
>>
>> Há uns 5 anos, usar o Perl padrão do sistema e instalar local::lib era
>> o mais indicado. Hoje, a menos que o seu usuário não tenha acesso a um
>> compilador, o que no caso eu duvido, a melhor opção tende a ser perlbrew.
>>
>> Pode ser que no seu caso específico, tenha um detalhe ou outro, mas não
>> me parece tão problemático.
>>
>> Quanto a módulos especiais, a menos que sejam alguma coisa proprietária
>> e não estejam acessíveis via cpan, você também pode instalá-los.
>>
>> Eu sei que Bioinformática é bem diferente de computação em geral, mas
>> se vocês puderem, ao invés de criar scripts que rodam scripts, tentem criar
>> módulos, ou seja, bibliotecas, que são chamados em um pequeno script.
>>
>> É um investimento bobo, que ajuda a resolver uma porrada de problemas e
>> a diminuir o tempo que você gasta montando o seu ambiente.
>>
>> ***
>>
>> Quanto a replicação para os nós, tem várias opções também desde
>> empacotadores até a distribuição com git.
>>
>> []'s
>>
>>
>>
>>
>>
>> 2014-01-30 Aureliano Guedes <guedes_1000 em hotmail.com>
>>
>> Nicole, nunca fui no x-meeting, mas gostaria. Agora se voce fala que a
>> bioinfo esta lotada de mulher, amem senhor, mande umas pra goiania. Hahaha.
>> Eu tbm sou paranoico quanto a modificar o perl do sistema. Eu prefiro o
>> perlbrew. Apesar de que 2 de 5 vezes que configurei o perlbrew deu problema.
>> Mas essa taxa da erro de configuracai do perlbrew de 40% e compativel com
>> minha taxa de erros por falta da atencao na hora de programar.
>>
>> Tiago Peczenyj <tiago.peczenyj em gmail.com> escreveu:
>>
>> eu não gosto de alterar o perl do sistema.
>>
>> mas posso estar sendo paranoico.
>>
>>
>> 2014-01-30 Nicole Scherer <bionica2007-perl em yahoo.com>
>>
>> Oi Blabos,
>>
>> Pelo que entendi, o perlbrew (que deve ser fabuloso) cuida de novas
>> instalações, tanto locais, quando no sistema, caso seja de interesse do
>> admin.
>> No meu caso específico, já tenho uma outra versão de perl, instalada
>> pelo Rocks em /opt/perl e disponível para todos os nós do cluster. Esse
>> "Perl Roll" já vem com alguns módulos especiais para cluster e para
>> bioinformática, e também vem com o CPAN, que o do sistema não vem. O meu
>> objetivo é preparar o cluster de tal forma, que os usuários possam utilizar
>> esta versão bombada do Perl sem ter que brigar comigo :-)
>> Minha primeira ideia era colocar o /opt/perl/bin no início do $PATH de
>> todo mundo, forçando para ser o perl padrão, mas fiquei com receio de que
>> algum programa do sistema RHEL6 dependesse da instalação do fabricante.
>> Estou nesse dilema porque é uma máquina de uso compartilhado. Tenho receio
>> de colocar no $PATH e o usuário ter problemas porque os scripts que usa tem
>> shebang #!/usr/bin/perl e sejam chamados como executáveis. (Em
>> bioinfomática usamos muitos scripts feitos por terceiros).
>> Claro que se o usuário quiser usar o perlbrew, ele pode, mas não poderá
>> usar o curl para fazer isto, pois a máquina está configurada para não
>> acessar a internet. Para o CPAN criei um mirror local.
>>
>> Sei lá, devo estar fazendo tempestade em copo d'água. Tenho é que
>> deixar tudo isso bem claro no guia do usuário e deixar que eles decidam.
>>
>> Obrigada!!!
>> Nicole
>>
>>
>>
>> Em Quinta-feira, 30 de Janeiro de 2014 12:12, Blabos de Blebe <
>> blabos em gmail.com> escreveu:
>> Pessoal,
>>
>> O perlbrew não ajudaria não?
>>
>> Porque ele já cuida automagicamente de toda a complicação.
>>
>> Seriam apenas os comandos:
>>
>> $ curl -L http://install.perlbrew.pl | bash
>> $ echo "source ~/perl5/perlbrew/etc/bashrc" >> .bashrc
>> $ perlbrew install perl-5.18.2
>> $ perlbrew switch perl-5.18.2
>> $ perlbrew install-cpanm
>> $ cpanm My::Incredible::Module
>>
>>
>> []'s
>>
>>
>>
>>
>>
>> 2014-01-30 Stanislaw Pusep <creaktive em gmail.com>
>>
>> Isso mesmo; na primeira vez em que "perl -Mlocal::lib" roda ele cria os
>> diretórios necessários. Se salvar as variáveis de ambiente, não precisa
>> rodar nunca mais.
>> Entretanto, as variáveis serão diferentes para cada usuário. Para
>> melhorar a automação, basta colocar no final do /etc/profile (sim, o do
>> sistema): "eval $(perl -Mlocal::lib)". Desse jeito os usuários
>> automagicamente terão local::lib configurado ao fazer o login :)
>>
>>
>> 2014-01-30 Nicole Scherer <bionica2007-perl em yahoo.com>
>>
>> Obrigada, Stanislaw!
>>
>> Então o usuário só precisará rodar o "perl -Mlocal::lib" uma única vez e
>> colocar este output no .bashrc ou .profile, certo? Tendo feito isso, ele
>> nunca mais precisará invocar o local::lib, ou terá que fazer isto toda vez
>> que for instalar novos pacotes? Com as variáveis de ambiente definidas
>> ainda preciso do local::lib?
>>
>> Abraços,
>> Nicole
>>
>>
>>
>>
>> Em Quinta-feira, 30 de Janeiro de 2014 11:06, Stanislaw Pusep <
>> creaktive em gmail.com> escreveu:
>> Olá Nicole! O processo que eu descrevi é o de bootstrapping; se o
>> Perl do seu /opt/perl já tiver local::lib instalado como root, não precisa
>> dessa etapa.
>> O que acontece se você rodar "perl -Mlocal::lib"?
>> Aqui, por exemplo, aparece:
>>
>> PATH="/Users/stas/perl5/bin${PATH+:}$PATH";
>> export PATH;
>> PERL5LIB="/Users/stas/perl5/lib/perl5${PERL5LIB+:}$PERL5LIB";
>> export PERL5LIB;
>>
>> PERL_LOCAL_LIB_ROOT="/Users/stas/perl5${PERL_LOCAL_LIB_ROOT+:}$PERL_LOCAL_LIB_ROOT";
>> export PERL_LOCAL_LIB_ROOT;
>> PERL_MB_OPT="--install_base \"/Users/stas/perl5\"";
>> export PERL_MB_OPT;
>> PERL_MM_OPT="INSTALL_BASE=/Users/stas/perl5";
>> export PERL_MM_OPT;
>>
>> Se você colar o output produzido no seu sistema para o
>> .bashrc/.profile, o Perl "se sentirá em casa" no $HOME :)
>> O cpanminus é opcional; única coisa absolutamente necessária é que "perl
>> -Mlocal::lib" seja rodado para inicializar o $HOME/perl5, e que as
>> variáveis de ambiente estejam definidas do jeito que o "perl -Mlocal::lib"
>> diz.
>>
>>
>> 2014-01-30 Nicole Scherer <bionica2007-perl em yahoo.com>
>>
>> Obrigada Stanislaw e Aureliano!
>>
>> Aureliano, a bioinformática está tomada por mulheres :-) Já foste no
>> X-Meeting?
>>
>> Stanislaw,
>>
>> como gestora do cluster, meu objetivo é deixar para o usuário o sistema
>> pronto para que ele possa instalar seus módulos localmente sem ter que
>> fazer acrobacias. Eu já instalei o local::lib no sistema como root, então
>> não seria necessário que o usuário instalasse novamente, correto? Ou ele
>> precisaria fazer sua própria instalação?
>>
>> Quando o usuário faz sua primeira incursão no cpan e realiza a
>> configuração, aparece a seguinte mensagem:
>>
>>
>> ---------------------------------------------------------------------------------------------------------------
>> local::lib is installed. You must now add the following environment
>> variables
>> to your shell configuration files (or registry, if you are on Windows) and
>> then restart your command line shell and CPAN before installing modules:
>>
>>
>> Would you like me to append that to /home/hpcst06/.bashrc now? [yes]
>>
>>
>> ---------------------------------------------------------------------------------------------------------------
>>
>> Porém, como podes ver, o "following environment variables" está vazio e
>> nenhuma modificação é feita no .bashrc
>>
>> Esta etapa é que deveria definir as tais variáveis de ambiente. Não
>> entendo por que não está funcionando.
>> Desta forma, a única solução seria mesmo acrescentar estas linhas ao
>> .profile a força.
>>
>> Uma opção que tenho é criar toda a árvore de diretórios do perl e do cpan
>> e colocar no /etc/skel para ser criada junto com o usuário, mas talvez isso
>> seja demais, não?
>>
>> Qual o objetivo de instalar o App::cpanminus?
>> A partir daí o usuário deve usar cpanm ao invés de cpan?
>>
>> Outra dúvida, se eu não instalar o local::lib nos nós do cluster (só
>> instalei no frontend), pode dar problema na hora de executar os programas
>> em paralelo? Digo, o local::lib só é chamado na instalação de módulos e na
>> configuração do ambiente local, não é usado na execução dos módulos, certo?
>> O home do usuário é montado em cada nó durante a execução, então o perl vai
>> executar com as variáveis de ambiente já definidas pelo usuário, então não
>> vai precisar executar o local::lib, certo?
>>
>>
>> Obrigada pela ajuda!
>>
>>
>> Abraços,
>> Nicole
>>
>>
>> Em Quinta-feira, 30 de Janeiro de 2014 8:38, Aureliano Guedes <
>> guedes_1000 em hotmail.com> escreveu:
>> Caraca. Complexo.
>> O melhor, foi ver a pela primeira vez uma mulher na bioinformatica.
>> Hello colega bioinformata.
>>
>> Stanislaw Pusep <creaktive em gmail.com> escreveu:
>>
>> Olá Nicole!
>> Já passei por situação semelhante à sua, quando não podia atualizar o
>> Perl default do sistema e a opção foi instalar um Perl mais atualizado
>> avulso no /usr/local. Para sempre usar o Perl do /usr/local, 3 medidas
>> foram tomadas:
>>
>> 1. export PATH=/usr/local/bin:$PATH
>>
>> 2. Os shebangs de todos os scripts executáveis do projeto foram
>> modificados de:
>>
>> #!/usr/bin/perl
>>
>> para:
>>
>> #!/usr/bin/env perl
>>
>> 3. local::lib foi utilizado para CPAN "desovar" no $HOME. O local::lib
>> requer uma intervenção do .profile do sistema, para inicializar o
>> environment apropriadamente. Seguem os passos para instalar o local::lib
>> dessa forma.
>>
>> 3.1. Download do local::lib:
>>
>> $ wget
>> http://cpan.metacpan.org/authors/id/H/HA/HAARG/local-lib-2.000004.tar.gz
>> $ tar xzvf local-lib-2.000004.tar.gz
>> $ cd local-lib-2.000004/
>>
>> 3.2. Instalação do local::lib:
>>
>> $ perl Makefile.PL --bootstrap=$HOME/perl5
>> $ make
>> $ make test
>> $ make install
>>
>> 3.3. Ativando local::lib na inicialização da shell (Bash):
>>
>> $ cat << PROFILE >> $HOME/.profile
>> eval \$(perl -I\$HOME/perl5/lib/perl5/ -Mlocal::lib)
>> PROFILE
>> $
>>
>> A idéia aqui é que rodar "perl -I$HOME/perl5/lib/perl5/ -Mlocal::lib"
>> retorna para STDOUT as tais das variáveis de ambiente que fazem o Perl
>> buscar instalação dos módulos em um lugar específico ($HOME). Pode
>> simplesmente colar essas variáveis direto no .profile, ou (como demonstrado
>> acima) rodar eval do output do Perl.
>>
>> 3.4. Carregar a configuração:
>>
>> . $HOME/.profile
>>
>> 3.5. Prosseguindo com a configuração/teste do CPAN e do cpanm (essa
>> configuração faz as dependências serem instaladas automaticamente):
>>
>> $ cpan
>>
>> cpan[1]> o conf prerequisites_policy follow
>> cpan[2]> o conf commit
>> cpan[3]> install App::cpanminus
>> cpan[4]> quit
>>
>> Boa sorte!
>>
>>
>> 2014-01-29 Nicole Scherer <bionica2007-perl em yahoo.com>
>>
>> Boa tarde, queridos Mongers,
>>
>> eu não queria importuná-los com problemas simples, mas após três dias
>> batendo a cabeça e vasculhando fóruns na internet sem solução para algumas
>> das perguntas, recorro a vocês. Vou tentar explicar a novela.
>>
>> Montamos um cluster HPC para pesquisa usando o Rocks 6.1 (
>> http://www.rocksclusters.org/) -- um tipo de linux que instala outro
>> linux em todos os nós do cluster e gerencia tudo isso. Novidade pra mim,
>> mas funciona. Esse Rocks instala os chamados Rolls, entre eles o próprio SO
>> (neste caso o RHEL6) e outros Rolls úteis, como SGE, Ganglia, Web-Server,
>> Bio, Perl (4.14.2) entre outros. Estes Rolls são instalados em /opt/ e as
>> vezes coexistem com os binários do SO. Desta forma, tenho duas versões de
>> Perl:
>>
>> - a do sistema (RHEL6):
>> $ /usr/bin/perl -v
>> This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
>>
>> - e a do Rocks:
>> $ /opt/perl/bin/perl -v
>> This is perl 5, version 14, subversion 2 (v5.14.2) built for
>> x86_64-linux-thread-multi
>>
>> Cada qual com as suas bibliotecas.
>>
>> @INC:
>> /usr/local/lib64/perl5
>> /usr/local/share/perl5
>> /usr/lib64/perl5/vendor_perl
>> /usr/share/perl5/vendor_perl
>> /usr/lib64/perl5
>> /usr/share/perl5
>> .
>> @INC:
>> /opt/perl/lib/site_perl/5.14.2/x86_64-linux-thread-multi
>> /opt/perl/lib/site_perl/5.14.2
>> /opt/perl/lib/5.14.2/x86_64-linux-thread-multi
>> /opt/perl/lib/5.14.2
>> .
>>
>>
>> Agora é que começam meus problemas...
>>
>> Primeiro: Alguém já teve experiência com duas instalações coexistentes
>> de Perl? Posso ter problemas de funcionamento no SO se eu mover o
>> /usr/bin/perl e criar um link do /opt/perl/bin/perl para /usr/bin/perl
>> (uma vez que as shebang dos scripts costuma ter este endereço). Colocar
>> simplesmente /opt/perl/bin no início do $PATH pode não ser a solução.
>>
>>
>> O CPAN só está instalado na versão do Rocks, o que me motiva mais a
>> deixá-lo como default.
>> Como a maioria dos usuários não terão privilégios de root e além disso,
>> qualquer instalação no sistema operacional tem que ser espelhada para todos
>> os nós, a melhor opção para instalar pacotes é na home dos usuários,
>> concordam? Então eu quero deixar tudo o mais fácil possível para que os
>> usuários instalem os pacotes desejados. Como não teremos acesso direto à
>> internet usei o minicpan para criar um mirror em uma pasta compartilhada
>> com minha máquina local. Configurei o urllist do cpan pra ela e ficou tudo
>> ok.
>> Agora esbarrei em um problema que não estou achando resposta fácil.
>>
>> Quando executo o cpan pela primeira vez como usuário comum, da forma
>> mais automática possível, ele cria, como esperado o arquivo MyConfig.pm e
>> toda a estrutura de diretórios no home do usuário. Ele executa quase tudo
>> com perfeição, substituindo o endereço default pelo do usuário em QUASE
>> todos os itens, menos em prefs_dir.
>>
>> [hpcst06 em crab ~]$ grep cpan .cpan/CPAN/MyConfig.pm
>> 'build_dir' => q[/home/hpcst06/.cpan/build],
>> 'cpan_home' => q[/home/hpcst06/.cpan],
>> 'histfile' => q[/home/hpcst06/.cpan/histfile],
>> 'keep_source_where' => q[/home/hpcst06/.cpan/sources],
>> 'prefs_dir' => q[/export/cpan/cpan/prefs],
>>
>>
>> (O default cpan_home é /export/cpan/cpan )
>> [hpcst06 em crab ~]$ grep cpan /opt/perl/lib/5.14.2/CPAN/Config.pm
>> 'build_dir' => q[/export/cpan/cpan/build],
>> 'cpan_home' => q[/export/cpan/cpan],
>> 'histfile' => q[/export/cpan/cpan/histfile],
>> 'keep_source_where' => q[/export/cpan/cpan/sources],
>> 'prefs_dir' => q[/export/cpan/cpan/prefs],
>>
>>
>> Claro que o usuário pode executar
>> >o conf prefs_dir /home/hpcst06/.cpan/prefs
>> para alterar esta variável, mas concordam que deveria ter sido
>> automático.
>> Alguém já passou por isto?
>>
>> Procurei o erro em FirstTime.pm, mas não consegui localizar algo que me
>> chamasse a atenção.
>> Exatamente igual ao que tenho no Ubuntu, e que funciona normalmente.
>>
>>
>> - Tendo corrigido manualmente o prefs_dir, segui tentando instalar
>> localmente algum pacote.
>> Aí eu admito uma grande falta de conhecimento da minha parte, mas tentei
>> entender o que os tutoriais na internet e fiquei perdida. Devo usar direto
>> o cpan? (já que na configuração ele me pergunta se eu quero que use
>> local::lib)
>> What approach do you want? (Choose 'local::lib', 'sudo' or 'manual')
>> [local::lib]
>> Ou devo usar sempre
>> $ perl -MCPAN -Mlocal::lib -e 'CPAN::install(Acme::Time::Baby)'
>> ?
>> (tudo bem, posso colocar esta linha no tutorial, vai assustar os
>> usuários, mas funciona)
>>
>>
>> - Rodando
>> [hpcst06 em crab ~]$ perl -MCPAN -Mlocal::lib -e
>> 'CPAN::install(Acme::Time::Baby)'
>>
>> - deu tudo certo.
>> [...]
>> Result: PASS
>> ABIGAIL/Acme-Time-Baby-2010090301.tar.gz
>> /usr/bin/make test -- OK
>> Running make install
>> Prepending
>> /home/hpcst06/.cpan/build/Acme-Time-Baby-2010090301-wJGXda/blib/arch
>> /home/hpcst06/.cpan/build/Acme-Time-Baby-2010090301-wJGXda/blib/lib to
>> PERL5LIB for 'install'
>> Installing /home/hpcst06/perl5/lib/perl5/Acme/Time/Baby.pm
>> Installing /home/hpcst06/perl5/man/man3/Acme::Time::Baby.3
>> Appending installation info to
>> /home/hpcst06/perl5/lib/perl5/x86_64-linux-thread-multi/perllocal.pod
>> ABIGAIL/Acme-Time-Baby-2010090301.tar.gz
>> /usr/bin/make install -- OK
>>
>>
>> - Agora, tentei instalar o Data::Printer (Oi Breno!) pela mesma
>> estratégia e não consegui. Pode ser que não tenha a ver com a estratégia.
>>
>> Test Summary Report
>> -------------------
>> t/05-obj.t (Wstat: 512 Tests: 0 Failed: 0)
>> Non-zero exit status: 2
>> Parse errors: No plan found in TAP output
>> t/06-obj2.t (Wstat: 512 Tests: 0 Failed: 0)
>> Non-zero exit status: 2
>> Parse errors: No plan found in TAP output
>> t/07-sort.t (Wstat: 512 Tests: 1 Failed: 0)
>> Non-zero exit status: 2
>> Parse errors: No plan found in TAP output
>> t/25-weak.t (Wstat: 512 Tests: 8 Failed: 0)
>> Non-zero exit status: 2
>> Parse errors: No plan found in TAP output
>> Files=54, Tests=258, 4 wallclock secs ( 0.19 usr 0.09 sys + 2.82 cusr
>> 0.40 csys = 3.50 CPU)
>> Result: FAIL
>> Failed 4/54 test programs. 0/258 subtests failed.
>> make: *** [test_dynamic] Error 255
>> GARU/Data-Printer-0.35.tar.gz
>> /usr/bin/make test -- NOT OK
>> //hint// to see the cpan-testers results for installing this module, try:
>> reports GARU/Data-Printer-0.35.tar.gz
>> Running make install
>> make test had returned bad status, won't install without force
>>
>>
>>
>> Desculpem a postagem tão longa. Acabei até solucionando algumas outras
>> dúvidas enquanto tentava descrevê-las aqui.
>>
>> Abraços a todos,
>> Nicole Scherer
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>>
>> --
>> Tiago B. Peczenyj
>> Linux User #405772
>>
>> http://about.me/peczenyj
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
>
> --
> Saravá,
> Renato CRON
> http://www.renatocron.com/blog/
> @renato_cron <http://twitter.com/#!/renato_cron>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140130/b7f3882b/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm