linux 图形化版本控制,Linux系统配置管理：版本控制和部署

我正在寻找最佳方式(根据我的目的和情况)来版本系统配置文件并管理两台机器之间的部署(所有权和模式)(实时和备份,两者都应被视为’生产’).我希望能够使用此系统自动(但有选择地)复制和管理备份计算机(EC2实例)上的相关和指定配置.

目前,这些机器主要是Web服务器和SMTP服务器(我们不存储用户邮箱),但我们的项目正在增长,谁知道未来的需求可能是什么.例如,我们有可能在将来的某个时候实施无线电和基于网络的聊天.

我更喜欢按常规管理服务器(即,根据需要进入并对实时服务器进行更改),然后将这些更改(一旦确定)存储在管理系统中. (好吧,如果我是诚实的,我应该有机地说：我不想失去根据需求和情况需要做的事情的灵活性.)我发现这种方法,而不是部署在其他地方调整和测试的配置,更可预测,并且可能会减少意外(除了在现场系统上搞砸配置的可能性之外,就是这样！)

我意识到,从哲学的角度来说,这是前后的,如果我有资源(测试基础,更重要的是人力),我可能会反过来做.事实上,我必须做我所拥有的.我非常喜欢结构,但是过多的基础设施会占用自己的生命,并且在某些时候它的价值就会丢失.

我做了一些功课并回顾了几个选项,但是他们似乎没有真正做我想要的,所以我现在很想推出自己的解决方案.这个问题的目的是在我咆哮错误的树之前看看我没有想到的东西和理智检查.

选项

>像Puppet这样的声明性元信标配置系统可能是很好的选择,其中许多服务器之间很少或没有区别,特别是当提前明确配置应该是什么样的时候.我不认为在没有基础设施的情况下使用这样的工具是明智之举.

它也有点沉重,过于复杂.我是唯一的管理员,我在业余时间做这件事,如果发生任何问题,无论我留下什么,都需要为那些在我身后介入的幸运男/女孩合理理智.

> etckeeper可能会这样做,但就我所见,它并不能真正用于管理/ etc以外的任何东西.也就是说,它不适合存储自定义脚本,传统上,它们位于/usr/local / bin中.此外,etckeeper可能管理所有/ etc,我认为我更喜欢只对特定的东西进行版本化(例如postfix,apache,fail2ban,ssh和munin).

>一个简单的git或svn repo肯定不行,因为虽然git跟踪权限,但它不跟踪所有权,svn也不跟踪.

svn在每个被跟踪的目录中保留.svn子目录,而.git仅存在于工作副本的根目录中.两种情况都有利有弊.某些地方存在.svn目录在某些地方可能没问题(例如/ etc / apache2 / sites-enabled),但在其他地方打乱了脑死亡的脚本/工具. (我确定我早就读过一些东西：是不是cron在/etc/cron.d中使用了.svn目录,但是depmod没有/ lib / modules？)

另一方面,使用.git /,git认为一切都是跟踪的候选人,甚至(大概)其他git回购！

定制解决方案

这是我建议做的事情：存储在主机上的subversion repo(比如/usr/local / sc-repo)和用Pysvn编写的管理脚本实现以下内容：

>添加(但默认情况下不递归),它将文件的模式和所有权存储为自定义属性.此外,我喜欢配置文件中的$Id $标签,因此这将确保正确设置svn：keywords.

>提交

> update,在写入文件后应用所有权和模式

>还原,同上

> perms,如diff,但是对于所有权和模式,如果需要,可以使用fix flag进行更正.

备份机器将通过ssh访问repo并每晚执行更新操作. (它还会做其他事情,比如从主机的备份仓库(S3)恢复站点SQL和应用程序文件系统,我可能不得不写一些hackery,寻找在主机上添加的新软件包并将它们添加到备份机器 – 但所有超出本课题范围的.)

为什么要颠覆？

>我知道,喜欢并且比使用git更熟悉svn.是的,我可能是一只恐龙.

> Pysvn很简单,我以前用过它.

> svn支持版本化的自定义属性,git似乎不支持

>这不是分布式开发：分布式回购复杂化没有任何好处.远程repo可用性无关紧要,因为来自远程计算机的提交很少见.

我很感激你的反馈.我尽可能地想到了这一点,但我一定会错过一些东西.