Linux 系统管理技术手册（第二版）

版权信息

书名：Linux 系统管理技术手册（第二版）

ISBN：978-7-115-17514-4

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

•　著　　　　[美]Evi Nemeth Garth Snyder Trent R.Hein

　 译　　　　张　辉

　 责任编辑　李　际

•　人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

　 邮编　100164 　电子邮件　315@ptpress.com.cn

　 网址　http://www.ptpress.com.cn

•　读者服务热线：(010)81055410

　 反盗版热线：(010)81055315

版权声明

Authorized translation from the English language edition, entitled LINUX ADMINISTRAITON HANDBOOK, 2nd Edition, 0131480049 by Nemeth, Evi; Snyder, Garth, published by Pearson Education, Inc, publishing as Prentice Hall, Copyright © 2007 Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD.,and POSTS & TELECOMMUNICATIONS PRESS Copyright © 2008.

本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签。无标签者不得销售。

内容提要

本书延续了本书前一版以及《UNIX系统管理技术手册》的讲解风格，以当前主流的5种Linux发行版本（Red Hat ES、SUSE、Debian、Fedora Core和Ubuntu）为例，把Linux系统管理技术分为3个方面分别介绍。第1部分全面介绍了运行单机Linux系统涉及的各种管理知识和技术，如系统引导和关机、进程控制、文件系统管理、用户管理、设备管理、系统备份、软件配置以及cron和系统日志的管理使用等。第2部分从详细讲解TCP/IP协议基本原理开始，深入讨论了网络的两大基本应用——域名系统和路由技术，然后逐章讲解Linux上的各种Internet关键应用，如电子邮件、NFS、文件共享、Web托管和Internet服务，在这部分里还有专门的章节介绍网络硬件、网络管理与调试以及系统安全。第3部分包括了多种不容忽视的重要主题：X窗口系统、打印系统、系统维护与环境、性能分析、与Windows系统的协作、串行设备、操作系统驱动程序和内核、系统守护进程以及政策与行政管理方面的知识等。

本书的几位作者是分别来自学术界、企业界以及职业培训领域的Linux/UNIX系统管理专家，这使得本书从第一版开始，即成为全面、深入而且颇富实用性的Linux系统管理权威参考书。本书适合于从Linux初学者到具有丰富经验的Linux专业技术人员使用。

关于供稿人

Lynda McGinley在教育领域从事系统和网络管理工作有20年了，她曾经是《UNIX系统管理技术手册》（第三版）（中文版已由人民邮电出版社出版）的供稿人之一。现如今，她在美国大学大气研究联盟（University Corporation for Atmospheric Research）担任系统安全工程师。Lynda相信，自己在科罗拉多大学为Evi做了数年系统管理员的经历会让大家牢牢记住她。

Ben Whaley是Applied Trust Engineering公司的一名资深工程师。他获得了科罗拉多大学计算机科学专业的学位，并且还是Red Hat认证工程师。Ben不但从事Perl和PHP编程，而且在启蒙课程中担任教师。

在20世纪90年代后期，Adam Boggs一直在科罗拉多大学本科生实验室做第一线的学生系统管理员。前几年他在从事内核开发工作，为Solaris和Linux系统开发文件系统和存储管理。目前，他在为用于大气建模的超级计算机做网络、存储和集群管理工作。

Jeffrey S. Haemer从1983年起就一直在从事与Linux和商业版的UNIX相关的工作，他始终坚持不用Microsoft Word软件。他前前后后在打印机制造公司QMS里工作过11年。Evi曾经教Jeff开车。他最喜爱的口头禅是：“A man, a plan, a canal, Suez”。

Tobi Oetiker是电气工程师，工作干的却是系统管理员。他从1994年起就开始做系统管理工作。他在苏黎世理工（ETH Zurich）工作了多年，为那里的师生建立了一个功能丰富的计算环境，同时还编写了几种流行的开放源代码软件，例如MRTG、RRDtool和SmokePing，现在他在Oetiker+Partner AG公司工作，这是一家提供IT和咨询服务的公司。他已经结婚，生活在瑞士。

Fritz Zaucker学的是物理学。他先前从事了几年气候变化方面的研究，之后领导苏黎世理工（ETH Zurich）信息技术和电气工程系的IT支持小组（IT Support Group，ISG.EE）长达10年之久。他和一群志同道合的同事们一起，把ISG.EE变成了一个专业机构，主要面向高效系统管理、可靠IT基础设施以及满足客户需求。现在他加入了

Oetiker+ Partner AG公司，和他的一些朋友和同事一起工作。Oetiker+ Partner AG公司是一家IT和管理咨询公司，同时还提供IT服务。Fritz同Evi及其侄女一起在地中海驾艇畅游，诚心邀请读者朋友们也来Wonderland号上和她一起享受一下。

Scott Seidel是Applied Trust Engineering公司的一位资深工程师，他在该公司专门研究企业安全和性能管理。他从位于玻尔得（Boulder）的科罗拉多大学获得工商管理学位，研究重点在信息系统和金融方面。Scott感兴趣的研究领域包括系统监测和服务器虚拟化。在管理Linux系统的工作之余，Scott喜爱在厨房里自酿新酒。

Bryan Buus在Adeptive Software公司担任负责工程的副总裁，这是一家承接定制软件开发的公司。在网络公司（.COM）热潮之前，Bryan是XOR公司负责开发的副总裁，他领导该公司的Web和Internet服务部门。Bryan获得波士顿大学计算机科学学士和硕士学位。

Ned McClain是Applied Trust Engineering公司的创办人之一，也是该公司的CTO。在美国的USENIX和亚洲的APRICOT这样的技术大会上，他主讲各种涉及系统管理和安全的专题。Ned从美国康奈尔大学工学院获得计算机科学专业的学位，他还是一位CISSP（编号39389）。

David Schweikert在瑞士的苏黎世理工（ETH Zurich）做系统管理员，他在那里主要负责电气工程系的电子邮件系统。他是开放源代码项目Mailgraph（绘制邮件统计图的工具）和Postgrey（用于Postfix的一种greylisting[灰名单]技术实现）的开发者。David还对数据库和大型站点的系统管理有兴趣。

关于作者

Evi Nemeth已经从科罗拉多大学（University of Colorado）计算机科学系教师的岗位上退休了，但是她仍然在参与CAIDA的网络研究工作，CAIDA是圣地亚哥超级计算中心（San Diego Supercomputer Center）的Internet数据分析协作组织（Cooperative Association for Internet Data Analysis）。她现在正坐在自己的新玩具—12米长的帆船Wonderland号—上遨游加勒比海呢。

Garth Snyder曾经在NeXT和Sun公司工作过，他从斯沃索莫学院（Swarthmore College）获得了电机工程专业的学位，并且在罗彻斯特大学（University of Rochester）取得MD和MBA学位。

Trent R. Hein是Applied Trust Engineering公司的创办人之一，这是一家提供网络基础设施的安全和性能咨询服务的公司。Trent从科罗拉多大学（University of Colorado）获得了计算机科学专业学士学位。

致 谢

许多人都以这样或者那样的方式为本书的编写工作提供了帮助，他们的帮助包括从技术评审或者习题建议一直到精神上全面支持的各个方面。我们要特别感谢下面这些人士，感谢他们一直给予我们的鼓励：

Bo Connell Jon Corbet Jim Lane

Sam Leffler Cricket Liu Derek Martin

Laszlo Nemeth Eric Robinson Sam Stoller

Paul Vixie Aaron Weber Greg Woods

我们不但要感谢Prentice Hall公司负责本书的编辑Catherine Nolan和Mary Franz，而且还要褒奖她们能够成功地和我们这几个有点儿不靠谱的作者以及一群“配角人物”打好交道，后者有时候似乎就是多达成千上万的供稿人。

作为版面文字编辑，Mary Lou Nohr再次做出了异常优秀的工作成绩。她做到了集补救高手和润色大师的角色于一身。我们要说，我们今后将非常高兴同她再度合作。

Mark G·Sobell在索引上面肯定付出了细致和耐心的工作。我们对结果非常满意，多谢他的帮助。

最后，Evi要向加勒比海沿岸海滩上的众多酒吧和咖啡屋表示歉意，同时也要谢谢它们。Evi把她的帆船停泊在信号最强的地方，偷偷地使用了它们的免费无线网络接入服务。当Evi坐在船上把身边的天堂美景抛到一边，忙于处理本书各个章节的时候，她发誓说这将是她写的最后一本。不过，她说的这话谁会当真呢？

第一版序

能预先看到这本书，我感觉到异常的兴奋，因为这是UNIX System Administration Handbook（USAH）一书专为Linux出版的最新版本。USAH第三版已经包含了Red Hat Linux的内容，但当时它仅仅是4种不同的UNIX变体之一。本书的这一版介绍的则全部是几种不同的Linux发行版本，原先与Linux无关的素材大多被略去不再赘述了。我自己也很好奇，想看看它究竟和以前有多少不同之处。

太多了，它涵盖的内容真是太多了。Linux各个发行版本都是从开放源代码软件的共同资源中提炼出来的，所以比起UNIX的其他版本来说，它们彼此之间要相像得多。因此本书内容的针对性显得愈发突出。几位作者不但阐述了您的系统运行“可能”采取的各种不同方式，而且现在还会准确地告诉您，它是如何“那样”运行的。

与此同时，本书仍然全面介绍了UNIX种类繁多的丰富软件。现在，世界上的流行软件几乎全都能在Linux上运行，而Linux的站点却发现它们所面对的威胁越来越少。随着像IBM、Oracle和SGI这样的业界巨人展开双臂热情地将Linux拥入怀中，它正在迅速成为世界的标准，人们会拿别的UNIX版本和这个标准做比较（而且还不一定能比得上！）。

正如本书所体现出来的那样，Linux系统和与之对应的那些专有UNIX一样功能强大、一样安全，也一样可靠。幸亏有了数以千计的Linux开发人员无时无刻的努力，才让Linux比以前任何时候都准备得更充分，更适合投入到现实世界的各条“战线”上。本书的几位作者十分熟悉“地形”，所以我很高兴地把您交到他们最有能力的手中。尽情享受阅读带来的乐趣吧！

Linus Torvalds—Linux之父

April 2002

2002年4月

前言

当我们在大约5年前编写本书第一版的时候，Linux才刚刚开始在企业级的应用领域中崭露头角。那时候，我们希望本书第一版会有助于传播这样的信息，即Linux已经是一种最高档次的操作系统，具备了同Sun、HP和IBM公司的系统产品相媲美的实力。

现如今Linux已经是IBM提供的产品了。IBM在2004年宣布其全线服务器均支持Linux，对于任何还在等待明确无误的信号来表明Linux这汪池水对于企业级游泳者已经没有危险的人们来说，这个消息非常振奋人心。没有人曾经因为购买了IBM的产品而丢掉工作，采用Linux基本上也是一项同样保险的提议。^[1]

我们着手撰写本书的目的，就是让它成为专业Linux系统管理员的最好朋友。在任何合适的地方，我们都会重新编写我们以前写过的深受读者欢迎的书—《UNIX系统管理技术手册》（已由人民邮电出版社出版）—所验证过的概念和资料。我们加上了大量专门针对Linux的素材，并且把其余内容根据最新情况做了调整，但是本书的覆盖面仍然保持和原来的类似。我们希望您能够认可这一点，即这样做的结果会给读者送来一本高质量的Linux系统管理工作指南，它得益于过去几个版本的经验。

Linux系统管理方面也有不少别的书籍，但是其中没有一本能在深度和广度上，提供在现实的商业环境下高效地使用Linux所必须掌握的资料。下面是本书有别于他人的突出特色。

• 我们采取了一种结合实践讲述问题的方式。我们的目的不是复述系统手册上的内容，而是总结我们在系统管理工作中积累起来的经验。这本书包含了许多在现实中向困难宣战的故事，也给出了大量注重实践的建议。

• 这本书不是讲如何在家里、在车库里或者在PDA上运行Linux。我们介绍的是如何在实际工作的环境下，比如商业公司、政府机关以及大学里使用Linux。

• 我们详细地讲解了Linux的连网技术。这是系统管理工作中最为困难的方面，也是我们认为自己可以向读者提供最多帮助的领域。

• 我们没有过于简化材料。我们的例子都反映出了实际中的真实情况，并没有掩盖它们所有的繁冗和复杂。在大多数情况下，这些例子都是直接取自实际工作的系统。

