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