[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 下一頁 ]

Debian 參考手冊
第 2 章 - Debian 基礎


本章講述非開發人員需要掌握的 Debian 系統基礎知識。相關知識的權威參考,請參閱:

列表請參閱 參考資料, 第 15.1 節.

如果你想查閱簡要的 "how-to" 文件,可直接跳到 Debian 套件管理系統, 第 6 章 或其它相關章節。

本章的內容取自 "Debian FAQ",經過較大的改編,以適合於一般的 Debian 系統管理者上手。


2.1 Debian archives


2.1.1 目錄結構

Debian 套件可經由 FTP 或 HTTP 在 Debian mirror site 其中之一的目錄樹中取得。

下列目錄存在於任何 Debian 映射站台的 debian/ 目錄下:

dists/:
本目錄包含 "distributions",此處是獲得 Debian releases 和 pre-releases 的套件的正規途徑。有些舊套件及 Packages.gz 檔仍在其中。
pool/:
所有 Debian releases 及 pre-releases 的套件的新的實體位址。
tools/:
一些DOS下的小工具,用於建立開機磁片,分割硬碟,壓縮/解壓縮和啟動 Linux。
doc/:
Debian 的基本文件,如 FAQ、錯誤報告、系統使用說明等。
indices/:
維護人員文件和重載文件。
project/:
大部分為開發人員的資源,例如:
project/experimental/:
本目錄包含了處於開發中的套件和工具,它們均處於 alpha 測試階段。用戶不應使用這些軟件,因為即使是經驗豐富的用戶也會被搞得一團糟。
project/orphaned/:
已不再有人維護的套件,它們已從 distribution 中孤立出來。

2.1.2 Debian distributions

通常在 dists 目錄下有三個 Debian distributions。它們是 stable distribution,testing distribution,和 unstable distribution。有時還有一個 frozen distribution。每個 distribution 均定義成一個符號鏈接指向 dists 目錄中相應的開發代號 (codename) 目錄。


2.1.3 The stable distribution

stable distribution 套件的入口,Debian Woody (3.0r0),被登記到 stable (符號鏈接指向 woody/ 目錄):

現在,除了上述的目錄外,新上傳的套件的實體儲存位置為 pool 目錄 (pool 目錄, 第 2.1.10 節)。

現階段 stable 發行版錯誤報告位於 Stable Problems 頁面。


2.1.4 The testing distribution

testing distribution 的套件入口,Debian Sarge,在 unstable 中通過某種程度的測試後會登記到 testing (符號鏈接指向 sarge/) 目錄。現在,除了上述目錄,新上載的套件的實體儲存位置為 pool 目錄 (pool 目錄, 第 2.1.10 節)。在 testing/ 下同樣有 maincontrib ,和 non-free 子目錄,它們的作用與 stable/ 中的一樣。

這些套件必須可以同時運行於所有架構,並且沒有相依性問題影響到其安裝。比起在 unstable 中的對應版本,它們必需有更少的 release-critical 錯誤。這個種方式,我們將 testing 視為更接近發布的候選版本。有關 testing 機制的更多資訊請參閱 http://ftp-master.debian.org/testing/

testing distribution 的最新消息發佈在下列站台:


2.1.5 The unstable distribution

unstable distribution 的套件入口,總是被命名為 "Sid",被登記到 unstable (符號鏈接指向 sid/) 目錄,上傳至 Debian archive 的套件在被移至 testing/ 前就一直放在這兒。新上傳的套件的實體儲存位置為 pool 目錄 (pool 目錄, 第 2.1.10 節)。在 unstable/ 下同樣有 maincontribnon-free 子目錄, 它們的作用與 stable/ 中相同。

unstable distribution 反映了系統最新的開發進展。歡迎廣大用戶使用並測試這些套件,同時也提醒你們這些套件還不完善。使用 unstable distribution 的好處就是你可以獲得 Debian 軟體專案 — 的最新更新,不過新東西也會出新問題,你得好壞兼收 :-)

unstable distribution 的最新錯誤報告見於 Unstable Problems 頁面。


2.1.6 The frozen distribution

testing distribution 足夠成熟了,它便成為 frozen,表示這個版本不再加入新程式,只進行除錯工作。如果需要的話, dists 目錄中會建立新的 testing 目錄樹,並給予新的開發代號。 frozen distribution 再經過幾個月的測試、更新、再凍結也稱之為“循環測試”。(最近的 Woody 發佈進程沒有建立 frozen/ 的符號鏈接,所以 frozen 並不算 distribution,僅是 testing distribution 的一個開發階段。)