• 我们介绍了5种主流的Linux发行版本。

我们举例的发行版本

和许多操作系统一样，Linux也在成长过程中出现了几个不同方向的分支。虽

然内核的开发仍然保持高度的集中，但是打包和发布完整Linux操作系统的工作则由各种不同的组织来完成，每家都有自己的套路。

我们详细介绍了5种Linux发行版本：

• Red Hat^® Enterprise Linux^® 4.3 ES；

• Fedora™ Core 5；

• SUSE^® Linux Enterprise 10.2；

• Debian^® GNU/Linux 3.2“Etch”（2006年9月的测试发布）；

• Ubuntu^® 6.06 “Dapper Drake”。

我们之所以选择这几种发行版本，不仅因为它们最流行，而且因为它们是整个Linux界的代表。不过，本书里的许多内容也都能应用到其他主流的发行版本上。

对于我们所讨论的每个主题，我们都提供了有关每种发行版本的详细信息。针对某种特定操作系统的注释，则用发行版本的徽标标出。

本书的组织

本书分为3大部分：基本管理技术、网络管理技术和其他管理技术。

基本管理技术部分从系统管理员的角度全面介绍Linux。其中的章节涉及运行单机Linux系统所需要的大部分知识和技术。

网络管理技术部分描述了Linux系统使用的各种协议，介绍了用来安装、扩展和维护网络所使用的各种技术。在这个部分中还介绍了高层网络软件。各章的专题内容包括域名系统、网络文件系统、路由技术、sendmail和网络管理。

其他管理技术部分包括各种各样的补充信息。其中有些章节讨论了一些可选的软件包，例如Linux的打印系统。其他一些章节就各种主题——从硬件维护到Linux安装的执行策略——提供了若干建议。

每一章的后面还有一组练习题。我们用星号标出了我们估计要完成这道题所需付出的努力，“努力”则体现在题目的难度和需要花费的时间两方面。

题目有4级：

没有星号简单题目，应该很容易就能做出来；

★ 比较难或者要花比较长时间的题目，可能要求做实验；

★★ 最困难或者最花时间的题目，要求做实验，并进行深入分析；

★★★★ 作为整个学期的项目（只在个别章节出现）。

有些习题需要有系统上的root或者sudo权限，有些题目要求得到本地系统管理小组的许可。有这两种要求的时候，习题会予以说明。

我们的供稿人

我们很高兴Adam Boggs、Bryan Buus和Ned McClain能以供稿人的身份再度参与本书的编写工作。我们还欢迎Ben Whaley、Tobi Oetiker、Fritz Zaucker、Jeffrey S. Haemer、David Schweikert和Scott Seidel在这一版也成为我们的供稿人和朋友。他们在各个领域的深厚知识已经极大地丰富了本书的内容。我们首先要向Lynda McGinley表示感谢，她不但编写了大量文字内容，而且还不知疲倦地组织和协调了供稿人的工作。

我们希望您会喜欢本书，并祝您的系统管理工作好运连连！

Evi Nemeth

Garth Snyder

Trent R. Hein

2006年10月

[1]　至少对于服务器而言是这样。现在的竞争集中在台式机上，微软的Windows仍然在这个领域保持着几乎垄断的地位。Linux和Windows竞争的结果尚难预料。到目前为止，Windows提供的用户界面仍然更精美一些。但是要想战胜“免费”的Linux可绝非易事。

第一部分　基本管理技术

第1章　从何处入手

我们着手编写的是一本可以成为系统管理员所信赖的工作伙伴的书，它不但提供实用建议，而且还包含系统管理的基本理论，读者不可能通过阅读系统手册获得这些知识。因此，本书的目的就是补充而不是替代Linux系统文档。

本书以如下5种方式向读者提供帮助：

• 概述几种主要的管理系统，确定每种管理系统的不同组成部分，并且解释它们怎样一起发挥作用；

• 介绍一些通用的管理技术，我们根据经验发现这些管理技术既有效又有益；

• 帮助读者选择解决方案，随着站点规模和复杂性的增加，这些解决方案仍然行之有效；

• 帮助读者从各种想法中汲取精华，剔除糟粕，并且告诉读者由版本发布者造成的各式各样的错误；

• 总结一些共同的处理步骤，以使读者不必为了完成简单的任务而深究手册中的过多细节。

本书不可能绝对客观地履行这些功能，但是我们认为，我们已经在字里行间中相当清楚地说出了我们自己的偏好。在系统管理领域，实际中会有这样一个有趣的现象：对于最合适的策略和步骤该由什么来构成这一问题，理性的人们可能会有完全不同的观点。我们把我们的主观意见作为原始数据提供给读者。对于我们的建议，读者必须自己决定能接受多少，并在多大程度上用于自己的环境。

1.1　读者的知识背景

本书假定读者已经具备一定程度的Linux或者UNIX经验。尤其是在学习管理

知识之前，读者应该从用户的角度对Linux的风格有一个一般性的概念，有一些优秀的书籍可以帮助读者迅速掌握这些概念，参见本章1.10节。

用户要执行的大多数管理任务都是通过编辑配置文件和编写脚本来完成的，因此读者必须熟悉某种文本编辑器。让许多用户感到沮丧的是，把Microsoft Word作为自己惟一的文本编辑器来用，这将会极大地妨碍进行有效的系统管理工作。

我们极力建议读者学会使用vi（在Linux系统中最常见的是它的一种经过重写的形式，即vim）。该编辑器是所有UNIX和Linux系统上的标准软件，尽管同emacs这样的华丽软件相比，vi可能显得有些平淡，但vi的功能还是非常强大和完善的。我们也喜欢用pico，这是一种“入门者的编辑器”，简单易学，适合系统管理员新手使用。许多Linux发行版本中都包含有pico。选用非标准的编辑器则要小心，如果读者已经对这样的一种编辑器“上了瘾”，那么很快就会对需要把它带在身边以便在每个新系统上安装而感到厌烦。

系统管理工作的主要支柱之一（并且也是贯穿本书的一个主题）是使用脚本来自动完成管理任务。要成为高效的管理人员，必须能够阅读并修改Perl和sh脚本（后者在Linux下实际上是bash脚本）。读者从头开始写的脚本可以用shell或者自己所选择的脚本语言来编写。

对于编写新脚本，我们推荐使用Perl或者Python。作为一种编程语言，Perl有些奇怪。不过，它确实包含了许多对于管理员来说是必不可少的特性。本章1.10节给出了该书的完整信息。从cpan.org可以了解到有关Perl语言的所有精选软件。

许多管理员更愿意用Python而不是Perl，而且我们也知道有些站点正在一起努力从Perl转向Python。Python是一种比Perl更精练的语言，而且Python脚本往往可读性更好，也更容易维护。

我们还推荐读者学习expect，它与其说是一种编程语言，倒不如说是用于驱动交互式程序执行的前端语言。读者极有可能会很快地学起expect脚本来。

1.2　Linux同UNIX的关系

在一句话里同时用Linux和UNIX这两个称谓就仿佛一脚踏入了政治漩涡，或许也像是陷入了一大片泥潭。我们尽可能言简意赅地描述出的现实就是这个样子。

Linux重新实现了UNIX，也丰富了UNIX。Linux遵循POSIX标准，能够在几种硬件平台上运行，兼容现有的大多数UNIX软件。它同大多数别的UNIX变体的不同之处在于，它是自由的，开放源代码的，而且是由成百上千不同的个人和组织无私奉献协同开发出来的。Linux融入了在原来的UNIX版本中所没有的技术改进，所以它超出了克隆UNIX的范畴。从法律意义上讲，它也是一种有别于UNIX的东西，严格来说不能称之为“UNIX”。

还值得一提的是，Linux不是现今世界惟一的自由UNIX版本。FreeBSD、NetBSD和OpenBSD，以及从UC Berkeley（加州大学伯克利分校）的BSD（伯克利软件发布，即Berkeley Software Distribution）发展而来的所有分支，都有其各自的热诚追随者。虽然这些操作系统从第三方软件厂商得到的支持有点少，但它们在功能和可靠性上却往往可以同Linux相媲美。

Linux软件就是UNIX软件。多亏有了GNU计划，使UNIX系统更富价值的重要软件大多都以某种开放源代码的形式被开发出来。在Linux和非Linux系统上运行的代码是相同的。比如说，Web服务器Apache全然不在意它是在Linux上还是在HP-UX上运行的。从应用软件的立场来看，Linux只不过是得到最好支持的UNIX变体之一罢了。

UNIX和Linux系统用于生产环境已经有许多年了。同其他大多数介绍Linux系统管理的书不同，本书着重介绍如何在一个工作环境中——而不只是在单用户桌面环境中——有效地使用Linux^[1]。

1.3　历史上的Linux

Linux源自于芬兰研究生Linus Torvalds在1991年的一项个人计划。他最初构想的这个项目是要作为Minix的一个有限分支，Minix是由Andrew S. Tanenbaum编写的一种模型操作系统。但是Linux引发了世界上对它的普遍浓厚兴趣，内核很快呈现出了它自己的生命力。利用协作开发的巨大力量，Linus得以实现更富有雄心的开发进度。1.0版内核于1994年发布，在撰写本书（英文版）的时候（2006年9月），Linux内核的最新稳定版本是2.6.17。

因为Linux继承了其祖先UNIX的太多东西，所以把Linux时代的开端算做1991年并不算非常公正。UNIX的历史要回溯到几十年前的1969年，它源于当时在AT&T贝尔实验室中的一个研究项目。1976年，UNIX被无偿向大学发放，因而成了许多操作系统课程和学术研究项目的基础。

1977年，加州大学伯克利分校的计算机系统研究小组（Computer System Research Group，CSRG）从AT&T获得了有许可证的代码，自此成为伯克利UNIX（Berkeley UNIX）的开端。伯克利的发布版本（称为BSD，代表Berkeley Software Distribution）从1977年用于PDP-11的第一个版本1BSD开始，到1993年以最高版本4.4BSD结束。

随着UNIX获得了商业上的认可，源代码许可证的价格迅速攀升。最后，伯克利制订出长期目标，要从BSD中去除AT&T的代码，这是一个单调乏味而且耗时的过程。在这项工作即将完成时，伯克利失去了研究操作系统的资金支持，于是CSRG被解散了。

在解散以前，CSRG发布了其不含AT&T代码的最终软件包，即4.4BSD-Lite。目前大多数BSD UNIX的版本（包括FreeBSD、NetBSD、Mac OS X^[2]和OpenBSD等）都宣称4.4BSD-Lite软件包是它们的“鼻祖”。

大多数其他的主流UNIX版本（包括HP-UX和Solaris）都是有原AT&T代码“血统”的后代。Linux并没有和AT&T或者BSD风格的UNIX共享代码，但是从功能上看，Linux系统的位置则介于两者之间。

1.4　Linux的发行版本

Linux不同于其他UNIX变体的原因在于，它只定义了一个操作系统内核。内核必须同命令、守护进程（daemon）以及其他软件一起打包（packaged）来组成一个可以使用的完整操作系统——用Linux的术语来说就是一个“发行版本（distribution）”。所有的Linux发行版本共享相同的内核源，但是和内核一起的辅助材料则随着发行版本的不同而有很大不同。参考30.16节开始的内容了解有关发行版本的更多说明。

上述的“辅助材料”由过去30年里成千上万人开发出的大量软件所构成。一直以来都存有这样的争议，即把完整的操作系统简单地称为“Linux”的做法没有让那些开发人员的贡献得到承认，也没有体现出他们工作的历史延续性，这种争议还是有些道理的。遗憾的是，最常被推荐采用的替代称谓“GNU/Linux”也有它自己的历史包袱，所以只有Debian这个发行版本正式使用它。在维基百科“GNU/Linux naming controversy（GNU/Linux称谓的争议）”这个词条中列出了争执双方各自的理由。

各发行版本在其侧重点、支持度和流行度方面都不尽相同。表1.1列举了最流行的通用发行版本。这些发行版本按字母顺序而不是按优先级或者流行度来排列。

表1.1　　最流行的通用Linux发行版本

　　a．以前的Mandrakelinux。

表1.1没有列出许多较小的发行版本，许多没有列出的专用发行版本专门供有特定需要的人们（比如嵌入式系统的开发人员）使用。

