在我们的环境中，我们有30多种服务器上使用的各种脚本。 目前，我们在安装操作系统时将脚本复制到每台服务器上。 但是，这具有脚本更改需要手动重新部署的问题。
我正在考虑设置一个NFS导出，但是这有一些缺点：
我考虑的其他选项是Subversion（或任何源代码pipe理），rsync和rpms。 svn的好处在于脚本的版本控制。 Rsync很简单，并允许本地脚本。 我不认为rpm会因为我们的Solaris服务器而起作用。
我们有Solaris，Redhat Enterprise Linux和Suse Linux服务器，而且我们只有less量（〜10）个小脚本可供部署，所以越简单越好。
考虑一下：Puppet，Bcfg2，Cfengine。
我们使用subversion来开发我们的本地脚本，然后使用RPM进行部署 – 一个简单的构build脚本（也作为我们的脚本包的一部分进行维护）将获取SVN导出并运行它在其中find的RPM规范文件。 然后将结果部署到我们的本地yum存储库中，所有机器都可以使用自动更新或根据机器types（开发，分段，生产等）手动将其取出。
在我现在的公司，我们只使用RHEL / CentOS服务器，所以我们只需要一个yum repo，但是在以前的公司，我已经build立了一个类似的设置，输出RHEL（yum repo）和Mandriva（urpmi repo）的RPM，为Solaris自解压tgzs，甚至为Windows提供可执行安装程序（NSIS可用于在所有构build的同一台Linux服务器上构build安装程序包）。
一旦你有一个自解压的tgz，自动将它部署到你的Solaris机器是一个简单的SSH调用问题。
如果你有这么小的设置，那么Subversion可能会有点多。 同时，它也提供变更pipe理，作为良好系统pipe理的支柱之一。
Subversion听起来像一个好主意，而且我们是如何处理类似的部署，虽然我们不使用相当多的机器。 如果你的机器分布在多个地方，你可能要考虑使用一个分布式的VCS系统（git等），这样你可以在每台机器上从本地位置获得一个cron作业，并有一个“中央每个数据中心的位置也会定期更新。
如果你喜欢使用rpm的想法，solaris有自己的打包系统（sysv软件包），你可以随着rpm生成一个solaris软件包。 我假设这个过程是自动化的，所以这样做不会太麻烦。
NFS没有提到的最大缺点是整个架构在单个文件服务器上的依赖性。 如果发生故障，则会丢失所有脚本。 根据脚本的function，这可能会或可能不会被您接受。
我们有一个类似的情况，大约30个服务器，15到25个脚本分发，其他包。 SVN在实验室中取得了非常好的效果，在实际的服务器上，Yum的分发和RPM的维护都非常成功。
棘手的部分是自动化RPMbuild设，因为它会征收一定的时间税。 每次你发现一个bug，你需要在本地完成，然后在RPM上创build一个新的版本来安装它，否则你将失去所有的魔力。
虽然Puppet或Bcfg2似乎是不错的select，但我们放弃了它们，因为它们似乎增加了系统的复杂性。 把事情简单化。