2311.3 6 本地化和配置

针对您的本地环境对计算机进行调配是系统管理的主要任务之一：告诉系统网络上所有打印机的位置、启动专门发放许可证的守护进程，加上每周清理一次/scratch目录的cron任务，集成对绘图部门的特殊扫描仪的支持等。要注意让这些事情都按有组织和可重复的方式完成，这就是系统结构考虑的中心目标。

牢记下面的要点。

— 用户没有超级用户（root）权限。在正常操作过程中，出现要求获得超级用户权限的现象都很可疑，或许预示着您的本地配置有可疑之处。

— 用户意外地破坏系统。设定内部安全机制，让它保护系统不受意外失误的影响，也不会散布管理权限。

— 应该对行为轻微不端的用户先面谈再惩罚。对于效率不高的管理流程，用户会通过暗中破坏的方式来频繁报复，所以考虑用户不愿遵守纪律的现象可能预示着结构性的问题则是明智之举。

— 以客户为中心。和用户交谈，询问他们什么任务他们觉着最难。找到让这类任务更简单的方法。

— 您个人的偏好只是个人的。让用户有他们自己的偏好。尽可能提供多种选择。

— 当您的系统管理决策影响了用户对系统的使用时，要清楚所做决策的理由。让大家知道您的理由。

— 保持本地文档不断更新，而且容易获得。参考第30章的内容了解有关这个话题更多的信息。

安装好一台新的计算机只是完成了一半工作。需要为每台机器对通用配置做改动几乎是无可避免的事情。下面给出的一组针对本地化的特定指导原则能让您和您的用户方便不少，而且还考虑到了构筑能够支持数千台计算机的安全环境。

许多本地化的问题实际上都是规程方面而不是技术方面的问题，您或许在开始安装计算机之前就应该先考虑它们。您必须面对全部问题，正确的解决方案则取决于您站点的性质。您的机构是很集中的吗？还是有若干不同的用户组，需要对他们的计算机有一定程度的控制权？您的用户懂技术吗？还是他们都是初学者？您的站点要求达到什么程度的安全性和保密性？这些宏观方面的问题有很多会在本书的第29~~章里介绍。~~

您特别应该考虑如何避免站点内的每台机器能被所有其他的机器访问到。您还必须能保证您的方案能便于在系统管理员弄乱系统以及系统发生故障之后恢复过来。

~~把您的Linux~~环境想成是一个软件产品——一个由您所选择的发行版本、本地应用、管理定制措施以及您用于系统管理的任何软件所构成的软件产品——会有助于工作。避免许多问题的关键就在于遵守可靠的软件工程惯例：使用版本控制、定义质量保证规程，以及给您的规程和发布建立文档。

如果您只有几个系统，那么可以不管其中的一些棘手问题。不过，任何时候考虑您所管的范围可能会增大都不算太早。如果您的规程能够扩展受理更多的负担，那么您的机构就可以更平稳地扩大。

23~~.3.1~~ ~~自动化~~

~~要求对每台新主机进行手工干预的本地化方案是不能扩展的方案。不管它们的初衷有多好，系统管理员都会犯错误，跳过某些步骤。根据墨菲定律（Murphy’s Law），这些疏忽总能找一条路悄悄回来，正好在您最受不了它的时候给您一个回击。~~

~~本地化的过程是最适宜进行自动化处理的地方。不管您的编程技术有多么不济，Perl脚本通常都会证明，它还是会比一份~~8页长的复查表更不容易出错。自动化处理是让站点的规划能够扩展到数百乃至数千台主机规模的“神奇妙方”——一次完成改动，而不是成千上万次地重复它们。

2311.36.2 1 版本升级本地化的组织

如果您的站点有1 000台计算机，每台计算机都有自己的配置，那么您的大部分工作时间都会花在确定为什么一台机器有个特别的问题，而另一台却没有。显然，解决这种局面的办法就是让每台计算机的配置都一样，不是吗？但是现实世界里的限制，以及用户多变的需求一般不会让您做到这一点。

在系统的可管理性上，多重（multiple）配置和无数（countless）配置有着很大不同。诀窍在于要把您的设置划分为可以管理的小部分。您会发现有些本地化的部分适用于所有被管主机，而有些部分则只适用于几台主机，而剩下的一些部分专门针对个别机器。