Knoppix（www.knoppix.com）是表1.1之中没有列出的一种很有用的发行版本，这个版本的Linux保存在一张可以启动的CD-ROM上。它最重要的价值在于，当某个Linux系统因为安全或者技术问题而无法启动的时候，可以用作恢复光盘使用。可启动光盘的概念得到广泛认同，绝大多数发行版本都开始向这个方向转变。现如今的Ubuntu就可以从发行光盘启动，Knoppix的作用变得越发不重要了。从www.frozentech.com/content/livecd.php可以找到可启动Linux发行版本的最新清单。

在过去将近十年的时间里，Red Hat公司一直是Linux界的领头羊，它的发行版本在北美地区最有影响力。到了2003年，Red Hat Linux发行版本分裂成了两种，一种是以生产应用为中心的产品线，叫做Red Hat Enterprise Linux（在本书中有时候称之为RHEL），另一种是依托Linux社群的开发项目，叫做Fedora。在技术、经济、后勤和法律等诸多因素的综合作用下，才促成这次分裂，但时至今日，两方面的发行版本依然保持着相似性。RHEL提供大量支持，而且稳定性好，但是如果不向Red Hat公司支付许可证费，则无法有效地使用它。

CentOS项目（www.centos.org）收集了Red Hat为遵守各种许可证协议（最知名的就是GNU的GPL许可证）而必须公布的源代码，把这些源代码整理成一个类似于Red Hat Enterprise Linux，但是却免费的完整发行版本。这个发行版本没有Red Hat商标，也没有个别一些专有工具，但是其他各方面都和RHEL相似。CentOS追求同RHEL在二进制乃至bug上面的完全兼容。

对于那些想要部署一个面向生产应用的发行版本，但又不想向Red Hat公司交钱的地方来说，CentOS是一种很好的选择。采用混合搭配的方式也可行：前端服务器运行Red Hat Enterprise Linux，使之获得Red Hat公司良好的支持，而桌面则运行CentOS。这样的安排既照顾到让重要的基础系统获得安全保障和技术支持，又将成本和系统管理的复杂度降至最低。

SUSE现在属于Novell公司，最近走上了和Red Hat一样的路子，分裂成两种相关的发行版本：一种叫做openSUSE，只包含自由软件；另一种叫做SUSE Linux Enterprise，要花钱购买，包含正规的支持渠道，并且多提供了一些额外的东西。以前，SUSE似乎在有意回避它有免费版本的事实，但是Novell已经比其前任更为支持SUSE的这个免费版本。现在，读者可以直接访问www.opensuse.org获得最新的信息。本书的内容不专门针对哪一种SUSE的发行版本，所以我们就直接把它们都统称为“SUSE”。

Debian和Ubuntu这两种发行版本都保持着支持Linux社群开发和开放访问的思想意识，所以两者都不存在任何有关自身哪部分自由，哪部分可以重新发布的问题。Debian在GNU社群的热情支持下生存了下来，而Ubuntu目前还在享受着南非企业家Mark Shuttleworth的慈善资助。Ubuntu甚至无需读者支付邮费就可以邮寄免费的光盘。

1.4.1　最好的发行版本是什么

在网上随便搜索一下，就会发现这是问得最多、答得最少的Linux问题之一。对于读者来说，正确的答案取决于您要怎样使用系统、您所熟悉的UNIX变体是什么，以及您对支持的需求。

大多数Linux发行版本能够完成您想要让Linux系统完成的所有任务。它们中的一些可能要求安装附加的软件来获得完整的功能，有些可能会让某些任务更容易完成。然而，它们之间并不会有太大不同。实际上，为什么会有那么多种不同的发行版本，且每种都宣称“易于安装”和“丰富的软件库”是其突出的特色，这本身就是一件挺奇怪的事情。于是难免会得出这样的结论，人们只不过是喜欢做出新的Linux发行版本罢了。

另一方面，既然我们在本书中所关注的是大型Linux安装的管理问题，那么我们就会侧重考虑像Red Hat Enterprise Linux这样用于管理计算机网络的发行版本。有些发行版本的设计考虑到了生产环境，其他的发行版本则没有。面向生产环境的系统所提供的额外支持功能，对于方便系统管理工作来说，带来了巨大的不同。

当用户采用了一种发行版本之后，就是在某个特定发行商的做事方式上进行了投资。不要只看到软件安装以后的功能，而是要明智地考虑到，自己的单位和那家发行商要在未来的数年里共事。因此要取得一些重要问题的答案。

• 该发行版本能够在今后5年内继续存在吗？

• 该发行版本会有最新的安全补丁吗？

• 该发行版本会迅速发布更新软件吗？

• 如果我有问题，发行商会帮助我吗？

有了这样的认识再来看，有些更有意思、规模更小的发行版本就不会太有吸引力了。另一方面，最有生命力的发行版本并不一定是最商业化的发行版本。例如，我们认为Debian（对，就是Debian GNU/Linux！）在相当长的一段时间里是会存在的，尽管Debian并不是一家公司，既不销售任何东西，也不正式提供需要的支持。

在www.linux.org/dist和distrowatch.com上都可以找到Linux发行版本的完整清单，其中也包括非英语的发行版本。

在本书中，我们采用5种流行的Linux发行版本作为例子：Red Hat Enterprise Linux 4.3 ES、Fedora Core 5、SUSE Linux Enterprise 10.2、Ubuntu 6.06（“Dapper Drake”）以及当前（到2006年9月为止）还是测试版的Debian GNU/Linux 3.2（“Etch”）。这些系统是企业级Linux市场的代表，它们合起来占据了如今在大型站点中投入使用的Linux的大部分。

1.4.2　特定于发行版本的系统管理工具

许多发行版本提供了可视化的工具（比如Red Hat的Network Administration Tool或者SUSE的YaST2），帮助用户配置或者管理选定的系统功能。这些工具非常有用，特别是对于管理员新手来说更是如此，但是它们倾向于掩盖用户在进行改动时实际发生的细节。在本书中，出于下述原因，我们要介绍可视化工具调用的底层机制，而不是工具本身。

第一，可视化工具趋于专有化，或者至少是趋于为发行版本所特有，它们给配置过程带来了变数，而在各个发行版本之间，这些过程在较低层面上实际上可能是相当一致的。第二，我们相信，对于系统管理员来说，准确了解他们的系统是如何工作的非常重要。当系统发生故障的时候，可视化工具通常对于确定并修正问题来说没有什么帮助。最后，手工配置往往更好：更快、更灵活、更可靠，而且更易于用脚本实现。

1.5　表示法和印刷约定

在本书中，文件名、命令和命令的参数用粗体（黑体）来表示；占位符（例如，不应该按字面直接照搬的命令参数）用斜体来表示。例如，在下面的命令中：

cp　file　directory

用户应该用实际的文件名和实际目录来分别替换file和directory。

配置文件和终端会话的节录用等宽字体来显示^[3]。有时候，我们用斜体字来给交互式会话做注释，例如：

$ grep Bob /pub/phonelist　　　　　/* 查找Bob的电话号码 */
Bob Knowles 555-2834
Bob Smith 555-2311

在这些特定情况以外，我们试图把特殊字体和格式约定减到最少，只要我们这样做不会影响理解即可。例如，我们经常会提到的一些词条，比如叫做daemon的Linux组和打印机anchor-lw等，根本不采用特殊格式。

一般说来，我们使用的约定与联机用户手册中用来表示命令的语法相同：

• 中括号（“[”和“]”）之间的任何内容都是可选的；

• 英文省略号（“...”）后面的任何内容都是可以重复的；

• 大括号（“{”和“}”）表示应该选择由竖线（“|”）隔开的各项中的一个。

例如，规则：

bork [-x] {on | off } filename ...

可以匹配下面任何一条命令：

bork on /etc/passwd　
bork -x off /etc/passwd /etc/termcap
bork off /usr/lib/tmac 

我们将shell风格的特殊字符用于模式匹配：

　星号（*）匹配零个或多个字符；

• 问号（?）匹配一个字符；

• 中波浪线（~）表示当前用户的主目录（home）；

• ~user表示user用户的主目录。

例如，我们会采用速记模式/etc/rc*.d来指代Debian的启动脚本目录/etc/rc0.d、/etc/rc1.d等。

引号中的文本经常具有确切的技术含义。在这些情况下，我们忽略英语的一般规则，把标点符号放在引号外边，以使读者不会对什么包括而什么不包括在引号中产生混淆。

特定于系统的信息

除非指定出一种特定发行版本，否则本书中的信息通常适用于我们用来举例的所有发行版本。只适用于某种特定发行版本的细节采用发行商的徽标来标记：

Red Hat^® Enterprise Linux^® 4.3 ES

Fedora™ Core 5

SUSE^® Linux Enterprise 10.2

Ubuntu^® 6.06 “Dapper Drake”

Debian^® GNU/Linux 3.2 “Etch”（2006年9月的测试版）

使用这些徽标都获得了其各自拥有人的许可。

1.6　从哪里获得信息

Linux的文档分布在一系列资源中，读者会发现其中有些已经安装到了自己的系统中，而有些还留在网上。较大的资源有：

• 手册页（man页），用命令man阅读；

• Texinfo文档，用命令info阅读；

• HOWTO，就各种不同主题发表的简短说明；

• Guide，就各种不同主题发表的较长论述；

• 特定于发行版本的文档；

• 同特定的软件项目有关的Web网页。

man手册页和Texinfo文档构成了传统的“联机”文档（当然，所有的文档都以这样或者那样的形式在线存在）。这些文档一般伴随系统一起安装，针对特定程序的man手册页通常随着新软件包一同安装。

man手册页对单条命令、驱动程序、文件格式或者库例程做简洁的描述。它们不会解释诸如“我该怎样安装一个新设备？”或者“为什么我们的系统这么慢？”这样较为普通的话题。对于这些问题来说，用户必须参考HOWTO。

Texinfo文档是在很久以前由GNU人士发明的，针对的是设定man页面格式的nroff命令为AT&T专有这一现实情况。现在，我们已经有了GNU的groff来为我们完成这项工作，nroff的问题不再重要了。遗憾的是，许多GNU软件包坚持用Texinfo文件而不是man页面来提供自身的文档。Texinfo除了为文档规定了不必要的标准之外，其自身也表现为一种相当错综复杂的超文本系统。

要摆脱Texinfo的麻烦，可以把info命令的输出通过管道送给less命令，避开info命令内建的浏览体系。这样做还有一个好处，就是能让使用者利用less命令内置的搜索功能。

幸运的是，采用Texinfo提供文档的软件包通常会安装指示性的man页面，告诉用户使用info命令来阅读了解那些特殊的软件包。用户可以坚持使用man命令来查找手册，只有在被告知要采用info时再这么做，这样的做法很保险。命令info info将会把用户带入Texinfo的黑暗神秘世界。

HOWTO和guide是由Linux建档计划（Linux Documentation Project，LDP）维护的。LDP是所有各类Linux有用信息的中心知识库。它也集中力量将Linux的相关文档翻译成其他语言。

特别针对系统管理而言，一些免费的在线LDP guide有：Lars Wirzenius、Joanna Oja、Stephen Stafford和Alex Weeks编写的The Linux System Administrators' Guide；Mendel Cooper编写的The Advanced Bash-Scripting Guide；Olaf Kirch和Terry Dawson编写的The Linux Network Administrator's Guide，Second Edition；以及Steve Frampton编写的Linux System Administration Made Easy。

遗憾的是，许多LDP文档现在并没有得到持续维护。因为Linux的时间概念相对于真实的时间来说要短得多，被忽略掉的文档容易很快过时。一定要查看HOWTO或者guide上的时间戳，并据此估计它的可信度。

Linux基本软件中最重要的部分里有许多是由中立的第三方来维护的，比如Internet软件联盟（Internet Software Consortium）和Apache软件基金会（Apache Software Foundation）。这些组织一般为它们所发布的软件包提供充足的文档。发行版本有时包含了软件，但却给文档打了折扣，于是，到软件原本的发源地看看有没有更多的材料常常会有帮助。

有关许多Linux软件包设计原理的另一种有用信息源是“RFC（Request for Comments，请求评议）”系列文档，它们描述了在Internet上使用的协议和过程。参考第12章了解更多的信息。

1.6.1　手册页的组织

Linux的手册页一般分成9节，如表1.2所示。

