版本控制可以在多大程度上帮助系统管理?

发布于 2024-07-11 07:03:07 字数 429 浏览 15 评论 0原文

我目前正在修补 OpenBSD 系统,目的是为自己构建一个防火墙和其他一些小东西。

由于这是相当实验性的(我是 OpenBSD n00b,我已经把我的系统搞砸了 3 或 4 次),我想知道其他人在制作部分或全部文件系统方面有什么经验(我特别想到/etc) 某些 VCS 或其他版本的工作副本。

  • 这是一个好主意吗?

  • 我特别感兴趣的是哪些 VCS 人们用于此目的。 我正在考虑 subversion、bazaar 和 git; 这不会是一个共享存储库,因此我可能对基本的 vcs 功能比分布式或非分布式的争论更感兴趣。

  • 我还想听听人们发现的想象中或实际的陷阱。 我可以想象保存文件所有权和权限需要仔细考虑!

  • 当然,还有不涉及 VCS 的任何替代方法

I'm currently tinkering at an OpenBSD system with a view to building myself a firewall and some other bits and bobs.

As this is fairly experimental (I'm an OpenBSD n00b, and I've already trashed my system 3 or 4 times), I wonder what experience others have of making part or all of the file system (I'm thinking in particular of /etc) a working copy of some VCS or other.

  • Is this a good idea?

  • I'm particularly interested in which VCS people have used for this. I'm considering subversion, bazaar, and git; this won't be a shared repository, so I'm perhaps more interested in the basic vcs functionality than the distributed-or-not argument.

  • I'd also like to hear about imagined or actual pitfalls people have found. I can imagine the preservation of file ownership and permissions needs careful thought!

  • And, of course, any alternative approaches not involving VCS

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

饮湿 2024-07-18 07:03:07

这里有关于使用 git 将 /etc/ 置于修订控制之下的详细修订。

另一种分步方法。

Here you have a detailed revision about putting /etc/ under revision control using git.

Another step by step method.

溺深海 2024-07-18 07:03:07

对于你正在做的事情,我建议你不要从 OpenBSD 开始,而是从一个已经完成了大部分工作的发行版开始,例如 pfsense

至于 VCS 本身,您可能需要考虑 mercurial,它已被 这些项目

For what you're doing I'd suggest rather than starting from OpenBSD you begin from a distribution where much of the work has already been done like pfsense.

As for the VCS itself you might want to consider mercurial that is being used successfully by these projects

倾城泪 2024-07-18 07:03:07

我认为还没有人提到 etckeeper

它将 /etc 存储在存储库中(git(默认)、mercurial 或 bzr)。 它解决了保存文件所有权、权限和空目录的问题。 它可以与软件包管理网集成(至少与 apt 集成),以自动提交在安装新软件包期间发生的对 /etc 的更改。 非常好,如果安装破坏了您自己的更改,只需回滚即可。

我已经在 Ubuntu 中成功使用它一段时间了。

I don't think anyone mentioned etckeeper yet.

It stores /etc in a repos (git (default), mercurial or bzr). It solves problems with preservation of file ownership, permissions and empty directories. It can integrate with package managemnet (at least with apt) to automatically commit changes to /etc that happens during the install of a new package. Very good if an install borks your own changes, just roll back.

I've been successfully using it in Ubuntu for a while.

各自安好 2024-07-18 07:03:07

不仅仅是在修订控制系统中拥有配置文件,我建议使用配置管理系统,例如 Chef Puppet 来管理配置文件的内容、权限和其他详细信息,例如当配置文件更改时重新启动应用程序,并在 git/subversion/yourfavoriteVCS 中管理这些文件。

More than just having configuration files in a revision control system, I suggest using a configuration management system such as Chef or Puppet to manage the contents, permissions and other details of the configuration files, such as restarting applications when a config file changes, and manage those files in git/subversion/yourfavoriteVCS.

唐婉 2024-07-18 07:03:07

我在“法国 Gnu/Linux 杂志”中读到过一些相关内容。
这家伙使用 rsync 从 /etc 到 root/,然后通过 subversion 存储它,而不创建工作副本。

我要引用杂志上的一些内容。

好吧,在这个例子中,服务器运行 freeBSD 并且是“sparky”,而要保存的机器是在 debian 下并且是“replica”。
创建一个用户“副本”。

在 /usr/local/etc/ssh/sshd_config 添加:

Match User replica
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/svnserv -t -r /home/replica/svnrepo -tunnel-user=replica

创建存储库

Sparky # svnadmin create /home/replica/svnrepo

修复权限:

sparky # chown -R replica:nogroup /home/replica
sparky # chown -R o-rwx /home/replica
sparky # chown -R g-rwx /home/replica

客户端:

安装 subversion

replica # mkdir -p /root/scripts/svnrepo
replica # rsync -av /etc /root/scripts/svnrepo

export SVN_SSH ="ssh -i /root/.ssh/id_rsa"
svn import -m "replica config files" /root/scripts/svnrepos svn+ssh://replica@sparky/home/replica/svnrepo

现在,我们的文件夹还不是工作副本,所以我们必须制作它。 你能创建一个 .svn 文件吗? 他不能:)

