[SP-pm] usando plugins em perl

Marcel webknowledge em gmail.com
Quarta Março 26 09:49:28 PDT 2008


Oopa. CFENGINE Rulez... Mas achei o puppet mais simples de usar, e com
transações seguras, plugável, só que é em python.

Já ouvi o POE ser utilizado para implementar esse tipo de recurso.


2008/3/26 Luis Motta Campos <luismottacampos em yahoo.co.uk>:

> Frederico Recsky wrote:
> > Olá,
> > O que eu tenho é um instalador automatico de um programa para linux.
>
> Posso saber que programa é esse?
>
> > E devo permitir aos usuarios "interferir" no processo com funções ou
> > personalizações no meio. Devo suportar perl, shell e python. Em shell
> > o caboclo joga tudo num diretorio e o script é chamado. Em Perl e
> > Python deve adicionar funções num arquivo que é lido e absorvido pelo
> > instalador. Eu queria fazer isso de outro jeito, mas ... como ainda
> > não sou senior architect na empresa então..
>
> Argh. Deixa eu ver se eu consigo compreender esta mente tortuosa que a
> tua empresa acredita ser capaz de bancar o senior software architect...
>
> 1. você tem um programa linux que alguém quer instalar;
>
> 2. o teu programa vem num pacote (Que tipo? Tarball? debian? rpm?);
>
> 3. junto com o programa, vocês mandam um script capaz de gerar ųm script
> de instalação;
>
> 4. O script descrito em (3) aceita opções do usuário (presumivelmente
> final) que está instalando o sistema, através de uma interface de
> personalização que parece um sistema de plug-ins, mas não é;
>
> Agora, as minhas perguntas.
>
> A. Que linuxes você suporta oficialmente para este programa?
>
> B. Que tipo de pacote o teu programa usa?
>
> C. O teu programa não pode ser distribuido usando um sistema de pacotes
> padrão?
>
> DEB e RPM são sistemas de pacotes prontos, configuráveis, muito fáceis
> de construir e de usar, e que ainda vão te permitir um maior grau de
> controle sobre que versões do sistema que você tem ou deixa de ter
> intalado, e coisas mais sofisticadas, como decidir se você precisa ou
> não forçar um upgrade de outros pacotes durante a instalação.
>
> D. Por que o teu /system/ /architect/ acha que ele precisa reinventar a
> roda e fazer tudo o do jeito mais complicado, enviando um meta-script de
> instalação para rodar num ambiente que ele não conhece e não controla?
>
> E. O que você precisa oferecer aos usuários no passo (4) que não pode
> ser feito automaticamente num script de pré-instalação, usando um
> sistema de pacotes padrão?
>
> > O programa em questão é gigante e complicado e permite a si mesmo
> > regerar a sua instalação para um grupo de servidores com
> > caracteristicas iguais. O usuario só interage com ele definindo antes
> > o que deve ser feito e adicionando suas funçòes se necessario.
>
> Isso parece tanto com o CFEngine que eu vou apenas te apontar para o
> link: www.cfengine.org. Isto vai resolver os teus problemas com "grupos
> de servidores (aproximadamente) iguais".
>
> Você tem problemas sérios de projeto. Espero que isso ajude.
>
> Putamplexos!
> --
> Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
> Perl fanatic evangelist, and amateur {cook, photographer}
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/saopaulo-pm/attachments/20080326/b4507765/attachment.html 


Mais detalhes sobre a lista de discussão SaoPaulo-pm