表1.2　　Linux手册页的各节及其内容

手册页中有些节会做进一步细分。例如，第3M节经常包含了有关系统中数学库的手册页。第6节和第9节一般是没有内容的。很多系统在手册中都有一个称之为l的节，用于本地手册页。另外一个惯用的约定是把第“n”节作为特定于软件的子命令（例如bash的内建命令）。

手册页的nroff输入通常保存在/usr/share/man/manX目录中，X是1～9的数字，或者是字母l或n。正常情况下，页面会以gzip压缩，以节省空间（命令man知道如何当场将它们解压缩）。手册的格式化版本保存在/var/cache/man/catX目录中。命令man会随需要确定手册页格式；如果cat目录可写，那么man也将在创建格式化页面的同时，把经过格式化的页面存放到cat目录中去，从而生成一个常读手册页的高速缓存。

命令man实际上会在若干不同的目录中寻找用户需要的手册页。用户可以使用manpath命令来确定搜索路径。这个搜索路径（在Fedora中）一般为：

$ manpath 
/usr/kerberos/man:/usr/local/share/man:/usr/share/man/en:/usr/share/man

如果有必要，用户可以设置自己的环境变量MANPATH来覆盖默认路径。用户也可以在/etc/man. config（RHEL和Fedora）或者/etc/manpath.config（SUSE、Debian和Ubuntu）中设置系统级的默认搜索路径。

1.6.2　man：读取手册页

man title命令格式化特定的手册页并通过less命令（或者在PAGER环境变量中指定的任何程序）把手册页发送到用户终端。title通常是一个命令、设备或文件名。手册中的各节大致是按照数字顺序进行搜索的，不过通常首先搜索描述命令的那些节（第1、8和6节）。

命令格式man section title可让用户从某个特定的节获取手册页。于是，man tty命令可得到tty命令的手册页，man 4 tty命令可得到针对控制终端驱动程序的手册页。

man -k keyword输出一份手册页清单，在其单行概要中有keyword。例如：

1.6.3　其他的Linux信息资源

在世界上有一个巨大的Linux爱好者群体。我们不可能说出每一处有用的Linux信息资源，或只是主要的资源，但是在表1.3中给出了几个很重要的信息资源。

不要羞于访问普通的UNIX资源——大多数信息都能直接用于Linux。在网上可以获得有关系统管理的丰富信息，形式非常多样。例如，用户可以在任何流行的搜索引擎，比如Google、Yahoo!或者Ask中键入系统管理方面的问题。在第30章中可以找到一份其他“入门”资源的清单。

表1.3　　Web上的Linux资源

许多站点直接迎合了系统管理员的需求。下面是我们特别喜爱的几个站点：

• www.ugu.com——UNIX Guru Universe（UNIX高手世界），有许多系统管理的资料；

• www.stokely.com——系统管理资源链接的好集合；

• www.tucows.com——Windows和Mac软件，按质量进行了筛选；

• slashdot.org——“计算机迷”的新闻“集散地”；

• www.cpan.org——Perl脚本和库的中心资源库；

• securityfocus.com——安全信息，巨大而且可以搜索的安全漏洞数据库。

另一个有趣且有用的资源是Bruce Hamilton的“Rosetta Stone”网页，地址为http://bhami.com/ rosetta.html。它提供了在许多不同的操作系统上执行各种系统管理任务所使用的命令和工具的指导。

1.7　如何找到和安装软件

大多数Linux发行版本把它们的软件分成可以彼此独立安装的软件包。当用户在一台新的计算机上安装Linux的时候，一般要选择一定范围的“起步”软件包，把它们复制到新的系统上。

这种体系简化了系统配置许多方面的工作，也是Linux优于UNIX传统版本的关键点之一。遗憾的是，这种设计也使得写书介绍这些发行版本的任务复杂了，因为总是不能确切地搞清楚哪些软件是某个给定发行版本的“一部分”。如果一个软件包在安装光盘中，但又不是默认安装的一部分，它还算是该发行版本里的软件包吗？只有在运行那个发行版本的每台计算机上都有这个软件包时，它才算是该发行版本里的软件包吗？如果它只在发行版本的超级版“奉送”光盘上才有，那么它算是该发行版本里的软件包吗？

在本书中，我们一般介绍每个所举例子的发行版本的默认安装。当我们说某个特殊软件包没有包含在默认安装里的时候，并不一定意味着该软件包不会出现在读者的系统上，或者读者的发行版本不支持它。下面就讲一下，如果读者有该软件，如何把它找出来，如果读者没有该软件，那么怎样得到它。

首先，使用shell的which命令来找出相关命令是否已经在搜索路径中。例如，下面的命令揭示出GNU的C编译器已经安装在了本机的/usr/bin目录下：

$ which gcc 
/usr/bin/gcc

如果which没有找到要找的命令，那么试试whereis，该命令搜索更大范围的系统目录，和shell的搜索路径无关。还要注意，有些系统上的which命令不显示用户没有执行权限的文件。例如：

另一种方法是采取作用非凡的locate命令，它考察预先编译好的一个文件系统索引，以此确定与特定模式相匹配的文件名。它搜索的并不特定于命令或者软件包，而是能够找到任何类型的文件。例如，如果读者不能确定在哪儿能找到头文件signal.h（它是Linux信号定义的正式代码），可以试试：

locate的数据库通常由updatedb命令在每天晚上重新生成，这条命令由cron来运行。因此，执行一次locate的结果不是总能够反映出文件系统新近的变化。

如果用户知道正在找的软件包的名字，那么也可以使用系统上的软件包工具来直接检查是否有该软件包出现。例如，在Red Hat、Fedora或者SUSE系统上，下面的命令可以检查是否有Python脚本语言：

$ rpm -q　python
python-1.5.2-27

参考第11章，了解有关在我们举例的系统中软件打包命令的更多信息。

如果感兴趣的软件包似乎还没有安装，那么找它的第一个地方就是所用发行版本的自动软件包管理系统。每一种发行版本都支持某种形式基于Internet的升级旧软件包和查找新软件包的系统。最常见的系统有yum和APT，这两种系统将在本书的11.4节介绍。

例如，在使用APT的Debian系统上，就可以用下面的命令获得并安装最新版的Python：

# apt-get install python

大多数Linux软件是由独立的小组开发，这些小组以源代码的形式发布软件。接着，Linux发行商收集源代码，按照其特定系统上采用的规范来编译，并将二进制编译结果打包。安装特定于发行版本的二进制软件包通常要比取得并编译原来的源代码更容易。但是，发行商提供的软件有时候要比当前的版本落后一两个版本。

两个发行商使用相同的软件打包系统不一定意味着两个系统的软件包能够互换使用。例如，Red Hat和SUSE都使用RPM，但是它们的文件系统布局有点儿不一样。如果能得到针对于您的特殊发行版本而设计的软件包，那么就用它，这始终是最好的做法。

如果其他方式没有找到，那么试试在一个下载站点上查找该软件包，或者用该软件包的名字在Google上搜一下。

1.8　系统管理员的基本任务

下面各小节简要介绍了一般要求系统管理员履行的若干工作。这些职责未必是由一个人来执行的，在许多地方，这项工作会分配给几个人。不过，确实至少需要一个人懂得全部工作，并确保有人正在做这些工作。

1.8.1　增加、删除以及管理用户账号

系统管理员负责为新用户增设账号，将不再活动的用户账号删除。增删用户的处理过程可以自动进行，但在增设新用户之前，仍然必须做出某些管理决定（把用户的主目录放在什么位置、在哪些机器上创建账号等）。参考第6章了解有关添加新用户的更多知识。

当某个用户不应该再访问系统时，必须禁用该用户的账号。由该账号拥有的所有文件必须备份到磁带上并保存起来，以使系统不会随着时间的增长，积累不想要的信息。

1.8.2　增删硬件

购买了新硬件或把硬件从一台机器移到另外一台机器上时，必须配置系统，使之识别并使用该硬件。硬件支持的任务可能很简单，例如添加打印机，也可能是复杂得多的任务，例如添加磁盘阵列。参考第7章、第28章和第23章了解有关这些专题的更多知识。

1.8.3　执行备份

执行备份可能是系统管理员最重要的工作了，这也是经常被忽视或者不经心去做的工作。备份工作耗时且单调，但又绝对必要。备份可以自动进行并授权给下属去做，但系统管理员仍然要确保备份工作在按计划正确进行（备份产生的介质真的可以用来恢复文件）。参考第9章了解有关备份的更多知识。

1.8.4　安装和更新软件

当获得新软件时，必须安装并测试它，并且经常在几种类型的操作系统和硬件下进行安装和测试。一旦软件能够正常工作，就必须通知用户可以用它，以及它的位置。在补丁和安全升级被发布出来的同时，也必须平稳地将它们融入到本地环境里。

本地软件应该安装到合适的位置，让用户能容易地把它同系统软件区分开来。采用这样的方式可以简化升级操作系统的任务，因为本地软件将不会被升级过程所覆盖。参考第11章了解有关软件管理的更多知识。

1.8.5　监视系统

大型设备需要时刻进行监视。日常的监视活动包括确保电子邮件和Web服务正常工作、查看日志文件来掌握故障的早期迹象、确保本地网络都连接正确，并监视系统资源（例如磁盘空间）的可用性。

1.8.6　故障诊断

Linux系统和运行它们的硬件系统偶尔会发生故障。充当技工来诊断故障以及在必要时请来专家排除故障等就成了管理员的工作职责。找出问题往往比修复更为困难。

1.8.7　维护本地文档

系统为适合单位的需要而逐渐改造，随着改造的进行该系统便开始不同于文档当初所描述的那个基本系统了。给整个系统特定于本地环境的各方面建立文档是管理员的职责。这项职责包括为新安装的，但又不是伴随操作系统而来的任何软件编写文档，把电缆的走线位置以及电缆连接方式等信息编写成文档，维护所有硬件维护记录，记录备份状态，编写本地处理过程和策略的文档等。参考30.8节了解有关文档的建议。

1.8.8　时刻警惕系统安全

系统管理员必须实施某种安全策略并定期检查，以确保系统安全没有受到侵害。在安全要求低的系统上，这项工作任务可能仅仅包括对非授权访问进行粗略的检查。在安全要求高的系统上，这可能包括仔细布置陷阱和审计程序的监视网。有关安全主题的更详细信息，请参见第20章。

1.8.9　帮助用户

尽管帮助用户解决各种问题很少包括在系统管理员工作的规定范围之内，但这通常占据了多数系统管理员日常工作的很大一部分。系统管理员往往遭到从“我的程序昨天正常工作了，今天却不干活了！您改变了什么？”到“我把咖啡洒在键盘上了！我应该泼水到键盘上洗掉咖啡么？”等形形色色的问题的狂轰烂炸。

1.9　重压下的系统管理员

系统管理员通常有多种身份。在现实生活中，系统管理员经常从事其他工作，但同时又被请来管理身边的一些计算机。如果您是处于这种情况，那么也许想要考虑一下这种兼职最终可能出现的情况。

您对您的系统懂得越多，那么用户群体对您的依赖也就越多。网络规模总是在增长，您可能不得不花费更多的时间在系统管理上。很快，您就会发现在您所在的机构中，您成了唯一懂得怎样去执行各种重要任务的人。

一旦同事们开始把您看作是本地系统的管理员，那时要把自己从这种角色中解救出来就很困难了。我们就知道有几个人为了逃避这种状况已经改变了自己的工作。由于许多管理任务是无形中的，您还可能发现自己所在的单位希望您既成为一名全职的系统管理员，同时也成为全职的工程师、作家或秘书。

有些不乐意这样做的系统管理员通过态度不好和服务差劲儿来摆脱这类要求，我们不推荐这种方法。这种方法有损自己的形象，并且可能产生更多问题。

相反，我们建议您把花费在系统管理上的时间用文档的形式写出来，您的目标应该是保持其工作处于可以管理的水平，而且应该搜集让您在申请减轻管理任务时用得上的证据。在大多数单位里，您需要游说管理层半年到一年的时间以后，才可能让自己的管理员位置由别人来取代，因此应该提前计划好。

另一方面，您可能发现自己喜欢系统管理员的工作，并希望成为全职的系统管理员，那么找到一份工作将不会有什么问题。请参考第30章，以预先了解可能出现的一些“恐怖”问题。

系统管理员人格综合症