我們將 frozen distribution 中可能延遲套件或整個版本發佈的錯誤都記錄在案,一但錯誤總數低於可接受的最大值,frozen distribution 就晉升成 stable,而新版本發布了,前一個 stable distribution 成為過期版 (obsolete) (並被移至相對應的目錄)。


2.1.7 Debian distribution 開發代號 (codenames)

存在於 dists 目錄下的實體目錄名稱,例如 woody/sarge/ ,就是 "開發代號 (codenames)"。當某個 Debian distribution 處於開發階段,它並沒有版本號碼,取而代之的是開發代號。使用開發代號的目的在於簡化建立 Debian distributions 映射站台的工作(如果真實目錄例如 unstable 突然改名為 stable/ ,許多文件都沒必要再次下載)。

現在,stable 是一個指向 Woody 的符號鏈接,testing 是指向 Sarge 的符號鏈接。也就是說 Woody 是當前的 stable distribution, Sarge 是當前的 testing distribution。

unstable/ distribution 是指向 sid/ 的永久符號鏈接,即 unstable distribution 總是稱為 Sid 。


2.1.8 已用過的開發代號

已使用過的開發代號有:"Buzz" 用在 release 1.1 , "Rex" 用在 release 1.2 , "Bo" 用在releases 1.3.x , "Hamm" 用在 release 2.0 , "Slink" 用在 release 2.1 和 "Potato" 用在 release 2.2.


2.1.9 開發代號的來源

到目前為止它們均出自 Pixar 的電影 玩具總動員 (Toy Story)


2.1.10 pool 目錄

過去,套件均放在 dists 目錄下相應的 distribution 子目錄中。這種做法產生了許多問題,例如映射站台進行新版本發佈時大量頻寬被消耗。

現在套件均依原本的套件名稱分類放進一個巨大的池子 "pool"。為了方便管理, pool 目錄下按屬性再分類 (maincontrib ,和 non-free),分類下面再按原本的套件名稱的英文字首字母歸檔。這些目錄包含的文件有:運行於各種系統架構的二進位套件,和生成這些二進制套件的源碼套件。

你可以執行命令 apt-cache showsrc mypackagename ,查看 "Directory:" 行獲知每個套件的存放位置。例如:apache 套件存放在 pool/main/a/apache/ 。因為 lib* 的套件數量龐大,它們以特殊的方式歸檔:例如,libpaper 套件存放在 pool/main/libp/libpaper/

諸如 apt 等命令訪問的索引文件仍位於 dists 目錄中。而且,直到本文寫作之時,舊的 distributions 套件還沒轉到 pool 目錄,所以你將看到路徑中的 "Directory" 標頭欄中包含有 distribution 名稱如 potatowoody

通常,你大可不必注意這些事情,新版的 apt 和舊版 dpkg-ftp (參閱 Methods for upgrading a Debian system, 第 2.3.1 節) 會自動處理它們。想了解更多資訊,參閱 RFC: implementation of package pools


2.1.11 sid 的歷史記錄

過去 Sid 並不存在, Debian archive 組織有一個主要的工作流程:它假設當前 unstable 中建立了某個軟體開發項目,它會在整個 distribution 形成一個新的 stable/ 時發佈。但是因為很多軟體不是用這個方式在開發,所以一但軟體要發佈時,就必需把整個目錄都搬移到 stable 下。因為在搬移目錄時會用掉大量的頻寬,所以這個流程就顯得很不切實際。

經過幾年的研究摸索,archive 管理員提出一個方案,將未發佈的二進位檔放在一個名為 sid 的特定目錄。由於這些軟體尚未發佈,從那時起,它們就被加入到 unstable 目錄樹。當它們首次發布時,將會建立一個從當前 stable 指向 sid 的鏈接。這個方案的確會使使用者覺得困惑。

有了套件 pool 的幫助(參閱 pool 目錄, 第 2.1.10 節),在 woody distribution 開發過程中,二進位套件均按一定規範存放於 pool 目錄,而與 distribution 無關,當發佈新版本時,就不會再出現大量頻寬被消耗的問題。(不過,開發過程還是會用掉大量頻寬)。


2.1.12 在 incoming 中的上傳套件

