Considere: Puppet, Bcfg2, Cfengine.
Em nosso ambiente, temos vários scripts que usamos em mais de 30 servidores. Atualmente, copiamos os scripts em cada servidor quando o sistema operacional é instalado. No entanto, isso tem o problema de que as alterações nos scripts exigem uma reimplementação manual.
Estou pensando em configurar uma exportação do NFS, mas isso tem algumas desvantagens:
Outras opções que eu considerei são Subversion (ou qualquer controle de origem), rsync e rpms. O benefício para o svn é o controle de versão dos scripts. O Rsync é simples e permite scripts locais. Eu não acho que o rpm funcionaria por causa de nossos servidores Solaris.
Temos servidores Solaris, Redhat Enterprise Linux e Suse Linux, e só temos um pequeno número (~ 10) de pequenos scripts para implantar, então quanto mais simples melhor.
Usamos o subversion para desenvolver nossos scripts locais e implementá-los usando o RPM - um script de compilação simples (também mantido como parte do nosso pacote de scripts) extrai uma exportação do SVN e executa o arquivo de especificação do RPM que encontra lá. O resultado é então implantado em nosso repositório yum local, do qual todas as máquinas podem obtê-lo, seja usando atualizações automáticas ou manualmente, dependendo do tipo de máquina (desenvolvimento, teste, produção, etc.).
Na minha empresa atual, usamos apenas servidores RHEL / CentOS para que um único repositório yum seja tudo o que precisamos, mas em uma empresa anterior eu criei uma configuração semelhante que gerou RPMs para RHEL (yum repo) e Mandriva (urpmi repo), tgzs de extração automática para Solaris e até mesmo instaladores executáveis para Windows (o NSIS pode ser usado para criar pacotes de instalador no mesmo servidor Linux onde todas as suas compilações estão sendo feitas).
Uma vez que você tenha um tgz auto-extraível, implantá-lo automaticamente em suas máquinas Solaris é uma simples questão de uma chamada SSH.
Se você tem uma configuração tão pequena, o Subversion pode ser um pouco demais. Ao mesmo tempo, também fornece gerenciamento de mudanças, um dos pilares da boa administração de sistemas.
Subversion parece uma ótima idéia, e é como lidamos com implementações similares, embora não usemos tantas máquinas quanto. Se as suas máquinas estão espalhadas por vários locais, você pode querer considerar o uso de um dos sistemas VCS distribuídos (git etc.), assim você pode ter um cron em cada máquina puxando de um local local, e ter uma central 'localização em cada data center que também atualiza em intervalos regulares.
Se você gosta da idéia de usar rpm, o solaris tem seu próprio sistema de pacotes (pacotes sysv) e você pode simplesmente gerar um pacote solaris junto com o rpm. Presumo que este processo será automatizado, por isso não será muito difícil fazê-lo.
A maior desvantagem do NFS que você não mencionou é a confiança em toda a sua arquitetura em um único servidor de arquivos. Se isso cair, você perderá todos os seus scripts. Dependendo da função dos scripts, isso pode ou não ser aceitável para você.
Temos um cenário semelhante, em torno de 30 servidores com 15 a 25 scripts para distribuir, entre outros pacotes. Tivemos resultados muito bons com o SVN em laboratórios externos, yum para distribuição e RPM para manutenção de pacotes nos servidores reais.
A parte complicada é automatizar o edifício do RPM, uma vez que irá impor um imposto sobre o tempo. Cada vez que você encontrar um bug, você precisa trabalhá-lo localmente e, em seguida, fazer um novo lançamento no RPM para instalá-lo, caso contrário, você perde toda a magia.
Embora o Puppet ou o Bcfg2 pareçam ser boas escolhas, descartamo-los porque parecem adicionar complexidade ao sistema. Mantenha isso simples.