作为系统管理员，由于其工作而导致的不幸却常见的临床症状是“系统管理员人格综合症”。这种症状通常开始于系统管理员职业生涯的第三年年初，并且症状能够持续到退休。特征症状如下所述，但绝不仅限于这些。

• 急性寻呼机幻想恐惧症：烦乱地觉得自己的呼机已经关闭（而实际上没有）、觉得自己平和的夜晚以及其他有意义的事情即将突然结束，要不吃饭来干长达72小时马拉松式的工作。

• 用户巫毒绘画症：强制性地给自己的用户群中的某些人创建巫毒娃娃（扎针草人）画像，这些人似乎不知道他们老是缺乏计划的行为并没有给您的世界带来紧急情况。

• 查看磁带强迫症：深夜出现突如其来的强烈欲望，想要安装备份的磁带以查看磁带是否确实可读、磁带的标签是否正确。

• 科学方法强迫症：强烈地希望去粗暴地摇晃那些看来还没有采用科学方法的从事系统管理的同事。

有许多医疗方法可以用来治愈这些不幸的症状。最有效的是培养良好的幽默感和营造一个小而丰富的办公室酒窖。还可以考虑更具思考意味的方法：任何时候，当有人在您旁边说“服务器是不是又死机了？”时，让自己静静地向远处眺望，并同时敲击自己的脚后跟。如果所有别的治疗方法都不管用，那么就休假吧。

1.10　推荐读物

在出版领域中针对系统管理最好的资源（除去本书之外）就是O’Reilly公司的系列图书。这个系列的图书从20年前的UNIX in a Nutshell开始，到现在已经给每个重要的UNIX和Linux子系统以及命令都单独出了书。这个系列还包括有关Internet、Windows和其他非UNIX专题的图书。所有这些书都价廉物美、内容及时而且针对性强。Tim O’Reilly对开放源代码运动相当有兴趣，为此专门搞了一个OSCON大会，而且还为其他一些技术潮流搞了大会。OSCON每年召开两次，美国一次，欧洲一次。

虽然市场上有许多介绍性的Linux书籍，但是尚未发现值得我们毫无保留地给予推荐的书。一般而言，读者最好找到UNIX的“经典著作”。您读到的几乎每样东西都能同等地用到Linux上。

SIEVER, ELLEN, AARON WEBER, AND STEPHEN FIGGINS. Linux in a Nutshell (5th Edition). Sebastopol, CA: O’Reilly Media, 2006.

LAMB, LINDA, AND ARNOLD ROBBINS. Learning the vi Editor（6th Edition）. Sebastopol, CA: O’Reilly and Associates. 1998.

POWERS, SHELLY, JERRY PEEK, TIM O’REILLY, AND MIKE LOUKIDES. UNIX Power Tools (3rd Edition). Sebastopol, CA: O’Reilly Media, 2003.

WALL, LARRY, TOM CHRISTIANSEN, AND JON ORWANT. Programming Perl (3rd Edition). Cambridge, MA: O’Reilly Media, 2000.

CHRISTIANSEN, TOM, AND NATHAN TORKINGTON. Perl Cookbook (2nd Edition). Sebastopol, CA: O’Reilly Media, 2003.

GANCARZ, MIKE. Linux and the Unix Philosophy. Boston: Digital Press, 2003.

SALUS, PETER. The Daemon, the GNU & the Penguin. Groklaw. 2006.

1.11　习题

　E1.1　　了解系统调用sync（不是sync命令）应该使用什么命令？应该怎样阅读保存在/usr/local/share/man中的sync本地手册页。

　E1.2　　在您的站点上，有一个系统级的配置文件来控制man的行为吗？如果想要在/doc/man中保存本地的文档，应该在这个文件中加入哪些行？必须在/doc/man中使用什么样的目录结构来让它成为man手册页层次结构中的一部分？

　E1.3　man和info之间的主要区别是什么？它们各自有什么优点？

★ E1.4　Linux内核的当前发展状态如何？热点问题是什么？关键人物都有谁？项目是怎样进行管理的？

★ E1.5　研究几种Linux发行版本（参考1.4节的清单，以此作为出发点），为下列每种应用推荐一个发行版本。解释做出选择的理由。

　　　　a）在家办公的单个用户；

　　　　b）大学的计算机科学实验室；

　　　　c）企业的Web服务器。

★ E1.6　假定您发现了在Fedora Core 5提供的文档中说明的Apache httpd的某种功能并不可行。

　　　　a）在报告这个bug之前，您应该做什么？

　　　　b）如果认定这确实是一个bug，那么您应该通知谁？怎样通知？

　　　　c）要让bug报告有用处的话，它必须包含什么信息？

[1]　工作环境是一个单位赖以完成实际工作的环境（与之对照的是测试、研究或者开发环境）。

[2]　严格地说，Mac OS X的内核是Mach的一种变体，它是一个混合型的系统，其中既有BSD的成分，也有非UNIX风格的成分。

[3]　实际上，并不是真正的等宽字体，但看起来是的。比起我们所尝试过的真正的等宽字体，我们更喜欢这种安排。这就是为什么在有些示例中，列没有正好对齐的原因。

第2章　引导和关机

Linux是一种复杂的操作系统，比起只是开关电源来说，打开和关闭Linux系统要复杂得多。如果要使系统保持正常运行的话，必须正确地执行打开和关闭系统的操作。

尽管系统的引导过程一直带有点儿神秘色彩，但是到了制造商能够控制系统软硬件的所有方面之时，这个过程就比较简单了。既然我们让Linux运行在PC硬件上，那么引导过程就要按照PC的规则来执行，并且要能处理大量不同可能的配置。

虽然这一章出现在本书的前面部分，但是它却援引了书中几百页后才详细讨论的一些内容。具体来说，先熟悉了第5章、第28章和第29章的内容，将会有助于理解本章的知识。如果您的系统已经能够毫无问题地引导起来，那么可以跳过这一章，以后再回过头来学习。

2.1　引导

引导（bootstrapping）是“启动计算机（starting up a computer）”的标准术语。操作系统所提供的正常功能在启动过程中还不能使用，因此，计算机必须“通过其引导程序让自己启动起来”。在引导过程中，内核被加载到内存中并开始执行。各种初始化任务得以执行之后，用户就能够使用系统了。

引导阶段是系统特别脆弱的一段时间。配置文件中的错误、丢失设备或者设备不可靠，以及受损的文件系统都会妨碍计算机的启动。引导配置经常是系统管理员必须在新系统上执行的首批任务之一。遗憾的是，这也是最困难的任务之一，它要求在一定程度上熟悉Linux的许多其他方面。

当打开计算机时，计算机执行存储在ROM中的引导代码，这些代码接下来尝试确定如何加载并启动内核。内核检测系统的硬件，然后产生系统的init进程，这个进程总是PID1（译者注：PID 1表示进程的ID号为1）。

在出现登录提示符以前，要完成几项工作。系统必须检查并安装文件系统，而且系统的守护进程必须启动起来，这些步骤是由init进程按顺序运行的一系列shell脚本来管理的。启动脚本由于它们的命名方式而经常被称作“rc文件”，“rc”代表“runcom”或“run command（运行命令）”，这是大约出现于1965年的CTSS操作系统的历史遗迹。启动脚本的确切位置布局以及它们的执行方式随操作系统的不同而异。我们将在本章后面详细介绍。

2.1.1　自动引导和手工引导

Linux系统既可以以自动方式也可以以手工方式来引导。在自动方式下，系统自己执行全部引导过程，不需要任何外部的帮助。在手工方式下，系统先自动执行一些过程，然后到某一时刻后，在运行大多数初始化脚本以前，把控制权交给操作员。在这时候，计算机处于“单用户模式”，大多数系统进程还没有运行，其他用户还不能够登录进入系统。

在日常运行中，几乎总是使用自动引导。对于用户来说，在现代机器上典型的引导过程就是打开计算机的电源并等待系统准备就绪。尽管如此，懂得自动引导过程并知道怎样执行手工引导还是很重要的。当出现某些故障而打断了自动引导过程时，例如，出现损坏的文件系统或者出现没有正确配置的网络接口时，通常就不得不采用手工引导。

2.1.2　引导过程的步骤

Linux系统典型的引导过程由下面6个不同的阶段组成：

• 加载并初始化内核；
• 检测和配置设备；
• 创建内核线程；
• 操作员干预（仅用于手工引导）；
• 执行系统启动脚本；
• 多用户模式运行。

系统管理员对以上大多数步骤几乎没有什么控制权。我们通过编辑系统启动脚本来影响大多数的引导配置。

2.1.3　初始化内核

Linux内核本身就是一个程序，系统引导过程中的第一项任务就是把这个程序载入内存，以便执行它。内核的路径名通常是/vmlinuz或者/boot/vmlinuz。参考第28章了解有关内核的更多知识。

Linux系统实现了一种有两个阶段的加载过程。在第一阶段中，系统ROM把一个小的引导程序从磁盘载入到内存中。然后，这个程序再安排载入内核。

内核执行内存检测来确定有多少RAM可用。内核的一些内部数据结构按静态方式分配其内存量，因此，当内核启动时，它就为自己划分出一块固定大小的实存空间。这块空间保留给内核使用，用户级进程不能使用。内核在控制台上打印一条消息，报告物理内存的总量以及用户进程可用的内存量。

2.1.4　配置硬件

内核执行的第一批任务之一包括检查机器的环境以确定机器有什么硬件。当您为自己的系统构建内核时，要告诉内核，它会找到哪些硬件设备。当内核开始执行时，它试图找到并初始化已经告诉它的每一个设备。大多数内核为它们所找到的每个设备打印出一行专门信息。现在的发行版本所包含的内核能够在绝大多数机器配置上运行，只要做最少量的定制（如果需要的话）。

在内核配置期间提供的设备信息经常不够明确。在这样的情况下，内核通过探测设备总线和向适当的驱动程序寻求信息来尝试确定它所需要的其他信息。那些没有检测到设备的驱动程序或者那些没有响应探测的驱动程序将被禁用。如果某个设备后来被连接到系统上，那么还是有可能随时加载或者启用它的驱动程序的。参考第28章了解细节。

2.1.5　内核线程

一旦完成了基本的初始化任务，内核就在用户空间创建几个“自发”的进程。它们之所以被称作是自发进程，是因为这些进程不是通过系统正规的fork机制所创建的。详情可参见4.2节。

自发进程的数量和特性随系统的不同而不同。在Linux上，看不到有PID 0进程。和进程init（一定是进程1）一起的是几个内存和内核处理进程，包括表2.1所列出的进程。这些进程的PID（进程号）都比较小，在ps命令的输出中它们的名字都被中括号括了起来（例如，[kacpid]）。有时候这些进程的名字以一个斜线加一个数字结尾，比如[kblockd/0]。这个数字表明该线程在哪个处理器上运行，在多处理器的系统上会出现这种有意思的情况。有关ps的详细介绍参见4.7节。

表2.1　　各系统都有一些的Linux内核进程

　　a．每个已经安装的ext3文件系统对应一个kjournald。

在所有这些进程中，只有init是真正完整的用户进程。其他进程实际上都是内核的组成部分，为了调度或者结构上的原因而进行了装扮，使它们看上去像是进程罢了。

一旦创建完毕自发进程，内核在引导阶段的任务就完成了。不过，处理基本操作（比如接受登录）的进程还一个都没有创建呢，而且大多数Linux守护进程也都没有启动。这些任务都是由init来（有些情况下是间接）负责的。

2.1.6　操作员干预（仅限手工引导）

如果系统以单用户模式进行引导，那么在init启动时，内核所给出的命令行标志（就是“single”这个单词）会通知init实际要引导的是单用户模式。进程init最后会把控制权交给sulogin，后者是login的一个“中间但不可控”的特殊版本，它提示用户输入root口令^[1]。如果输入的口令正确，系统将产生一个root shell。用户可以按下<Control-D>而不是输入口令来绕过单用户模式而继续进入到多用户模式。更详细的信息可参见2.4节的内容。参考第3章了解更多有关root账号的知识。

在单用户shell中执行命令的方式和登录到已完全引导的系统上执行命令的方式类似。不过在SUSE、Debian还有Ubuntu系统上，这时通常只安装了root分区。为了使用不在/bin、/sbin或/etc下的程序，用户必须手工安装其他文件系统。有关文件系统和安装的更多信息，请参见第5章。