上載的套件在經確認它們是由 Debian 開發者上載的後,會先存放於 http://incoming.debian.org/ (對於那些無維護者上載(Non-Maintainer Upload (NMU))的套件則放入 DELAYED 子目錄)。會有一天,它們將從 incoming/ 移入 unstable/

在緊急情況下,你可能會等不及它們移入 unstable/ 而直接從 incoming. 中下載安裝。


2.1.13 找回舊套件

最新的 Debian distribution 存放在任何一個 Debian mirror sitedebian 目錄下。舊版本的 Debian 如 Slink 存放在 http://archive.debian.org/ 或 Debian 映射站台的 debian-archive 目錄下。

舊的 testingunstable 套件存放在 http://snapshot.debian.net/


2.1.14 Architecture sections

在每個主要目錄樹下(dists/stable/maindists/stable/contribdists/stable/non-freedists/unstable/main/ 等)按晶片架構又分了子目錄,每個子目錄中存放著在該晶片架構下編譯的二進位套件。

請注意,testingunstable 的二進位套件不再存放在這些目錄中,而是放在最上層 pool 目錄中。但為了向下相容,所以在目錄中仍保留有索引文件(PackagesPackages.gz)。

要獲得實際上的二進制架構技術支持,請參閱各發行版的發佈記錄(Release Notes)。它們放發佈記錄站台 stabletesting


2.1.15 源碼

Debian 系統中包含了所有東西的源碼,不僅如此,許可證條款規定系統中所有的程式必須和其源碼一起發行,或提供源碼。

通常源碼發佈在 source 目錄,該目錄同時處於所有特定平台的目錄中,或是把更新的源碼放在 pool 目錄中(參閱 pool 目錄, 第 2.1.10 節)。對於不太熟悉 Debian archive 目錄結構的用戶,想獲得源碼可以試試 apt-get source mypackagename 命令。

有些套件,如著名的 pine,由於許可證限制,只提供源碼套件。(最近,pine-tracker 套件提供了一個簡易的安裝方式。)參閱 把套件引入 stable 系統, 第 6.4.10 節包裝套件, 第 13.9 節 教你如何手動編建一個套件。

contribnon-free 目錄中的套件可能不提供源碼,因為它們不算正式 Debian 系統的一部分。


2.2 Debian 套件管理系統


2.2.1 Debian 套件概觀

套件通常包含了實現一系列相關命令或特性的所有必需的檔案。Debian 套件有兩種類型:

使用套件管理系統來安裝套件時會用到由套件維護者精心設計的"相依資訊"。這些相依資訊記錄在每個套件的 control 文件中。例如,包含 GNU C 編譯器 (gcc) 的套件"相依"於包含連結器 (linker) 和組譯器 (assembler) 的 binutils 套件。如果用戶試圖在沒有安裝 binutils 的情況下安裝 gcc,軟件包管理系統(dpkg)就會發一條錯誤信息,告訴你需要安裝 binutils,並停止安裝 gcc 。(不過,倔強的用戶可以對這個信息視而不見,參閱 dpkg(8) )。)更多資訊請參閱下面的 Package dependencies, 第 2.2.8 節

Debian 套件管理工具可用來:


2.2.2 Debian 套件格式

Debian 的"套件",或是 Debian 保存壓縮檔 (archive) 包含了和特定程式或一組相關的程式有關的可執行檔,函式庫,和文件。通常,Debian 保存壓縮檔是以 .deb 做為結尾。

The internals of this Debian binary package format are described in the deb(5) manual page. Because this internal format is subject to change (between major releases of Debian), always use dpkg-deb(8) for manipulating .deb files.

Through at least the Woody distribution, all Debian archive files have been manipulable by the standard Unix commands ar and tar, even when dpkg commands are not available.


2.2.3 Naming conventions for Debian package filenames

The Debian package filenames conform to the following convention:

     foo_VersionNumber-DebianRevisionNumber.deb

where foo represents the package name. As a check, one can determine the package name associated with a particular Debian archive file (.deb file) in one of these ways:

The VVV component is the version number specified by the upstream developer. There are no standards governing version numbers, so they may have formats as different as "19990513" and "1.3.8pre1".

The RRR component is the Debian revision number, and is specified by the Debian developer (or an individual user if he chooses to build the package himself). This number corresponds to the revision level of the Debian package; thus, a new revision level usually signifies changes in the Debian makefile (debian/rules), the Debian control file (debian/control), the installation or removal scripts (debian/p*), or the configuration files used with the package.