除了从头开始安装系统之外，您还需要持续铺开系统更新。要记住，单台主机有自己在电流、稳定性和开机时间（uptime）方面的要求。

谨慎的系统管理员决不应该一股脑地放出新的软件发布来。相反，软件发布应该按阶段，根据一项逐步的计划提供出来，这一计划会将其他组的需求包含进来，而且还要考虑留些时间，在问题所造成的危害尚且有限时就能发现它们。在您对所要做的改动有一定信心之前决不要贸然更新关键服务器^{^[11]}。

不过，您在设计本地化的系统时，要确保把原来所有的数据都保存到了一个版本控制系统中~~单台主机有自己在电流、稳定性和开机时间（uptime）方面的要求~~。谨慎的系统管理员决不应该一股脑地发出新的软件发布来。相反，软件发布应该按阶段，根据一项逐步的计划提供出来，这一计划会将其他组的需求包含进来，而且还要考虑留些时间，在问题所造成的危害尚且有限时就能发现它们。在您对所要做的改动有一定信心之前决不要贸然更新关键服务器。

~~遗憾的是，大多数系统管理员都发现他们自己支持要有多重软件配置的想法。不过，在系统管理上，多重（~~~~multiple~~~~）配置和无数（~~~~countless~~~~）配置有着很大不同。诀窍在于要紧紧控制住前者，不要让它们悄悄就变成了后者。~~

~~在这场战斗中，您主要的武器就是一个版本升级系统。把本地的~~OS~~安装当作是一个独立的软件发布，它有着自己的发布版本编号系统和测试规程。~~这个预防措施方法让~~具有很大优点：~~您可以跟踪哪些改动已经完全测试过，准备好用于部署。此外，它还能让您辨别出任何引发问题的改动。在这个过程中涉及的人越多，上面考虑到的措施也就越重要。这些观点或许都不正确，但是我们倾向于支持限制软件发布的数量。~~把某个新的软件发布用在生产（production）主机上之前先测试一下它；您可以在发生问题之后将系统退回（roll back）到一个“安全的”软件发布，最重要的是，您可以把您环境里的配置数量限制在一个很小的、能管理好的数值上。~~

~~内部发布版本的组成应该包括：一个~~OS~~平台、应用、为本地操作环境所做的定制，以及对这些组成部分所打的任何必需的补丁。每一个发布都应该带发布说明（参见~~23~~.3.8节）和适当的验证步骤。~~

~~有几种实现版本化发布的方法。新安装可以使用SystemImager这样的系统，它能为每个发布定义一个独立的映像。如果您采用Kickstart~~或者~~YaST~~这样的基于软件包的安装程序，那么只能一一列出组成每个发布的各个特定的软件包（以及软件包的版本）。当本地定制本身就是打包完成的时候，采用基于软件包的系统效果特别好。

仔细考虑好您想要保留的发布数量。存在的发布数量越多，您必须要关照的发布数量也就越多。另一方面，不要修改没有坏的发布。没有理由地升级系统不但费时费力，而且“最新”往往意味着“最麻烦”。

~~还要考虑高度正式的发布控制系统所带来的成本和缺点。要准备好让成本~~/效益之间的权衡适合于您的站点，而且要证实您所做的决定是正确的。发布控制的规程会让您的管理小组不够灵活，而且会影响您快速响应紧急情况的能力（例如，如果您有一个安全补丁要马上落实，就可能没有时间按照正确的发布管理规程来处理）。不过，这些代价往往会被降到最低，而且同长期的获益相比一般也不大。按您自己的时间安排来升级系统，要比因为外部的一次紧急情况来迫使系统升级好得多。

把基础的OS版本和本地化的OS版本区分开来是有好处的。根据环境对稳定性的需求不同，您可以使用仅仅修正了bug的改动最轻微的本地版本。不过我们发现，一点点增加新特性的过程，比起排着队把多项修改一股脑加到“重大”版本中，冒着服务出现大问题的风险来说，并不会更顺利。

您随时能掌控最多多少“版本”，那就制定多少“版本”，这样做往往是个不错的主意。有些系统管理员认为，软件没有出问题的话，就没理由要去修正。他们指出，无端地去升级系统费时费力，而一切“前卫”在太多情况下都意味着“代价惨痛”。实施这些原则的人就必须乐意接受更多的活动版本类型。

