最近评论
正在载入评论列表...
2311.3.5
版本控制让改动可撤消
生活中总会犯错。因此，跟踪您所做的改动就变得很重要，这样一来，当改动造成问题的时候，您就可以轻而易举地恢复到一个已知是好的配置上。如果您的站点使用了一种正式的版本化了的发布系统，那么回滚（rollback）工作就会变得很容易，但这是一种重量级的解决方案，只能粗略地进行控制。如果您只需要改一两个文件该怎么办呢？
在这一节里，我们讨论一些以单个文件为单位管理修改的常用方法。这些方法是对内部发布控制等其他较大改动的有力补充—选择同您的本地需要和您站点复杂程度相符合的一类工具。
11.5.1 创建备份文件
给您修改的文件留备份是一项历史悠久的管理传统，要依靠本地化脚本以及系统管理员个人来遵守这个传统。备份文件能让您退回到配置的一个早先状态，但或许更为重要的是，它们还能让您把一个文件当前和过去的版本做差异比较，得知做了哪些改动。
您最好通过把原来的文件（用mv命令）改为一个新名字（比如filename.old或者filename.bak），然后再把它拷回一个用原名的文件，创建备份文件。使用cp的-p选项保留文件的属性设定。一旦您更新为这个文件的活动版本，它的修改时间就反映出了最近的修改，而备份文件的修改时间则反映了上一次修改的时间（如果您只用cp拷贝，没有带-p选项，那么两个文件的修改时间则接近）。把原来的文件移动到一边的做法也能处理好这样的情形，即一个活动进程打开对该文件的访问：您对文件的当前活动拷贝所做的修改，要等到该文件被关闭再打开之后才看得到。
生活中处处会犯错。因此，跟踪您所做的改动就变得很重要了，这样一来，如果您——最糟糕的情况——确实犯了个错误，您就可以轻而易举地恢复到一个已知是好的配置上。如果您的站点使用了一种正式的版本化了的发布系统，那么回滚（rollback）就会和重新安装以前的发布一样容易。但是即便您没有这种支持系统，也还是有一些办法让回滚更容易。
支持回滚最简单的办法就是保留一份您所改动过的任何文件的备份副本。例如，在做改动之前，您可以把syslog.conf复制到syslog.conf.old。保留一个备份副本也能让您在丢掉了您所做的改动之时，用diff比较得到配置文件的当前和以前版本之间的差异。系统定期被备份到磁带上的系统仍然能够从手工创建的备份文件上获益。从一个备份文件恢复要比从一卷磁带恢复快得多，也容易得多，手工备份多保留了一层历史信息。
如果您采用了这种手工的备份体系，那么要有一种给备份文件起名字的约定，并且试着让站点上所有的系统管理员都坚持采用这种约定。有些站点使用减号（例如，syslog.conf-），有些站点使用.old或者.bak做后缀，而其他一些站点则使用了多版本编号的方案。
定期备份到磁带上的系统仍然能够从手工创建的备份文件上获益。从一个备份文件来恢复要比从磁带来恢复速度快，而且也容易，手工备份多保留了一层历史信息。
手工备份有一个限度，但如果您所做的修改达到了一定数量，它们很快就变成麻烦事儿了（您是保留多个有不同名字的副本呢，还是只保留最近的一个副本？）。幸运的是，程序开发界很早以前就有了针对这个问题的解决办法：版本控制（revision control）。
2311.35.6
2 正式的版本控制系统
备份文件非常有用，它们在小站点上实际效果最好。复杂性和健壮性再高一个层次的做法是采用正式的版本控制系统（revision control system），这种系统是一种软件包，能够跟踪、保存文件的多个版本，并且可以提供访问这些不同版本的手段。这类版本控制软件包源自于软件开发领域，但是它们也对系统管理员非常有用。
版本控制系统解决了几个问题。首先，它们提供了一种有组织的方式来跟踪对一个文件的修改历史，从而让人理解改动文件的来龙去脉，并且能够恢复早先的版本。其次，它们把版本的概念扩展到了单个文件的层次之外。有关系的一组文件可以按其相互间的依赖性一起指定版本。最后，版本控制系统能够协调多个编辑人员之间的活动，使得竞争条件（race condition）不会让任何人的改动永久丢失[9]，这样一来，多个编辑人员做出的不兼容的改动不会同时起作用。
常用的最简单的
如果不同的几个人要编辑同一个文件，必须要克服可能出现的两个问题。首先，必须有某种方式能保证一次不会有一个以上的人编辑这个文件；同时编辑可以形成一种竞争条件（race condition），其次，必须有某种有组织的方式跟踪修改的历史，不但能够让人理解修改的来龙去脉，而且不会永远地失去文件早先的版本。为了解决这两个问题，程序员们开发出了版本控制系统（revision control system）。
在UNIX的早期时代，最初的版本控制系统叫做RSCCS，名字正好就是版本控制系统。它的功能已经够好了，但是很贵；Walter Tichy开发的RCS（Revision Control System，版本控制系统）。RCS已经存在了数十年，许多系统上都预装了它。是SCCS的替代软件，它是开发源代码的。如今，RCS业已成为UNIX和Linux的事实标准，而SCCS则变成了历史陈迹。每一种Linux发行版本都带RCS，它用起来既简单又方便。
还有几种商业的版本控制系统。如果您在一家开发公司工作，那么您可能已经用过这几种系统中的一种。不过，根据我们的经验，商业系统对于系统管理员使用来说，一般是大材小用了。
另一种选择是一种称为CVS（Concurrent
Versions System，并发版本系统）的开放源代码系统，它在RCS之上增加了一些功能。它支持一种分布式的模型（配合远程服务器来使用），而且更好地支持了多位开发人员的协同工作。有大量的站点已经将CVS用于系统管理的任务，它的客户机/服务器的功能特别有用。但是如果您是从头开始使用版本控制系统的，那我们还是建议先从RCS开始遗憾的是，CVS有一些概念上的缺陷，使得它毁誉参半。
在开放源代码领域新近出现（但仍然需要时间考验）的一种版本控制系统是Subversion，它提供了CVS所有的优点，但它似乎有更合理的默认举动。从系统管理的角度来看，它的主要缺点在于项目的模型过于以目录为中心。不过，它仍然不失为一种非常好的系统，是可供系统管理使用的一种合理选择。
最近几年，我们目睹了开放源代码版本控制系统的繁荣发展，可供选择的系统扩大了几乎一个数量级。在比较新的系统中，主要的竞争者有Monotone、Darcs、Arch和BazaarNG。这些系统都很有意思，但是它们看上去都侧重于非集中式的工作：多个分支、多个库、众多的并行开发。根据我们的观点，传统的“集中库”模型更适合于系统管理方面的版本控制。
还有几种商业的版本控制系统。如果您在一家开发公司工作，那么您可能已经用过这几种系统中的一种，而且可能试着把它用于系统管理数据。不过，根据我们的经验，商业系统对于系统管理员使用来说，一般是大材小用了。
如果您是从头开始，我们建议一开始从RCS获得对版本控制的总体感觉。如果您想要建立一个集中式的系统管理信息库，那么应该用Subversion。
2311.35.7
3 RCS：版本控制系统：版本控制系统
RCS（版本控制系统，Revision Control System）是现存的最古老的UNIX应用程序之一。它实际上是一种相当简单的系统。它在单个文件的层面上执行操作（这和CVS相反，CVS可以在文件树的结构上执行操作），并且把每个文件的版本信息保存在独立的隐蔽文件中。这个隐蔽文件的名字和原来的文件名一样，但是在原名后面加了.v两个字符。例如，如果您把文件/etc/syslog.conf置于RCS的控制之下，那么RCS会将它的各个版本保存在/etc/syslog. conf.v里。
为了减少混乱，RCS在和原来文件相同的目录下寻找一个叫做RCS的目录。如果有这个目录，RCS就把.v文件放到那个目录里面，而不是把它们留在原来文件的目录里。这样一来，列出的目录内容就会变得清楚多了，因为许多文件都可以共享RCS目录。这是一种很棒的功能，而且也是我们极力推荐的一种做法。
RCS的基本概念就是，您“检出（check out）”您想要修改的文件，而“检入（check in）”您所做的改动，把它们保存起来。相应地，您确实需要知道的RCS命令只有几个：ci用于检入、co用于检出，而rcs执行各种维护工作。如果您使用的编辑器是emacs，那么就要完全不必使用命令行工具了，因为emacs内置了对RCS的支持。
要让一个文件开始处于RCS的控制之下的跟踪之下，可以像下面这样在这个文件上运行ci：
-u标志让ci立即以一种未上锁（不可编辑）的状态检出syslog.conf文件。如果您省略了这个标记，那么ci就会检入这个文件，然后删除原来的副本，这或许并不是您想要的做法。
您可以用chmod命令将syslog.conf文件变成可写的，并且以此来修改它，但是这个过程会破坏和扰乱RCS。您每次想要改变一个受RCS控制的文件时，都必须检出它，并用co -l命令对它上锁：
# co -l syslog.conf
RCS/syslog.conf,v --> syslog.conf revision 1.2 (locked)
done
这一操作告诉RCS，您打算修改这个文件了，RCS不会让其他任何人检入这个文件不会让其他任何人检出这个文件，直到您再把它检入为止。
RCS在未上锁的文件上取消了写权限，提醒用户在正确检出它们之前，不要编辑它们。一种常见的错误是，把一个文件载入您的编辑器，进行修改，但直到编辑器拒绝保存所做的修改，才意识到需要把文件检出。要纠正这样的错误，只要暂停编辑器，或者启动另一个shell窗口，运行适当的co -l命令，然后再试着保存就可以了。您只要用chmod命令就能把文件改为可写，但这样做会破坏和弄乱RCS。
从理论上说，RCS上锁避免了两个不同的人同时修改文件的情况出现。在实际中，您必须是root才能修改系统文件，因此一旦某个系统文件以root权限被检出以后，有sudo权利的任何人都能修改它。不过，如果第二个系统管理员试图再用命令co -l的时候，RCS会提示说已经有一个可写版本了。系统管理员应该形成习惯，在他们想要修改由RCS控制的文件时都必须尝试先检出它。文件可写意味着“住手！有别人已经检出这个文件了。”
您可能偶尔会发现有其他人已经改动了一个文件，并且让它留在了上锁状态，甚至更糟糕，这个人没管RCS，没对文件上锁就做了修改。您可以用rcsdiff复查犯错误的人所做的修改，这条命令是一个能懂RCS的diff版本。例如：
最后一招是您可以用命令rcs -u filename打破上锁。这条命令提示您输入对所采取的措施给予的解释，并且发邮件给前面对文件上锁的用户（遗憾的是，同时就是root）。
一旦您对检出文件所做的修改感到满意以后，就可以用ci -u命令把它检入。RCS会要求您提供一条注释，说明您刚才做的是什么。虽然人们倾向于跳过这步，或者写些诸如“做了一次修改”这样的无用信息，但是应该坚持加注释这个习惯。在两年以后，当您要弄清楚为什么您要做改动的原因时，有帮助的注释会救您一命的。
您可以用rlog命令查看一个文件的版本历史信息：
如果您想要看看文件在换到新日志主机之前的样子，可以用co的-r选项检出这个文件的1.2版：
# co -r1.2 syslog.conf
RCS/syslog.conf,v --> syslog.conf
revision 1.2
done
这条命令用老版本替换了当前的syslog.conf文件，所以要确保在您做完以后执行一次正常的co命令，否则您（和syslogd）都可能会被搞糊涂！另一种做法是co -r1.2 -p syslog.conf，它把所需版本的内容发送到标准输出。遗憾的是，没有办法把文件检出到一个不同的文件名里。决不要检出老版本的上锁副本（用co -l命令），因为这一操作会在版本树中创建分支。版本分支偶尔会在源代码上使用，但是对系统管理员的工作来说几乎没有用处，只需略过RCS文档中所有涉及它们的地方，让您的生活更简单些即可。
有关RCS的更多知识可以在下面的地址找到：http://www.cs.purdue.edu/homes/trinkle/RCS/。您可能偶尔会发现有其他人已经改动了一个文件，并且让它留在了上锁状态，甚至更糟糕，这个人没管RCS，没对文件上锁就做了修改。您可以用rcsdiff复查犯错误的人所做的修改，这条命令是一个能懂RCS的diff版本。
最后一招是您可以用命令rcs -u filename打破上锁。这条命令提示您输入对所采取的措施给予的解释，并且发邮件给前面对文件上锁的用户。
有关RCS的更多知识可以在下面的地址找到：
http://www.cs.purdue.edu/homes/trinkle/RCS/。
有关CVS的信息，请参见www.cvshome.org。
11.5.4 CVS：并发版本系统
RCS有一些显著的缺点。您在编辑文件的时候，必须小心不要和您的同事同时编辑文件。您必须遵守一组相当专门的操作步骤。您不能一次安全地修改几个文件，而又让系统不受没修改完的文件的影响。这些（以及其他一些）不足之处推动了设计下一代CVS（并发版本系统，Concurrent Versions System）的工作，CVS是目前在UNIX和Linux系统上使用最为广泛的版本控制系统。
CVS背后的主要思想之一是项目文件（及其历史版本）都保存在一个中心位置。和在RCS系统中一样，您要检出要开始在上面工作的文件，然后做完修改之后把这些文件再次检入到代码库里。CVS的优势在于，它没有“上锁”和“解锁”检出的概念，若干人可以同时检出并修改相同的文件（“并发”由此得名）。
既然CVS可以让多个用户修改同一个文件，它必须提供一种方法，在文件被再次检入代码库的时候能把多个用户的修改集成到一起。这种合并工作在正常情况下会自动完成，但只有文件是文本文件，而且各种不同的改动互相并不矛盾的情况下，才能顺利实现。如果不满足上述条件，那么CVS就要靠人工检入，手工解决冲突。如果对一个文本文件做的多个改动相互冲突，那么CVS就要插入帮助性的注释，反映出冲突出现的位置。
理论就说这么多。听上去挺酷的，实际也确实如此—即使合并工作也做得不错。但是CVS仍然存在一些问题。
— 它不支持“原子提交”。如果两个人都尝试检入影响到多个文件的一次重大修改，两个版本可能都以接受一半而告终，交给每个操作员解决的是随意选择的一些冲突。这可不对。
— 要改变一个文件的名字，必须先把它拷贝为新名字，然后删除原来的文件，因此失去了这个文件以前的所有历史信息。类似地，只有先拷贝目录，再删除原来版本的目录，才能改变目录的名字，除此之外别无他法。
— 文件属性不受版本控制。文件第一次检入时的设定就一直保留下来不会变化。
尽管如此，许多开放源代码软件项目仍然使用CVS。之所以如此，不是因为它无懈可击，而是因为以前缺乏好用的替代软件。然而，随着很多开发小组投入到开发CVS替代软件的项目上，这种情况已经发生了变化。现如今的选择多种多样，竞争的主旨可能落在了哪种版本控制系统应该超过CVS的问题上。Shlomi Fish的网站Better SCM Initiative（better-scm.berlios.de）介绍了大多数CVS的候选替代软件，并对它们的功能进行了系统性的比较（但未标注比较的时间）。
下面从用户的角度快速列举一下最重要的CVS命令。修改一个项目的第一步是登录到服务器，检出想要改动的模块。我们在这里要修改的模块叫做sort。
$ cvs -d :pserver:username@servername:/path/to/repository login
CVS password: <password>
$ cvs -d :pserver:username@servername:/path/to/repository co sort
其中pserver是联络代码库所用的访问方法，本例中的代码库是一个专用的CVS口令服务器。login操作把口令与服务器的口令进行对照检查，并且保留口令的一个副本，供以后的交互使用。co操作直接类似于RCS的同名命令。
您现在可以进入sort目录在本地的副本，开始编辑文件。当您准备把文件再次检入CVS库的时候，不需要用-d选项，因为CVS在子目录sort/CVS里留下了一份所有必须的本地信息。
sort/CVS subdirectory.
$ cd sort
$ vi foo.c
$ cvs commit foo.c -m “Added more efficient sort routine”
如果您已经在模块的副本上工作了一段时间，想要用其他人自从您检出该文件后已经对它做的修改来刷新本地副本，可以使用cvs update命令。-d选项的意思是要包括所有的子目录，而-P选项则要求CVS删除任何空目录。
$ cvs update -dP
要记住，虽然您没有把自己的文件检入到中心代码库，但这也是一种集成。其他用户的改动总有可能与您的改动发生冲突，如果有需要您解决的冲突，CVS会让您知道。
11.5.5 Subversion：做得好的CVS
虽然CVS是当前占据主导的版本控制系统，但是我们建议系统管理员从RCS直接跳到Subversion。这个软件包由Karl Fogel和Jim Blandy编写，他们两人在1995年创办了Cyclic Software公司，销售CVS支持合同。到了2000年，他们与CollabNet签订合同，编写一个代替CVS的开放源代码软件。结果就有了Subversion，经过漫长的孕育阶段，Subversion的1.0版在2004年2月发布了。
Subversion具备了上面提到的所有“欠缺”的功能，但是又没有牺牲整洁性和易用性。和在CVS里一样，Subversion系统里有一个集中式的代码库保存所有的版本控制文件。Subversion能够处理二进制文件，而且速度比CVS快。
Subversion服务器默认是Apache 2.x版Web服务器中的一个模块。它特别适用于分布式的软件开发工作，但是可能不适合系统管理工作使用。不过还好，Subversion的开发者提供了第二种以守护进程形式出现的服务器，叫做svnserve。您可以从您的主目录中运行svnserve来试用Subversion，但是在正规工作上使用的时候，它应该有自己的用户账号，从inetd运行。
Subversion一开始的发布版本使用Berkeley DB数据库用于代码库的后端保存，但是Subversion 1.1增加了对另一种叫做FSFS系统的支持。两种保存方式都各有优缺点。主要区别在于，Berkeley DB依靠内存映射I/O语义，因此不能用NFS[10]。使用Berkeley DB的Subversion库必须放在Subversion服务器运行的主机上。FSFS库不受这样的限制。参考subversion.tigris.org了解更多优缺点介绍。
设置Subversion库很简单。例如，下面几步可以创建一个称为admin的新Subversion库：
如果您想要自己的Subversion库使用FSFS格式而不是默认的Berkeley DB格式，就要给svnadmin create命令加上--fs-type=fsfs选项。格式要选得聪明，确定好库的格式之后就难以再变了。
如果您扫一眼admin目录，就会发现它是一个组织得很好的库结构，其中还有一个README文件。在子目录conf里可以找到配置文件svnserve.conf。这个文件告诉服务器守护进程如何提供对新库的访问。下面是一个适用于系统管理文件的配置：
因为Subversion的设计目标之一就是方便位于不同地点的人们之间的协作，所以它有一个独立于操作系统的访问控制模型。（在同一目录下的）passwd文件里有用户名及其明文（！）口令。这种明文口令着实不好，但作为补偿，口令也绝不会通过网络传送。用户也不会把它们从内存敲出来，所以您也可以把口令设得足够长和随机，以此保证安全性。例如：
passwd文件的权限自然应该严格设定。
剩下的就是在新库上启动服务器了：
# svnserve --daemon --root /home/svn/repositories
您作为一个没有特权的用户，现在就可以在网络上的任何地方把admin模块检出：
$ svn checkout --username tobi svn://server.atrust.com/admin checkout
Authentication realm: <svn://server.atrust.com:3690> The Sysadmin Repository
Password for 'tobi': <password>
当您第一次输入口令的时候，Subversion会把它的一个副本保存在您的主目录中创建的.subversion目录里。使用svn命令可以向项目在本地的副本添加文件，或者从中删除文件：
$ cd checkout
$ vi foo.c
$ svn add foo.c
完成之后，把您的改动提交给Subversion库：
$ svn commit -m “Initial checkin; added foo.c”
不必列出您想要提交的修改过的文件列表，虽然您愿意的话，也可以这么做，svn能分析得到它自己的文件列表。如果省略了-m选项，那么svn会启动一个编辑器，您可以编辑提交消息。
要从Subversion库获得最新更新，可以在项目中运行svn update。和在CVS系统里一样，Subversion在项目的本地副本和主控库里修改过的所有文件上执行一次合并操作。冲突无法解决的文件被标为“conflicted（有冲突）”，您只有先改正这些问题，告诉Subversion冲突已经解决了，Subversion才能让您把文件检入到库中：
$ svn resolved foo.c
如果您想要知道一个文件里的哪些行是由谁改的，可以要求Subversion提供抱怨信息：
$ svn blame bar.c
这条命令打印出了这个文件包含说明的版本，显示出文件每行内容上次由谁在什么时候修改过（要获得容错性更好，或者说最乐观的特性可以使用svn praise命令）。Subversion也能很容易地提供相对于一个特殊日期或者版本的变化信息。例如，如果您想要知道自从2006年6月2日以来，foo.c这个文件发生了哪些变化，就可以用下面的命令：
$ svn diff -r "{2006-06-02}" foo.c
您可以从subversion.tigris.org下载最新版的Subversion。该软件的标准文档是O’Reilly出版的Version Control with Subversion一书。在svnbook.red-bean.com上可以在线获得全文内容。
Subversion还有一个出色的Windows GUI；参见tortoisesvn.tigris.org。我们用它管理本书的源文件。
23.3.8 文档
给软件配置建立正确的文档对于让您的站点流畅运行来说绝对至关重要。如果您正式发布本地的配置，那么就必须给每种新发布提供有用的发布说明。即使您的站点太小，不足以采用正式发布的办法，让其他系统管理员和您的用户群都知道您做过什么改动也是很重要的。您肯定不愿意让另一个办公室的人因为他们无法搞清楚为什么他们的软件在目前的发布上坏了而在凌晨4点给您打电话。
另外，维护一份汇总文档，介绍您的站点和标准发行版本的不同之处也是很有用的。这份文档以本地化复查表的形式来维护帮助最大，复查表里描述了如何设置您的本地环境（也就是说，对基本安装做哪些改动）以及（如果两个步骤不同的话，它们经常不一样）如何安装一台新机器。
有关建立文档的问题将在本书的第29章详细介绍。
23.3.10 客户机安装多少软件
本地软件实际应该装在哪儿：在各个客户机上，还是在一台能够通过NFS共享本地软件的中央文件服务器上？NFS的解决方案能够让更新的速度快得多（更新10台NFS服务器要比1000台客户机快），节省客户机上的磁盘空间（虽然在充斥着50GB硬盘的世界上，这几乎不再是个问题），还更容易做备份（如果有任何本地状态，那么备份10台服务器要比备份1000台客户机容易）。
这个问题实际上归结为可管理性同速度和可靠性之间的对比。远程访问是集中式的，更易于管理，但是访问网络总是要比直接访问本地磁盘速度慢。此外，远程服务器模式还加入了对网络和远程文件服务器的依赖性。
无盘工作站在UNIX的早期时代，硬盘还非常贵的时期相当常见。这些机器没有硬盘，它们所有的文件（包括它们的根分区和交换分区）都要通过网络来取得。我们并不推荐这种配置（出于这个原因，无盘工作站要淘汰了），但是FHS确实允许/usr的所有内容都可以被远程共享，许多站点都利用了这一功能。
23.4 用rsync或者rdist保持系统更新
好了，您已经掌握了“集中式发布”的思想，并且制定了一些您要支持的特定配置。现在您该如何让所有的单台主机看上去都像是主控主机呢？将来如何更新它们呢？
常见的方法有两种：用rsync这样的工具直接把文件从一台主控主机复制到各个主机上，或者使用发行版本中所带的软件包管理系统安装新的或者是升级的软件包。后一种选择可以用apt-get这样的系统自动处理。参见第18章，回顾保持系统文件同步的几种方式。
有些站点会做定期更新；这一方案确定了客户机系统过期的时间上限。其他站点则在主机引导的时候更新它们；这一方案虽然保险，但意味着两次更新之间的时间太长。有些站点里的用户懂技术，这些站点就让用户自己选择何时更新他们的机器。这是一种没有强迫性的协作方案，但是您可能会发现一些用户不催的话永远也不会做更新。
迄今为止，使用rsync或者rdist是在保持系统同步方面最古老、最传统的技术。在服务器上，您只要制定一项夜间执行的cron任务，把文件用rsync或者rdist送到客户机上即可。有了这样的系统，您就能保证，机器只要开机就能保持更新。
作为一种备选方法，您可能会考虑使用“拉”的机制，由客户机来负责请求更新。拉的系统让客户机能更好地控制它们所做的更新安排。例如，在“每天夜里”更新的站点上，正确的更新时间则取决于时区；在美国的夜间更新相当于在亚洲的工作日当中更新。您能够通过在服务器上以守护进程模式运行rsync，让每台客户机发起自己的rsync任务来实现“拉”更新。SystemImager也会以提供updateclient工具来促进拉更新的实施。
rsync一般要比rdist更好，但是它们两者的设置都很容易；参见18.2节了解更多的信息。根据您的机器数量总共有多少，以及它们覆盖的地理区域有多大，您既可以只设置一台分发主机，也可以建立一个分发主机的层次结构。例如，您可以让一台中央的主控服务器向其中有机器的每座建筑物里的从服务器发布更新，而从服务器接下来再把更新分发给客户机。这种层次布局的确能够降低消耗的WAN带宽。
使用rsync/rdist保持一个文件系统（比如/tools）的更新非常直观易懂；几乎没有什么暗藏的困难。不过，要用这些工具来更新您的核心OS安装则困难得多。首先，需要维护一份在更新期间保持不动的文件清单。这份清单应该包括那些规定了主机自身信息（比如Red Hat上的/etc/sysconfig/network文件）的文件、由守护进程创建的文件（比如大多数以.pid结尾的文件）、临时文件（/tmp和/var/tmp），以及和正在运行的进程有关的文件（比如/proc）。/var下的大多数文件都应该不动。您可能要复制/etc的某些部分，也可能不用，这取决于您想要保持多少一致性。
更新特定的一些文件必须要采用特殊的步骤。例如，在您安装了新内核之后，必须重新运行lilo命令。这实际上是一个rdist优于rsync的方面：它有一项特殊的操作，可以容许做这些考虑。不过，只要对rsync稍加发掘，也能达到同样的效果。您可能需要在rsync之后运行一个shell脚本完成清理工作，或者加入一项cron任务，在每天夜里运行lilo。
下面的这个例子列出了要rysnc在Red Hat机器上不予处理的文件。您几乎肯定还要加上其他一些您不想复制的文件（例如，/etc/resolv.conf，如果您不想到处共享它的话），但从这个文件开始是一个很好的起点。