2.2.4 Preservation of the local configuration

Preservation of user-configurable files is enabled through Debian's "conffiles" mechanism. User configuration files (usually placed in /etc/) are specified in the conffiles within the Debian package system. The package management system guarantees not to overwrite these files when the package is upgraded.

When it is possible to configure the system without modifying files that belong to various Debian packages, it is usually a good idea not to modify them even if they are "conffiles". This ensures faster and smoother upgrade operations.

To determine exactly which files are preserved during an upgrade, run:

     dpkg --status package

and look under "Conffiles:".

Specifics regarding the contents of a Debian conffiles file are provided in the Debian Policy Manual, section 11.7 (see 參考資料, 第 15.1 節).


2.2.5 Debian maintenance scripts

Debian maintenance scripts are executable scripts which are automatically run before or after a package is installed. Along with a file named control, all of these files are part of the "control" section of a Debian archive file.

The individual files are:

preinst
This script executes before its package is unpacked from its Debian archive (.deb) file. Many "preinst" scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the "postinst" script).
postinst
This script typically completes any required configuration of a package once it has been unpacked from its Debian archive (.deb) file. Often, "postinst" scripts ask the user for input, and/or warn the user that if he accepts default values, he should remember to go back and reconfigure the package as the situation warrants. Many "postinst" scripts then execute any commands necessary to start or restart a service once a new package has been installed or upgraded.
prerm
This script typically stops any daemons which are associated with a package. It is executed before the removal of files associated with the package.
postrm
This script typically modifies links or other files associated with a package, and/or removes files created by it. (Also see Virtual packages, 第 2.2.7 節.)

Currently all of the control files can be found in the directory /var/lib/dpkg/info. The files relevant to package foo begin with the name "foo" and have file extensions of "preinst", "postinst", etc., as appropriate. The file foo.list in that directory lists all of the files that were installed with the package foo. (Note that the location of these files is a dpkg internal, and may be subject to change.)


2.2.6 Package priorities

Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:


2.2.7 Virtual packages

A virtual package is a generic name that applies to any one of a group of packages, all of which provide similar basic functionality. For example, both the tin and trn programs are news readers, and either one should therefore satisfy any dependency of a program that requires a news reader on a system in order to work or to be useful. They are therefore both said to provide the "virtual package" called news-reader.

Similarly, exim and sendmail both provide the functionality of a mail transport agent. They are therefore said to provide the virtual package mail-transport-agent. If either one is installed, then any program depending on the installation of a mail transport agent will be satisfied by the existence of this virtual package.

Debian has a mechanism so that, if more than one package which provides the same virtual package is installed on a system, the system administrator can set one as the preferred package. The relevant command is update-alternatives, and is described further in Alternative 指令, 第 6.5.3 節.


2.2.8 Package dependencies

The Debian package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system:

More detailed information on the use of each these terms can be found in the Packaging Manual and the Policy Manual.

Note that dselect has more fine-grained control over packages specified by recommends and suggests than apt-get, which simply pulls all the packages specified by depends and leaves all the packages specified by recommends and suggests. Both programs in modern form use APT as their back end.


2.2.9 The meaning of "pre-depends"

"Pre-depends" is a special dependency. In the case of an ordinary package, dpkg will unpack its archive file (i.e., its .deb file) independently of whether or not the files on which it depends exist on the system. Unpacking basically means that dpkg will extract the files from the archive file that were meant to be installed on your filesystem, and put them in place. If those packages depend on the existence of some other packages on your system, dpkg will refuse to complete the installation (by executing its "configure" action) until the other packages are installed.

However, there are some packages that dpkg will refuse even to unpack until certain dependencies are resolved. Such packages are said to "pre-depend" on the presence of some other package(s). The Debian project provided this mechanism to support the safe upgrading of systems from a.out format to ELF format, where the order in which packages were unpacked was critical. There are other large upgrade situations where this method is useful, e.g., for packages with "required" priority and their libc dependency.

Once again, more detailed information about this can be found in the Packaging Manual.


2.2.10 Package status

Package status can be "unknown", "install", "remove", "purge", or "hold". These "want" flags indicate what the user wanted to do with a package (either by making choices in the "Select" section of dselect, or by directly invoking dpkg).

Their meanings are:


2.2.11 Holding back packages from an upgrade

There are two mechanisms for holding back packages from an upgrade, through dpkg, or, beginning with Woody, through APT.