与此相反，喜欢“精悍”的人士们则指出，这些版本自身很复杂不说，要理解（更不用说管理）这些经年累月留下来的各式版本也很困难。他们打出的王牌是安全补丁，一般而言必须打这些补丁，而且要经常打。给过期的操作系统版本打补丁往往不可避免，所以系统管理员就要面临选择，是在有些计算机上跳过升级，还是将这些机器彻头彻尾地升级为一个更新的内部版本。这情形可真算不上好。

上述两种观点没有一种是肯定正确的，但是我们倾向于支持乐意限制版本数量的一方。按照您自己的时间安排做升级，要比遇到外部的一次紧急情况被迫升级更好。

23~~.3.3~~ ~~离群的用户和部门~~

软件配置的标准化过程经常会造成冲突。有技术倾向的用户（有时是整个部门）可能会觉得集中式的发布控制系统不能充分地满足他们的配置需求，或者他们需要对自己使用的计算机有自主控制权。

您的第一步努力可能就是要尝试促成这类“离群”用户接受标准配置，从而把支持他们所需的成本和时间降到最少。不过，这样的“铁碗”方法通常既让用户不高兴，也让系统管理员不悦。要牢记一点，离群用户的愿望经常是完全合理的，而且系统管理员的任务就是要去支持他们——或者至少也要避免让他们的日子更不好过。

最可取的（但是经常也是不可行的）解决方法就是让这些离群的用户参与制订发布内容的过程。如果他们有一个正式的、制度化的良好渠道，通过这个渠道，他们能够影响到标准发布的内容（或者有一个在系统管理员监督下制订的他们自己的发布），他们可能就不需要那么多的本地控制权。这种沟通渠道必须易于使用，而最重要的应该是反映迅速；如果建议被采用之前已经累积了6~~个月之久的话，那么就没有人会对系统管理员可以解决个别需求的能力有信心了。~~

另一种融合策略就是把支持工作交由他们去自治。让离群的用户或者用户组为所欲为，但要明确，他们必须也要为保证定制系统的运行而负责。要清楚地说明，您不会去清理烂摊子，但是要注意该以什么样的方式提出这么一种安排。这一方案应该是作为因系统管理资源有限而不可避免、令人惋惜的结果被提出来的，而决不能作为“照我的方式做，否则我就不奉陪了”这样让人觉得是强权的方式提出来。

您可能还需要采取措施，保护您所控制的系统不会受到机构内桀骜不逊、无法无天的自治区域的伤害。例如，有些地方把自治区域放在了内部防火墙的后面，这样一来，当网络的其余部分还在庆幸不要去管“自发”区域的同时，“自发”区域就能出乎意料地把双方都搞崩溃。

无论您怎么做，都不要让您自己走上随便接受别人创意的道路。那样是浪费您的时间，而且它开了一个危险的先例。必要的时候，您可以用一种得到支持的配置来重装机器；让用户去掂量接受帮助同保留一个自定义环境相比的代价和好处。

2311.36.4 2 测试

在对外界做出改动之前先测试很重要。~~至少这意味着您需要测试自己的变动~~至少这意味着您需要测试自己本地的配置变化~~（比如新版的配置文件，像sendmail.cf~~）；。不过，您确实也应该测试一下厂商发布的软件。~~一家知名的~~一家主要的UNIX~~（幸好还不是Linux~~）厂商曾经有一次发布了一个会执行rm -fr ./的补丁（在以某种方式施加这个补丁的时候）。先设想一下，没有先测试就在您的机构内到处施加这个补丁会有怎样的情况出现~~——我们猜您要去找新工作了~~。

如果您使用了像apt-get或者Red Hat Network这样的服务，它们提供自动打补丁的功能，那么测试就成了一件非常重要的事情。关键性的应用系统一定不要直接连到厂商支持的更新服务上。找一台可以牺牲的机器，连到这样的服务上，在测试正确后，再从这台机器把改动传遍站点内的其他机器。在测试过程中禁止更新，否则，在您测试的同时，可能会将更改的顺序弄颠倒，过早地偷偷渗透到您的生产系统之中。