在许多单用户环境下，文件系统的根目录是按只读方式安装的。如果/tmp是根文件系统的一部分，那么许多要使用临时文件的命令（例如vi）都不能执行。为了解决这个问题，必须先把根文件系统（/）以读写方式重新安装，再开始单用户模式的交互操作。下面这条命令通常就能实现这个技巧。

# mount -o rw,remount /

Red Hat和Fedora的单用户模式比正常的模式要稍微多做些工作。在出现shell的命令行提示之前，这两种发行版本都会尝试安装所有的本地文件系统。虽然这样做乍看起来挺有用，但是如果系统中包含一个有错的文件系统，那么就会发生问题。

正常的自动引导过程会运行fsck命令，检查并修复文件系统。在以单用户模式启动系统时，可能需要手工执行fsck。有关fsck的更多信息请参见7.6节。

当单用户shell退出时，系统将尝试继续引导进入多用户模式。

2.1.7　执行启动脚本

到了系统准备运行其启动脚本的时候，我们就能看出它是Linux系统了。尽管它看起来还不很像全部启动完毕的系统，但在接下来的启动过程中已经没有什么“奇妙”步骤了。启动脚本就是普通的shell脚本，由init根据一定的算法来选择并运行它们，尽管算法有时候有些复杂，但还是相当容易理解的。

启动脚本的处理、馈送和分类有其自己的专门一节来介绍。本章后面从2.5节开始将更详细地介绍这方面的内容。

2.1.8　多用户运行

在初始化脚本运行过以后，系统就是完全运行的系统了，不过现在用户还不能登录进来。为了在某个特定终端（包括控制台）上接受用户登录，必须有一个getty进程监听终端或者控制台。init直接生成这些getty进程，完成引导过程。init还负责生成图形登录系统，例如xdm或gdm（如果设置系统使用它们的话）。有关登录过程的详细信息，请参见27.9.1节。

请记住：即使在引导完成以后，init还继续担当重要的角色。init拥有一个单用户和几个多用户“运行级”，运行级决定启用系统的哪些资源。运行级将在本章后面的2.5节介绍。

2.2　引导PC

至此，我们已经看到了引导过程的一般流程。现在我们回顾几个更重要的（并且是更复杂的）步骤。

　PC的引导过程是一次长时间的考验，理解这个过程需要相当多的背景信息。在引导一台机器的时候，它是从执行存储在ROM中的代码开始的。根据机器类型的不同，这些代码的确切位置和特性也不相同。在明确为UNIX或其他专有操作系统而设计的机器上，这些代码通常是固件，它知道怎样使用连接到机器的设备，知道怎样和网络进行基本通信，还知道怎样理解基于磁盘的文件系统。像这样知道一切的固件对于系统管理员来说是非常方便的。例如，只要键入新内核的文件名，这种固件就知道怎样定位并读取该文件。

在PC上，这种初始化的引导代码通常叫做BIOS（Basic Input/ Output System，基本输入/输出系统），同专有机器的固件相比，它极为简单。实际上，PC拥有几种级别的BIOS：一个用于机器本身，一个用于显示卡，另一个用于SCSI卡（如果系统有SCSI卡的话），有时候还有一个用于其他外设（比如网卡）。

内置的BIOS知道主板上一些设备的信息，如IDE控制器（和磁盘）、键盘、串口和并口等。SCSI卡通常只知道与它们相连的设备。幸好让这些设备一起工作所需的复杂交互操作在前几年都已经标准化了，所以几乎无需进行手工干预。

　现代的BIOS要比以前的稍微聪明一些。它们通常允许用户在启动的时候按下一个或两个特殊键来进入一种配置模式。大多数BIOS都可以在启动时告诉用户有哪些特殊键，这样一来用户就不需要再到手册中去查了。

BIOS通常让用户选择想从什么设备进行引导，这听起来似乎很有用，其实不然。用户通常可以指定“请尝试从软驱引导，然后尝试从CD-ROM引导，然后尝试从硬盘引导”诸如此类的顺序。遗憾的是，BIOS一般被局限于从第一个IDE CD-ROM驱动器或第一个IDE硬盘引导。以前只有运气非常好，才可能会给您一个能够识别是否有SCSI卡的BIOS。

一旦机器确定从什么设备来启动，那么它将尝试加载磁盘开头512个字节的信息。这512字节的段叫做MBR（Master Boot Record，主引导记录）。MBR包含一个程序，该程序告诉计算机从磁盘的哪个分区加载第二个引导程序（引导加载程序，boot loader）。有关PC风格的磁盘分区和MBR的更多信息，请参见第7章。

默认的MBR是一个简单的程序，它告诉计算机从磁盘上的第一个分区获取引导加载程序。Linux提供了一种更为复杂的MBR，它知道怎样去处理多操作系统和多内核。

一旦MBR已经选定从什么分区进行引导，它就试图加载针对那个分区的引导加载程序。之后，就由引导加载程序负责加载内核。

2.3　引导加载程序：LILO和GRUB

没有选择的生活会是什么样子？如今的Linux世界里有两种流行的引导加载程序可供选择：LILO和GRUB。LILO是传统的Linux引导加载程序，它非常稳定而且有很好的文档，但却迅速被GRUB的锋芒盖过。GRUB已经成为Red Hat、SUSE和Fedora系统默认的引导加载程序。实际上，如今的Red Hat和Fedora发行版本根本都不带LILO。另一方面，Debian仍然使用LILO作为其引导加载程序。

2.3.1　GRUB：全面统一的引导加载程序

对于在同一主机上运行多个操作系统（比如Windows、OpenBSD、FreeBSD等）的用户，或者对于积极从事内核开发的用户来说，GRUB（Grand Unified Boot loader）在他们中间格外流行。GRUB对于频繁改变系统配置的用户来说也很有帮助。每次改变LILO的配置之后，必须重新把它安装到引导记录（即MBR）里，GRUB与此不同，它会在启动时读入自己的配置文件，省却了上述容易忘记的管理步骤。

用户通过运行grub-install把GRUB安装到引导驱动器上。这条命令的参数是要引导的设备名。GRUB给物理磁盘命名的方法和Linux的习惯标准（虽然GRUB也使用标准的Linux名字）不一样。遗憾的是，GRUB自己有一套给物理磁盘设备命名的方法，和标准的Linux约定不一样。GRUB设备名看上去类似于：

(hd0,0)

第一个数值表示物理驱动器号（从0开始），第二个数值表示分区号（也是从0开始）。在本例中，(hd0,0)等同于Linux设备/dev/hda1。因此，如果用户想要在主（primary）设备上安装GRUB，那么应该使用命令：

# grub-install　'(hd0,0)'

必须用引号来避免shell用它自己的方式来解释括号。

在默认情况下，GRUB从/boot/grub/grub.conf读取它的默认引导配置。下面是一个grub.conf文件的例子：

这个例子只配置了一个操作系统，如果GRUB在10s内（timeout=10）没有接收到任何来自键盘的输入，那么就自动引导(default=0)。“Red Hat Linux”配置的根文件系统是GRUB设备(hd0,0)。GRUB从/boot/vmlinuz-2.6.9-5加载内核，而且在加载内核的时候显示文件/boot/grub/splash.xpm.gz作为“闪屏”（译者注：即通常所说的启动画面）。

GRUB支持一种功能强大的命令界面，而且能随时编辑配置文件中的配置项。在GRUB的启动画面键入c就可以进入命令行模式。从命令行可以启动grub.conf文件里没有列出的操作系统，可以显示系统信息，还可以执行对文件系统的基础测试。用户还能够在命令行上享受到类似shell的特色功能，包括命令补全、光标移动等等。通过grub.conf文件能做到的事情，也能通过GRUB命令行实现。

在命令行上按下<Tab>键就可以看到可能命令的快捷清单。表2.2给出了比较有用的一些命令。

表2.2　　GRUB的命令行选项

要了解有关GRUB及其命令行选项的详细信息，可以参考其官方手册：

www.gnu.org/software/grub/manual/。

2.3.2　LILO：传统的Linux引导加载程序

LILO要用lilo命令来配置和安装。lilo命令根据文件/etc/lilo.conf的内容安装配置信息。要改变引导配置，只要更新/etc/lilo.conf并重新运行lilo即可。引导过程每次发生变化时，都必须重新配置LILO——具体来说，当用户每次想要添加一个新的引导分区以及每次有一个新的内核要引导时，都要重新配置LILO。

下面是Linux系统的一个基本的lilo.conf文件，它既拥有一个工作内核，也有一个备份内核：

每种可能的引导情形都有一个标签。在引导时，用户通过输入合适的标签就可以告诉LILO使用哪一个标签来引导。出现在lilo.conf中的第一个标签成为默认的引导标签。

在默认的情况下（名为linux）引导内核文件/vmlinuz。“read-only”标记指出内核应该以只读方式安装它的根文件系统。一定要有这个选项，启动脚本在适当的时候将以读写方式来重新安装这个分区。这个系统还配置成可以从备份内核/vmlinuz-backup进行引导。有这么一个备选方案总是一个好主意，内核配置受损的话会致使系统无法启动。

不带任何参数去运行lilo命令将生成并安装引导加载程序，而且告诉用户有哪些引导项可供使用。它在默认的引导映像旁边打一个星号。不过，如果用户已经在lilo.conf文件中犯了某个错误，lilo通常要到引导加载程序安装到半途中才会发现这个问题。当这种情况发生时，引导加载程序就陷入一种混乱状态。在您成功地运行了lilo命令之前不要重新启动系统。

为了避免陷入这种状态，可以运行lilo -t来测试配置而不真的去安装它。如果一切看上去正常，那么就可以运行lilo进行实际安装。为什么lilo不默认地运行这个选项来为用户作预先测试呢？这可有点儿奇怪。

针对上述配置文件运行lilo，其输出如下：

#　lilo 
Added　linux* 
Added　backup

当系统引导时，LILO显示下面的提示符：

LILO:

等待2秒（20个1/10秒，用delay标记来设置），然后引导/vmlinuz内核并把第一个IDE硬盘的第一个分区安装为根分区。按下<Tab>键，可以看到已经定义好的引导方案：

LILO:　<Tab> 
linux　 backup 
LILO:

要使用另外一种方案进行引导，只要在提示符处输入它的标签即可。

2.3.3　内核选项

LILO和GRUB都能把命令行选项传给内核。这些选项往往用来修改内核参数的取值，命令内核探测特殊的设备，指定init所在的路径，或者指派一个特定的根设备。表2.3给出了几个例子。

表2.3　　内核启动时的选项

2.3.4　PC上的多重引导

由于PC上可以运行多种操作系统，因此配置一台机器使它能够引导几种不同的系统就成为相当常见的做法。要实现这一点，需要配置一个引导加载程序能认出磁盘上所有不同的操作系统。在接下来的几节中，我们将介绍多重引导常见的一些难点，然后看一些配置的例子。

每个磁盘分区都可以拥有自己的第二阶段的引导加载程序。但是，整个磁盘却只有一个MBR。在建立多重引导配置时，必须决定哪一个引导加载程序将成为“主”引导加载程序。不管如何，您所做出的选择将取决于涉及到的各个操作系统的特性。对于有一个Linux分区的系统来说，LILO和GRUB通常是最佳选择。在多重引导的情况下，GRUB要比LILO更好。

2.3.5　GRUB的多重引导配置

多重引导的GRUB系统和单一引导的GRUB系统很相像。先装好所有想要的操作系统，然后再对/boot/grub/grub.conf做相应的修改。

引导Windows的grub.conf配置看上去和引导UNIX或者Linux系统的配置不一样：

title Windows XP
　　　 rootnoverify (hd0,0)
　　　 chainloader +1

chainloader这个选项从一个指定的位置加载引导加载程序（本例中是主IDE驱动器上第一个分区的第一个扇区）。rootnoverify选项确保GRUB不会尝试安装指定的分区。这个选项避免了GRUB被它所不能理解的分区搞糊涂，比如NTFS分区或者GRUB所能读取的范围之外的其他分区。

下面的grub.conf文件能够从分区1引导Windows XP，从分区2引导Red Hat Enterprise Linux，还能从分区3引导Fedora：

2.3.6　LILO的多重引导配置

要配置一个使用MBR中LILO的多重引导系统（例如，Linux和Windows XP共存的情况），可以拿前面给出的标准LILO配置作为基础，然后返回去向/etc/lilo.conf中添加用于其他操作系统的条目。