With dpkg, first export the list of package selections:

     dpkg --get-selections \* > selections.txt

Then edit the resulting file selections.txt, changing the line containing the package you wish to hold, e.g. libc6, from this:

     libc6                       install

to this:

     libc6                       hold

Save the file, and reload it into dpkg database with:

     dpkg --set-selections < selections.txt

Or, if you know the package name to hold, simply run:

     echo libc6 hold | dpkg --set-selections

This procedure holds packages at the install process of each package file.

The same effect can be obtained through dselect. Simply enter the [S]elect screen, find the package you wish to hold in its present state, and press the `=' key (or `H'). The changes will take effect immediately after you exit the [S]elect screen.

The APT system in the Woody distribution has a new alternative mechanism for holding packages during the archive retrieval process using Pin-Priority. See the manual page apt_preferences(5), along with http://www.debian.org/doc/manuals/apt-howto/ or the apt-howto package; /etc/apt/preferences 概觀, 第 6.2.8 節 also contains a brief explanation.


2.2.12 Source packages

Source packages are distributed in a directory called source, and you can either download them manually, or use

     apt-get source foo

to fetch them (see the apt-get(8) manual page on how to set up APT for doing that).


2.2.13 Building binary packages from a source package

For a package foo, you will need all of foo_*.dsc, foo_*.tar.gz and foo_*.diff.gz to compile the source (note: there is no .diff.gz for a Debian native package).

Once you have them, if you have the dpkg-dev package installed, the command

     $ dpkg-source -x foo_version-revision.dsc

will extract the package into a directory called foo-version.

Issue the following command to build the binary package:

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Then,

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

to install the newly built package. See 把套件引入 stable 系統, 第 6.4.10 節.


2.2.14 Creating new Debian packages

For detailed information on creating new packages, read the New Maintainers' Guide, available in the maint-guide package, or at http://www.debian.org/doc/manuals/maint-guide/.


2.3 Upgrading a Debian system

One of Debian's goals is to provide a consistent upgrade path and a secure upgrade process, and we always do our best to make a new release smoothly upgradable from the previous ones. Packages will alert the user when there are important notices during the upgrade process, and will often provide a solution to a possible problem.

You should also read the Release Notes, the document that describes the details of specific upgrades, shipped on all Debian CDs, and available on the WWW at http://www.debian.org/releases/stable/releasenotes or http://www.debian.org/releases/testing/releasenotes.

A practical guide to upgrades is provided in Debian 套件管理系統, 第 6 章. This section describes the fundamental details.


2.3.1 Methods for upgrading a Debian system

One can always simply execute an anonymous FTP or wget call to a Debian archive, peruse the directories until one finds a desired file, fetch it, and finally install it using dpkg. (Note that dpkg will install upgrade files in place, even on a running system.) Sometimes, however, a revised package will require the installation of a newly revised version of another package, in which case the installation will fail until/unless the other package is installed.

Many people find this manual approach much too time-consuming, since Debian evolves so quickly—typically, a dozen or more new packages are uploaded every week. This number is larger just before a new major release. To deal with this avalanche, many people prefer to use an automated program for upgrading. Several specialized package management tools are available for this purpose.


2.3.2 Package management tools overview

The Debian package management system has two objectives: the manipulation of the package file itself and the retrieval of package files from the Debian archive. dpkg performs the former task, APT and dselect the latter.


2.3.3 dpkg

This is the main program for manipulating package files; read dpkg(8) for a full description.

dpkg comes with several primitive supplemental programs.

dpkg-ftp and dpkg-mountable have been superseded by the introduction of the APT system.


2.3.4 APT

APT (the Advanced Packaging Tool) is an advanced interface to the Debian packaging system consisting of several programs whose names typically begin with "apt-". apt-get, apt-cache and apt-cdrom are the command-line tools for handling packages. These also function as the user's "back end" programs to other tools, such as dselect and aptitude.

For more information, install the apt package and read apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody), and /usr/share/doc/apt/guide.html/index.html.

An alternative source of information is the APT HOWTO. This can be installed by apt-howto at /usr/share/doc/Debian/apt-howto/.

apt-get upgrade and apt-get dist-upgrade pull only the packages listed under "Depends:" and overlook all the packages listed under "Recommends:" and "Suggests:". To avoid this, use dselect.


2.3.5 dselect

This program is a menu-driven user interface to the Debian package management system. It is particularly useful for first-time installations and large-scale upgrades. See dselect, 第 6.2.3 節.