cd /root/scripts
mv svnrepo svnrepo.old
svn checkout svn+ssh://replica@sparky/home/replica/svnrepo

现在尝试修改etc中的文件,例如hosts。

再次rsync。 您应该只获取修改后的文件,即复制的 /etc/hosts 。

现在你可以承诺:

svn commit -m "backup 1" /root/scripts/svnrepo

还有最后一件事。 如果您希望 subversion 获取某个文件,则必须添加该文件。 例如,如果您在 /etc 中创建一个新文件,默认情况下不会保存它。

该怎么办?

svn status /root/scripts/svnrepo | grep -e '^!' | awk '{ print $2 }' | xargs -r svn delete 
svn status /root/scripts/svnrepo | grep -e '^?' | awk '{ print $2 }' | xargs -r svn add

然后,你必须制作自己的脚本。

希望这可以帮助。

(gtg,我稍后会编辑以设置标题,如果没有人这样做的话)

I have read something on that in "Gnu/Linux Magazine France".
The guy uses rsync from /etc to root/ then stores it via subversion, without creating a working copy.

I'm gonna quote a little the magazine.

Ok so, in the example, the server runs freeBSD and is "sparky", whereas the machine to be saved is under debian and is "replica".
Create an user "replica".

in /usr/local/etc/ssh/sshd_config add:

Match User replica
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/svnserv -t -r /home/replica/svnrepo -tunnel-user=replica

Creating the repository

sparky # svnadmin create /home/replica/svnrepo

Fix rights:

sparky # chown -R replica:nogroup /home/replica
sparky # chown -R o-rwx /home/replica
sparky # chown -R g-rwx /home/replica

Client side:

install subversion

replica # mkdir -p /root/scripts/svnrepo
replica # rsync -av /etc /root/scripts/svnrepo

export SVN_SSH ="ssh -i /root/.ssh/id_rsa"
svn import -m "replica config files" /root/scripts/svnrepos svn+ssh://replica@sparky/home/replica/svnrepo

Now, our folder is not yet a working copy, so we have to make it. Can you create a .svn file? He can't :)

cd /root/scripts
mv svnrepo svnrepo.old
svn checkout svn+ssh://replica@sparky/home/replica/svnrepo

Now try to modify a file in etc, like hosts for instance.

rsync again. You should only get the modified file, wich is /etc/hosts copied.

now you can commit :

svn commit -m "backup 1" /root/scripts/svnrepo

There is one last thing. If you want a file to be taken by subversion, it must be added. So for instance, if you create a new file into /etc, it won't be saved by default.

What's to be done?

svn status /root/scripts/svnrepo | grep -e '^!' | awk '{ print $2 }' | xargs -r svn delete 
svn status /root/scripts/svnrepo | grep -e '^?' | awk '{ print $2 }' | xargs -r svn add

Then, you have to make your own script.

Hope this helps.

(gtg, I'll edit later to set titles and so one if nobody does)

醉态萌生 2024-07-18 07:03:07

我管理的每台服务器上的 /etc 中的所有内容(超过 300 个并且还在增加)都位于 Mercurial 下。 为什么?

  • 对于曾经使用过 SVN 或 CVS 的任何人来说,它都易于使用(如果您没有使用过,那么您就没有必要在我的生产机器上的 /etc 中开展业务)。
  • 它可以轻松地将更改从一台服务器的配置拉到
  • 我可以滚动的 许多其他服务器上当其他管理员脑子里放屁时,很快,

在这种情况下,Git 的功能太大,问题却太少。 由于 HG 是 DVCS,因此提交和回滚干净且简单。 我还使用 HG 来管理我的大部分网站

它不仅仅适用于源代码:)另一个更基本的选择是使用某种在写入时拍摄快照的版本控制文件系统(CoW),DVCS 更容易。

