[Rio-pm] Configuração de usuário não root no cpan & Perl Roll em Rocks Cluster
Aureliano Guedes
guedes_1000 em hotmail.com
Quinta Janeiro 30 11:44:58 PST 2014
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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140130/77e98ac8/attachment-0001.html>
-------------- Próxima Parte ----------
_______________________________________________
Rio-pm mailing list
Rio-pm em pm.org
http://mail.pm.org/mailman/listinfo/rio-pm
Mais detalhes sobre a lista de discussão Rio-pm