下面是从第一个IDE硬盘的第一个分区引导Windows所需的lilo.conf配置项：

other = /dev/hda1 
label = windows 
table = /dev/hda

从第一个分区引导Windows、从第二个分区引导Linux、从第三个分区引导FreeBSD的完整的lilo.conf文件如下：

把这些配置项加到lilo.conf文件以后，需要重新运行lilo命令。别忘了先运行lilo -t，测试一下这个配置文件。请参考7.4节了解更多有关分区的信息。

发行商（或者是志愿者）经常发布针对Linux发行版本的补丁，内核也不例外。安全漏洞、bug以及新功能都会定期补充到内核中来。但是和其他软件包不一样的是，内核补丁并不对原来内核进行更新，而是与现有的内核平行安装。随着时间的推移，LILO和GRUB的启动菜单中就会充满各种不同版本的内核。使用默认的选择通常是安全的，但是如果系统在打过补丁之后无法启动了，就要意识到可能要简单地对此做些修正。

2.4　引导单用户模式

单用户模式是一种在不影响其他用户（或者不被其他用户影响）的情况下，修改系统配置或者实施维护工作的好方式。单用户模式也是在受损系统上展开恢复工作所采用的模式。

向引导加载程序传递参数是进入单用户模式最常用的做法。不过，用户也可以在其他运行级内通过执行telinit 1命令进入单用户模式。除非正在调式和引导有关的问题，否则没必要重新启动系统。

文件系统的根目录在系统引导时以只读方式安装，这是一种预防系统不稳定的手段。如果需要通过修改位于根文件系统中的一个配置文件或者命令来解决问题，或者需要执行一条会修改这些文件的命令，那么上述手段就会妨碍我们达到预期的目的。为了解决这个问题，可以用下面的命令重新按读写模式安装根文件系统：

# mount -o remount-w /

GRUB和LILO在系统引导过程中进入单用户模式的确切步骤不一样。

2.4.1　用GRUB引导单用户模式

在GRUB下，不需要使用命令行就能进入单用户模式。GRUB的作者们认识到，引导选项应该很容易就能修改，并且用“a”键作为相应的工具来设定引导选项。在GRUB的启动画面中，加亮显示所需的内核，按下“a”键后添加引导选项即可。要引导单用户模式，就在现有的内核选项之后再加上single标志。下面是一个典型的配置例子：

grub append> ro root=LABEL=/ rhgb quiet single

2.4.2　用LILO引导单用户模式

各个发行版本提供了不同的访问LILO命令行的途径。如果在偏爱GRUB的Red Hat、Fedora或者SUSE上安装了LILO，那么就就要从绚丽的全彩色启动界面上选择“command line”这个菜单选项。Debian和Ubuntu的用户则应该在BIOS刚执行完内存检查和其他系统自检之后马上按下shift键不松手。

在LILO提示符处，键入想要引导的配置的标签名（按照lilo.conf中指定的名字），后跟-s或者single。例如，Debian自带的默认配置叫做“linux”，所以要引导该配置进入单用户模式，应该使用

LILO: linux single

2.5　启动脚本

从单用户模式退出以后（或者，在自动引导过程中要运行单用户shell的时刻），init执行系统的启动脚本。这些脚本实际上只是由sh（实际是bash）解释的普通shell脚本。在不同的系统中，这些脚本的确切位置、内容和组织结构有相当大的区别。

经常在启动脚本中执行的一些任务如下：

• 设置计算机的名称；
• 设置时区；
• 采用fsck检查磁盘（只在自动模式下）；
• 安装系统的磁盘；
• 从/tmp目录删除旧文件；
• 配置网络接口；
• 启动守护进程和网络服务。

大多数启动脚本的内容相当详尽，而且能打印出正在做的每件事情的描述。如果系统在引导过程中出现问题而挂起，或者用户正试图确定错误在某个脚本中的位置时，这种打印信息的啰嗦做法将会有莫大帮助。

在以前的系统上，系统管理员常做的一件事是修改启动脚本，使得脚本为特定的环境做合适的事情。不过，由于软件打包的粒度更细，而且会频繁从Internet进行更新，迫使系统采用了一种更可靠的方式。现在，系统装了由各个软件安装的大量启动小脚本，这些脚本从若干独立的文件读取它们的本地配置信息。这些本地配置文件通常采用微小sh脚本的形式来设置shell变量的值，然后启动脚本再用这些变量的取值。

2.5.1　init和运行级

传统的init定义了7个“运行级（run level）”，每一个级别都代表系统应该补充运行的某些特定服务：

• 0级是完全关闭系统的级别；
• 1级或S级代表单用户模式；
• 2～5级是多用户级别；
• 6级是“重新引导（reboot）”的级别。

0级和6级比较特殊，因为系统实际上不能留在这两个级别里，进入这两个级别的效果是关闭系统或者重新引导系统。在大多数系统上，正常的多用户运行级别是2或3级。运行级5经常用于X Windows的登录进程，比如xdm。运行级4很少使用，运行级1和S的定义在每种系统上是不同的。

单用户模式传统上是init的级别1。它关闭所有的多用户和远程登录进程，确保系统运行在最小软件组合的模式下。不过，由于单用户模式提供对系统的超级用户访问权限，因此只要引导系统进入到单用户模式，管理员都要让系统提示用户输入root的口令。创建S运行级是为了解决下面的需要：它产生一个进程提示输入root的口令。在Linux上，这一级别只是用来提示输入root的口令，而它本身并不是最终的运行目的。

看起来，定出的运行级别比严格需要的或者说有用的级别要多。对这一点的通常解释是：电话交换机（phone switch）有7个运行级别，那么想来一个UNIX系统至少也应该拥有这么多的运行级吧。Linux实际上支持多达10个运行级，但运行级7～9并没有定义。

/etc/inittab文件告诉init在它的每个运行级上要做什么事情。它的格式随系统的不同而异，但基本思想是：inittab规定了系统进入到每一级别时要运行（或者要保持运行）的命令。

在机器引导时，init从运行级0开始，一级一级往上运行到在/etc/inittab中所设置的默认运行级别。为了完成在每一对相邻运行级别之间的过渡，init运行在/etc/inittab中为这种过渡而说明的一些操作。当机器关闭时，以相反的顺序执行同样的处理过程。

遗憾的是，inittab文件的语义有点儿不那么完善，为了把inittab文件的功能映射成为某种更为灵活的形式，Linux系统实现了另一层抽象，它通常采用“改变运行级”脚本的形式（通常为/etc/init.d/rc），由inittab来调用。这一脚本接下来执行位于与运行级有关的目录下的其他脚本，从而把系统带入到新的状态。

现在，大多数Linux发行版本默认启动到运行级5，对于不需要运行X的服务器来说这个级别并不合适。默认运行级很容易修改。下面这个从SUSE主机上的inittab文件中截取的片段设置默认启动到运行级5：

id:5:initdefault:

系统管理员通常不必直接处理/etc/inittab，因为几乎对于任何应用程序来说，基于脚本的接口就足够了。在本章的其余部分里，我们将会按惯例忽略inittab文件和其他将init与启动脚本的执行联系起来的文件。只要记住，当我们说init运行这样那样的脚本时，这种关系可能并不那么直接就行了。

启动脚本的主拷贝位于/etc/init.d这个目录下。每个脚本负责一个守护进程或者系统的某个特定方面。这些脚本都认识参数start和stop，从而知道它们所处理的服务是应该启动还是应该停止。大多数脚本还认识参数restart，通常该参数等同于在stop后面再接start。作为系统管理员，要启动和停止各个服务，只要手工运行与之有关的init.d脚本就可以了。

例如，下面是一个简单的启动脚本，它可以启动、停止或重新启动sshd：

尽管/etc/init.d中的脚本能够启动和停止各个服务，但是由init运行的主控制脚本需要知道其他一些信息，这些信息说明了要进入任何指定的运行级别需运行哪些脚本（并带什么参数）。当主脚本把系统引入到一个新的运行级别时，它不是直接在init.d目录下找，而是查找叫做rclevel.d的目录，这里的level就是要进入的运行级别编号（例如，rc0.d、rc1.d等）。

在典型情况下，这些rclevel.d目录包含的符号链接都链接到了init.d目录中的脚本上。这些符号链接的名称都以S或K开头，后跟一个数字以及该脚本所控制的服务名（例如，S34named）。当init从低的运行级别向高的运行级别过渡时，它按照数字递增的顺序运行所有以S开头的、带有start参数的脚本。当init从高的运行级别向低的运行级别过渡时，它按照数字递减的顺序运行所有以K（表示kill，杀死的意思）开头的、带有stop参数的脚本。

这一机制让系统管理员可以细粒度地控制启动服务的顺序。例如，在网络接口启动之前先启动SSH就没有意义。在Fedora系统上，虽然network和sshd都配置了在运行级2启动，但是network的脚本序号为10，而sshd的脚本序号为55，所以network肯定先运行。在加入新服务的时候，一定要考虑到这种依赖关系。要告诉系统什么时候启动一个守护进程，我们必须在适当的目录下创建符号链接。例如，要告诉系统在运行级2期间启动CUPS并在系统关闭以前妥善地停止这个守护进程，那么创建下面这一对链接就够了：

#　ln　-s　/etc/init.d/　cups　/etc/rc2.d/S80cups
#　ln　-s　/etc/init.d/　cups　/etc/rc0.d/K80cups

第一行命令告诉系统：当进入运行级2时，把运行启动脚本/etc/init.d/cups作为最后要做的事情之一，并且带start参数去运行这个脚本。第二行告诉系统：当关闭系统时，要较早运行/etc/init.d/cups，并且带stop参数来运行这个脚本。有些系统以不同方式处理系统关闭（shutdown）和重新引导（reboot），所以我们需要在/etc/rc6.d目录中也放一个符号链接，以确保当系统重新引导时，该守护进程能够被正确关闭。

2.5.2　Red Hat和Fedora的启动脚本

Red Hat和Fedora的启动脚本历来非常混乱，代码中包含有许多注释，例如：

在每个运行级上，init都把新运行级作为参数来调用脚本/etc/rc.d/rc。/etc/rc.d/rc一般运行在“正常”模式下，在这种模式下，它只做它自己的事情。它也可以运行在“确认”模式下，在这种模式下，它在运行每个单独的启动脚本以前询问用户。

#　Yes, this is an ugly, but necessary hack

Red Hat和Fedora有一个chkconfig命令来帮助用户管理服务。这条命令可以在系统中增删启动脚本，也可以管理这些脚本执行的运行级，还能列出一个脚本目前为哪些运行级做了配置。参考man chkconfig的输出了解有关这个简便工具的用法。

Red Hat还有一个rc.local脚本，和在BSD系统上看到的非常类似。rc.local是作为启动过程的一部分而运行的最后一个脚本。以前initscripts这个软件包会覆盖rc.local的内容。不过现在已经不这样了，向rc.local中添加用户自己定制的启动内容也很安全。

下面是Red Hat启动会话的一个例子：

一旦看到“Welcome to Red Hat Enterprise Linux”这则消息，用户就可以按“i”键进入“确认”模式。遗憾的是，Red Hat并没有让用户确认是否已经按下了正确的键。它继续安装本地文件系统、激活交换分区、加载键映射文件并定位它的内核模块。只有当它切换到运行级3时，才真正开始提示用户进行确认：

交互式启动模式和单用户模式在引导过程中的起点是相同的。当启动过程被中断而使得用户不能够安全地到达这个起点时，就可以使用应急软盘或者光盘去引导。

也可以给LILO传递参数init=/bin/sh，用技巧让它在init启动以前运行一个单用户的shell^[2]。如果采用后面这种方案，那么必须手工完成全部的启动工作，包括手工用fsck命令检查本地文件系统以及安装它们。

Red Hat引导过程的大多数配置应该通过操作/etc/sysconfig中的配置文件来完成。表2.4总结了/etc/sysconfig目录中各项的功能。

表2.4　　Red Hat的/etc/sysconfig目录下的文件和子目录

　　a．如果用户的PC是多重引导的，那么时钟的时区应该如何设置就不好说了。

我们将对表2.4中的几个选项进行进一步的说明：