Everything in /etc on every server that I manage (300 + and counting) is under Mercurial. Why?

  • Its easy to use for anyone who has ever used SVN or CVS (if you have not, you have no business doing business in /etc on my production machines)
  • It makes it easy to pull changes from one server's config to many others
  • I can roll back when other admins have a brain fart, quickly

Git was just too much power for too little of a problem in this instance. As HG is a DVCS, commits and roll backs are clean and easy. I also use HG to manage most of my web sites.

Its not just for source code :) Another more basic option would be to use some kind of versioning file system that takes snapshots on writes (CoW), a DVCS is much easier.

掐死时间 2024-07-18 07:03:07

反馈:我最终做了什么

(@Aif,感谢您温柔的提醒,我有点缺乏礼貌)

我使用 /etc 作为 git 存储库,但因为我对此仍然有点不安(我,不是git),我正在手动进行 gitwork 。

作为副作用,我开始了一个小项目来并行评估 subversion、git、bazaar、mercurial、monotone、darcs 和化石,尽管是在更通用的版本管理上下文(合并等)中。


我对您的回答的反应

感谢大家的帮助。 我在选择接受哪个答案时遇到了一些困难,所以如果不是你的答案,请相信我,我也很欣赏你的答案。

@Luis Melgratti

Luis,感谢您提供了一些出色的参考资料。 我已经接受你的答案,因为它是最有用的。


@康拉德

康拉德,我很欣赏你的建议。

我当然会调查pfsense,尽管我的目标之一是亲自动手,以及建立防火墙,所以“制造而不是获取”很重要。

至于 Mercurial,我没有将它列入我的列表,因为我(以前)尝试过它,而且我觉得我更“喜欢”bazaar,而 git 乍一看似乎拥有很大的功能(不可否认,我可能不需要)。 我目前的“主要”版本控制系统是 Subversion,尽管我不确定这对于这种情况来说是一个好的答案。 因此列出了三个。

(我现在查看了 pfsense 并在我的网络上启动了它。非常好,但我根本不确定我的手是否会弄脏……)


@Aif

谢谢,艾芙。 我肯定会尝试一下,尽管我怀疑我最终会选择 git。


@tinkertim

感谢您对 Mercurial 的想法,我现在计划重新访问它,尽管我对 Bazaar 非常满意。


@Per Wiklander

感谢您提出非常有趣的建议! 当我可以摆脱当前的工作堆时,我肯定会看看 etckeeper。

Feedback: What I ended up doing

(@Aif, Thanks for the gentle reminder that my good manners were a bit missing)

I went with /etc as a git repository, but as I'm still a little uneasy with this (me, not git), I'm doing the gitwork manually.

As a side effect, I've started myself on a small project to evaluate, side by side, subversion, git, bazaar, mercurial, monotone, darcs, and fossil, though in a more general version management context (merges and such).


My reactions to your answers

Thank you all for your help. I had some difficulty in choosing which answer to accept, so if it wasn't yours, please believe me, I appreciated yours, too.

@Luis Melgratti

Luis, thanks for a couple of excellent references. I have accepted your answer as the most useful.


@Conrad

Conrad, I appreciate both your suggestions.

I shall certainly investigate pfsense, though one of my objectives in this is to get my hands really dirty, as well as building a firewall, so "make rather than acquire" is important.

As to Mercurial, I didn't include it in my list because I have tried it (previously), and I felt that I "liked" bazaar better, while git seems at first sight to have a great deal of power (which admittedly I may not need). My "main" VCS at present is Subversion, though I'm not sure it's a good answer for this case. Hence the list of three.

(I've now taken a look at pfsense and fired it up on my network. Very good, but I'm not at all sure I'll get my hands even slightly soiled...)


@Aif

Thanks, Aif. I'm definitely going to give that a try, though I suspect I'll end up with git.


@tinkertim

Thank you for your thoughts on Mercurial, which I now plan to revisit, though I'm well pleased with Bazaar.


@Per Wiklander

Thank you for a very interesting suggestion! I'm definitely going to take a look at etckeeper, when I can get out from under the current workpile.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文