您肯定不愿意自己的关键主机下载到一个不完整的补丁，所以这些系统不应该直接连到一种更新服务上。一种合理的机制是要有一台得到自动更新的机器用作一台“重要的主控主机（~~gold master）”。定期以这台主控主机上的瞬态映像构造新的发布，测试它们，然后慢慢把它们发布到机构的其余部分。~~

要确保让您的用户配合您的测试制度。他们往往不太愿意这么做，但是他们的参与却至关重要——这是能够涵盖到他们实际使用的全部组件的唯一途径。您当然应该有您自己的测试过程复查表，但是在覆盖范围上不可避免地会有疏忽和遗漏。如果某个您忘记了的虽然小但却很关键的应用不能配合您刚刚安装的~~glibc运行，那么您将要面临的就会是一个痛苦的恢复过程。~~

如果您预见到一次有计划的更新活动会引发用户能看到的问题或者变化，那么就要提前通知用户，让他们有机会和您交流一下，他们是否在意您打算做的改动或者做改动的时间。要保证用户有很容易的方法来报告bug~~要确保用户有一条报告bug的方便途径。如果填写bug报告单很麻烦，那么用户一般会忽略问题，然后想当然地认为“别人会去报告的”。参考29.5节了解有关bug追踪（“故障工单”）系统的更多知识。~~。参考30.9节的内容了解有关bug跟踪的更多知识。

~~如果您的机构是全球性的机构~~如果您的单位在地理位置上是分散的，那么就要~~，就要~~确保其他办事处也能帮忙做测试。国际性的参与在多语言的环境中特别有价值。例如，如果在美国的办事处里没有人讲日语，那么您最好让东京的办事处来测试任何可能影响到对日文汉字支持的东西。随地点不同而变化的系统参数多得惊人。美国的办事处会测试对采用A4纸型打印设施的改动吗？还是非美国的办事处参与才能给大家带来一个惊奇？（译者注：美国普遍采用的纸型为Letters，而欧洲多采用A4纸型。）

2311.36.9 3 本地软件的位置本地编译软件

在UNIX的早期时代，当时有许多不同的体系结构，程序一般都是以源代码包的形式发布的，通常这种源代码包是.tar.Z文件，您可以解压缩，然后编译它们。一旦构建好了程序，接着就可以把软件安装在像/usr/local这样的地方。现如今如今，使用软件包管理系统则意味着几乎没有什么程序要以这样的方式来安装。它也意味着系统管理员几乎不需要决定把软件安装到哪儿，因为软件包指出了它们的内容会安装到什么地方。

即使有了简便的软件包管理，可许多人仍然愿意编译他们自己的软件[12]。执行您自己的构建过程能让您对软件的编译选项有更多的控制。它还能让您更偏执，因为您可以检查正在编译的源代码。有些人认为这很重要，但是除非您有时间和技术检查有20 000行代码的软件包中的每行代码，我们还是会怀疑增加的安全价值可能非常之低。

因为这个世界上不是每种软件都有用于每种Linux发行的打包版本，~~所以很可能至少会有几种程序需要您自己安装~~所以很可能至少会有几个程序需要您自己安装，特别是如果您的Linux主机不是基于Intel的IA-32体系结构时更是如此。而且，如果您的站点是一个开发站点，您将不得不考虑该把站点自己本地开发的软件安装到什么地方。

从历史上看，本地软件最常用的位置一直是/usr/local，这个习惯到了今天仍然被广为遵守，UNIX/Linux的FHS（Filesystem Hierarchy Standard，文件系统层次结构标准）规定，在OS的初始安装完成之后，要有/usr/local目录，而且为空。许多软件包都要把它们自己安装在那儿。

~~从历史上看，本地软件最常用的位置一直是/usr/local，这个习惯到了今天仍然被广为遵守，UNIX/Linux~~的~~FSH~~（~~Filesystem Hierarchy Standard，文件系统层次结构标准）规定，在~~OS~~的初始安装完成之后，要有/usr/local目录，而且为空。许多软件包都要把它们自己安装在那儿。~~还有数目不少的其他软件（尤其是商业应用）要求安装在/usr里，在没有软件包管理系统的环境下，这么做一般这是个不好的想法[13]，。我们的经验是，虽然许多应用软件要安装到/usr下，但把它们安装到别处一般工作起来也不会有问题~~应该予以避免，并在您力所能及的程度上保证/usr多少和您的发行版本安装它时一样~~。对于个别不规矩的软件包，~~如果您确实有个应用坚持要把文件装到/usr，那么~~我们建议您把文件实际放装在别处，只是在/usr里建一个指向它们的符号链接。另一种方案是检查这个不规矩的应用是不是要读取一个环境变量的值来找到自己的安装目录。这样的特性通常会有文档予以说明，但并不一定如此。