For more information, install the install-doc package and read /usr/share/doc/install-doc/dselect-beginner.en.html or dselect Documentation for Beginners.


2.3.6 Upgrading a running system

The kernel (filesystem) in Debian systems supports replacing files even while they're being used.

We also provide a program called start-stop-daemon which is used to start daemons at boot time or to stop daemons when the kernel runlevel is changed (e.g., from multiuser to single-user or to "halt"). The same program is used by installation scripts when a new package containing a daemon is installed, to stop running daemons, and to restart them as necessary.

Note that the Debian system does not require use of the single-user mode to upgrade a running system.


2.3.7 Downloaded and cached .deb archive files

If you have manually downloaded package files to your disk (which is not absolutely necessary, see above for the description of dpkg-ftp or APT), then after you have installed the packages, you can remove the .deb files from your system.

If APT is used, these files are cached in the /var/cache/apt/archives directory. You may erase them after installation (apt-get clean) or copy them to another machine's /var/cache/apt/archives directory to save downloading during subsequent installations.


2.3.8 Record-keeping for upgrades

dpkg keeps a record of the packages that have been unpacked, configured, removed, and/or purged, but does not (currently) keep a log of terminal activity that occurred while a package was being so manipulated.

The simplest way to work around this is to run your dpkg, dselect, apt-get, etc., sessions within the script(1) program.


2.4 The Debian boot process


2.4.1 The init program