• hwconf包含了所有的硬件信息。Kudzu服务检查它来看看用户是否已经添加或者删除了任何硬件，并询问用户对所做的改动采取什么措施。用户很可能想在一个工作系统上禁用这个服务，因为只要这个服务检测硬件配置有了变化，它都会延迟引导过程，造成为每个硬件变化额外多等30s以上的时间。
• network-scripts目录包含与网络配置有关的补充信息。用户需要改动的惟一地方是名为ifcfg-interface的文件。例如，network-scripts/ifcft-eth0包含接口eth0的配置参数。它设置接口的IP地址和连网参数。有关配置网络接口的更多信息请参见第12.7节。
• sendmail文件包含两个变量：DAEMON和QUEUE。如果DAEMON变量设置为yes，那么系统将在系统引导时就以守护进程模式（-bd）启动sendmail。QUEUE告诉sendmail，在两次邮件排队操作（-q）之间间隔多长时间；默认是一小时。

2.5.3　SUSE的启动脚本

虽然SUSE的启动脚本类似于RHEL和Fedora的启动脚本，但是SUSE的启动脚本确实是它比其他Linux变体显得耀眼的一个领域。SUSE的脚本组织得不错，健壮可靠，而且有很好的文档说明。维护操作系统这一部分的人应该得到褒奖。

同Red Hat和Fedora系统里的情况一样，init在每个运行级都要把新运行级作为参数来调用/etc/init. d/rc脚本。针对软件的脚本都在/etc/init.d目录下，它们的配置文件则在/etc/sysconfig目录下。/etc/init.d/README里可以找到对SUSE引导过程很好的介绍。

虽然SUSE和RHEL/Fedora都把它们的引导配置文件放在了/etc/sysconfig目录下，但是在这个目录下的具体文件则大有不同。（首先，SUSE的文件一般都有很好的文档说明。）通过设置shell的环境变量就能调用配置选项，而这些变量接下来供/etc/init.d里的脚本访问。有些子系统比别的子系统需要更多的配置，那些需要多个配置文件的子系统有专门的子目录，比如sysconfig/network目录。

windowmanager文件是sysconfig目录下的一个典型例子：

每个变量前面都有YaST^[3]可以读懂的配置信息，还有对这个变量用途的详细说明。例如，在windowmanager文件里，DEFAULT_WM这个变量设置了由X使用的桌面窗口管理器。

SUSE在/etc/sysconfig/network目录下的网络配置文件组织得格外不错。这个目录既包含全局配置文件（设置与所有网络接口有关的配置选项），也有特定于网络的文件。例如，network/routes这个文件保存有全局的路由信息。在一个典型安装的SUSE系统上，它的内容类似下面的情况：

# Destination Dummy/Gateway 　　Netmask　　Device
default 　　　　　192.168.10.254　　0.0.0.0　　eth0

仅当一个特定网络接口启动且正在运行的时候应该出现的路由，在一个叫做ifroute-ifname的文件里指定。例如，对于名为eth1的接口，这个文件就成了ifroute-eth1，其内容可以是：

# Destination　　Dummy/Gateway　 Netmask　 Device
10.10.0.0/24 　　10.10.0.254

如果愿意，Netmask和Device也能指定，但是启动脚本会推断出正确的值。

SUSE也带一个管理启动脚本的chkconfig命令。它和Red Hat提供的版本完全不同，不过它仍然是一个有效的工具，在偏好手工管理脚本的情况下应该使用它。

不论选择使用YaST还是chkconfig，或者手工维护启动脚本，浏览/etc/sysconfig目录并且琢磨一下它的内容将会是一个好主意。

下面是一个典型的SUSE引导会话的例子：

2.5.4　Debian和Ubuntu的启动脚本

如果说SUSE是对管理启动脚本有良好设计、良好执行规划的典型，那么Debian却正好相反。Debian的脚本脆弱、缺少文档而且还令人难以置信地不一致。真糟糕，在这一块，设置脚本的方式缺乏标准似乎造成了混乱。

在每个运行级中，init都以新的运行级作为参数来调用脚本/etc/init.d/rc。每个脚本负责找到它自己的配置信息，这些信息可能是在/etc、/etc/default、以及/etc下其他子目录里，或者在脚本自身中的什么地方。

如果用户正在查找系统的主机名，那它保存在/etc/hostname里，供脚本/etc/init.d/hostname.sh读取。网络接口和默认网关的参数保存在/etc/network/interfaces里，由从/etc/init.d/networking里调用的ifup命令读取。有些网络选项也会在/etc/network/options中设置。

Debian和Utuntu有一种神秘的启动脚本管理程序，其形式为update-rc.d。虽然它的man手册警告说不要以交互的方式使用它，但是我们发现它虽然有点儿不友好，但还是能用的，可以替代chkconfig。例如，要在运行级2、3、4和5都启动sshd，而在运行级0、1和6停止它，就可以用：

$ sudo /usr/sbin/update-rc.d sshd start 0123 stop 456

2.6　重新引导和关机

Linux的文件系统缓冲一般在内存中变化，只是偶尔才把它们写回磁盘。这种方案使得磁盘I/O速度更快，但是当系统被粗暴地中止时，这种方案也更容易使文件系统丢失数据。

传统的UNIX和Linux机器要非常小心地处理关机方式才行。现代的系统已经变得不那么敏感了（尤其是当用户使用一个像ext3fs这样强健的文件系统时），但有可能的话，妥善关机总是一个好主意。不恰当的关机可能产生隐蔽的小问题，从而导致重大灾难事故。

在面向消费级用户的操作系统上，重新引导操作系统是适合处理几乎任何故障的第一课。而在Linux系统上，最好首先考虑清楚，然后再重新引导机器。Linux的故障更微妙、更复杂一些，因此，盲目地重新引导系统只会在很小比例的场合下起作用。还有，Linux系统引导所花费的时间很长，这对于多用户来说是不太方便的。

当添加一种新硬件或现有硬件出现问题甚至不能够复位时，通常需要重新引导系统。如果所修改的配置文件只有在引导过程中才使用的话，那么，要让改动起作用，也必须重新引导系统。如果系统出现故障，使得用户不能够登录进入系统去正确地诊断故障，这时显然除了重新引导系统以外别无选择。

只要修改启动脚本，就应该重新引导系统，以确保系统能够成功地运行起来。如果时隔几个星期之后才发现问题，那么就不太可能回想起最近所做修改的细节。

引导系统本质上只能用一种方法来完成，与此不同的是，关闭或重新引导系统有许多种方法。这些方法如下：

• 关闭电源；
• 使用shutdown命令；
• 使用halt和reboot命令；
• 使用telinit来改变init的运行级别；
• 使用poweroff命令告诉系统关闭电源。

2.6.1　关闭电源

即使是在桌面系统上，关闭电源也不是关闭系统的一个好方法。这样做有可能丢失数据和破坏文件系统。

许多机器有一个“软电源开关”，当用户按下电源按钮时，机器实际上运行一串命令来执行关闭系统的正确操作。如果不清楚自己的机器是否提供这个特性，那么不要按下电源按钮来证明这一点！最好是自己去执行这一串关闭系统的操作。

不过，这并不是说绝对不可以关闭电源。在发生紧急情况时，如果没有足够的时间来妥善关机的话，那么关闭电源也是可以的。老式机房经常有一个“意外事件处理按钮”可以立即关闭所有设备的电源。我们的系统管理员曾经让一个踢歪了的足球触动了那个开关。

2.6.2　shutdown：停止系统的妥善方式

shutdown是停止或重新引导系统，或者返回到单用户模式的最安全、考虑最周到的、最彻底的方式。

可以让shutdown在开始关闭系统以前等待一定的时间。在这个等待的过程中，shutdown以越来越短的时间间隔发送一些消息给已经登录的用户，警告用户关闭系统的时间即将到来。默认情况下，这些警告消息只是说系统即将关闭并给出离关闭系统还剩的时间，管理员也可以提供自己的简短消息。消息应该说明为什么要关闭系统、并应该估计多长时间以后用户可以再次登录进入系统（比如，上午11:00恢复）。在大多数系统上，立即执行shutdown时，用户是不能够登录进入系统的，但如果管理员设定自己的消息，那么用户能够看到消息，从而明白是怎么回事。

shutdown让管理员指定当该任务完成后，机器是应该停机（-h），还是重新引导（-r）。还可以指定在重新引导以后是强制使用fsck命令检查磁盘（-F），还是不检查（-f）。在默认情况下，只要文件系统是正确卸载的，Linux系统会自动跳过fsck检查。

例如，一条提醒用户上午9:30实施预定的维护而停止系统运行的shutdown命令如下：

# shutdown　-h　09:30　"Going　down　for　scheduled　maintenance. Expected 
　　downtime is 1 hour"

还可以指定相对的关机时间。例如，下面的命令将在它开始运行15分钟之后关机：

# shutdown　-h　+15　"Going　down　for　emergency　disk　repair."

2.6.3　halt：关闭系统的更简单方式

halt命令执行关闭系统所需要的基本任务。它可以被shutdown -h调用，也可以单独使用。halt记录关机的情况，终止那些非必需的进程，执行sync系统调用（被sync命令调用并与sync命令等效），等待文件系统写操作完成，然后停止内核。

halt -n不执行sync调用。在fsck修好了根分区之后会用到这条命令。如果fsck没有使用-n选项，那么内核可能会用内存中缓存的超级块的老版本覆盖fsck的修改。

2.6.4　reboot：快速的重新启动

reboot几乎跟halt完全一样，只不过它是让机器重新启动，而halt是让机器停止。reboot由shutdown -r来调用。与halt类似，它也支持-n参数。

2.6.5　telinit:改变init的运行级

使用telinit可以指引init进入特定的运行级。例如：

#　telinit　1

让系统进入单用户模式。

在使用telinit的时候，不会得到像shutdown那样友好的警告消息或者善意的等候时间，所以在大多数情况下，可能都要避免用到它。对于测试对inittab文件的修改来说，telinit是最有用处的。

2.6.6　Poweroff：请Linux关闭电源

poweroff命令等价于halt，不同之处是在Linux关闭后poweroff可以向电源管理系统（在有这项功能的系统上）发送一则请求来关闭系统的主电源。这项功能易于实现远程关机（例如，在一次供电故障期间）。

遗憾的是，没有对应的poweron命令。这一疏忽的原因留给读者作为练习。

2.7　习题

　　E2.1　为什么在安装LILO引导加载程序之前先运行lilo -t很重要？该怎样引导一个名字不是vmlinuz的内核？

　　E2.2　为什么不应该用计算机机箱上的电源开关来关闭Linux系统？有什么别的替代办法吗？

　　E2.3　用GRUB的命令行引导一个grub.conf文件中没有的内核。

　★E2.4　试述运行级的概念。列出Linux中定义的运行级，并简短描述一下每个运行级。运行级1和S之间有什么关系？

　★E2.5　编写一个启动脚本，启动名为“foo”的守护进程（/usr/local/sbin/foo），它是一项网络服务。说明如何把它融入系统，在引导时刻自动启动。

　★E2.6　取得并安装由Dan Farmer和Wietse Venema所写的程序mactime（它是TCT工具集的一部分）。运行mactime，创建一个与系统文件相关联的时间戳初始数据库。重启机器。再次运行mactime，判断因为引导机器而被修改的文件有哪些。哪些文件访问了而没被修改？（需要root访问权限）　　

★★E2.7　如果一个系统处于运行级4，而用户运行了命令telinit 1，init会采取哪些步骤？命令最终的结果将会是什么？

★★E2.8　绘制一张依赖关系图，画出在您的Linux系统上启动别的守护进程之前，必须启动哪些守护进程？

★★E2.9　个能工作的多OS系统——包含Linux和Windows——所用到的步骤。使用GRUB和Windows的引导加载程序。

[1]　参考inittab和sulogin的man手册页了解更多信息。糟糕的是，即便是Red Hat和Fedora当前的版本，在进入单用户模式之前，也不要求输入口令。

[2]　我们曾经有一个损坏的键映射（keymap）文件，由于即便是在单用户模式下也装载键映射，因此单用户模式就没有办法使用了。设置init=/bin/sh是引导系统到可以使用的单用户状态并解决这个问题的惟一办法。这个办法在其他一些情况下也是一个有用的窍门。

[3]　YaST是SUSE特有的一种图形化配置工具，它可以维护一个SUSE系统许多方面的配置。参考第11章了解更多信息。