虽然/usr/local是传统位置，但是许多站点发现它成了不好管理的倾倒场。它的传统布局方式（基本上和/usr一样，在/usr/local/bin里放二进制文件，在/usr/local/man里放手册页，依此类推）造成了大量问题：难以安装同一软件的多个版本，目录会变得很大，管理多种体系结构会很痛苦等。

~~比较大的站点经常会求助于为软件创建它们自己的名字空间约定。这个名字空间经常通过NFS~~或者~~Coda~~（两者都常用于支持多种体系结构）这样的网络文件系统来安装。常见的技术是使用一个三级的层次结构，顶级按厂商或者软件分类，在它下面是应用程序一级，再下面是版本一级。顶级的分类可以基于厂商、基于功能或者（对于内部应用程序来说）基于开发产品的小组。例如，如果您是按照功能来组织分类的，那么可能会有一个~~graphics目录，里面包含gimp~~、xv~~和其他图形工具。Stow是一种维护层次结构的有用工具；从www.gnu.org可以找到它。~~

接着，您可以创建目录/tools/graphics/bin，其中包含链接到每个软件包最新二进制程序的符号链接。例如，如果有人要用gimp 1.0.4，他们可以直接运行它。这种方法的缺点之一是“老工具决不会消失”。一旦您已经有了更新的版本，就该考虑宣布软件包老版本“结束生命”的时限。11.6.4 发布本地软件

您站点里的本地系统必须做好初始安装和增加更新两方面的工作。更新工作特别富有诀窍。因为您可能想要重复整个本地化过程，只为更新一个文件的权限，所以高效性成了一个关键问题。即使这个过程是自动执行的，“从头再来”的构建模式也会让更新工作成为一个费时费力的过程。

组织本地化工作的一种简单且可扩展的方式就是维护一个树形结构下的文件，这个结构模拟出某个生产机器上的文件系统（框架）。有一个专门的安装脚本可以把这个目录树复制到目标主机上，完成所需的任何编辑工作。

这种类型的设置有几个优点。实现您的本地管理方案需要多少目录树，您就可以维护多少本地化的目录树。有些树是可供选择的，一台机器只能选择其中之一。有些树可以覆盖，能复制到它们之前的树上面。如果必要，本地化的目录树可以覆盖文件，或者也可以完全分解。每个有可能独立安装的树都应该用一个单独的版本控制项目来表示。

覆盖树的方法在实现上有很大灵活性。如果您使用了一个打包系统来发布本地定制信息，那么覆盖树可以简单地汇集起来成为独立的软件包。在软件包中可以包括适当的定制脚本，设为在安装过程中执行。

另一种比较好的实现思路是使用rsync命令让目标机器和它们的覆盖树保持一致。rsync命令只复制那些过时的文件，所以它对于发布增量变化来说特别高效。单用软件打包系统的方式还很难模拟这种方式。参考17.3节了解有关rsync的更多知识。

11.6.5 解决时间安排上的问题

有些站点定期更新所有的系统。这样的计划可能有点强迫性，但是它也有优势，能够规定客户机的系统过时的时间上限。一些别的站点让系统在启动的时候更新自己。这是一种相对安全的选择，但它也意味着两次更新之间可能会间隔很长时间。有些站点的用户技术水平较高，让用户自己选择什么时候更新自己的机器。这是一种协作性的对用户友好的方案，但是它倾向于需要有另一种方案做补充，因为有些用户从不会自己去更新系统。

更新既可以从更新服务器（通常通过cron）“推（push）”出，也可以由各个客户机去“拉（pull）”回来。拉回更新的系统赋予客户机更多的控制权，从而能控制自己更新系统的时间安排。例如，一家全球运作的机构可能会发现，采用一个在夜间“拉”回更新的系统更容易实现，在美国的半夜升级在亚洲就成了正午升级。