Like all Unices, Debian boots up by executing the program init. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by sourcing or forking a subprocess depending on their file extension to perform initialization such as checking and mounting file systems, loading modules, starting the network services, setting the clock, etc. Then, for compatibility, it also runs the files (except those with a `.' in the filename) in /etc/rc.boot/. Any scripts in the latter directory are usually reserved for system administrator use, and using them in packages is deprecated. See System initialization hints, 第 9.1 節 for more info.


2.4.2 Runlevels

After completing the boot process, init executes all start scripts in a directory specified by the default runlevel (this runlevel is given by the entry for id in /etc/inittab). Like most System V compatible Unices, Linux has 7 runlevels:

Debian systems come with id=2, which indicates that the default runlevel will be 2 when the multiuser state is entered, and the scripts in /etc/rc2.d/ will be run.

In fact, the scripts in any of the directories /etc/rcN.d/ are just symbolic links back to scripts in /etc/init.d/. However, the names of the files in each of the /etc/rcN.d/ directories are selected to indicate the way the scripts in /etc/init.d/ will be run. Specifically, before entering any runlevel, all the scripts beginning with `K' are run; these scripts kill services. Then all the scripts beginning with `S' are run; these scripts start services. The two-digit number following the `K' or `S' indicates the order in which the script is run. Lower-numbered scripts are executed first.

This approach works because the scripts in /etc/init.d/ all take an argument which can be either "start", "stop", "reload", "restart" or "force-reload" and will then do the task indicated by the argument. These scripts can be used even after a system has been booted, to control various processes.

For example, with the argument "reload" the command

     # /etc/init.d/sendmail reload

sends the sendmail daemon a signal to reread its configuration file.


2.4.3 Customizing the boot process

Debian does not use a BSD-style rc.local directory to customize the boot process; instead it provides the following mechanism for customization.

Suppose a system needs to execute script foo on startup, or on entry to a particular (System V) runlevel. Then the system administrator should:

  1. Enter the script foo into the directory /etc/init.d/.
  1. Run the Debian command update-rc.d with appropriate arguments, to set up links between the (command-line-specified) directories rc?.d and /etc/init.d/foo. Here, ? is a number from 0 through 6 that corresponds to one of the System V runlevels.
  1. Reboot the system.

The command update-rc.d will set up links between files in the directories rc?.d and the script in /etc/init.d/. Each link will begin with an `S' or a `K', followed by a number, followed by the name of the script. When the system enters a runlevel N, scripts beginning with `K' in /etc/rcN.d/ are executed with stop as their argument, followed by those beginning with `S' in /etc/rcN.d/ with start as their argument.

One might, for example, cause the script foo to execute at boot-up, by putting it in /etc/init.d/ and installing the links with update-rc.d foo defaults 19. The argument defaults refers to the default runlevels, which are 2 through 5. The argument 19 ensures that foo is called before any scripts containing numbers 20 or larger.


2.5 Supporting diversity

Debian offers several avenues to accommodate any wishes of the system administrator without breaking the system.

Any files under /usr/local/ belong to the system administrator and Debian will not touch them. Most (or all) files under /etc are conffiles and Debian will not overwrite them upon upgrade unless the system administrator requests so explicitly.


2.6 Internationalization

The Debian system is internationalized and provides support for character display and entry in many languages, both within the console and under X. Many documents, manual pages, and system messages have been translated into a growing number of languages. During installation, Debian prompts the user to choose an installation language (and sometimes a local language variant).

If your installed system does not support all the language features you need, or if you need to change languages or install a different keyboard to support your language, see Localization and national language support, 第 9.7 節.


2.7 Debian and the kernel

See The Linux kernel under Debian, 第 7 章.


2.7.1 Compiling a kernel from non-Debian source

One has to understand the Debian policy with respect to headers.

The Debian C libraries are built with the most recent stable releases of the kernel headers.

For example, the Debian-1.2 release used version 5.4.13 of the headers. This practice contrasts with the Linux kernel source packages distributed at all Linux FTP archive sites, which use even more recent versions of the headers. The kernel headers distributed with the kernel source are located in /usr/include/linux/include/.

If you need to compile a program with kernel headers that are newer than those provided by libc6-dev, then you must add -I/usr/src/linux/include/ to your command line when compiling. This came up at one point, for example, with the packaging of the automounter daemon (amd). When new kernels changed some internals dealing with NFS, amd needed to know about them. This required the inclusion of the latest kernel headers.


2.7.2 Tools to build custom kernels

Users who wish to (or must) build a custom kernel are encouraged to download the package kernel-package. This package contains the script to build the kernel package, and provides the capability to create a Debian kernel-image package just by running the command

     # make-kpkg kernel_image

in the top-level kernel source directory. Help is available by executing the command

     # make-kpkg --help

and through the manual page make-kpkg(8) and The Linux kernel under Debian, 第 7 章.

Users must separately download the source code for the most recent kernel (or the kernel of their choice) from their favorite Linux archive site, unless a kernel-source-version package is available (where version stands for the kernel version). The Debian initrd boot script requires a special kernel patch called initrd; see http://bugs.debian.org/149236.

Detailed instructions for using the kernel-package package are given in the file /usr/share/doc/kernel-package/README.gz.


2.7.3 Alternative boot loaders

To employ alternative boot loaders such as grub or loadlin, copy the compiled Linux kernel bzimage to other locations (e.g., to /boot/grub or to an MS-DOS partition).


2.7.4 Custom boot floppies

The task of making a custom boot floppy is greatly aided by the Debian package boot-floppies, normally found in the admin section of the Debian FTP archive. Shell scripts in this package produce boot floppies in syslinux format. These are MS-DOS formatted floppies whose master boot records have been altered so that they directly boot Linux (or whatever other operating system has been defined in the syslinux.cfg file on the floppy). Other scripts in this package produce emergency root disks and can even reproduce the base disks.

You will find more information about this in the /usr/doc/boot-floppies/README file after installing the boot-floppies package.


2.7.5 Special provisions for dealing with modules

Debian's modconf package provides a shell script (/usr/sbin/modconf) which can be used to customize the configuration of modules. This script presents a menu-based interface, prompting the user for particulars on the loadable device drivers in his system. The responses are used to customize the file /etc/modules.conf (which lists aliases, and other arguments that must be used in conjunction with various modules) through files in /etc/modutils/, and /etc/modules (which lists the modules that must be loaded at boot time).

Like the (new) Configure.help files that are now available to support the construction of custom kernels, the modconf package comes with a series of help files (in /usr/lib/modules_help/) which provide detailed information on appropriate arguments for each of the modules. See The modularized 2.4 kernel, 第 7.2 節 for examples.


2.7.6 De-installing an old kernel package

The kernel-image-NNN.prerm script checks to see whether the kernel you are currently running is the same as the kernel you are trying to de-install. Therefore you can safely remove unwanted kernel image packages using this command:

     dpkg --purge --force-remove-essential kernel-image-NNN

(Replace NNN with your kernel version and revision number, of course.)


[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 下一頁 ]

Debian 參考手冊

1.06-16, 週六 一月 3 21:37:21 UTC 2004

青木 修 (Osamu Aoki) osamu@debian.org
翻譯者:唐偉清 (Tang Wei-Ching) wctang@csie.nctu.edu.tw
作者, 第 A.1 節