mirror of https://github.com/tLDP/LDP
sag
This commit is contained in:
parent
da1f87fcce
commit
afd648a914
|
@ -0,0 +1,461 @@
|
|||
<appendix id="gfdl1.2">
|
||||
<appendixinfo>
|
||||
<title>GNU Free Documentation License</title>
|
||||
|
||||
<pubdate>Version 1.2, November 2002</pubdate>
|
||||
<copyright><year>2000,2001,2002</year>
|
||||
<holder>Free Software Foundation, Inc.</holder></copyright>
|
||||
<legalnotice id="gfdl-legalnotice">
|
||||
<para><address>Free Software Foundation, Inc.
|
||||
<street>59 Temple Place, Suite 330</street>,
|
||||
<city>Boston</city>,
|
||||
<state>MA</state>
|
||||
<postcode>02111-1307</postcode>
|
||||
<country>USA</country>
|
||||
</address></para>
|
||||
<para>Everyone is permitted to copy and distribute verbatim
|
||||
copies of this license document, but changing it is not
|
||||
allowed.</para>
|
||||
</legalnotice>
|
||||
<releaseinfo>Version 1.2, November 2002</releaseinfo>
|
||||
</appendixinfo>
|
||||
|
||||
<title>GNU Free Documentation License</title>
|
||||
<section id="gfdl-0"><title>PREAMBLE</title>
|
||||
|
||||
<para>The purpose of this License is to make a manual, textbook, or
|
||||
other functional and useful document "free" in the sense of freedom: to
|
||||
assure everyone the effective freedom to copy and redistribute it, with
|
||||
or without modifying it, either commercially or noncommercially.
|
||||
Secondarily, this License preserves for the author and publisher a way
|
||||
to get credit for their work, while not being considered responsible for
|
||||
modifications made by others.</para>
|
||||
|
||||
<para>This License is a kind of "copyleft", which means that derivative
|
||||
works of the document must themselves be free in the same sense. It
|
||||
complements the GNU General Public License, which is a copyleft license
|
||||
designed for free software.</para>
|
||||
|
||||
<para>We have designed this License in order to use it for manuals for
|
||||
free software, because free software needs free documentation: a free
|
||||
program should come with manuals providing the same freedoms that the
|
||||
software does. But this License is not limited to software manuals; it
|
||||
can be used for any textual work, regardless of subject matter or
|
||||
whether it is published as a printed book. We recommend this License
|
||||
principally for works whose purpose is instruction or reference.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-1"><title>APPLICABILITY AND DEFINITIONS</title>
|
||||
|
||||
<para id="gfdl-doc">This License applies to any manual or other work, in
|
||||
any medium, that contains a notice placed by the copyright holder saying
|
||||
it can be distributed under the terms of this License. Such a notice
|
||||
grants a world-wide, royalty-free license, unlimited in duration, to use
|
||||
that work under the conditions stated herein. The "Document", below,
|
||||
refers to any such manual or work. Any member of the public is a
|
||||
licensee, and is addressed as "you". You accept the license if you
|
||||
copy, modify or distribute the work in a way requiring permission under
|
||||
copyright law.</para>
|
||||
|
||||
<para id="gfdl-mod-ver">A "Modified Version" of the Document means any
|
||||
work containing the Document or a portion of it, either copied verbatim,
|
||||
or with modifications and/or translated into another language.</para>
|
||||
|
||||
<para id="gfdl-secnd-sect">A "Secondary Section" is a named appendix or
|
||||
a front-matter section of the Document that deals exclusively with the
|
||||
relationship of the publishers or authors of the Document to the
|
||||
Document's overall subject (or to related matters) and contains nothing
|
||||
that could fall directly within that overall subject. (Thus, if the
|
||||
Document is in part a textbook of mathematics, a Secondary Section may
|
||||
not explain any mathematics.) The relationship could be a matter of
|
||||
historical connection with the subject or with related matters, or of
|
||||
legal, commercial, philosophical, ethical or political position
|
||||
regarding them.</para>
|
||||
|
||||
<para id="gfdl-inv-sect">The "Invariant Sections" are certain Secondary
|
||||
Sections whose titles are designated, as being those of Invariant
|
||||
Sections, in the notice that says that the Document is released under
|
||||
this License. If a section does not fit the above definition of
|
||||
Secondary then it is not allowed to be designated as Invariant. The
|
||||
Document may contain zero Invariant Sections. If the Document does not
|
||||
identify any Invariant Sections then there are none.</para>
|
||||
|
||||
<para id="gfdl-cov-text">The "Cover Texts" are certain short passages of
|
||||
text that are listed, as Front-Cover Texts or Back-Cover Texts, in the
|
||||
notice that says that the Document is released under this License. A
|
||||
Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at
|
||||
most 25 words.</para>
|
||||
|
||||
<para id="gfdl-transparent">A "Transparent" copy of the Document means a
|
||||
machine-readable copy, represented in a format whose specification is
|
||||
available to the general public, that is suitable for revising the
|
||||
document straightforwardly with generic text editors or (for images
|
||||
composed of pixels) generic paint programs or (for drawings) some widely
|
||||
available drawing editor, and that is suitable for input to text
|
||||
formatters or for automatic translation to a variety of formats suitable
|
||||
for input to text formatters. A copy made in an otherwise Transparent
|
||||
file format whose markup, or absence of markup, has been arranged to
|
||||
thwart or discourage subsequent modification by readers is not
|
||||
Transparent. An image format is not Transparent if used for any
|
||||
substantial amount of text. A copy that is not "Transparent" is called
|
||||
"Opaque".</para>
|
||||
|
||||
<para>Examples of suitable formats for Transparent copies include plain
|
||||
ASCII without markup, Texinfo input format, LaTeX input format, SGML or
|
||||
XML using a publicly available DTD, and standard-conforming simple HTML,
|
||||
PostScript or PDF designed for human modification. Examples of
|
||||
transparent image formats include PNG, XCF and JPG. Opaque formats
|
||||
include proprietary formats that can be read and edited only by
|
||||
proprietary word processors, SGML or XML for which the DTD and/or
|
||||
processing tools are not generally available, and the machine-generated
|
||||
HTML, PostScript or PDF produced by some word processors for output
|
||||
purposes only.</para>
|
||||
|
||||
<para id="gfdl-title-page">The "Title Page" means, for a printed book,
|
||||
the title page itself, plus such following pages as are needed to hold,
|
||||
legibly, the material this License requires to appear in the title page.
|
||||
For works in formats which do not have any title page as such, "Title
|
||||
Page" means the text near the most prominent appearance of the work's
|
||||
title, preceding the beginning of the body of the text.</para>
|
||||
|
||||
<para id="gfdl-entitled">A section "Entitled XYZ" means a named subunit
|
||||
of the Document whose title either is precisely XYZ or contains XYZ in
|
||||
parentheses following text that translates XYZ in another language.
|
||||
(Here XYZ stands for a specific section name mentioned below, such as
|
||||
"Acknowledgements", "Dedications", "Endorsements", or "History".) To
|
||||
"Preserve the Title" of such a section when you modify the Document
|
||||
means that it remains a section "Entitled XYZ" according to this
|
||||
definition.</para>
|
||||
|
||||
<para>The Document may include Warranty Disclaimers next to the notice
|
||||
which states that this License applies to the Document. These Warranty
|
||||
Disclaimers are considered to be included by reference in this License,
|
||||
but only as regards disclaiming warranties: any other implication that
|
||||
these Warranty Disclaimers may have is void and has no effect on the
|
||||
meaning of this License.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-2"><title>VERBATIM COPYING</title>
|
||||
|
||||
<para>You may copy and distribute the Document in any medium, either
|
||||
commercially or noncommercially, provided that this License, the
|
||||
copyright notices, and the license notice saying this License applies to
|
||||
the Document are reproduced in all copies, and that you add no other
|
||||
conditions whatsoever to those of this License. You may not use
|
||||
technical measures to obstruct or control the reading or further copying
|
||||
of the copies you make or distribute. However, you may accept
|
||||
compensation in exchange for copies. If you distribute a large enough
|
||||
number of copies you must also follow the conditions in section 3.
|
||||
</para>
|
||||
|
||||
<para>You may also lend copies, under the same conditions stated above,
|
||||
and you may publicly display copies.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-3"><title>COPYING IN QUANTITY</title>
|
||||
|
||||
<para>If you publish printed copies (or copies in media that commonly
|
||||
have printed covers) of the Document, numbering more than 100, and the
|
||||
Document's license notice requires Cover Texts, you must enclose the
|
||||
copies in covers that carry, clearly and legibly, all these Cover Texts:
|
||||
Front-Cover Texts on the front cover, and Back-Cover Texts on the back
|
||||
cover. Both covers must also clearly and legibly identify you as the
|
||||
publisher of these copies. The front cover must present the full title
|
||||
with all words of the title equally prominent and visible. You may add
|
||||
other material on the covers in addition. Copying with changes limited
|
||||
to the covers, as long as they preserve the title of the Document and
|
||||
satisfy these conditions, can be treated as verbatim copying in other
|
||||
respects.</para>
|
||||
|
||||
<para>If the required texts for either cover are too voluminous to fit
|
||||
legibly, you should put the first ones listed (as many as fit
|
||||
reasonably) on the actual cover, and continue the rest onto adjacent
|
||||
pages.</para>
|
||||
|
||||
<para>If you publish or distribute Opaque copies of the Document
|
||||
numbering more than 100, you must either include a machine-readable
|
||||
Transparent copy along with each Opaque copy, or state in or with each
|
||||
Opaque copy a computer-network location from which the general
|
||||
network-using public has access to download using public-standard
|
||||
network protocols a complete Transparent copy of the Document, free of
|
||||
added material. If you use the latter option, you must take reasonably
|
||||
prudent steps, when you begin distribution of Opaque copies in quantity,
|
||||
to ensure that this Transparent copy will remain thus accessible at the
|
||||
stated location until at least one year after the last time you
|
||||
distribute an Opaque copy (directly or through your agents or retailers)
|
||||
of that edition to the public.</para>
|
||||
|
||||
<para>It is requested, but not required, that you contact the authors of
|
||||
the Document well before redistributing any large number of copies, to
|
||||
give them a chance to provide you with an updated version of the
|
||||
Document.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-4"><title>MODIFICATIONS</title>
|
||||
|
||||
<para>You may copy and distribute a Modified Version of the Document
|
||||
under the conditions of sections 2 and 3 above, provided that you
|
||||
release the Modified Version under precisely this License, with the
|
||||
Modified Version filling the role of the Document, thus licensing
|
||||
distribution and modification of the Modified Version to whoever
|
||||
possesses a copy of it. In addition, you must do these things in the
|
||||
Modified Version:</para>
|
||||
|
||||
<orderedlist id="gfdl-modif-cond" numeration="upperalpha">
|
||||
<title>GNU FDL Modification Conditions</title>
|
||||
<listitem><simpara>Use in the Title Page (and on the covers, if any) a
|
||||
title distinct from that of the Document, and from those of previous
|
||||
versions (which should, if there were any, be listed in the History
|
||||
section of the Document). You may use the same title as a previous
|
||||
version if the original publisher of that version gives permission.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>List on the Title Page, as authors, one or more
|
||||
persons or entities responsible for authorship of the modifications in
|
||||
the Modified Version, together with at least five of the principal
|
||||
authors of the Document (all of its principal authors, if it has fewer
|
||||
than five), unless they release you from this requirement.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>State on the Title page the name of the publisher of
|
||||
the Modified Version, as the publisher.</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve all the copyright notices of the Document.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Add an appropriate copyright notice for your
|
||||
modifications adjacent to the other copyright notices.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Include, immediately after the copyright notices, a
|
||||
license notice giving the public permission to use the Modified
|
||||
Version under the terms of this License, in the form shown in the
|
||||
<link linkend="gfdl-addendum">Addendum</link> below.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve in that license notice the full lists of
|
||||
Invariant Sections and required Cover Texts given in the Document's
|
||||
license notice.</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Include an unaltered copy of this License.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve the section Entitled "History", Preserve its
|
||||
Title, and add to it an item stating at least the title, year, new
|
||||
authors, and publisher of the Modified Version as given on the Title
|
||||
Page. If there is no section Entitled "History" in the Document,
|
||||
create one stating the title, year, authors, and publisher of the
|
||||
Document as given on its Title Page, then add an item describing the
|
||||
Modified Version as stated in the previous sentence.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve the network location, if any, given in the
|
||||
Document for public access to a Transparent copy of the Document, and
|
||||
likewise the network locations given in the Document for previous
|
||||
versions it was based on. These may be placed in the "History"
|
||||
section. You may omit a network location for a work that was
|
||||
published at least four years before the Document itself, or if the
|
||||
original publisher of the version it refers to gives permission.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>For any section Entitled "Acknowledgements" or
|
||||
"Dedications", Preserve the Title of the section, and preserve in the
|
||||
section all the substance and tone of each of the contributor
|
||||
acknowledgements and/or dedications given therein.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve all the Invariant Sections of the Document,
|
||||
unaltered in their text and in their titles. Section numbers or the
|
||||
equivalent are not considered part of the section titles.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Delete any section Entitled "Endorsements".
|
||||
Such a section may not be included in the Modified Version.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Do not retitle any existing section to be Entitled
|
||||
"Endorsements" or to conflict in title with any Invariant Section.
|
||||
</simpara></listitem>
|
||||
|
||||
<listitem><simpara>Preserve any Warranty Disclaimers.
|
||||
</simpara></listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If the Modified Version includes new front-matter sections or
|
||||
appendices that qualify as Secondary Sections and contain no material
|
||||
copied from the Document, you may at your option designate some or all
|
||||
of these sections as invariant. To do this, add their titles to the
|
||||
list of Invariant Sections in the Modified Version's license notice.
|
||||
These titles must be distinct from any other section titles.</para>
|
||||
|
||||
<para>You may add a section Entitled "Endorsements", provided it
|
||||
contains nothing but endorsements of your Modified Version by various
|
||||
parties--for example, statements of peer review or that the text has
|
||||
been approved by an organization as the authoritative definition of a
|
||||
standard.</para>
|
||||
|
||||
<para>You may add a passage of up to five words as a Front-Cover Text,
|
||||
and a passage of up to 25 words as a Back-Cover Text, to the end of the
|
||||
list of Cover Texts in the Modified Version. Only one passage of
|
||||
Front-Cover Text and one of Back-Cover Text may be added by (or through
|
||||
arrangements made by) any one entity. If the Document already includes
|
||||
a cover text for the same cover, previously added by you or by
|
||||
arrangement made by the same entity you are acting on behalf of, you may
|
||||
not add another; but you may replace the old one, on explicit permission
|
||||
from the previous publisher that added the old one.</para>
|
||||
|
||||
<para>The author(s) and publisher(s) of the Document do not by this
|
||||
License give permission to use their names for publicity for or to
|
||||
assert or imply endorsement of any Modified Version.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-5"><title>COMBINING DOCUMENTS</title>
|
||||
|
||||
<para>You may combine the Document with other documents released under
|
||||
this License, under the terms defined in <link linkend="gfdl-4">section
|
||||
4</link> above for modified versions, provided that you include in the
|
||||
combination all of the Invariant Sections of all of the original
|
||||
documents, unmodified, and list them all as Invariant Sections of your
|
||||
combined work in its license notice, and that you preserve all their
|
||||
Warranty Disclaimers.</para>
|
||||
|
||||
<para>The combined work need only contain one copy of this License, and
|
||||
multiple identical Invariant Sections may be replaced with a single
|
||||
copy. If there are multiple Invariant Sections with the same name but
|
||||
different contents, make the title of each such section unique by adding
|
||||
at the end of it, in parentheses, the name of the original author or
|
||||
publisher of that section if known, or else a unique number. Make the
|
||||
same adjustment to the section titles in the list of Invariant Sections
|
||||
in the license notice of the combined work.</para>
|
||||
|
||||
<para>In the combination, you must combine any sections Entitled
|
||||
"History" in the various original documents, forming one section
|
||||
Entitled "History"; likewise combine any sections Entitled
|
||||
"Acknowledgements", and any sections Entitled "Dedications". You must
|
||||
delete all sections Entitled "Endorsements".</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-6"><title>COLLECTIONS OF DOCUMENTS</title>
|
||||
|
||||
<para>You may make a collection consisting of the Document and other
|
||||
documents released under this License, and replace the individual copies
|
||||
of this License in the various documents with a single copy that is
|
||||
included in the collection, provided that you follow the rules of this
|
||||
License for verbatim copying of each of the documents in all other
|
||||
respects.</para>
|
||||
|
||||
<para>You may extract a single document from such a collection, and
|
||||
distribute it individually under this License, provided you insert a
|
||||
copy of this License into the extracted document, and follow this
|
||||
License in all other respects regarding verbatim copying of that
|
||||
document.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-7"><title>AGGREGATION WITH INDEPENDENT WORKS</title>
|
||||
|
||||
<para>A compilation of the Document or its derivatives with other
|
||||
separate and independent documents or works, in or on a volume of a
|
||||
storage or distribution medium, is called an "aggregate" if the
|
||||
copyright resulting from the compilation is not used to limit the legal
|
||||
rights of the compilation's users beyond what the individual works
|
||||
permit. When the Document is included in an aggregate, this License does
|
||||
not apply to the other works in the aggregate which are not themselves
|
||||
derivative works of the Document.</para>
|
||||
|
||||
<para>If the Cover Text requirement of section 3 is applicable to these
|
||||
copies of the Document, then if the Document is less than one half of
|
||||
the entire aggregate, the Document's Cover Texts may be placed on covers
|
||||
that bracket the Document within the aggregate, or the electronic
|
||||
equivalent of covers if the Document is in electronic form. Otherwise
|
||||
they must appear on printed covers that bracket the whole
|
||||
aggregate.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-8"><title>TRANSLATION</title>
|
||||
|
||||
<para>Translation is considered a kind of modification, so you may
|
||||
distribute translations of the Document under the terms of section 4.
|
||||
Replacing Invariant Sections with translations requires special
|
||||
permission from their copyright holders, but you may include
|
||||
translations of some or all Invariant Sections in addition to the
|
||||
original versions of these Invariant Sections. You may include a
|
||||
translation of this License, and all the license notices in the
|
||||
Document, and any Warranty Disclaimers, provided that you also include
|
||||
the original English version of this License and the original versions
|
||||
of those notices and disclaimers. In case of a disagreement between the
|
||||
translation and the original version of this License or a notice or
|
||||
disclaimer, the original version will prevail.</para>
|
||||
|
||||
<para>If a section in the Document is Entitled "Acknowledgements",
|
||||
"Dedications", or "History", the requirement (section 4) to Preserve its
|
||||
Title (section 1) will typically require changing the actual
|
||||
title.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-9"><title>TERMINATION</title>
|
||||
|
||||
<para>You may not copy, modify, sublicense, or distribute the Document
|
||||
except as expressly provided for under this License. Any other attempt
|
||||
to copy, modify, sublicense or distribute the Document is void, and will
|
||||
automatically terminate your rights under this License. However,
|
||||
parties who have received copies, or rights, from you under this License
|
||||
will not have their licenses terminated so long as such parties remain
|
||||
in full compliance.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-10"><title>FUTURE REVISIONS OF THIS LICENSE</title>
|
||||
|
||||
<para>The Free Software Foundation may publish new, revised versions of
|
||||
the GNU Free Documentation License from time to time. Such new versions
|
||||
will be similar in spirit to the present version, but may differ in
|
||||
detail to address new problems or concerns. See
|
||||
http://www.gnu.org/copyleft/.</para>
|
||||
|
||||
<para>Each version of the License is given a distinguishing version
|
||||
number. If the Document specifies that a particular numbered version of
|
||||
this License "or any later version" applies to it, you have the option
|
||||
of following the terms and conditions either of that specified version
|
||||
or of any later version that has been published (not as a draft) by the
|
||||
Free Software Foundation. If the Document does not specify a version
|
||||
number of this License, you may choose any version ever published (not
|
||||
as a draft) by the Free Software Foundation.</para>
|
||||
</section>
|
||||
|
||||
<section id="gfdl-addendum"><title>ADDENDUM: How to use this License for
|
||||
your documents</title>
|
||||
|
||||
<para>To use this License in a document you have written, include a copy
|
||||
of the License in the document and put the following copyright and
|
||||
license notices just after the title page:</para>
|
||||
|
||||
<blockquote id="copyright-sample">
|
||||
<title>Sample Invariant Sections list</title>
|
||||
<para>Copyright (c) YEAR YOUR NAME.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled "GNU
|
||||
Free Documentation License".
|
||||
</para></blockquote>
|
||||
|
||||
<para>If you have Invariant Sections, Front-Cover Texts and Back-Cover
|
||||
Texts, replace the "with...Texts." line with this:</para>
|
||||
|
||||
<blockquote id="inv-cover-sample">
|
||||
<title>Sample Invariant Sections list</title>
|
||||
<para>
|
||||
with the Invariant Sections being LIST THEIR TITLES, with the
|
||||
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
|
||||
</para></blockquote>
|
||||
|
||||
<para>If you have Invariant Sections without Cover Texts, or some other
|
||||
combination of the three, merge those two alternatives to suit the
|
||||
situation.</para>
|
||||
|
||||
<para>If your document contains nontrivial examples of program code, we
|
||||
recommend releasing these examples in parallel under your choice of free
|
||||
software license, such as the GNU General Public License, to permit
|
||||
their use in free software.</para>
|
||||
</section>
|
||||
</appendix>
|
|
@ -0,0 +1,184 @@
|
|||
<preface id="preface">
|
||||
<title>About This Book</title>
|
||||
|
||||
<blockquote><para><quote>Only two things are infinite, the universe
|
||||
and human stupidity, and I'm not sure about the former.</quote>
|
||||
Albert Einstein</para></blockquote>
|
||||
|
||||
<sect1 id="acknowledgements">
|
||||
<title>Acknowledgments</title>
|
||||
<sect2 id="acknowledgements-joanna"><title>Joanna's acknowledgments</title>
|
||||
<para>Many people have helped me with this book, directly or
|
||||
indirectly. I would like to especially thank Matt Welsh for
|
||||
inspiration and LDP leadership, Andy Oram for getting me to work
|
||||
again with much-valued feedback, Olaf Kirch for showing me that it
|
||||
can be done, and Adam Richter at Yggdrasil and others for showing
|
||||
me that other people can find it interesting as well.</para>
|
||||
|
||||
<para>Stephen Tweedie, H. Peter Anvin, Remy Card, Theodore
|
||||
Ts'o, and Stephen Tweedie have let me borrow their work (and
|
||||
thus make the book look thicker and much more impressive):
|
||||
a comparison between the xia and ext2 filesystems, the device
|
||||
list and a description of the ext2 filesystem. These aren't
|
||||
part of the book any more. I am most grateful for this, and
|
||||
very apologetic for the earlier versions that sometimes lacked
|
||||
proper attribution.</para>
|
||||
|
||||
<para>In addition, I would like to thank Mark Komarinski for
|
||||
sending his material in 1993 and the many system administration
|
||||
columns in Linux Journal. They are quite informative and
|
||||
inspirational.</para>
|
||||
|
||||
<para>Many useful comments have been sent by a large number
|
||||
of people. My miniature black hole of an archive doesn't let
|
||||
me find all their names, but some of them are, in alphabetical
|
||||
order: Paul Caprioli, Ales Cepek, Marie-France Declerfayt,
|
||||
Dave Dobson, Olaf Flebbe, Helmut Geyer, Larry Greenfield and
|
||||
his father, Stephen Harris, Jyrki Havia, Jim Haynes, York Lam,
|
||||
Timothy Andrew Lister, Jim Lynch, Michael J. Micek, Jacob Navia,
|
||||
Dan Poirier, Daniel Quinlan, Jouni K Seppänen, Philippe Steindl,
|
||||
G.B. Stotte. My apologies to anyone I have forgotten.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="acknowledgements-stephen"><title>Stephen's acknowledgments</title>
|
||||
<para>I would like to thank Lars and Joanna for their hard
|
||||
work on the guide.</para>
|
||||
|
||||
<para>In a guide like this one there are likely to be at least
|
||||
some minor inaccuracies. And there are almost certainly going to
|
||||
be sections that become out of date from time to time. If you
|
||||
notice any of this then please let me know by sending me an email
|
||||
to: <email>bagpuss@debian.org.NOSPAM</email>. I will take virtually
|
||||
any form of input (diffs, just plain text, html, whatever), I am
|
||||
in no way above allowing others to help me maintain such a large
|
||||
text as this :) </para>
|
||||
|
||||
<para>Many thanks to Helen Topping Shaw for getting the red pen out
|
||||
and making the text far better than it would otherwise have been.
|
||||
Also thanks are due just for being wonderful.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="acknowledgements-alex">
|
||||
<title>Alex's Acknowledgments</title>
|
||||
<para>I would like to thank Lars, Joanna, and Stephen for all the
|
||||
great work that they have done on this document over the years. I
|
||||
only hope that my contribution will be worthy of continuing the work
|
||||
they started.</para>
|
||||
|
||||
<para>Like the previous maintainers, I openly welcome any comments,
|
||||
suggestions, complains, corrections, or any other form of feedback
|
||||
you may have. This document can only benefit from the suggestions
|
||||
of those who use it.</para>
|
||||
|
||||
<para>There have been many people who have helped me on my journey
|
||||
through the "Windows-Free" world, the person I feel I need to thank the
|
||||
most is my first true UN*X mentor, Mike Velasco. Back in a time before
|
||||
SCO became a "dirty word", Mike helped me on the path of tar's, cpio's,
|
||||
and many, many man pages. Thanks Mike! You are the 'Sofa King'.<para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="revision-hist">
|
||||
<title>Revision History</title>
|
||||
<para>
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.7</revnumber>
|
||||
<date>2001-12-03</date>
|
||||
<authorinitials>SS</authorinitials>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.8</revnumber>
|
||||
<date>2003-11-18</date>
|
||||
<authorinitials>AW</authorinitials>
|
||||
<revdescription><orderedlist spacing='compact'>
|
||||
<listitem><simpara>Added a section on NTP
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Cleaned some SGML
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Added ext3 to the filesystem
|
||||
section
|
||||
</simpara></listitem>
|
||||
</orderedlist></revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.9</revnumber>
|
||||
<date> </date>
|
||||
<authorinitials>AW</authorinitials>
|
||||
<revdescription><orderedlist spacing='compact'>
|
||||
<listitem><simpara>Cleaned some SGML code, changed
|
||||
doctype to lds.dsl, and added id tags
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Updated section on filesystem types,
|
||||
and Filesystem comparison
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Updated partition type section
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Updated section on creating
|
||||
partitions
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Wrote section on Logical Volume
|
||||
Manager (LVM)
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Updated section on space allocation
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Added chapter on System Monitoring
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Added more command line utilities
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Verified Device list
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Modified email address for Authors
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Added references to more in-depth
|
||||
documents where applicable
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Added notes on upcoming sections
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Indexed chapters 1 - 4, & part of 5
|
||||
</simpara></listitem>
|
||||
<listitem><simpara>Updated Misc Information throughout
|
||||
the book
|
||||
</simpara></listitem>
|
||||
</orderedlist></revdescription>
|
||||
</revision>
|
||||
</revhistory>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="available-versions">
|
||||
<title>Source and pre-formatted versions available</title>
|
||||
<para>The source code and other machine readable formats
|
||||
of this book can be found on the Internet via anonymous FTP at the
|
||||
Linux Documentation Project home page <ulink
|
||||
url="http://www.tldp.org/">http://www.tldp.org/</ulink>, or
|
||||
at the home page of this book at
|
||||
<ulink url="http://www.draxeman.com/sag.html">
|
||||
http://www.draxeman/sag.html</ulink>. This book is available in at
|
||||
least it's SGML source, as well as, HTML and PDF formats. Other
|
||||
formats may be available.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="typo-conventions">
|
||||
<title>Typographical Conventions</title>
|
||||
|
||||
<para>Throughout this book, I have tried to use uniform
|
||||
typographical conventions. Hopefully they aid readability. If
|
||||
you can suggest any improvements please contact me.</para>
|
||||
|
||||
<para>Filenames are expressed as:
|
||||
<filename>/usr/share/doc/foo</filename>.</para>
|
||||
|
||||
<para>Command names are expressed as: <command>fsck</command>
|
||||
|
||||
<para>Email addresses are expressed as:
|
||||
<email>user@domain.com</email></para>
|
||||
|
||||
<para>URLs are expressed as: <ulink
|
||||
url="http://www.tldp.org">http://www.tldp.org</ulink>
|
||||
</para>
|
||||
|
||||
<para>I will add to this section as things come up whilst
|
||||
editing. If you notice anything that should be added then
|
||||
please let me know.</para>
|
||||
</sect1>
|
||||
</preface>
|
|
@ -0,0 +1,172 @@
|
|||
<chapter id="intro">
|
||||
<title>Introduction</title>
|
||||
<blockquote><para><quote>In the beginning, the file was without
|
||||
form, and void; and emptiness was upon the face of the bits.
|
||||
And the Fingers of the Author moved upon the face of the
|
||||
keyboard. And the Author said, Let there be words, and there
|
||||
were words.</quote></para></blockquote>
|
||||
|
||||
<para>The Linux System Administrator's Guide,
|
||||
describes the system administration aspects of using Linux.
|
||||
It is intended for people who know next to nothing about system
|
||||
administration (those saying ``what is it?''), but who have already
|
||||
mastered at least the basics of normal usage. This manual
|
||||
doesn't tell you how to install Linux; that is described in the
|
||||
Installation and Getting Started document. See below for more
|
||||
information about Linux manuals.</para>
|
||||
|
||||
<para>System administration covers all the things that you have to
|
||||
do to keep a computer system in usable order. It includes
|
||||
things like backing up files (and restoring them if necessary),
|
||||
installing new programs, creating accounts for users (and deleting
|
||||
them when no longer needed), making certain that the filesystem
|
||||
is not corrupted, and so on. If a computer were, say, a house,
|
||||
system administration would be called maintenance, and would
|
||||
include cleaning, fixing broken windows, and other such things.
|
||||
</para>
|
||||
|
||||
<para>The structure of this manual is such that many of the
|
||||
chapters should be usable independently, so if you need information
|
||||
about backups, for example, you can read just that chapter. However,
|
||||
this manual is first and foremost a tutorial and can be read
|
||||
sequentially or as a whole.</para>
|
||||
|
||||
<para>This manual is not intended to be used completely
|
||||
independently. Plenty of the rest of the Linux documentation is also
|
||||
important for system administrators. After all, a system
|
||||
administrator is just a user with special privileges and duties.
|
||||
Very useful resources are the manual pages, which should always be
|
||||
consulted when you are not familiar with a command. If you do not
|
||||
know which command you need, then the <command>apropos</command>
|
||||
command can be used. Consult its manual page for more details.</para>
|
||||
|
||||
<para>While this manual is targeted at Linux, a general principle
|
||||
has been that it should be useful with other UNIX based operating
|
||||
systems as well. Unfortunately, since there is so much variance
|
||||
between different versions of UNIX in general, and in system
|
||||
administration in particular, there is little hope to cover
|
||||
all variants. Even covering all possibilities for Linux is
|
||||
difficult, due to the nature of its development.</para>
|
||||
|
||||
<para>There is no one official Linux distribution, so different
|
||||
people have different setups and many people have a setup they
|
||||
have built up themselves. This book is not targeted at any
|
||||
one distribution. Distributions can and do vary considerably.
|
||||
When possible, differences have been noted and alternatives
|
||||
given. For a list of distributions <indexterm id="Linux-distro">
|
||||
<primary>Linux</primary><secondary>Distributions</secondary></indexterm>
|
||||
and some of their differences see
|
||||
<ulink url="http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions">
|
||||
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions</ulink>.
|
||||
</para>
|
||||
|
||||
<para>In trying to describe how things work, rather than just
|
||||
listing ``five easy steps'' for each task, there is much information
|
||||
here that is not necessary for everyone, but those parts are marked
|
||||
as such and can be skipped if you use a preconfigured system.
|
||||
Reading everything will, naturally, increase your understanding of
|
||||
the system and should make using and administering it more
|
||||
productive.</para>
|
||||
|
||||
<para>Understanding is the key to success with Linux. This book
|
||||
could just provide recipes, but what would you do when confronted by
|
||||
a problem this book had no recipe for? If the book can provide
|
||||
understanding, then recipes are not required. The answers will be self
|
||||
evident.</para>
|
||||
|
||||
<para>Like all other Linux related development, the work
|
||||
to write this manual was done on a volunteer basis: I did it because
|
||||
I thought it might be fun and because I felt it should be done.
|
||||
However, like all volunteer work, there is a limit to how much time,
|
||||
knowledge and experience people have. This means that the manual is
|
||||
not necessarily as good as it would be if a wizard had been paid
|
||||
handsomely to write it
|
||||
and had spent millennia to perfect it. Be warned.</para>
|
||||
|
||||
<para>One particular point where corners have been cut is that
|
||||
many things that are already well documented in other freely
|
||||
available manuals are not always covered here. This applies
|
||||
especially to program specific documentation, such as all the
|
||||
details of using <command>mkfs</command>. Only the purpose of the
|
||||
program and as much of its usage as is necessary for the purposes of
|
||||
this manual is described. For further information, consult these
|
||||
other manuals. Usually, all of the referred to documentation is
|
||||
part of the full Linux
|
||||
documentation set.</para>
|
||||
|
||||
<sect1 id="GNU-or-not">
|
||||
<title>Linux or GNU/Linux, that is the question.</title>
|
||||
|
||||
<para>Many people feel that Linux should really be called GNU/Linux.
|
||||
<indexterm id="ch01-GNU-or-not"><primary>Linux</primary><secondary>GNU
|
||||
</secondary></indexterm>
|
||||
This is because Linux is only the kernel, not the applications that run
|
||||
on it. Most of the basic command line utilities were written by the
|
||||
Free Software Foundation while developing their GNU operating system.
|
||||
Among those utilities are some of the most basic commands like cp, mv
|
||||
lsof, and dd.</para>
|
||||
|
||||
<para>In a nutshell, what happened was, the FSF <indexterm id="fsf">
|
||||
<primary>Free Software Foundation</primary></indexterm>started developing GNU
|
||||
by writing things like compliers, C libraries, and basic command line
|
||||
utilities before the kernel. Linus Torvalds, started Linux by writing
|
||||
the Linux kernel first and using applications written for GNU.</para>
|
||||
|
||||
<para>I do not feel that this is the proper forum to debate what name
|
||||
people should use when referring to Linux. I mention it here, because
|
||||
I feel it is important to understand the relationship between GNU and
|
||||
Linux, and to also explain why some Linux is sometimes referred to as
|
||||
GNU/Linux. The document will be simply referring to it as Linux.
|
||||
</para>
|
||||
|
||||
<para>GNU's side of the issue is discussed on their website:</para>
|
||||
|
||||
<para>The relationship -
|
||||
<ulink url="http://www.gnu.org/gnu/linux-and-gnu.html">
|
||||
http://www.gnu.org/gnu/linux-and-gnu.html</ulink></para>
|
||||
|
||||
<para>Why Linux should be GNU/Linux - <ulink
|
||||
url="http://www.gnu.org/gnu/why-gnu-linux.html">
|
||||
http://www.gnu.org/gnu/why-gnu-linux.html</ulink></para>
|
||||
|
||||
<para>GNU/Linux FAQ's - <ulink
|
||||
url="http://www.gnu.org/gnu/gnu-linux-faq.html">
|
||||
http://www.gnu.org/gnu/gnu-linux-faq.html</ulink></para>
|
||||
|
||||
<para>Here are some Alternate views:</para>
|
||||
|
||||
<para><ulink url="http://librenix.com/?inode=2312">
|
||||
http://librenix.com/?inode=2312</ulink></para>
|
||||
|
||||
<para><ulink url="http://www.topology.org/linux/lingl.html">
|
||||
http://www.topology.org/linux/lingl.html</ulink></para>
|
||||
|
||||
<para><ulink url="http://atulchitnis.net/writings/gnulinux.php">
|
||||
http://atulchitnis.net/writings/gnulinux.php</ulink></para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Trademarks</title>
|
||||
|
||||
<para>Microsoft, Windows, Windows NT, Windows 2000, and Windows XP
|
||||
are trademarks and/or registered trademarks of Microsoft Corporation.
|
||||
</para>
|
||||
|
||||
<para>Red Hat is a trademark of Red Hat, Inc., in the United States
|
||||
and other countries.</para>
|
||||
|
||||
<para>SuSE is a trademark of Novell.</para>
|
||||
|
||||
<para>Linux is a registered trademark of Linus Torvalds.</para>
|
||||
|
||||
<para>UNIX is a registered trademark in the United States and other
|
||||
countries, licensed exclusively through X/Open Company Ltd.</para>
|
||||
|
||||
<para>GNU is a registered trademark of the Free Software Foundation.
|
||||
</para>
|
||||
|
||||
<para>Other product names mentioned herein may be trademarks and/or
|
||||
registered trademarks of their respective companies. </para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,538 @@
|
|||
<chapter id="overview">
|
||||
<title>Overview of a Linux System</title>
|
||||
|
||||
<blockquote><para><quote>God saw everything that he
|
||||
had made, and saw that it was very good. </quote> -- Bible
|
||||
King James Version. Genesis 1:31</para></blockquote>
|
||||
|
||||
<para>This chapter gives an overview of a Linux system. First,
|
||||
the major services provided by the operating system are described.
|
||||
Then, the programs that implement these services are described
|
||||
with a considerable lack of detail. The purpose of this chapter
|
||||
is to give an understanding of the system as a whole, so that
|
||||
each part is described in detail elsewhere.</para>
|
||||
|
||||
<sect1 id="various-parts">
|
||||
<title>Various parts of an operating system</title>
|
||||
|
||||
<para>UNIX and 'UNIX-like' operating systems (such as Linux) consist
|
||||
of a <glossterm>kernel</glossterm> and some
|
||||
<glossterm>system programs</glossterm>. There are also some
|
||||
<glossterm>application programs</glossterm> for doing work.
|
||||
The kernel <indexterm id="ch02-kern-over"><primary>kernel</primary>
|
||||
<secondary>overview</secondary></indexterm>is the heart of the operating
|
||||
system. In fact, it is often mistakenly considered to be the
|
||||
operating system itself, but it is not. An operating system provides
|
||||
provides many more services than a plain kernel.</para>
|
||||
|
||||
<para>It keeps track of files on the disk, starts programs and runs
|
||||
them concurrently, assigns memory and other resources to various
|
||||
processes, receives packets from and sends packets to the network,
|
||||
and so on. The kernel does very little by itself, but it provides
|
||||
tools with which all services can be built. It also prevents anyone
|
||||
from accessing the hardware directly, forcing everyone to use the
|
||||
tools it provides.
|
||||
This way the kernel provides some protection for users from each
|
||||
other. The tools provided by the kernel are used via
|
||||
<glossterm>system calls<glossterm>. See manual page section 2 for more
|
||||
information on these. </para>
|
||||
|
||||
<para>The system programs use the tools provided by the kernel to
|
||||
implement the various services required from an operating system.
|
||||
System programs, and all other programs, run `on top of the
|
||||
kernel', in what is called the <glossterm>user mode</glossterm>.
|
||||
The difference between system and application programs is
|
||||
one of intent: applications are intended for getting useful
|
||||
things done (or for playing, if it happens to be a game),
|
||||
whereas system programs are needed to get the system working.
|
||||
A word processor is an application; <command>mount</command>
|
||||
is a system program. The difference is often somewhat blurry,
|
||||
however, and is important only to compulsive categorizers.</para>
|
||||
|
||||
<para>An operating system can also contain compilers and their
|
||||
corresponding libraries (GCC and the C library in particular under
|
||||
Linux), although not all programming languages need be part of
|
||||
the operating system. Documentation, and sometimes even games,
|
||||
can also be part of it. Traditionally, the operating system has
|
||||
been defined by the contents of the installation tape or disks;
|
||||
with Linux it is not as clear since it is spread all over the
|
||||
FTP sites of the world.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="kernel-parts">
|
||||
<title>Important parts of the kernel</title>
|
||||
|
||||
<para>The Linux kernel <indexterm id="ch02-kern-over2"><primary>kernel
|
||||
</primary><secondary>overview</secondary></indexterm> consists of several important
|
||||
parts: process
|
||||
management, memory management, hardware device drivers, filesystem
|
||||
drivers, network management, and various other bits and pieces.
|
||||
<xref linkend="kerneloverview">
|
||||
shows some of them.</para>
|
||||
|
||||
<figure id="kerneloverview" float="1">
|
||||
<title>Some of the more important parts of the Linux kernel</title>
|
||||
<graphic fileref="overview-kernel.png">
|
||||
</figure>
|
||||
|
||||
<para>Probably the most important parts of the kernel (nothing else
|
||||
works without them) are memory management and
|
||||
process management. Memory management <indexterm id="kern-mem">
|
||||
<primary>kernel</primary><secondary>memory management</secondary>
|
||||
</indexterm> takes care of assigning
|
||||
memory areas and swap space areas to processes, parts of the
|
||||
kernel, and for the buffer cache. Process management
|
||||
<indexterm id="kern-proc-mgt"><primary>kernel</primary><secondary>
|
||||
process management</secondary></indexterm> creates
|
||||
processes, and implements multitasking by switching the
|
||||
active process on the processor.</para>
|
||||
|
||||
<para>At the lowest level, the kernel contains a hardware device
|
||||
driver <indexterm id="hardware-driver"><primary>kernel</primary>
|
||||
<secondary>driver</secondary></indexterm>for each kind of hardware
|
||||
it supports. Since the world is
|
||||
full of different kinds of hardware, the number of hardware device
|
||||
drivers is large. There are often many otherwise similar pieces
|
||||
of hardware that differ in how they are controlled by software.
|
||||
The similarities make it possible to have general classes of
|
||||
drivers that support similar operations; each member of the class
|
||||
has the same interface to the rest of the kernel but differs in
|
||||
what it needs to do to implement them. For example, all disk
|
||||
drivers look alike to the rest of the kernel, i.e., they all
|
||||
have operations like `initialize the drive', `read sector N',
|
||||
and `write sector N'.</para>
|
||||
|
||||
<para>Some software services provided by the kernel itself have
|
||||
similar properties, and can therefore be abstracted into classes.
|
||||
For example, the various network protocols have been abstracted
|
||||
into one programming interface, the BSD socket library. Another
|
||||
example is the <glossterm>virtual filesystem</glossterm>
|
||||
<indexterm id="VFS"><primary>kernel</primary><secondary>virtual
|
||||
filesystem (VFS)</secondary></indexterm> (VFS)
|
||||
layer that abstracts the filesystem operations away from their
|
||||
implementation. Each filesystem type provides an implementation
|
||||
of each filesystem operation. When some entity tries to use
|
||||
a filesystem, the request goes via the VFS, which routes the
|
||||
request to the proper filesystem driver.</para>
|
||||
|
||||
<para>A more in-depth discussion of kernel internals can be found
|
||||
at <ulink url="http://www.tldp.org/LDP/lki/index.html">
|
||||
http://www.tldp.org/LDP/lki/index.html</ulink>. This document was
|
||||
written for the 2.4 kernel. When I find one for the 2.6 kernel, I
|
||||
will list it here.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="major-services">
|
||||
<title>Major services in a UNIX system</title>
|
||||
|
||||
<para>This section describes some of the more important UNIX
|
||||
services, but without much detail. They are described more
|
||||
thoroughly in later chapters.</para>
|
||||
|
||||
<sect2 id="init">
|
||||
<title><command>init</command></title>
|
||||
|
||||
<para>The single most important service in a UNIX system is
|
||||
provided by <command>init</command><indexterm id="ch02-init">
|
||||
<primary>init</primary></indexterm> <command>init</command>
|
||||
is started as the first process of every UNIX system, as the last
|
||||
thing the kernel does when it boots. When <command>init</command>
|
||||
starts, it continues the boot process by doing various startup
|
||||
chores (checking and mounting filesystems, starting daemons,
|
||||
etc).</para>
|
||||
|
||||
<para>The exact list of things that <command>init</command>
|
||||
does depends on which flavor it is; there are several to choose
|
||||
from. <command>init</command> usually provides the concept of
|
||||
<glossterm>single user mode</glossterm><indexterm id="ch02-single-user">
|
||||
<primary>runlevels</primary><secondary>1 - single user
|
||||
</secondary>, in which no one can
|
||||
log in and root uses a shell at the console; the usual mode is
|
||||
called <glossterm>multiuser mode</glossterm><indexterm id="multi-user">
|
||||
<primary>runlevels</primary><secondary>3 - multi-user</secondary>
|
||||
</indexterm>. Some flavors
|
||||
generalize this as <glossterm>run levels</glossterm>; single
|
||||
and multiuser modes are considered to be two run levels, and
|
||||
there can be additional ones as well, for example, to run X on
|
||||
the console.</para>
|
||||
|
||||
<para>Linux allows for up to 10
|
||||
<glossterm>runlevels</glossterm><indexterm id="rlevels">
|
||||
<primary>runlevels</primary></indexterm>, 0-9, but usually only some of
|
||||
these are defined by default. Runlevel 0 <indexterm id="rlevel0">
|
||||
<primary>runlevels</primary><secondary>0 - shutdown</secondary>
|
||||
</indexterm>is defined as ``system
|
||||
halt''. Runlevel 1 <indexterm id="rlevel1">
|
||||
<primary>runlevels</primary><secondary>1 - single-user</secondary>
|
||||
</indexterm>is defined as ``single user mode''. Runlevel 3
|
||||
<indexterm id="rlevel3"><primary>runlevels</primary>
|
||||
<secondary>3 - multi-user</secondary></indexterm> is defined as
|
||||
"multi user" because it is the runlevel that the system boot into
|
||||
under normal day to day conditions. Runlevel 5 <indexterm id="rlevel5">
|
||||
<primary>runlevels</primary><secondary>5 - multi-user with GUI
|
||||
</secondary> is typically the same as 3 except that a GUI
|
||||
<indexterm id="ch02-xwindows"><primary>GUI</primary></indexterm>
|
||||
gets started also.
|
||||
Runlevel 6 <indexterm id="rlevel6"><primary>runlevels</primary>
|
||||
<secondary>6 - reboot</secondary></indexterm>is defined as ``system
|
||||
reboot''. Other runlevels are
|
||||
dependent on how your particular distribution has defined them,
|
||||
and they vary significantly between distributions. Looking at
|
||||
the contents of <filename>/etc/inittab</filename>
|
||||
<indexterm id="ch02-inittab"><primary>inittab</primary></indexterm>
|
||||
usually will <indexterm id="ch02-rlevel-inittab"><primary>runlevels
|
||||
</primary><secondary>inittab</secondary></indexterm>
|
||||
give some hint what the predefined runlevels are and what they
|
||||
have been defined as.</para>
|
||||
|
||||
<para>In normal operation, <command>init</command>
|
||||
<indexterm id="ch02-init2"><primary>commands</primary>
|
||||
<secondary>init</secondary></indexterm> makes
|
||||
sure <command>getty</command><indexterm id="ch02-getty">
|
||||
<primary>commands</primary><secondary>getty</secondary></indexterm>
|
||||
is working (to allow users to log in)
|
||||
and to adopt orphan processes (processes whose parent has died; in
|
||||
UNIX <emphasis>all</emphasis> processes <emphasis>must</emphasis>
|
||||
be in a single tree, so orphans must be adopted).</para>
|
||||
|
||||
<para>When the system is shut down, it is <command>init</command>
|
||||
that is in charge of killing all other processes, unmounting all
|
||||
filesystems and stopping the processor, along with anything else
|
||||
it has been configured to do.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="terminal-logins">
|
||||
<title>Logins from terminals</title>
|
||||
|
||||
<para>Logins from terminals (via serial lines) and the console
|
||||
(when not running X) are provided by the <command>getty</command>
|
||||
<indexterm id="ch02-getty2"><primary>getty</primary></indexterm>
|
||||
program. <command>init</command><indexterm id="ch02-init3">
|
||||
<primary>init</primary></indexterm> starts a separate instance of
|
||||
<command>getty</command> for each terminal upon which logins are to
|
||||
be allowed. <command>getty</command> reads the username and runs
|
||||
the <command>login</command><indexterm id="ch02-login">
|
||||
<primary>login</primary></indexterm>program, which reads the password.
|
||||
If the username and password are correct, <command>login</command> runs
|
||||
the shell. When the shell terminates, i.e., the user logs out, or
|
||||
when <command>login</command> terminated because the username and
|
||||
password didn't match, <command>init</command> notices this and
|
||||
starts a new instance of <command>getty</command>. The kernel has no
|
||||
notion of logins, this is all handled by the
|
||||
<glossterm>system programs</glossterm>.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="syslog">
|
||||
<title>Syslog</title>
|
||||
|
||||
<para>The kernel and many <glossterm>system programs</glossterm>
|
||||
produce error, warning, and other messages. It is often important
|
||||
that these messages can be viewed later, even much later, so they
|
||||
should be written to a file. The program doing this is
|
||||
<command>syslog</command> <indexterm id="ch02-syslog"><primary>syslog
|
||||
</primary></indexterm>. It can be configured to sort the
|
||||
messages to different files according to writer or degree of
|
||||
importance. For example, kernel messages are often directed to a
|
||||
separate file from the others, since kernel messages are often more
|
||||
important and need to be read
|
||||
regularly to spot problems.</para>
|
||||
|
||||
<para><xref linkend="system-logs"> will provide more on
|
||||
this.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="cron">
|
||||
<title>Periodic command execution: <command>cron</command> and
|
||||
<command>at</command></title>
|
||||
|
||||
<para>Both users and system administrators often need
|
||||
to run commands periodically. For example, the system administrator
|
||||
might want to run a command to clean the directories with temporary
|
||||
files (<filename>/tmp</filename> and <filename>/var/tmp</filename>)
|
||||
from old files, to keep the disks from filling up, since not all
|
||||
programs clean up after
|
||||
themselves correctly.</para>
|
||||
|
||||
<para>The <command>cron</command> <indexterm id="ch02-cron">
|
||||
<primary>cron</primary></indexterm> service is set up to do this.
|
||||
Each user can have a <filename>crontab</filename>
|
||||
<indexterm id="ch02-crontab"><primary>cron</primary><secondary>crontab
|
||||
</secondary></indexterm> file, where she
|
||||
lists the commands she wishes to execute and the times they should
|
||||
be executed. The <command>cron</command> daemon takes care of
|
||||
starting the commands when specified.</para>
|
||||
|
||||
<para>The <command>at</command> <indexterm id="ch02-at"><primary>at
|
||||
</primary></indexterm> service is similar to
|
||||
<command>cron</command>, but it is once only: the command is
|
||||
executed at the given time, but it is not repeated.</para>
|
||||
|
||||
<para>We will go more into this later. See the manual pages
|
||||
cron(1), crontab(1), crontab(5), at(1) and atd(8) for more in
|
||||
depth information.</para>
|
||||
|
||||
<para><xref linkend="task-automation"> will cover this.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="gui">
|
||||
<title>Graphical user interface</title>
|
||||
|
||||
<para><indexterm id="ch02-gui2"><primary>GUI</primary></indexterm>
|
||||
UNIX and Linux don't incorporate the user interface
|
||||
into the kernel; instead, they let it be implemented by user level
|
||||
programs. This applies for both text mode and graphical
|
||||
environments.</para>
|
||||
|
||||
<para>This arrangement makes the system more flexible, but has
|
||||
the disadvantage that it is simple to implement a different user
|
||||
interface for each program, making the system harder to
|
||||
learn.</para>
|
||||
|
||||
<para>The graphical environment primarily used with Linux
|
||||
is called the X Window System <indexterm id="ch02-xwin"><primary>GUI
|
||||
</primary><secondary>X Windows</secondary></indexterm> (X for short).
|
||||
X also does not implement a user interface; it only implements a
|
||||
window system, i.e., tools with which a graphical user interface can
|
||||
be implemented. Some popular window managers are: fvwm <indexterm id="fvwm">
|
||||
<primary>GUI</primary><secondary>fvwm</secondary></indexterm>, icewm
|
||||
<indexterm id="icewm"><primary>GUI</primary><secondary>icewm</secondary>
|
||||
</indexterm>, blackbox <indexterm id="blackbox"><primary>GUI</primary>
|
||||
<secondary>blackbox</secondary></indexterm>, and windowmaker
|
||||
<indexterm id="windowmaker"><primary>GUI</primary><secondary>windowmaker
|
||||
</secondary></indexterm>. There are also two popular desktop managers,
|
||||
KDE <indexterm id="ch02-kde"><primary>KDE</primary></indexterm> and Gnome.
|
||||
<indexterm id="ch02-gnome"><primary>GNOME</primary></indexterm></para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="networking">
|
||||
<title>Networking</title>
|
||||
|
||||
<para>Networking <indexterm id="ch02-net"><primary>networking</primary>
|
||||
</indexterm>is the act of connecting two or more computers
|
||||
so that they can communicate with each other. The actual methods
|
||||
of connecting and communicating are slightly complicated, but
|
||||
the end result is very useful.</para>
|
||||
|
||||
<para>UNIX operating systems have many networking features.
|
||||
Most basic services (filesystems, printing, backups, etc) can
|
||||
be done over the network. This can make system administration
|
||||
easier, since it allows centralized administration, while
|
||||
still reaping in the benefits of microcomputing and distributed
|
||||
computing, such as lower costs and better fault tolerance.</para>
|
||||
|
||||
<para>However, this book merely glances at networking; see the
|
||||
<citetitle>Linux Network Administrators' Guide</citetitle>
|
||||
<ulink url="http://www.tldp.org/LDP/nag2/index.html">
|
||||
http://www.tldp.org/LDP/nag2/index.html</ulink>
|
||||
<indexterm id="ch02-nag"><primary>networking</primary><secondary>Network
|
||||
Admin Guide (NAG)</secondary></indexterm> for
|
||||
more information, including a basic description of how networks
|
||||
operate.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="network-logins">
|
||||
<title>Network logins</title>
|
||||
|
||||
<para>Network logins<indexterm id="logging-in">
|
||||
<primary>logging in</primary></indexterm> work a little differently
|
||||
than normal logins. For each person logging in via the network
|
||||
there is a separate virtual network connection,
|
||||
and there can be any number of these depending on the available
|
||||
bandwidth. It is therefore not possible to run a separate
|
||||
<command>getty</command><indexterm id="ch02-getty3"><primary>getty
|
||||
</primary></indexterm> for each possible virtual connection.
|
||||
There are also several different ways to log in via a network,
|
||||
<command>telnet</command><indexterm id="ch02-telnet"><primary>telnet
|
||||
</primary></indexterm> and <command>ssh</command>
|
||||
<indexterm id="ch02-ssh"><primary>ssh</primary></indexterm> being
|
||||
the major ones in TCP/IP networks.</para>
|
||||
|
||||
<para>These days many Linux system administrators consider
|
||||
<command>telnet</command> and <command>rlogin</command> to be
|
||||
insecure and prefer <command>ssh</command>, the ``secure shell'',
|
||||
which encrypts traffic going over the network, thereby making it far
|
||||
less likely that the malicious can ``sniff'' your connection and gain
|
||||
sensitive data like usernames and passwords. It is highly recommended
|
||||
you use <command>ssh</command> rather than <command>telnet</command>
|
||||
or <command>rlogin</command>.</para>
|
||||
|
||||
<para>Network logins<indexterm id="logging-in2">
|
||||
<primary>Logging in</primary></indexterm> have, instead of a herd
|
||||
of <command>getty</command>s<indexterm id="ch02-getty4">
|
||||
<primary>getty</primary></indexterm>, a single daemon per way
|
||||
of logging in
|
||||
(<command>telnet</command><indexterm id="ch02-telnet2">
|
||||
<primary>telnet</primary></indexterm> and <command>ssh</command>
|
||||
<indexterm id="ch02-ssh2"><primary>ssh</primary></indexterm> have
|
||||
separate daemons) that listens for all incoming login attempts.
|
||||
When it notices one, it starts a new instance of itself to
|
||||
handle that single attempt; the original instance continues to
|
||||
listen for other attempts. The new instance works similarly
|
||||
to <command>getty</command>.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="nfs">
|
||||
<title>Network file systems</title>
|
||||
<para>One of the more useful things that can be done with
|
||||
networking services is sharing files via a <glossterm>network
|
||||
file system</glossterm>. Depending on your network this could
|
||||
be done over the Network File System (NFS)<indexterm id="ch02-nfs">
|
||||
<primary>Network File System (NFS)</primary></indexterm>, or over
|
||||
the Common Internet File System (CIFS)<indexterm id="ch02-cifs">
|
||||
<primary>Common Internet File System (CIFS)</primary></indexterm>.
|
||||
NFS is typically a 'UNIX' based service. In Linux, NFS is supported
|
||||
by the kernel<indexterm id="ch02-kern-nfs"><primary>kernel</primary>
|
||||
<secondary>NFS</secondary></indexterm>. CIFS however is not. In Linux,
|
||||
CIFS is supported by Samba<indexterm id="ch02-samba"><primary>Samba
|
||||
</primary></indexterm> <ulink url="http://www.samba.org">
|
||||
http://www.samba.org</ulink>.
|
||||
|
||||
<para>With a network file system any file operations done by
|
||||
a program on one machine are sent over the network to another
|
||||
computer. This fools the program to think that all the files
|
||||
on the other computer are actually on the computer the program
|
||||
is running on. This makes information sharing extremely simple,
|
||||
since it requires no modifications to programs.</para>
|
||||
|
||||
<para>This will be covered in more detail in
|
||||
<xref linkend="net-attached">.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mail">
|
||||
<title>Mail</title>
|
||||
<para>Electronic mail<indexterm id="ch02-email">
|
||||
<primary>email</primary></indexterm> is the most popularly used method for
|
||||
communicating via computer. An electronic letter is stored in a
|
||||
file using a special format, and special mail programs are used
|
||||
to send and read the letters.</para>
|
||||
|
||||
<para>Each user has an <glossterm>incoming mailbox</glossterm>
|
||||
(a file in the special format), where all new mail is stored.
|
||||
When someone sends mail, the mail program locates the receiver's
|
||||
mailbox and appends the letter to the mailbox file. If the
|
||||
receiver's mailbox is in another machine, the letter is sent to
|
||||
the other machine, which delivers it to the mailbox as it best
|
||||
sees fit.</para>
|
||||
|
||||
<para>The mail system consists of many programs. The
|
||||
delivery of mail to local or remote mailboxes is done by one
|
||||
program (the <glossterm>mail transfer agent</glossterm> (MTA)
|
||||
<indexterm id="ch02-email2"><primary>mail transfer agent (MTA)
|
||||
</primary></indexterm>, e.g., <command>sendmail</command>
|
||||
<indexterm id="ch02-email3"><primary>mail transfer agent (MTA)
|
||||
</primary><secondary>sendmail</secondary></indexterm>
|
||||
or <command>postfix</command><indexterm id="ch02-email4">
|
||||
<primary>mail transfer agent (MTA)</primary>
|
||||
<secondary>postfix</secondary></indexterm>
|
||||
), while the programs users use are many and varied
|
||||
(<glossterm>mail user agent</glossterm> (MUA)
|
||||
<indexterm id="ch02-email5"><primary>mail user agent</primary>
|
||||
</indexterm>, e.g., <command>pine</command>
|
||||
<indexterm id="ch02-email6"><primary>mail user agent</primary>
|
||||
<secondary>pine</secondary></indexterm>, or
|
||||
<command>evolution</command>
|
||||
<indexterm id="ch02-email7"><primary>mail user agent</primary>
|
||||
<secondary>evolution</secondary></indexterm>.
|
||||
The mailboxes are usually stored
|
||||
in <filename>/var/spool/mail</filename> until the user's MUA
|
||||
retrieves them.</para>
|
||||
|
||||
<para>For more information on setting up and running mail services
|
||||
you can read the Mail Administrator HOWTO at
|
||||
<ulink url="http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO.html">
|
||||
http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO.html</ulink>, or
|
||||
visit the sendmail or postfix's website.
|
||||
<ulink url="http://www.sendmail.org/">http://www.sendmail.org/</ulink>,
|
||||
or <ulink url="http://www.postfix.org/">http://www.postfix.org/
|
||||
</ulink>.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="printing">
|
||||
<title>Printing</title>
|
||||
<para>Only one person can use a printer<indexterm id="ch02-print">
|
||||
<primary>printing</primary></indexterm> at one time, but it is
|
||||
uneconomical not to share printers between users. The printer is
|
||||
therefore managed by software that implements a <glossterm>print
|
||||
queue</glossterm><indexterm id="ch02-print2"><primary>printing
|
||||
</primary><secondary>queue</secondary></indexterm>: all print
|
||||
jobs are put into a queue and
|
||||
whenever the printer is done with one job, the next one is sent
|
||||
to it automatically. This relieves the users from organizing
|
||||
the print queue and fighting over control of the printer.
|
||||
Instead, they form a new queue <emphasis>at</emphasis>
|
||||
the printer, waiting for their printouts, since no one ever seems to
|
||||
be able to get the queue software to know exactly when anyone's printout
|
||||
is really finished. This is a great boost to intra-office social
|
||||
relations.</para>
|
||||
|
||||
<para>The print queue software also <glossterm>spools</glossterm>
|
||||
<indexterm id="ch02-print3"><primary>printing</primary>
|
||||
<secondary>spools</secondary></indexterm> the printouts on
|
||||
disk, i.e., the text is kept in a file while
|
||||
the job is in the queue. This allows an application program
|
||||
to spit out the print jobs quickly to the print queue software;
|
||||
the application does not have to wait until the job is actually
|
||||
printed to continue. This is really convenient, since it
|
||||
allows one to print out one version, and not have to wait for
|
||||
it to be printed before one can make a completely revised new
|
||||
version.</para>
|
||||
|
||||
<para>You can refer to the Printing-HOWTO located at
|
||||
<ulink url="http://www.tldp.org/HOWTO/Printing-HOWTO/index.html">
|
||||
http://www.tldp.org/HOWTO/Printing-HOWTO/index.html</ulink>
|
||||
for more help in setting up printers.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="fs-layout">
|
||||
<title>The filesystem layout</title>
|
||||
<para>The filesystem<indexterm id="ch02-filesystem">
|
||||
<primary>filesystem</primary></indexterm> is divided into many parts;
|
||||
usually along the lines of a root filesystem with
|
||||
<filename>/bin</filename>
|
||||
<indexterm id="ch02-filesystem2"><primary>filesystem</primary>
|
||||
<secondary>/bin</secondary></indexterm>,
|
||||
<filename>/lib</filename>
|
||||
<indexterm id="ch02-filesystem3"><primary>filesystem</primary>
|
||||
<secondary>/lib</secondary></indexterm>,
|
||||
<filename>/etc</filename>
|
||||
<indexterm id="ch02-filesystem4"><primary>filesystem</primary>
|
||||
<secondary>/etc</secondary></indexterm>,
|
||||
<filename>/dev</filename>
|
||||
<indexterm id="ch02-filesystem5"><primary>filesystem</primary>
|
||||
<secondary>/dev</secondary></indexterm>, and a few others;
|
||||
a <filename>/usr</filename>
|
||||
<indexterm id="ch02-filesystem6"><primary>filesystem</primary>
|
||||
<secondary>/usr</secondary></indexterm> filesystem with
|
||||
programs and unchanging data;
|
||||
<filename>/var</filename>
|
||||
<indexterm id="ch02-filesystem7"><primary>filesystem</primary>
|
||||
<secondary>/var</secondary></indexterm> filesystem with changing
|
||||
data (such as log files); and a
|
||||
<filename>/home</filename>
|
||||
<indexterm id="ch02-filesystem8"><primary>filesystem</primary>
|
||||
<secondary>/home</secondary></indexterm> for everyone's personal
|
||||
files. Depending on the hardware configuration and the decisions
|
||||
of the system administrator, the division can be different;
|
||||
it can even be all in one filesystem.</para>
|
||||
|
||||
<para><xref linkend="dir-tree-overview"> describes the filesystem
|
||||
layout in some little detail; the Filesystem Hierarchy Standard
|
||||
<indexterm id="ch02-fhs"><primary>Filesystem Hierarchy Standard (FHS)
|
||||
</primary></indexterm>. covers
|
||||
it in somewhat more detail. This can be found on the web at:
|
||||
<ulink url="http://www.pathname.com/fhs/">
|
||||
http://www.pathname.com/fhs/</ulink></para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,238 @@
|
|||
<chapter id="device-list">
|
||||
<title>Hardware, Devices, and Tools</title>
|
||||
|
||||
<blockquote><para><quote>Knowledge speaks, but wisdom listens.</quote>
|
||||
Jimi Hendrix</para></blockquote>
|
||||
|
||||
<para>This chapter gives an overview of what a device file is, and how to
|
||||
create one. The canonical list of device files is
|
||||
<filename>/usr/src/linux/Documentation/devices.txt</filename>
|
||||
<indexterm id="ch04-kern-dev"><primary>kernel</primary><secondary>devices</secondary>
|
||||
</indexterm> if you have
|
||||
the Linux kernel source code installed on your system. The devices listed
|
||||
here are correct as of kernel version 2.6.8.</para>
|
||||
|
||||
<sect1 id="hwutils">
|
||||
<title>Hardware Utilities </title>
|
||||
|
||||
<sect2 id="makedev">
|
||||
<title>The <command>MAKEDEV</command><indexterm id="ch04-makedev">
|
||||
<primary>commands</primary><secondary>MAKEDEV</secondary>
|
||||
</indexterm> Script</title>
|
||||
|
||||
<para>Most device files will already be created and will be there
|
||||
ready to use after you install your Linux system. If by some chance
|
||||
you need to create one which is not provided then you should first
|
||||
try to use the <command>MAKEDEV</command> script. This script is
|
||||
usually located in <filename>/dev/MAKEDEV</filename> but might also
|
||||
have a copy (or a symbolic link) in
|
||||
<filename>/sbin/MAKEDEV</filename>. If it turns out not to be in
|
||||
your path then you will need to specify the path to it
|
||||
explicitly.</para>
|
||||
|
||||
<para>In general the command is used as:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>/dev/MAKEDEV -v ttyS0</userinput>
|
||||
<computeroutput>create ttyS0 c 4 64 root:dialout 0660</computeroutput>
|
||||
</screen>
|
||||
|
||||
This will create the device file <filename>/dev/ttyS0</filename>
|
||||
<indexterm id="ch04-ttys0"><primary>filesystem</primary>
|
||||
<secondary>/dev</secondary><tertiary>/dev/ttyS0</tertiary></indexterm>
|
||||
with major node 4 and minor node 64 as a character device with
|
||||
access permissions 0660 with owner root and group dialout.</para>
|
||||
|
||||
<para><filename>ttyS0</filename> is a serial port. The major and
|
||||
minor node numbers are numbers understood by the kernel. The kernel
|
||||
refers to hardware devices as numbers, this would be very difficult
|
||||
for us to remember, so we use filenames. Access permissions of 0660
|
||||
means read and write permission for the owner (root in this case)
|
||||
and read and write permission for members of the group (dialout in
|
||||
this case) with no access for anyone else.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mknod">
|
||||
<title>The <command>mknod</command><indexterm id="ch04-mknod">
|
||||
<primary>commands</primary><secondary>mknod</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para><command>MAKEDEV</command><indexterm id="ch04-makedev2">
|
||||
<primary>commands</primary><secondary>MAKEDEV</secondary>
|
||||
</indexterm> is the preferred way of creating
|
||||
device files which are not present. However sometimes the
|
||||
<command>MAKEDEV</command> script will not know about the device
|
||||
file you wish to create. This is where the <command>mknod</command>
|
||||
command comes in. In order to use <command>mknod</command> you need
|
||||
to know the major and minor node numbers for the device you wish to
|
||||
create. The <filename>devices.txt</filename><indexterm id="kern-doc">
|
||||
<primary>kernel</primary><secondary>documentation</secondary>
|
||||
<tertiary>devices.txt</tertiary></indexterm> file in the kernel
|
||||
source documentation is the canonical source of this
|
||||
information.</para>
|
||||
|
||||
<para>To take an example, let us suppose that our version of the
|
||||
<command>MAKEDEV</command><indexterm id="ch04-makedev3">
|
||||
<primary>commands</primary><secondary>MAKEDEV</secondary>
|
||||
</indexterm> script does not know how to create the
|
||||
<filename>/dev/ttyS0</filename><indexterm id="ch04-ttys02">
|
||||
<primary>filesystem</primary><secondary>/dev</secondary>
|
||||
<tertiary>/dev/ttyS0</tertiary></indexterm> device file. We need
|
||||
to use <command>mknod</command><indexterm id="ch04-mknod2">
|
||||
<primary>commands</primary><secondary>mknod</secondary>
|
||||
</indexterm> to create it. We know from looking at the
|
||||
<filename>devices.txt</filename><indexterm id="kern-doc2">
|
||||
<primary>kernel</primary><secondary>documentation</secondary>
|
||||
<tertiary>devices.txt</tertiary></indexterm> that it should be a character
|
||||
device with major number 4 and minor number 64. So we now know all
|
||||
we need to create the file.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>mknod /dev/ttyS0 c 4 64</userinput>
|
||||
<prompt>#</prompt> <userinput>chown root.dialout /dev/ttyS0</userinput>
|
||||
<prompt>#</prompt> <userinput>chmod 0644 /dev/ttyS0</userinput>
|
||||
<prompt>#</prompt> <userinput>ls -l /dev/ttyS0</userinput>
|
||||
<computeroutput>
|
||||
crw-rw---- 1 root dialout 4, 64 Oct 23 18:23 /dev/ttyS0
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
As you can see, many more steps are required to create the file. In
|
||||
this example you can see the process required however. It is
|
||||
unlikely in the extreme that the ttyS0 file would not be provided by
|
||||
the <command>MAKEDEV</command><indexterm id="ch04-makedev4">
|
||||
<primary>commands</primary><secondary>MAKEDEV</secondary>
|
||||
</indexterm> script, but it suffices to illustrate
|
||||
the point.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="lspci">
|
||||
<title>The <command>lspci</command><indexterm id="ch04-lspci">
|
||||
<primary>commands</primary><secondary>lspci</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para>lspci</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="lsdev">
|
||||
<title>The <command>lsdev</command><indexterm id="ch04-lsdev">
|
||||
<primary>commands</primary><secondary>lsdev</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para>lsdev</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="lsusb">
|
||||
<title>The <command>lsusb</command><indexterm id="ch04-lsusb">
|
||||
<primary>commands</primary><secondary>lsusb</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para>lsusb</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="lsraid">
|
||||
<title>The <command>lsraid</command><indexterm id="ch04-lsraid">
|
||||
<primary>commands</primary><secondary>lsraid</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para>lsraid</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="hdparm">
|
||||
<title>The <command>hdparm</command><indexterm id="ch04-hdparm">
|
||||
<primary>commands</primary><secondary>hdparm</secondary>
|
||||
</indexterm> command</title>
|
||||
|
||||
<para>hdparm</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="more-hwresources">
|
||||
<title>More Hardware Resources</title>
|
||||
|
||||
<para>More information on what hardware resources the kernel is using
|
||||
can be found in the <filename>/proc</filename> directory. Refer to
|
||||
<xref linkend="proc-fs"> in chapter 3.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Kernel Modules<indexterm id="ch04-modules"><primary>kernel</primary>
|
||||
<secondary>modules</secondary></indexterm></title>
|
||||
|
||||
<para>This section will discuss kernel modules.</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
<sect2>
|
||||
<title>lsmod<indexterm id="ch04-lsmod1"><primary>commands</primary>
|
||||
<secondary>lsmod</secondary></indexterm><indexterm id="ch04-lsmod2">
|
||||
<primary>kernel</primary><secondary>modules</secondary>
|
||||
<tertiary>lsmod</tertiary></indexterm></title>
|
||||
|
||||
<para>lsmod</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>insmod<indexterm id="ch04-insmod1"><primary>commands</primary>
|
||||
<secondary>insmod</secondary></indexterm><indexterm id="ch04-insmod2">
|
||||
<primary>kernel</primary><secondary>modules</secondary>
|
||||
<tertiary>insmod</tertiary></indexterm></title>
|
||||
|
||||
<para>insmod</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>depmod<indexterm id="ch04-depmod1"><primary>commands</primary>
|
||||
<secondary>depmod</secondary></indexterm><indexterm id="ch04-depmod2">
|
||||
<primary>kernel</primary><secondary>modules</secondary>
|
||||
<tertiary>depmod</tertiary></indexterm></title>
|
||||
|
||||
<para>depmod</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>rmmod<indexterm id="ch04-rmmod1"><primary>commands</primary>
|
||||
<secondary>rmmod</secondary></indexterm><indexterm id="ch04-rmmod2">
|
||||
<primary>kernel</primary><secondary>modules</secondary>
|
||||
<tertiary>rmmod</tertiary></indexterm></title>
|
||||
|
||||
<para>rmmod</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>modprobe<indexterm id="ch04-modprobe1"><primary>commands</primary>
|
||||
<secondary>modprobe</secondary></indexterm><indexterm id="ch04-modprobe2">
|
||||
<primary>kernel</primary><secondary>modules</secondary>
|
||||
<tertiary>modprobe</tertiary></indexterm></title>
|
||||
|
||||
<para>modprobe</para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,436 @@
|
|||
<chapter id="memory-management">
|
||||
<title>Memory Management</title>
|
||||
|
||||
<blockquote><para><quote>Minnet, jag har tappat mitt minne,
|
||||
är jag svensk eller finne, kommer inte ihåg...</quote>
|
||||
(Bosse Österberg)
|
||||
</para>
|
||||
<para>A Swedish drinking song, (rough) translation: ``Memory, I
|
||||
have lost my memory. Am I Swedish or Finnish? I can't
|
||||
remember''</para>
|
||||
</blockquote>
|
||||
|
||||
<para> This section describes the Linux memory management
|
||||
features, i.e., virtual memory and the disk buffer cache.
|
||||
The purpose and workings and the things the system administrator
|
||||
needs to take into consideration are described.</para>
|
||||
|
||||
<sect1 id="vm-intro">
|
||||
<title>What is virtual memory?</title>
|
||||
|
||||
<para>Linux supports <glossterm>virtual memory</glossterm>, that
|
||||
is, using a disk as an extension of RAM so that the effective
|
||||
size of usable memory grows correspondingly. The kernel will
|
||||
write the contents of a currently unused block of memory to the
|
||||
hard disk so that the memory can be used for another purpose.
|
||||
When the original contents are needed again, they are read back
|
||||
into memory. This is all made completely transparent to the
|
||||
user; programs running under Linux only see the larger amount of
|
||||
memory available and don't notice that parts of them reside on
|
||||
the disk from time to time. Of course, reading and writing the
|
||||
hard disk is slower (on the order of a thousand times slower)
|
||||
than using real memory, so the programs don't run as fast.
|
||||
The part of the hard disk that is used as virtual memory is
|
||||
called the <glossterm>swap space</glossterm>.</para>
|
||||
|
||||
<para>Linux can use either a normal file in the filesystem or a
|
||||
separate partition for swap space. A swap partition is
|
||||
faster, but it is easier to change the size of a swap file
|
||||
(there's no need to repartition the whole hard disk, and
|
||||
possibly install everything from scratch). When you know how
|
||||
much swap space you need, you should go for a swap partition,
|
||||
but if you are uncertain, you can use a swap file first, use
|
||||
the system for a while so that you can get a feel for how much
|
||||
swap you need, and then make a swap partition when you're
|
||||
confident about its size.</para>
|
||||
|
||||
<para>You should also know that Linux allows one to use several swap
|
||||
partitions and/or swap files at the same time. This means
|
||||
that if you only occasionally need an unusual amount of swap space,
|
||||
you can set up an extra swap file at such times, instead of
|
||||
keeping the whole amount allocated all the time.</para>
|
||||
|
||||
<para>A note on operating system terminology: computer science
|
||||
usually distinguishes between swapping (writing the whole process
|
||||
out to swap space) and paging (writing only fixed size parts,
|
||||
usually a few kilobytes, at a time). Paging is usually more
|
||||
efficient, and that's what Linux does, but traditional Linux
|
||||
terminology talks about swapping anyway.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="swap-space">
|
||||
<title>Creating a swap space</title>
|
||||
|
||||
<para>A swap file is an ordinary file; it is in no way special
|
||||
to the kernel. The only thing that matters to the kernel is that it
|
||||
has no holes, and that it is prepared for use with
|
||||
<command>mkswap</command>. It must reside on a local disk, however;
|
||||
it can't reside in a filesystem that has been mounted
|
||||
over NFS due to implementation reasons.</para>
|
||||
|
||||
<para>The bit about holes is important. The swap file reserves
|
||||
the disk space so that the kernel can quickly swap out a page
|
||||
without having to go through all the things that are necessary
|
||||
when allocating a disk sector to a file. The kernel merely
|
||||
uses any sectors that have already been allocated to the file.
|
||||
Because a hole in a file means that there are no disk sectors
|
||||
allocated (for that place in the file), it is not good for the
|
||||
kernel to try to use them.</para>
|
||||
|
||||
<para>One good way to create the swap file without holes is through
|
||||
the following command:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>dd if=/dev/zero of=/extra-swap bs=1024
|
||||
count=1024</userinput>
|
||||
<computeroutput>1024+0 records in
|
||||
1024+0 records out</computeroutput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
where <filename>/extra-swap</filename> is the name of the swap
|
||||
file and the size of is given after the <literal>count=</literal>.
|
||||
It is best for the size to be a multiple of 4, because the
|
||||
kernel writes out <glossterm>memory pages</glossterm>, which
|
||||
are 4 kilobytes in size. If the size is not a multiple of 4,
|
||||
the last couple of kilobytes may be unused.</para>
|
||||
|
||||
<para>A swap partition is also not special in any way. You create
|
||||
it just like any other partition; the only difference is that
|
||||
it is used as a raw partition, that is, it will not contain any
|
||||
filesystem at all. It is a good idea to mark swap partitions
|
||||
as type 82 (Linux swap); this will the make partition listings
|
||||
clearer, even though it is not strictly necessary to the
|
||||
kernel.</para>
|
||||
|
||||
<para>After you have created a swap file or a swap partition, you
|
||||
need to write a signature to its beginning; this contains some
|
||||
administrative information and is used by the kernel. The
|
||||
command to do this is <command>mkswap</command>, used like this:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>mkswap /extra-swap 1024</userinput>
|
||||
<computeroutput>Setting up swapspace, size = 1044480
|
||||
bytes</computeroutput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
Note that the swap space is still not in use yet: it exists,
|
||||
but the kernel does not use it to provide virtual memory.</para>
|
||||
|
||||
<para>You should be very careful when using
|
||||
<command>mkswap</command>, since it does not check that the
|
||||
file or partition isn't used for anything else. <emphasis>You
|
||||
can easily overwrite important files and partitions with
|
||||
<command>mkswap</command>!</emphasis> Fortunately, you should
|
||||
only need to use <command>mkswap</command> when you install
|
||||
your system.</para>
|
||||
|
||||
<para>The Linux memory manager limits the size of each swap space to
|
||||
2 GB. You can, however, use up to
|
||||
8 swap spaces simultaneously, for a total of 16GB.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="using-swap">
|
||||
<title>Using a swap space</title>
|
||||
|
||||
<para>An initialized swap space is taken into use with
|
||||
<command>swapon</command>. This command tells the kernel that
|
||||
the swap space can be used. The path to the swap space is given
|
||||
as the argument, so to start swapping on a temporary swap file
|
||||
one might use the following command.
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>swapon /extra-swap</userinput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
Swap spaces can be used automatically by listing them in
|
||||
the <filename>/etc/fstab</filename> file.
|
||||
|
||||
<screen>
|
||||
/dev/hda8 none swap sw 0 0
|
||||
/swapfile none swap sw 0 0
|
||||
</screen>
|
||||
|
||||
The startup scripts will run the command <command>swapon
|
||||
-a</command>, which will start swapping on all the swap
|
||||
spaces listed in <command>/etc/fstab</command>. Therefore,
|
||||
the <command>swapon</command> command is usually used only when
|
||||
extra swap is needed.</para>
|
||||
|
||||
<para>You can monitor the use of swap spaces with
|
||||
<command>free</command>. It will tell the total amount of swap
|
||||
space used.
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>free</userinput>
|
||||
<computeroutput> total used free shared
|
||||
buffers
|
||||
Mem: 15152 14896 256 12404 2528
|
||||
-/+ buffers: 12368 2784
|
||||
Swap: 32452 6684 25768</computeroutput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
The first line of output (<literal>Mem:</literal>) shows the
|
||||
physical memory. The total column does not show the physical
|
||||
memory used by the kernel, which is usually about a megabyte.
|
||||
The used column shows the amount of memory used (the second
|
||||
line does not count buffers). The free column shows completely
|
||||
unused memory. The shared column shows the amount of memory
|
||||
shared by several processes; the more, the merrier. The buffers
|
||||
column shows the current size of the disk buffer cache.</para>
|
||||
|
||||
<para>That last line (<literal>Swap:</literal>) shows similar
|
||||
information for the swap spaces. If this line is all zeroes,
|
||||
your swap space is not activated.</para>
|
||||
|
||||
<para>The same information is available via
|
||||
<command>top</command>, or using the proc filesystem in file
|
||||
<filename>/proc/meminfo</filename>. It is currently difficult
|
||||
to get information on the use of a specific swap space.</para>
|
||||
|
||||
<para>A swap space can be removed from use with
|
||||
<command>swapoff</command>. It is usually not necessary to do it,
|
||||
except for temporary swap spaces. Any pages in use in the swap
|
||||
space are swapped in first; if there is not sufficient physical
|
||||
memory to hold them, they will then be swapped out (to some other
|
||||
swap space). If there is not enough virtual memory to hold all
|
||||
of the pages Linux will start to thrash; after a long while it
|
||||
should recover, but meanwhile the system is unusable. You should
|
||||
check (e.g., with <command>free</command>) that there is enough
|
||||
free memory before removing a swap space from use.</para>
|
||||
|
||||
<para>All the swap spaces that are used automatically
|
||||
with <command>swapon -a</command> can be removed from use
|
||||
with <command>swapoff -a</command>; it looks at the file
|
||||
<filename>/etc/fstab</filename> to find what to remove.
|
||||
Any manually used swap spaces will remain in use.</para>
|
||||
|
||||
<para>Sometimes a lot of swap space can be in use even though
|
||||
there is a lot of free physical memory. This can happen for
|
||||
instance if at one point there is need to swap, but later a big
|
||||
process that occupied much of the physical memory terminates
|
||||
and frees the memory. The swapped-out data is not automatically
|
||||
swapped in until it is needed, so the physical memory may remain
|
||||
free for a long time. There is no need to worry about this,
|
||||
but it can be comforting to know what is happening. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sharing-swap">
|
||||
<title>Sharing swap spaces with other operating systems</title>
|
||||
|
||||
<para>Virtual memory is built into many operating systems.
|
||||
Since they each need it only when they are running, i.e., never at
|
||||
the same time, the swap spaces of all but the currently running
|
||||
one are being wasted. It would be more efficient for them to
|
||||
share a single swap space. This is possible, but can require a
|
||||
bit of hacking. The Tips-HOWTO at
|
||||
<ulink url="http://www.tldp.org/HOWTO/Tips-HOWTO.html">
|
||||
http://www.tldp.org/HOWTO/Tips-HOWTO.html</ulink>, which contains
|
||||
some advice on how to
|
||||
implement this. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="swap-allocation">
|
||||
<title>Allocating swap space</title>
|
||||
|
||||
<para>Some people will tell you that you should allocate twice as
|
||||
much swap space as you have physical memory, but this is a bogus
|
||||
rule. Here's how to do it properly:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para> Estimate your total memory needs. This is the largest
|
||||
amount of memory you'll probably need at a time, that is the
|
||||
sum of the memory requirements of all the programs you want to
|
||||
run at the same time. This can be done by running at the same
|
||||
time all the programs you are likely to ever be running at the
|
||||
same time. </para>
|
||||
|
||||
<para>For instance, if you want to run X, you should allocate
|
||||
about 8 MB for it, gcc wants several megabytes (some
|
||||
files need an unusually large amount, up to tens of
|
||||
megabytes, but usually about four should do), and so on.
|
||||
The kernel will use about a megabyte by itself, and the
|
||||
usual shells and other small utilities perhaps a few
|
||||
hundred kilobytes (say a megabyte together). There is
|
||||
no need to try to be exact, rough estimates are fine,
|
||||
but you might want to be on the pessimistic side.</para>
|
||||
|
||||
<para>Remember that if there are going to be several people
|
||||
using the system at the same time, they are all going
|
||||
to consume memory. However, if two people run the same
|
||||
program at the same time, the total memory consumption
|
||||
is usually not double, since code pages and shared
|
||||
libraries exist only once.</para>
|
||||
|
||||
<para>The <command>free</command> and <command>ps</command>
|
||||
commands are useful for estimating the memory needs.
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Add some security to the estimate in step 1. This is because
|
||||
estimates of program sizes will probably be wrong, because
|
||||
you'll probably forget some programs you want to run, and to
|
||||
make certain that you have some extra space just in case. A
|
||||
couple of megabytes should be fine. (It is better to allocate
|
||||
too much than too little swap space, but there's no need to
|
||||
over-do it and allocate the whole disk, since unused swap space
|
||||
is wasted space; see later about adding more swap.) Also,
|
||||
since it is nicer to deal with even numbers, you can round the
|
||||
value up to the next full megabyte.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Based on the computations above, you know how much memory
|
||||
you'll be needing in total. So, in order to allocate swap
|
||||
space, you just need to subtract the size of your physical
|
||||
memory from the total memory needed, and you know how much
|
||||
swap space you need. (On some versions of UNIX, you need to
|
||||
allocate space for an image of the physical memory as well, so
|
||||
the amount computed in step 2 is what you need and you shouldn't
|
||||
do the subtraction.)</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>If your calculated swap space is very much larger than your
|
||||
physical memory (more than a couple times larger), you should
|
||||
probably invest in more physical memory, otherwise performance
|
||||
will be too low.</para>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>It's a good idea to have at least some swap space, even if
|
||||
your calculations indicate that you need none. Linux uses
|
||||
swap space somewhat aggressively, so that as much physical
|
||||
memory as possible can be kept free. Linux will swap out
|
||||
memory pages that have not been used, even if the memory
|
||||
is not yet needed for anything. This avoids waiting for
|
||||
swapping when it is needed: the swapping can be done
|
||||
earlier, when the disk is otherwise idle.</para>
|
||||
|
||||
<para>Swap space can be divided among several disks. This
|
||||
can sometimes improve performance, depending on the
|
||||
relative speeds of the disks and the access patterns
|
||||
of the disks. You might want to experiment with a few
|
||||
schemes, but be aware that doing the experiments
|
||||
properly is quite difficult. You should not believe
|
||||
claims that any one scheme is superior to any other,
|
||||
since it won't always be true.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="buffer-cache">
|
||||
<title>The buffer cache</title>
|
||||
|
||||
<para>Reading from a disk
|
||||
is very slow compared to accessing (real) memory. In addition,
|
||||
it is common to read the same part of a disk several times
|
||||
during relatively short periods of time. For example, one
|
||||
might first read an e-mail message, then read the letter into
|
||||
an editor when replying to it, then make the mail program read
|
||||
it again when copying it to a folder. Or, consider how often
|
||||
the command <command>ls</command> might be run on a system with
|
||||
many users. By reading the information from disk only once
|
||||
and then keeping it in memory until no longer needed, one can
|
||||
speed up all but the first read. This is called <glossterm>disk
|
||||
buffering</glossterm>, and the memory used for the purpose is
|
||||
called the <glossterm>buffer cache</glossterm>.</para>
|
||||
|
||||
<para>Since memory is, unfortunately, a finite, nay, scarce
|
||||
resource, the buffer cache usually cannot be big enough (it
|
||||
can't hold all the data one ever wants to use). When the cache
|
||||
fills up, the data that has been unused for the longest time
|
||||
is discarded and the memory thus freed is used for the new
|
||||
data.</para>
|
||||
|
||||
<para>Disk buffering works for writes as well. On the one hand,
|
||||
data that is written is often soon read again (e.g., a source
|
||||
code file is saved to a file, then read by the compiler),
|
||||
so putting data that is written in the cache is a good idea.
|
||||
On the other hand, by only putting the data into the cache, not
|
||||
writing it to disk at once, the program that writes runs quicker.
|
||||
The writes can then be done in the background, without slowing
|
||||
down the other programs.</para>
|
||||
|
||||
<para>Most operating systems have buffer caches (although
|
||||
they might be called something else), but not all of
|
||||
them work according to the above principles. Some are
|
||||
<glossterm>write-through</glossterm>: the data is written to disk
|
||||
at once (it is kept in the cache as well, of course). The cache
|
||||
is called <glossterm>write-back</glossterm> if the writes are done
|
||||
at a later time. Write-back is more efficient than write-through,
|
||||
but also a bit more prone to errors: if the machine crashes,
|
||||
or the power is cut at a bad moment, or the floppy is removed
|
||||
from the disk drive before the data in the cache waiting to be
|
||||
written gets written, the changes in the cache are usually lost.
|
||||
This might even mean that the filesystem (if there is one) is
|
||||
not in full working order, perhaps because the unwritten data
|
||||
held important changes to the bookkeeping information.</para>
|
||||
|
||||
<para>Because of this, you should never turn off the
|
||||
power without using a proper shutdown procedure
|
||||
or remove a floppy from the
|
||||
disk drive until it has been unmounted (if it was mounted)
|
||||
or after whatever program is using it has signaled that it
|
||||
is finished and the floppy drive light doesn't shine anymore.
|
||||
The <command>sync</command> command <glossterm>flushes</glossterm>
|
||||
the buffer, i.e., forces all unwritten data to be written to disk,
|
||||
and can be used when one wants to be sure that everything is
|
||||
safely written. In traditional UNIX systems, there is a program
|
||||
called <command>update</command> running in the background
|
||||
which does a <command>sync</command> every 30 seconds, so
|
||||
it is usually not necessary to use <command>sync</command>.
|
||||
Linux has an additional daemon, <command>bdflush</command>,
|
||||
which does a more imperfect sync more frequently to avoid the
|
||||
sudden freeze due to heavy disk I/O that <command>sync</command>
|
||||
sometimes causes.</para>
|
||||
|
||||
<para>Under Linux, <command>bdflush</command> is started by
|
||||
<command>update</command>. There is usually no reason to worry
|
||||
about it, but if <command>bdflush</command> happens to die for
|
||||
some reason, the kernel will warn about this, and you should
|
||||
start it by hand (<command>/sbin/update</command>).</para>
|
||||
|
||||
<para>The cache does not actually buffer files, but blocks, which
|
||||
are the smallest units of disk I/O (under Linux, they are usually
|
||||
1 KB). This way, also directories, super blocks, other filesystem
|
||||
bookkeeping data, and non-filesystem disks are cached.</para>
|
||||
|
||||
<para>The effectiveness of a cache is primarily decided by its
|
||||
size. A small cache is next to useless: it will hold so little
|
||||
data that all cached data is flushed from the cache before it
|
||||
is reused. The critical size depends on how much data is read
|
||||
and written, and how often the same data is accessed. The only
|
||||
way to know is to experiment.</para>
|
||||
|
||||
<para>If the cache is of a fixed size, it is not very good to have
|
||||
it too big, either, because that might make the free memory too
|
||||
small and cause swapping (which is also slow). To make the most
|
||||
efficient use of real memory, Linux automatically uses all free
|
||||
RAM for buffer cache, but also automatically makes the cache
|
||||
smaller when programs need more memory.</para>
|
||||
|
||||
<para>Under Linux, you do not need to do anything to make use
|
||||
of the cache, it happens completely automatically. Except for
|
||||
following the proper procedures for shutdown and removing
|
||||
floppies, you do not need to worry about it. </para>
|
||||
</sect1>
|
||||
</chapter>
|
|
@ -0,0 +1,505 @@
|
|||
<chapter id="system-monitoring">
|
||||
<title>System Monitoring</title>
|
||||
|
||||
<blockquote><para><quote>That's Hall Monitor to you!</quote>Spongebob
|
||||
Squarepants</para></blockquote>
|
||||
|
||||
<para>One of the most important responsibilities a system administrator
|
||||
has, is monitoring their systems. As a system administrator you'll need
|
||||
the ability to find out what is happening on your system at any given
|
||||
time. Whether it's the percentage of system's resources currently used,
|
||||
what commands are being run, or who is logged on. This chapter will cover
|
||||
how to monitor your system, and in some cases, how to resolve problems
|
||||
that may arise.</para>
|
||||
|
||||
<para>When a performance issue arises, there are 4 main areas to consider:
|
||||
CPU, Memory, Disk I/O, and Network. The ability to determine where the
|
||||
bottleneck is can save you a lot of time.</para>
|
||||
|
||||
<sect1 id="system-resources">
|
||||
<title>System Resources</title>
|
||||
<para>Being able to monitor the performance of your system
|
||||
is essential. If system resources become to low it can cause a lot of
|
||||
problems. System resources can be taken up by individual users, or by
|
||||
services your system may host such as email or web pages. The ability to
|
||||
know what is happening can help determine whether system upgrades are needed,
|
||||
or if some services need to be moved to another machine.</para>
|
||||
|
||||
<sect2 id="top">
|
||||
<title>The <command>top</command> command.</title>
|
||||
<para>The most common of these commands is <command>top</command>.
|
||||
The <command>top</command> will display a continually updating report
|
||||
of system resource usage.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>top</userinput>
|
||||
<computeroutput> 12:10:49 up 1 day, 3:47, 7 users, load average: 0.23, 0.19, 0.10
|
||||
125 processes: 105 sleeping, 2 running, 18 zombie, 0 stopped
|
||||
CPU states: 5.1% user 1.1% system 0.0% nice 0.0% iowait 93.6% idle
|
||||
Mem: 512716k av, 506176k used, 6540k free, 0k shrd, 21888k buff
|
||||
Swap: 1044216k av, 161672k used, 882544k free 199388k cached
|
||||
|
||||
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
|
||||
2330 root 15 0 161M 70M 2132 S 4.9 14.0 1000m 0 X
|
||||
2605 weeksa 15 0 8240 6340 3804 S 0.3 1.2 1:12 0 kdeinit
|
||||
3413 weeksa 15 0 6668 5324 3216 R 0.3 1.0 0:20 0 kdeinit
|
||||
18734 root 15 0 1192 1192 868 R 0.3 0.2 0:00 0 top
|
||||
1619 root 15 0 776 608 504 S 0.1 0.1 0:53 0 dhclient
|
||||
1 root 15 0 480 448 424 S 0.0 0.0 0:03 0 init
|
||||
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
|
||||
3 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kapmd
|
||||
4 root 35 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd_CPU0
|
||||
9 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 bdflush
|
||||
5 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kswapd
|
||||
10 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kupdated
|
||||
11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd
|
||||
15 root 15 0 0 0 0 SW 0.0 0.0 0:01 0 kjournald
|
||||
81 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 khubd
|
||||
1188 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
|
||||
1675 root 15 0 604 572 520 S 0.0 0.1 0:00 0 syslogd
|
||||
1679 root 15 0 428 376 372 S 0.0 0.0 0:00 0 klogd
|
||||
1707 rpc 15 0 516 440 436 S 0.0 0.0 0:00 0 portmap
|
||||
1776 root 25 0 476 428 424 S 0.0 0.0 0:00 0 apmd
|
||||
1813 root 25 0 752 528 524 S 0.0 0.1 0:00 0 sshd
|
||||
1828 root 25 0 704 548 544 S 0.0 0.1 0:00 0 xinetd
|
||||
1847 ntp 15 0 2396 2396 2160 S 0.0 0.4 0:00 0 ntpd
|
||||
1930 root 24 0 76 4 0 S 0.0 0.0 0:00 0 rpc.rquotad
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
|
||||
<para>The top portion of the report lists information such as
|
||||
the system time, uptime, CPU usage, physical ans swap memory usage,
|
||||
and number of processes. Below that is a list of the processes sorted
|
||||
by CPU utilization.</para>
|
||||
|
||||
<para>You can modify the output of <command>top</command> while
|
||||
is is running. If you hit an <option>i</option>, top will no longer
|
||||
display idle processes. Hit <option>i</option> again to see them
|
||||
again. Hitting <option>M</option> will sort by memory usage,
|
||||
<option>S</option> will sort by how long they processes have been
|
||||
running, and <option>P</option> will sort by CPU usage again.</para>
|
||||
|
||||
<para>In addition to viewing options, you can also modify processes
|
||||
from within the <command>top</command> command. You can use
|
||||
<option>u</option> to view processes owned by a specific user,
|
||||
<option>k</option> to kill processes, and <option>r</option> to
|
||||
renice them.</para>
|
||||
|
||||
<para>For more in-depth information about processes you can look in
|
||||
the <filename>/proc</filename> filesystem. In the <filename>/proc</filename>
|
||||
filesystem you will find a series of sub-directories with numeric names.
|
||||
These directories are associated with the processes ids of currently
|
||||
running processes. In each directory you will find a series of files
|
||||
containing information about the process.</para>
|
||||
|
||||
<para>YOU MUST TAKE EXTREME CAUTION TO NOT MODIFY THESE FILES, DOING
|
||||
SO MAY CAUSE SYSTEM PROBLEMS!</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iostat">
|
||||
<title>The <command>iostat</command> command.</title>
|
||||
<para>The <command>iostat</command> will display the current CPU load
|
||||
average and disk I/O information. This is a great command to monitor
|
||||
your disk I/O usage.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>iostat</userinput>
|
||||
<computeroutput>Linux 2.4.20-24.9 (myhost) 12/23/2003
|
||||
|
||||
avg-cpu: %user %nice %sys %idle
|
||||
62.09 0.32 2.97 34.62
|
||||
|
||||
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
|
||||
dev3-0 2.22 15.20 47.16 1546846 4799520
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
For 2.4 kernels the devices is names using the device's major
|
||||
and minor number. In this case the device listed is <filename>
|
||||
/dev/hda</filename>. To have <command>iostat</command> print this
|
||||
out for you, use the <option>-x</option>.
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>iostat -x</userinput>
|
||||
<computeroutput>Linux 2.4.20-24.9 (myhost) 12/23/2003
|
||||
|
||||
avg-cpu: %user %nice %sys %idle
|
||||
62.01 0.32 2.97 34.71
|
||||
|
||||
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
|
||||
/dev/hdc 0.00 0.00 .00 0.00 0.00 0.00 0.00 0.00 0.00 2.35 0.00 0.00 14.71
|
||||
/dev/hda 1.13 4.50 .81 1.39 15.18 47.14 7.59 23.57 28.24 1.99 63.76 70.48 15.56
|
||||
/dev/hda1 1.08 3.98 .73 1.27 14.49 42.05 7.25 21.02 28.22 0.44 21.82 4.97 1.00
|
||||
/dev/hda2 0.00 0.51 .07 0.12 0.55 5.07 0.27 2.54 30.35 0.97 52.67 61.73 2.99
|
||||
/dev/hda3 0.05 0.01 .02 0.00 0.14 0.02 0.07 0.01 8.51 0.00 12.55 2.95 0.01
|
||||
</computeroutput>
|
||||
</screen>
|
||||
<para>The <command>iostat</command> man page contains a detailed
|
||||
explanation of what each of these columns mean.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="ps">
|
||||
<title>The <command>ps</command> command</title>
|
||||
<para>The <command>ps</command> will provide you a list of
|
||||
processes currently running. There is a wide variety of options
|
||||
that this command gives you.</para>
|
||||
|
||||
<para>A common use would be to list all processes currently running.
|
||||
To do this you would use the <command>ps -ef</command> command.
|
||||
(Screen output from this command is too large to include, the following
|
||||
is only a partial output.)
|
||||
|
||||
<screen>
|
||||
UID PID PPID C STIME TTY TIME CMD
|
||||
root 1 0 0 Dec22 ? 00:00:03 init
|
||||
root 2 1 0 Dec22 ? 00:00:00 [keventd]
|
||||
root 3 1 0 Dec22 ? 00:00:00 [kapmd]
|
||||
root 4 1 0 Dec22 ? 00:00:00 [ksoftirqd_CPU0]
|
||||
root 9 1 0 Dec22 ? 00:00:00 [bdflush]
|
||||
root 5 1 0 Dec22 ? 00:00:00 [kswapd]
|
||||
root 6 1 0 Dec22 ? 00:00:00 [kscand/DMA]
|
||||
root 7 1 0 Dec22 ? 00:01:28 [kscand/Normal]
|
||||
root 8 1 0 Dec22 ? 00:00:00 [kscand/HighMem]
|
||||
root 10 1 0 Dec22 ? 00:00:00 [kupdated]
|
||||
root 11 1 0 Dec22 ? 00:00:00 [mdrecoveryd]
|
||||
root 15 1 0 Dec22 ? 00:00:01 [kjournald]
|
||||
root 81 1 0 Dec22 ? 00:00:00 [khubd]
|
||||
root 1188 1 0 Dec22 ? 00:00:00 [kjournald]
|
||||
root 1675 1 0 Dec22 ? 00:00:00 syslogd -m 0
|
||||
root 1679 1 0 Dec22 ? 00:00:00 klogd -x
|
||||
rpc 1707 1 0 Dec22 ? 00:00:00 portmap
|
||||
root 1813 1 0 Dec22 ? 00:00:00 /usr/sbin/sshd
|
||||
ntp 1847 1 0 Dec22 ? 00:00:00 ntpd -U ntp
|
||||
root 1930 1 0 Dec22 ? 00:00:00 rpc.rquotad
|
||||
root 1934 1 0 Dec22 ? 00:00:00 [nfsd]
|
||||
root 1942 1 0 Dec22 ? 00:00:00 [lockd]
|
||||
root 1943 1 0 Dec22 ? 00:00:00 [rpciod]
|
||||
root 1949 1 0 Dec22 ? 00:00:00 rpc.mountd
|
||||
root 1961 1 0 Dec22 ? 00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
|
||||
root 2057 1 0 Dec22 ? 00:00:00 /usr/bin/spamd -d -c -a
|
||||
root 2066 1 0 Dec22 ? 00:00:00 gpm -t ps/2 -m /dev/psaux
|
||||
bin 2076 1 0 Dec22 ? 00:00:00 /usr/sbin/cannaserver -syslog -u bin
|
||||
root 2087 1 0 Dec22 ? 00:00:00 crond
|
||||
daemon 2195 1 0 Dec22 ? 00:00:00 /usr/sbin/atd
|
||||
root 2215 1 0 Dec22 ? 00:00:11 /usr/sbin/rcd
|
||||
weeksa 3414 3413 0 Dec22 pts/1 00:00:00 /bin/bash
|
||||
weeksa 4342 3413 0 Dec22 pts/2 00:00:00 /bin/bash
|
||||
weeksa 19121 18668 0 12:58 pts/2 00:00:00 ps -ef
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>The first column shows who owns the process. The second
|
||||
column is the process ID. The Third column is the parent process
|
||||
ID. This is the process that generated, or started, the process.
|
||||
The forth column is the CPU usage (in
|
||||
percent). The fifth column is the start time, of date if the process
|
||||
has been running long enough. The sixth column is the tty associated
|
||||
with the process, if applicable. The seventh column is the cumulitive
|
||||
CPU usage (total amount of CPU time is has used while running). The
|
||||
eighth column is the command itself.</para>
|
||||
|
||||
<para>With this information you can see exacly what is running on
|
||||
your system and kill run-away processes, or those that are causing
|
||||
problems.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="vmstat">
|
||||
<title>The <command>vmstat</command> command</title>
|
||||
<para>The <command>vmstat</command> command will provide a report
|
||||
showing statistics for system processes, memory, swap,
|
||||
I/O, and the CPU. These statistics are generated using data from the
|
||||
last time the command was run to the present. In the case of the
|
||||
command never being run, the data will be from the last reboot until
|
||||
the present.<para>
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>vmstat</userinput>
|
||||
<computeroutput>
|
||||
procs memory swap io system cpu
|
||||
r b w swpd free buff cache si so bi bo in cs us sy id
|
||||
0 0 0 181604 17000 26296 201120 0 2 8 24 149 9 61 3 36
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
|
||||
<para>The following was taken from the
|
||||
<command>vmstat</command> man page.</para>
|
||||
|
||||
<blockquote><para><literallayout>
|
||||
FIELD DESCRIPTIONS
|
||||
Procs
|
||||
r: The number of processes waiting for run time.
|
||||
b: The number of processes in uninterruptable sleep.
|
||||
w: The number of processes swapped out but otherwise runnable. This
|
||||
field is calculated, but Linux never desperation swaps.
|
||||
|
||||
Memory
|
||||
swpd: the amount of virtual memory used (kB).
|
||||
free: the amount of idle memory (kB).
|
||||
buff: the amount of memory used as buffers (kB).
|
||||
|
||||
Swap
|
||||
si: Amount of memory swapped in from disk (kB/s).
|
||||
so: Amount of memory swapped to disk (kB/s).
|
||||
|
||||
IO
|
||||
bi: Blocks sent to a block device (blocks/s).
|
||||
bo: Blocks received from a block device (blocks/s).
|
||||
|
||||
System
|
||||
in: The number of interrupts per second, including the clock.
|
||||
cs: The number of context switches per second.
|
||||
|
||||
CPU
|
||||
These are percentages of total CPU time.
|
||||
us: user time
|
||||
sy: system time
|
||||
id: idle time</literallayout>
|
||||
</para></blockquote>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="lsof">
|
||||
<title>The <command>lsof</command> command</title>
|
||||
<para>The <command>lsof</command> command will print out a list of
|
||||
every file that is in use. Since Linux considers everythihng a file,
|
||||
this list can be very long. However, this command
|
||||
can be useful in diagnosing problems. An example of this is if you wish
|
||||
to unmount a filesystem, but you are being told that it is in use. You
|
||||
could use this command and <command>grep</command> for the name of the
|
||||
filesystem to see who is using it.</para>
|
||||
|
||||
<para>Or suppose you want to see all files in use by a particular process.
|
||||
To do this you would use <command>lsof -p -processid-</command>.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="more-utils">
|
||||
<title>Finding More Utilities</title>
|
||||
<para>To learn more about what command line tools are available, Chris
|
||||
Karakas has wrote a reference guide titled <ulink
|
||||
url="http://www.karakas-online.de/gnu-linux-tools-summary/"> GNU/Linux
|
||||
Command-Line Tools Summary</ulink>. It's a good resource for learning
|
||||
what tools are out there and how to do a number of tasks.</para>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="fs-usage">
|
||||
<title>Filesystem Usage</title>
|
||||
|
||||
<para>Many reports are currently talking about how cheap storage has
|
||||
gotten, but if you're like most of us it isn't cheap enough. Most of
|
||||
us have a limited amount of space, and need to be able to monitor it
|
||||
and control how it's used.</para>
|
||||
|
||||
|
||||
<sect2 id="df">
|
||||
<title>The df command</title>
|
||||
<para>The <command>df</command> is the simplest tool available to
|
||||
view disk usage. Simply type in <command>df</command> and you'll
|
||||
be shown disk usage for all your mounted filesystems in 1K blocks
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> <prompt><userinput>df</userinput>
|
||||
<computeroutput>
|
||||
Filesystem 1K-blocks Used Available Use% Mounted on
|
||||
/dev/hda3 5242904 759692 4483212 15% /
|
||||
tmpfs 127876 8 127868 1% /dev/shm
|
||||
/dev/hda1 127351 33047 87729 28% /boot
|
||||
/dev/hda9 10485816 33508 10452308 1% /home
|
||||
/dev/hda8 5242904 932468 4310436 18% /srv
|
||||
/dev/hda7 3145816 32964 3112852 2% /tmp
|
||||
/dev/hda5 5160416 474336 4423928 10% /usr
|
||||
/dev/hda6 3145816 412132 2733684 14% /var
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
|
||||
<para>You can also use the <command>-h</command> to see the output in
|
||||
"human-readable" format. This will be in K, Megs, or Gigs depending
|
||||
on the size of the filesystem. Alternately, you can also use the
|
||||
<command>-B</command> to specify block size.</para>
|
||||
|
||||
<para>In addition to space usage, you could use the
|
||||
<command>-i</command> option to view the number of used and available
|
||||
inodes.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>df -i</userinput>
|
||||
<computeroutput>
|
||||
Filesystem Inodes IUsed IFree IUse% Mounted on
|
||||
/dev/hda3 0 0 0 - /
|
||||
tmpfs 31969 5 31964 1% /dev/shm
|
||||
/dev/hda1 32912 47 32865 1% /boot
|
||||
/dev/hda9 0 0 0 - /home
|
||||
/dev/hda8 0 0 0 - /srv
|
||||
/dev/hda7 0 0 0 - /tmp
|
||||
/dev/hda5 656640 26651 629989 5% /usr
|
||||
/dev/hda6 0 0 0 - /var
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="du">
|
||||
<title>The du command</title>
|
||||
<para>Now that you know how much space has been used on a filesystem
|
||||
how can you find out where that data is? To view usage by a directory
|
||||
or file you can use <command>du</command>. Unless you specify a
|
||||
filename <command>du</command> will act recursively. For example:
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>du file.txt</userinput>
|
||||
<computeroutput>
|
||||
1300 file.txt
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
Or like the <command>df</command> I can use the <command>-h</command>
|
||||
and get the same output in "human-readable" form.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>du -h file.txt</userinput>
|
||||
<computeroutput>
|
||||
1.3M file.txt
|
||||
</computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>Unless you specify a filename <command>du</command> will act
|
||||
recursively.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>du -h /usr/local</userinput>
|
||||
<computeroutput>
|
||||
4.0K /usr/local/games
|
||||
16K /usr/local/include/nessus/net
|
||||
180K /usr/local/include/nessus
|
||||
208K /usr/local/include
|
||||
62M /usr/local/lib/nessus/plugins/.desc
|
||||
97M /usr/local/lib/nessus/plugins
|
||||
164K /usr/local/lib/nessus/plugins_factory
|
||||
97M /usr/local/lib/nessus
|
||||
12K /usr/local/lib/pkgconfig
|
||||
2.7M /usr/local/lib/ladspa
|
||||
104M /usr/local/lib
|
||||
112K /usr/local/man/man1
|
||||
4.0K /usr/local/man/man2
|
||||
4.0K /usr/local/man/man3
|
||||
4.0K /usr/local/man/man4
|
||||
16K /usr/local/man/man5
|
||||
4.0K /usr/local/man/man
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
|
||||
<para>If you just want a summary of that directory you can use the
|
||||
<command>-s</command> option.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>du -hs /usr/local</userinput>
|
||||
<computeroutput>
|
||||
210M /usr/local
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="quotas">
|
||||
<title>Quotas</title>
|
||||
<para>For more information about quotas you can read
|
||||
<ulink url="http://www.tldp.org/HOWTO/Quota.html">The Quota HOWTO
|
||||
</ulink>.
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="monitoring-users">
|
||||
<title>Monitoring Users</title>
|
||||
|
||||
<blockquote><para>Just because you're paranoid doesn't mean they
|
||||
AREN'T out to get you... Source Unknown</para></blockquote>
|
||||
|
||||
<para>From time to time there are going to be occasions where you will
|
||||
want to know exactly what people are doing on your system. Maybe you
|
||||
notice that a lot of RAM is being used, or a lot of CPU activity.
|
||||
You are going to want to see who is on the system, what they are
|
||||
running, and what kind of resources they are using.</para>
|
||||
|
||||
<sect2 id="who">
|
||||
<title>The who command</title>
|
||||
<para>The easiest way to see who is on the system is to do a
|
||||
<command>who</command> or <command>w</command>. The -->
|
||||
<command>who</command> is a simple tool that lists out who is logged -->
|
||||
on the system and what port or terminal they are logged on at.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~></prompt> <userinput> who</userinput>
|
||||
<computeroutput>
|
||||
bjones pts/0 May 23 09:33
|
||||
wally pts/3 May 20 11:35
|
||||
aweeks pts/1 May 22 11:03
|
||||
aweeks pts/2 May 23 15:04
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="ps-u">
|
||||
<title>The ps command -again!</title>
|
||||
|
||||
<para>In the previous section we can see that user aweeks is logged
|
||||
onto both <filename>pts/1</filename> and <filename>pts/2</filename>,
|
||||
but what if we want to see what they are doing? We could to a
|
||||
<command>ps -u aweeks</command> and get the following output
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>ps -u aweeks</userinput>
|
||||
<computeroutput>
|
||||
20876 pts/1 00:00:00 bash
|
||||
20904 pts/2 00:00:00 bash
|
||||
20951 pts/2 00:00:00 ssh
|
||||
21012 pts/1 00:00:00 ps
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
From this we can see that the user is doing a <command>ps</command>
|
||||
<command>ssh</command>.</para>
|
||||
|
||||
<para>This is a much more consolidated use of the
|
||||
<command>ps</command> than discussed previously.<para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="w">
|
||||
<title>The w command</title>
|
||||
|
||||
<para>Even easier than using the <command>who</command> and
|
||||
<command>ps -u</command> commands is to use the <command>w</command>.
|
||||
<command>w</command> will print out not only who is on the system,
|
||||
but also the commands they are running.
|
||||
|
||||
<screen>
|
||||
<prompt>user@server:~> </prompt><userinput>w</userinput>
|
||||
<computeroutput>
|
||||
aweeks :0 09:32 ?xdm? 30:09 0.02s -:0
|
||||
aweeks pts/0 09:33 5:49m 0.00s 0.82s kdeinit: kded
|
||||
aweeks pts/2 09:35 8.00s 0.55s 0.36s vi sag-0.9.sgml
|
||||
aweeks pts/1 15:03 59.00s 0.03s 0.03s /bin/bash
|
||||
</computeroutput>
|
||||
</screen></para>
|
||||
|
||||
<para>From this we can see that I have a <command>kde</command> session
|
||||
running, I'm working in this document :-), and have another terminal
|
||||
open sitting idle at a bash prompt.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="skill">
|
||||
<title>The skill command</title>
|
||||
|
||||
<para> To Be Added</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="nice">
|
||||
<title>nice and renice</title>
|
||||
|
||||
<para>To Be Added</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
|
@ -0,0 +1,421 @@
|
|||
<chapter id="boots-and-shutdowns">
|
||||
<title>Boots And Shutdowns</title>
|
||||
|
||||
<blockquote><para><literallayout>
|
||||
Start me up
|
||||
Ah... you've got to... you've got to
|
||||
Never, never never stop
|
||||
Start it up
|
||||
Ah... start it up, never, never, never
|
||||
You make a grown man cry,
|
||||
you make a grown man cry
|
||||
(Rolling Stones)
|
||||
</literallayout></para></blockquote>
|
||||
|
||||
<para> This section explains what goes on when a Linux system is
|
||||
brought up and taken down, and how it should be done properly.
|
||||
If proper procedures are not followed, files might be corrupted
|
||||
or lost.</para>
|
||||
|
||||
<sect1 id="boot-overview">
|
||||
<title>An overview of boots and shutdowns</title>
|
||||
|
||||
<para>The act of turning on a computer system and causing its
|
||||
operating system to be loaded
|
||||
is called <glossterm>booting</glossterm>. The name comes from
|
||||
an image of the computer pulling itself up from its bootstraps,
|
||||
but the act itself slightly more realistic.</para>
|
||||
|
||||
<para>During bootstrapping, the computer first loads a small piece
|
||||
of code called the <glossterm>bootstrap loader</glossterm>, which
|
||||
in turn loads and starts the operating system. The bootstrap
|
||||
loader is usually stored in a fixed location on a hard disk
|
||||
or a floppy. The reason for this two step process is that
|
||||
the operating system is big and complicated, but the first
|
||||
piece of code that the computer loads must be very small (a
|
||||
few hundred bytes), to avoid making the firmware unnecessarily
|
||||
complicated.</para>
|
||||
|
||||
<para>Different computers do the bootstrapping differently.
|
||||
For PCs, the computer (its BIOS) reads in the first sector
|
||||
(called the <glossterm>boot sector</glossterm>) of a floppy or
|
||||
hard disk. The bootstrap loader is contained within this sector.
|
||||
It loads the operating system from elsewhere on the disk (or
|
||||
from some other place).</para>
|
||||
|
||||
<para>After Linux has been loaded, it initializes the hardware and
|
||||
device drivers, and then runs <command>init</command>.
|
||||
<command>init</command>
|
||||
starts other processes to allow users to log in, and do things.
|
||||
The details of this part will be discussed below.</para>
|
||||
|
||||
<para>In order to shut down a Linux system, first all processes
|
||||
are told to terminate (this makes them close any files and
|
||||
do other necessary things to keep things tidy), then filesystems
|
||||
and swap areas are unmounted, and finally a message is printed
|
||||
to the console that the power can be turned off. If the proper
|
||||
procedure is not followed, terrible things can and will happen;
|
||||
most importantly, the filesystem buffer cache might not be flushed,
|
||||
which means that all data in it is lost and the filesystem on
|
||||
disk is inconsistent, and therefore possibly unusable.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="boot-process">
|
||||
<title>The boot process in closer look</title>
|
||||
|
||||
<para>When a PC is booted, the BIOS will do various tests to
|
||||
check that everything looks all right, and will then start the actual
|
||||
booting. This process is called the <glossterm>power on self test
|
||||
</glossterm>, or POST for short. It will choose a disk
|
||||
drive (typically the first floppy drive, if there is a floppy
|
||||
inserted, otherwise the first hard disk, if one is installed
|
||||
in the computer; the order might be configurable, however)
|
||||
and will then read its very first sector. This is called the
|
||||
<glossterm>boot sector</glossterm>; for a hard disk, it is also
|
||||
called the <glossterm>master boot record</glossterm>, since a
|
||||
hard disk can contain several partitions, each with their own
|
||||
boot sectors.</para>
|
||||
|
||||
<para>The boot sector contains a small program (small enough to
|
||||
fit into one sector) whose responsibility is to read the actual
|
||||
operating system from the disk and start it. When booting Linux
|
||||
from a floppy disk, the boot sector contains code that just reads
|
||||
the first few hundred blocks (depending on the actual kernel
|
||||
size, of course) to a predetermined place in memory. On a Linux
|
||||
boot floppy, there is no filesystem, the kernel is just stored
|
||||
in consecutive sectors, since this simplifies the boot process.
|
||||
It is possible, however, to boot from a floppy with a filesystem,
|
||||
by using LILO, the LInux LOader, or GRUB, the GRand Unifying
|
||||
Bootloader.</para>
|
||||
|
||||
<para>When booting from the hard disk, the code in the master
|
||||
boot record will examine the partition table (also in the master
|
||||
boot record), identify the active partition (the partition that is
|
||||
marked to be bootable), read the boot sector from that partition,
|
||||
and then start the code in that boot sector. The code in the
|
||||
partition's boot sector does what a floppy disk's boot sector
|
||||
does: it will read in the kernel from the partition and start it.
|
||||
The details vary, however, since it is generally not useful to
|
||||
have a separate partition for just the kernel image, so the
|
||||
code in the partition's boot sector can't just read the disk
|
||||
in sequential order, it has to find the sectors wherever the
|
||||
filesystem has put them. There are several ways around this
|
||||
problem, but the most common way is to use a boot loader like
|
||||
LILO or GRUB. (The details
|
||||
about how to do this are irrelevant for this discussion, however;
|
||||
see the LILO or GRUB documentation for more information; it is most
|
||||
thorough.)</para>
|
||||
|
||||
<para>When booting, the bootloader will normally go right ahead
|
||||
and read in and boot the default kernel. It is also possible
|
||||
to configure the boot loader to be able to boot one of several kernels,
|
||||
or even other operating systems than Linux, and it is possible
|
||||
for the user to choose which kernel or operating system is to
|
||||
be booted at boot time. LILO, for example, can be configured so that if one
|
||||
holds down the <keycap>alt</keycap>, <keycap>shift</keycap>, or
|
||||
<keycap>ctrl</keycap> key at boot time (when LILO is loaded),
|
||||
LILO will ask what is to be booted and not boot the default
|
||||
right away. Alternatively, the bootloader can be configured so that it
|
||||
will always ask, with an optional timeout that will cause the
|
||||
default kernel to be booted.</para>
|
||||
|
||||
<para>It is also possible to give a <glossterm>kernel
|
||||
command line argument</glossterm>, after the name of the kernel
|
||||
or operating system. For a list of possible options you can read
|
||||
<ulink url="http://www.tldp.org/HOWTO/BootPrompt-HOWTO.html">
|
||||
http://www.tldp.org/HOWTO/BootPrompt-HOWTO.html</ulink>.</para>
|
||||
|
||||
<para>Booting from floppy and from hard disk have both their
|
||||
advantages, but generally booting from the hard disk is nicer,
|
||||
since it avoids the hassle of playing around with floppies.
|
||||
It is also faster. Most Linux distributions will setup the bootloader
|
||||
for you during the install process.</para>
|
||||
|
||||
<para>After the Linux kernel has been read into the memory, by
|
||||
whatever means, and is started for real, roughly the following
|
||||
things happen:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>
|
||||
The Linux kernel is installed compressed, so it will first
|
||||
uncompress itself. The beginning of the kernel image
|
||||
contains a small program that does this.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
If you have a super-VGA card that Linux
|
||||
recognizes and that has some special text modes (such as 100
|
||||
columns by 40 rows), Linux asks you which mode
|
||||
you want to use. During the kernel compilation, it is
|
||||
possible to preset a video mode, so that this is never asked.
|
||||
This can also be done with LILO, GRUB or <command>rdev</command>.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
After this, the kernel checks what other hardware there is
|
||||
(hard disks, floppies, network adapters, etc), and configures
|
||||
some of its device drivers appropriately; while it does this,
|
||||
it outputs messages about its findings. For example, when I
|
||||
boot, I it looks like this:
|
||||
|
||||
<screen>
|
||||
<computeroutput>
|
||||
LILO boot:
|
||||
Loading linux.
|
||||
Console: colour EGA+ 80x25, 8 virtual consoles
|
||||
Serial driver version 3.94 with no serial options enabled
|
||||
tty00 at 0x03f8 (irq = 4) is a 16450
|
||||
tty01 at 0x02f8 (irq = 3) is a 16450
|
||||
lp_init: lp1 exists (0), using polling driver
|
||||
Memory: 7332k/8192k available (300k kernel code, 384k reserved, 176k
|
||||
data)
|
||||
Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M
|
||||
Loopback device init
|
||||
Warning WD8013 board not found at i/o = 280.
|
||||
Math coprocessor using irq13 error reporting.
|
||||
Partition check:
|
||||
hda: hda1 hda2 hda3
|
||||
VFS: Mounted root (ext filesystem).
|
||||
Linux version 0.99.pl9-1 (root@haven) 05/01/93 14:12:20
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
The exact texts are different on different systems, depending
|
||||
on the hardware, the version of Linux being used, and how
|
||||
it has been configured.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> Then the kernel will try to mount the root
|
||||
filesystem. The place is configurable at compilation time, or
|
||||
any time with <command>rdev</command> or the bootloader. The filesystem
|
||||
type is detected automatically. If the mounting of the root
|
||||
filesystem fails, for example because you didn't remember to
|
||||
include the corresponding filesystem driver in the kernel, the
|
||||
kernel panics and halts the system (there isn't much it can do,
|
||||
anyway). </para>
|
||||
|
||||
<para>The root filesystem is usually mounted read-only (this can
|
||||
be set in the same way as the place). This makes it possible
|
||||
to check the filesystem while it is mounted; it is not a good
|
||||
idea to check a filesystem that is mounted read-write.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> After this, the kernel starts
|
||||
the program <command>init</command> (located in
|
||||
<filename>/sbin/init</filename>) in the background (this will
|
||||
always become process number 1). <command>init</command> does
|
||||
various startup chores. The exact things it does depends on how
|
||||
it is configured; see <xref linkend="init"> for more information
|
||||
(not yet written). It will at least start some essential
|
||||
background daemons. </para></listitem>
|
||||
|
||||
<listitem><para> <command>init</command> then switches to
|
||||
multi-user mode, and starts a <command>getty</command> for virtual
|
||||
consoles and serial lines. <command>getty</command> is the
|
||||
program which lets people log in via virtual consoles and serial
|
||||
terminals. <command>init</command> may also start some other
|
||||
programs, depending on how it is configured. </para></listitem>
|
||||
|
||||
<listitem><para> After this, the boot is complete, and the system
|
||||
is up and running normally. </para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<sect2 id="bootloaders">
|
||||
<title>A Word About Bootloaders</title>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
<para>This section will give an overview of the difference between
|
||||
GRUB and LILO.</para>
|
||||
|
||||
<para>For more information on LILO, you can read
|
||||
<ulink url="http://www.tldp.org/HOWTO/LILO.html">
|
||||
http://www.tldp.org/HOWTO/LILO.html</ulink></para>
|
||||
|
||||
<para>For more information on GRUB, you can visit
|
||||
<ulink url="http://www.gnu.org/software/grub/grub.html">
|
||||
http://www.gnu.org/software/grub/grub.html</ulink></para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="shutdown">
|
||||
<title>More about shutdowns</title>
|
||||
|
||||
<para>It is important to follow the correct procedures when you shut
|
||||
down a Linux system. If you fail do so, your filesystems probably
|
||||
will become trashed and the files probably will become scrambled.
|
||||
This is because Linux has a disk cache that won't write things
|
||||
to disk at once, but only at intervals. This greatly improves
|
||||
performance but also means that if you just turn off the power
|
||||
at a whim the cache may hold a lot of data and that what is on
|
||||
the disk may not be a fully working filesystem (because only
|
||||
some things have been written to the disk).</para>
|
||||
|
||||
<para>Another reason against just flipping the power switch is that
|
||||
in a multi-tasking system there can be lots of things going on
|
||||
in the background, and shutting the power can be quite
|
||||
disastrous. By using the proper shutdown sequence, you ensure
|
||||
that all background processes can save their data.</para>
|
||||
|
||||
<para>The command for properly shutting down a Linux system
|
||||
is <command>shutdown</command>. It is usually used in one of
|
||||
two ways.</para>
|
||||
|
||||
<para>If you are running a system where you are the only user,
|
||||
the usual way of using <command>shutdown</command> is to quit
|
||||
all running programs, log out on all virtual consoles, log
|
||||
in as root on one of them (or stay logged in as root if you
|
||||
already are, but you should change to root's home directory or
|
||||
the root directory, to avoid problems with unmounting), then
|
||||
give the command <command>shutdown -h now</command> (substitute
|
||||
<literal>now</literal> with a plus sign and a number in minutes
|
||||
if you want a delay, though you usually don't on a single user
|
||||
system).</para>
|
||||
|
||||
<para>Alternatively, if your system has many users, use the command
|
||||
<command>shutdown -h +time message</command>, where
|
||||
<literal>time</literal>
|
||||
is the
|
||||
time in minutes until the system is halted, and
|
||||
<literal>message</literal>
|
||||
is a short explanation of why the system is shutting down.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>shutdown -h +10 'We will install a new
|
||||
disk. System should
|
||||
> be back on-line in three hours.'</userinput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
This will warn everybody that the system will shut down in
|
||||
ten minutes, and that they'd better get lost or lose data.
|
||||
The warning is printed to every terminal on which someone is
|
||||
logged in, including all <command>xterm</command>s:
|
||||
|
||||
<screen>
|
||||
<computeroutput>
|
||||
Broadcast message from root (ttyp0) Wed Aug 2 01:03:25 1995...
|
||||
|
||||
We will install a new disk. System should
|
||||
be back on-line in three hours.
|
||||
The system is going DOWN for system halt in 10 minutes !!
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
The warning is automatically repeated a few times before the boot,
|
||||
with shorter and shorter intervals as the time runs out.</para>
|
||||
|
||||
<para>When the real shutting down starts after any delays, all
|
||||
filesystems (except the root one) are unmounted, user processes
|
||||
(if anybody is still logged in) are killed, daemons are shut down,
|
||||
all filesystem are unmounted, and generally everything settles
|
||||
down. When that is done, <command>init</command> prints out a
|
||||
message that you can power down the machine. Then, and only then,
|
||||
should you move your fingers towards the power switch.</para>
|
||||
|
||||
<para>Sometimes, although rarely on any good system, it is
|
||||
impossible to shut down properly. For instance, if the kernel
|
||||
panics and crashes and burns and generally misbehaves, it might
|
||||
be completely impossible to give any new commands, hence shutting
|
||||
down properly is somewhat difficult, and just about everything
|
||||
you can do is hope that nothing has been too severely damaged
|
||||
and turn off the power. If the troubles are a bit less severe
|
||||
(say, somebody hit your keyboard with an axe), and the kernel
|
||||
and the <command>update</command> program still run normally,
|
||||
it is probably a good idea to wait a couple of minutes to give
|
||||
<command>update</command> a chance to flush the buffer cache,
|
||||
and only cut the power after that.</para>
|
||||
|
||||
<para>In the old days, some people like to shut down using the command
|
||||
<command>sync</command> three times, waiting for the disk I/O to stop,
|
||||
then turn off the power. If there are no running programs, this is
|
||||
equivalent to using <command>shutdown</command>. However, it
|
||||
does not unmount any filesystems and this can lead to problems
|
||||
with the ext2fs ``clean filesystem'' flag. The triple-sync
|
||||
method is <emphasis>not recommended</emphasis>.</para>
|
||||
|
||||
<para>(In case you're wondering: the reason for three syncs is
|
||||
that in the early days of UNIX, when the commands were
|
||||
typed separately, that usually gave sufficient time for most
|
||||
disk I/O to be finished.)
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="rebooting">
|
||||
<title>Rebooting</title>
|
||||
|
||||
<para>Rebooting means booting the system again. This can be
|
||||
accomplished by first shutting it down completely, turning
|
||||
power off, and then turning it back on. A simpler way is to
|
||||
ask <command>shutdown</command> to reboot the system, instead
|
||||
of merely halting it. This is accomplished by using the
|
||||
<option>-r</option> option to <command>shutdown</command>,
|
||||
for example, by giving the command <command>shutdown -r
|
||||
now</command>.</para>
|
||||
|
||||
<para>Most Linux systems run <command>shutdown -r now</command>
|
||||
when ctrl-alt-del is pressed on the keyboard. This reboots the
|
||||
system. The action on ctrl-alt-del is configurable, however, and
|
||||
it might be better to allow for some delay before the reboot on
|
||||
a multiuser machine. Systems that are physically accessible to
|
||||
anyone might even be configured to do nothing when ctrl-alt-del
|
||||
is pressed. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="single-user">
|
||||
<title>Single user mode</title>
|
||||
|
||||
<para>The <command>shutdown</command> command can also be used
|
||||
to bring the system down to single user mode, in which no one
|
||||
can log in, but root can use the console. This is useful for
|
||||
system administration tasks that can't be done while the system is
|
||||
running normally.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="emerg-boot-floppy">
|
||||
<title>Emergency boot floppies</title>
|
||||
|
||||
<para>It is not always possible to boot a computer from the hard
|
||||
disk.
|
||||
For example, if you make a mistake in configuring LILO, you might
|
||||
make your system unbootable. For these situations, you need an
|
||||
alternative way of booting that will always work (as long as the
|
||||
hardware works). For typical PCs, this means booting from the
|
||||
floppy drive.</para>
|
||||
|
||||
<para>Most Linux distributions allow one to create an
|
||||
<glossterm>emergency boot floppy</glossterm> during installation.
|
||||
It is a good idea to do this. However, some such boot disks
|
||||
contain only the kernel, and assume you will be using the programs
|
||||
on the distribution's installation disks to fix whatever problem
|
||||
you have. Sometimes those programs aren't enough; for example,
|
||||
you might have to restore some files from backups made with
|
||||
software not on the installation disks.</para>
|
||||
|
||||
<para>Thus, it might be necessary to create a custom root floppy
|
||||
as well. The Bootdisk HOWTO by Graham Chapman contains instructions
|
||||
for doing this. You can find this HOWTO at
|
||||
<ulink url="http://www.tldp.org/HOWTO/Bootdisk-HOWTO/index.html">
|
||||
http://www.tldp.org/HOWTO/Bootdisk-HOWTO/index.html</ulink>.
|
||||
You must, of course, remember to keep your emergency boot and
|
||||
root floppies up to date.</para>
|
||||
|
||||
<para>You can't use the floppy drive you use to mount the root
|
||||
floppy for anything else. This can be inconvenient if you only
|
||||
have one floppy drive. However, if you have enough memory, you
|
||||
can configure your boot floppy to load the root disk to a ramdisk
|
||||
(the boot floppy's kernel needs to be specially configured for
|
||||
this). Once the root floppy has been loaded into the ramdisk,
|
||||
the floppy drive is free to mount other disks. </para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,391 @@
|
|||
<chapter id="init-intro">
|
||||
<title><command>init</command></title>
|
||||
|
||||
<blockquote><para><quote>Uuno on numero yksi</quote>
|
||||
(Slogan for a series of Finnish movies.)</para></blockquote>
|
||||
|
||||
<para>This chapter describes the <command>init</command> process,
|
||||
which is the first user level process started by the kernel.
|
||||
<command>init</command> has many important duties, such as
|
||||
starting <command>getty</command> (so that users can log in),
|
||||
implementing run levels, and taking care of orphaned processes.
|
||||
This chapter explains how <command>init</command> is configured
|
||||
and how you can make use of the different run levels.</para>
|
||||
|
||||
<sect1 id="init-process">
|
||||
<title><command>init</command> comes first</title>
|
||||
|
||||
<para><command>init</command> is one of those programs that
|
||||
are absolutely essential to the operation of a Linux system,
|
||||
but that you still can mostly ignore. A good Linux distribution
|
||||
will come with a configuration for <command>init</command>
|
||||
that will work for most systems, and on these systems there is
|
||||
nothing you need to do about <command>init</command>. Usually,
|
||||
you only need to worry about <command>init</command> if you hook
|
||||
up serial terminals, dial-in (not dial-out) modems, or if you
|
||||
want to change the default run level.</para>
|
||||
|
||||
<para>When the kernel has started itself (has been loaded
|
||||
into memory, has started running, and has initialized all
|
||||
device drivers and data structures and such), it finishes its
|
||||
own part of the boot process by starting a user level program,
|
||||
<command>init</command>. Thus, <command>init</command> is always
|
||||
the first process (its process number is always 1).</para>
|
||||
|
||||
<para>The kernel looks for <command>init</command>
|
||||
in a few locations that have been historically used
|
||||
for it, but the proper location for it (on a Linux
|
||||
system) is <filename>/sbin/init</filename>. If the
|
||||
kernel can't find <command>init</command>, it tries to run
|
||||
<filename>/bin/sh</filename>, and if that also fails, the startup
|
||||
of the system fails.</para>
|
||||
|
||||
<para>When <command>init</command> starts, it finishes the
|
||||
boot process by doing a number of administrative tasks, such
|
||||
as checking filesystems, cleaning up <filename>/tmp</filename>,
|
||||
starting various services, and starting a <command>getty</command>
|
||||
for each terminal and virtual console where users should be able
|
||||
to log in (see <xref linkend="log-in-and-out">).</para>
|
||||
|
||||
<para>After the system is properly up, <command>init</command>
|
||||
restarts <command>getty</command> for each terminal
|
||||
after a user has logged out (so that the next user can log
|
||||
in). <command>init</command> also adopts orphan processes: when
|
||||
a process starts a child process and dies before its child, the
|
||||
child immediately becomes a child of <command>init</command>.
|
||||
This is important for various technical reasons, but it is good
|
||||
to know it, since it makes it easier to understand process lists
|
||||
and process tree graphs.
|
||||
There are a few variants of <command>init</command>
|
||||
available. Most Linux distributions
|
||||
use <command>sysvinit</command> (written by Miquel
|
||||
van Smoorenburg), which is based on the System V
|
||||
<command>init</command> design. The BSD versions of Unix have
|
||||
a different <command>init</command>. The primary difference
|
||||
is run levels: System V has them, BSD does not (at least
|
||||
traditionally). This difference is not essential. We'll look
|
||||
at <command>sysvinit</command> only. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="config-init">
|
||||
<title>Configuring <command>init</command> to start
|
||||
<command>getty</command>: the
|
||||
<filename>/etc/inittab</filename> file</title>
|
||||
|
||||
<para>When it starts up, <command>init</command> reads the
|
||||
<filename>/etc/inittab</filename>
|
||||
configuration file. While the system is running, it will
|
||||
re-read it, if sent the HUP signal (<command>kill -HUP 1</command>);
|
||||
this feature makes it unnecessary to boot the system to make
|
||||
changes to the <command>init</command> configuration take
|
||||
effect.</para>
|
||||
|
||||
<para>The <filename>/etc/inittab</filename> file is
|
||||
a bit complicated. We'll start with the simple case
|
||||
of configuring <command>getty</command> lines. Lines in
|
||||
<filename>/etc/inittab</filename> consist of four colon-delimited
|
||||
fields:
|
||||
|
||||
<screen>
|
||||
id:runlevels:action:process
|
||||
</screen>
|
||||
|
||||
The fields are described below. In addition,
|
||||
<filename>/etc/inittab</filename> can contain empty lines, and
|
||||
lines that begin with a number sign (`<literal>#</literal>');
|
||||
these are both ignored.
|
||||
|
||||
<glosslist>
|
||||
<glossentry><glossterm>id</glossterm>
|
||||
<glossdef><para>
|
||||
This identifies the line in the file. For
|
||||
<command>getty</command> lines, it specifies the terminal
|
||||
it runs on (the characters after <filename>/dev/tty</filename>
|
||||
in the device file name). For other lines,
|
||||
it doesn't matter (except for length restrictions),
|
||||
but it should be unique.
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
<glossentry><glossterm>runlevels</glossterm>
|
||||
<glossdef><para>
|
||||
The run levels the line should be considered
|
||||
for. The run levels are given as single digits,
|
||||
without delimiters. (Run levels are described
|
||||
in the next section.)
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
<glossentry><glossterm>action</glossterm>
|
||||
<glossdef><para>
|
||||
What action should be taken by the line, e.g.,
|
||||
<literal>respawn</literal> to run the command in the
|
||||
next field again, when it exits, or <literal>once</literal>
|
||||
to run it just once.
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
<glossentry><glossterm>process</glossterm>
|
||||
<glossdef><para>
|
||||
The command to run.
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
</glosslist>
|
||||
|
||||
To start a <command>getty</command> on the first virtual terminal
|
||||
(<filename>/dev/tty1</filename>), in all the normal multi-user
|
||||
run levels (2-5), one would write the following line:
|
||||
|
||||
<screen>
|
||||
1:2345:respawn:/sbin/getty 9600 tty1
|
||||
</screen>
|
||||
|
||||
The first field says that this is the line for
|
||||
<filename>/dev/tty1</filename>.
|
||||
The second field says that it applies to run levels 2, 3, 4,
|
||||
and 5. The third field means that the command should be run
|
||||
again, after it exits (so that one can log in, log out, and
|
||||
then log in again). The last field is the command that runs
|
||||
<command>getty</command> on the first virtual terminal.</para>
|
||||
|
||||
<para>Different versions of <command>getty</command> are run
|
||||
differently. Consult your manual page, and make sure it is
|
||||
the correct manual page.</para>
|
||||
|
||||
<para>If you wanted to add terminals or dial-in modem lines to a
|
||||
system, you'd add more lines to <filename>/etc/inittab</filename>,
|
||||
one for each terminal or dial-in line. For more details, see the
|
||||
manual pages <command>init</command>, <filename>inittab</filename>,
|
||||
and <command>getty</command>.</para>
|
||||
|
||||
<para>If a command fails when it starts,
|
||||
and <command>init</command> is configured to
|
||||
<literal>restart</literal> it, it will use a lot of
|
||||
system resources: <command>init</command> starts it,
|
||||
it fails, <command>init</command> starts it, it fails,
|
||||
<command>init</command> starts it, it fails, and so on, ad
|
||||
infinitum. To prevent this, <command>init</command> will keep
|
||||
track of how often it restarts a command, and if the frequency
|
||||
grows to high, it will delay for five minutes before restarting
|
||||
again. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="run-levels-intro">
|
||||
<title>Run levels</title>
|
||||
|
||||
<para>A <glossterm>run level</glossterm> is a state of
|
||||
<command>init</command> and the whole system that defines what
|
||||
system services are operating. Run levels are identified by
|
||||
numbers. Some system administrators
|
||||
use run levels to define which subsystems are working, e.g.,
|
||||
whether X is running, whether the network is operational, and
|
||||
so on. Others have all subsystems always running or start and
|
||||
stop them individually, without changing run levels, since run
|
||||
levels are too coarse for controlling their systems. You need
|
||||
to decide for yourself, but it might be easiest to follow the
|
||||
way your Linux distribution does things.</para>
|
||||
|
||||
<para>The following table defines how most Linux Distributions
|
||||
define the different run levels. However, run-levels 2 through 5
|
||||
can be modified to suit your own tastes.</para>
|
||||
|
||||
<table id="run-levels-table">
|
||||
<title>Run level numbers</title>
|
||||
<tgroup cols=2>
|
||||
<tbody>
|
||||
<row> <entry>0</entry> <entry>Halt the system.</entry> </row>
|
||||
<row> <entry>1</entry> <entry>Single-user mode (for special
|
||||
administration).</entry> </row>
|
||||
<row> <entry>2</entry> <entry>Local Multiuser with Networking
|
||||
but without network service (like NFS)</entry> </row>
|
||||
<row> <entry>3</entry> <entry>Full Multiuser with Networking
|
||||
</entry> </row>
|
||||
<row> <entry>4</entry> <entry>Not Used
|
||||
</entry> </row>
|
||||
<row> <entry>5</entry> <entry>Full Multiuser with Networking
|
||||
and X Windows(GUI)</entry> </row>
|
||||
<row> <entry>6</entry> <entry>Reboot.</entry> </row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>Services that get started at a certain runtime are determined
|
||||
by the contents of the various <filename>rcN.d</filename> directories.
|
||||
Most distributions locate these directories either at
|
||||
<filename>/etc/init.d/rcN.d</filename> or
|
||||
<filename>/etc/rcN.d</filename>. (Replace the N with the run-level
|
||||
number.)<para>
|
||||
|
||||
<para>In each run-level you will find a series of if links pointing
|
||||
to start-up scripts located in <filename>/etc/init.d</filename>.
|
||||
The names of these links all start as either K or S, followed by a
|
||||
number. If the name of the link starts with an S, then that indicates
|
||||
the service will be started when you go into that run level. If the
|
||||
name of the link starts with a K, the service will be killed (if
|
||||
running).</para>
|
||||
|
||||
<para>The number following the K or S indicates the order the scripts
|
||||
will be run. Here is a sample of what an
|
||||
<filename>/etc/init.d/rc3.d</filename> may look like.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ls -l /etc/init.d/rc3.d</userinput>
|
||||
<computeroutput>
|
||||
lrwxrwxrwx 1 root root 10 2004-11-29 22:09 K12nfsboot -> ../nfsboot
|
||||
lrwxrwxrwx 1 root root 6 2005-03-29 13:42 K15xdm -> ../xdm
|
||||
lrwxrwxrwx 1 root root 9 2004-11-29 22:08 S01pcmcia -> ../pcmcia
|
||||
lrwxrwxrwx 1 root root 9 2004-11-29 22:06 S01random -> ../random
|
||||
lrwxrwxrwx 1 root root 11 2005-03-01 11:56 S02firewall -> ../firewall
|
||||
lrwxrwxrwx 1 root root 10 2004-11-29 22:34 S05network -> ../network
|
||||
lrwxrwxrwx 1 root root 9 2004-11-29 22:07 S06syslog -> ../syslog
|
||||
lrwxrwxrwx 1 root root 10 2004-11-29 22:09 S08portmap -> ../portmap
|
||||
lrwxrwxrwx 1 root root 9 2004-11-29 22:07 S08resmgr -> ../resmgr
|
||||
lrwxrwxrwx 1 root root 6 2004-11-29 22:09 S10nfs -> ../nfs
|
||||
lrwxrwxrwx 1 root root 12 2004-11-29 22:40 S12alsasound -> ../alsasound
|
||||
lrwxrwxrwx 1 root root 8 2004-11-29 22:09 S12fbset -> ../fbset
|
||||
lrwxrwxrwx 1 root root 7 2004-11-29 22:10 S12sshd -> ../sshd
|
||||
lrwxrwxrwx 1 root root 8 2005-02-01 09:24 S12xntpd -> ../xntpd
|
||||
lrwxrwxrwx 1 root root 7 2004-12-02 20:34 S13cups -> ../cups
|
||||
lrwxrwxrwx 1 root root 6 2004-11-29 22:09 S13kbd -> ../kbd
|
||||
lrwxrwxrwx 1 root root 13 2004-11-29 22:10 S13powersaved -> ../powersaved
|
||||
lrwxrwxrwx 1 root root 9 2004-11-29 22:09 S14hwscan -> ../hwscan
|
||||
lrwxrwxrwx 1 root root 7 2004-11-29 22:10 S14nscd -> ../nscd
|
||||
lrwxrwxrwx 1 root root 10 2004-11-29 22:10 S14postfix -> ../postfix
|
||||
lrwxrwxrwx 1 root root 6 2005-02-04 13:27 S14smb -> ../smb
|
||||
lrwxrwxrwx 1 root root 7 2004-11-29 22:10 S15cron -> ../cron
|
||||
lrwxrwxrwx 1 root root 8 2004-12-22 20:35 S15smbfs -> ../smbfs
|
||||
</computeroutput>
|
||||
<prompt>
|
||||
</screen>
|
||||
|
||||
<para>How run levels start are configured in
|
||||
<filename>/etc/inittab</filename> by lines like the following:
|
||||
|
||||
<screen>
|
||||
l2:2:wait:/etc/init.d/rc 2
|
||||
</screen>
|
||||
|
||||
The first field is an arbitrary label, the second one means
|
||||
that this applies for run level 2. The third field means
|
||||
that <command>init</command> should run the command in the
|
||||
fourth field once, when the run level is entered, and that
|
||||
<command>init</command> should wait for it to complete. The
|
||||
<filename>/etc/init.d/rc</filename> command runs whatever
|
||||
commands are necessary to start and stop services to enter run
|
||||
level 2.</para>
|
||||
|
||||
<para>The command in the fourth field does all the hard work of
|
||||
setting up a run level. It starts services that aren't already
|
||||
running, and stops services that shouldn't be running in the
|
||||
new run level any more. Exactly what the command is, and how run
|
||||
levels are configured, depends on the Linux distribution.</para>
|
||||
|
||||
<para>When <command>init</command> starts, it looks for a line
|
||||
in <filename>/etc/inittab</filename> that specifies the default
|
||||
run level:
|
||||
|
||||
<screen>
|
||||
id:2:initdefault:
|
||||
</screen>
|
||||
|
||||
You can ask <command>init</command> to go to a non-default run
|
||||
level at startup by giving the kernel a command line argument
|
||||
of <literal>single</literal> or <literal>emergency</literal>.
|
||||
Kernel command line arguments can be given via LILO, for example.
|
||||
This allows you to choose the single user mode (run level 1).</para>
|
||||
|
||||
<para>While the system is running, the <command>telinit</command>
|
||||
command can change the run level. When the run level is
|
||||
changed, <command>init</command> runs the relevant command from
|
||||
<filename>/etc/inittab</filename>. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="inittab">
|
||||
<title>Special configuration in
|
||||
<filename>/etc/inittab</filename></title>
|
||||
|
||||
<para>The <filename>/etc/inittab</filename> has some special
|
||||
features that allow <command>init</command> to react to special
|
||||
circumstances. These special features are marked by special
|
||||
keywords in the third field. Some examples:
|
||||
|
||||
<glosslist>
|
||||
|
||||
<glossentry><glossterm><literal>powerwait</literal></glossterm>
|
||||
<glossdef><para>
|
||||
Allows <command>init</command> to shut the system
|
||||
down, when the power fails. This assumes the use of
|
||||
a UPS, and software that watches the UPS and informs
|
||||
<command>init</command> that the power is off.
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
<glossentry><glossterm><literal>ctrlaltdel</literal></glossterm>
|
||||
<glossdef><para>
|
||||
Allows <command>init</command> to reboot the system, when
|
||||
the user presses ctrl-alt-del on the console keyboard.
|
||||
Note that the system administrator can configure the
|
||||
reaction to ctrl-alt-del to be something else instead,
|
||||
e.g., to be ignored, if the system is in a public
|
||||
location. (Or to start <command>nethack</command>.)
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
<glossentry><glossterm><literal>sysinit</literal></glossterm>
|
||||
<glossdef><para>
|
||||
Command to be run when the system is booted. This command
|
||||
usually cleans up <filename>/tmp</filename>, for example.
|
||||
</para></glossdef></glossentry>
|
||||
|
||||
</glosslist>
|
||||
|
||||
The list above is not exhaustive. See your
|
||||
<filename>inittab</filename> manual page for all possibilities,
|
||||
and for details on how to use the above ones. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="boot-single-user">
|
||||
<title>Booting in single user mode</title>
|
||||
|
||||
<para>An important run level is <glossterm>single user
|
||||
mode</glossterm> (run level 1),
|
||||
in which only the system administrator is using the machine
|
||||
and as few system services, including logins, as possible are
|
||||
running. Single user mode is necessary for a few administrative
|
||||
tasks, such as running <command>fsck</command> on a
|
||||
<filename>/usr</filename> partition, since this requires that
|
||||
the partition be unmounted, and that can't happen, unless just
|
||||
about all system services are killed.</para>
|
||||
|
||||
<para>A running system can be taken to single user mode by using
|
||||
<command>telinit</command> to request run level 1. At bootup,
|
||||
it can be entered by giving the word <literal>single</literal>
|
||||
or <literal>emergency</literal> on the kernel command line: the
|
||||
kernel gives the command line to <command>init</command> as well,
|
||||
and <command>init</command> understands from that word that it
|
||||
shouldn't use the default run level. (The kernel command line is
|
||||
entered in a way that depends on how you boot the system.)</para>
|
||||
|
||||
<para>Booting into single user mode is sometimes necessary so
|
||||
that one can run <command>fsck</command> by hand, before anything
|
||||
mounts or otherwise touches a broken <filename>/usr</filename>
|
||||
partition (any activity on a broken filesystem is likely to
|
||||
break it more, so <command>fsck</command> should be run as soon
|
||||
as possible).</para>
|
||||
|
||||
<para>The bootup scripts <command>init</command> runs
|
||||
will automatically enter single user mode, if the automatic
|
||||
<command>fsck</command> at bootup fails. This is an attempt to
|
||||
prevent the system from using a filesystem that is so broken that
|
||||
<command>fsck</command> can't fix it automatically. Such breakage
|
||||
is relatively rare, and usually involves a broken hard disk or an
|
||||
experimental kernel release, but it's good to be prepared.</para>
|
||||
|
||||
<para>As a security measure, a properly configured system
|
||||
will ask for the root password before starting the shell in
|
||||
single user mode. Otherwise, it would be simple to just enter
|
||||
a suitable line to LILO to get in as root. (This will break if
|
||||
<filename>/etc/passwd</filename> has been broken by filesystem
|
||||
problems, of course, and in that case you'd better have a boot
|
||||
floppy handy.)</para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,252 @@
|
|||
<chapter id="log-in-and-out">
|
||||
<title>Logging In And Out</title>
|
||||
|
||||
<blockquote><para><quote>I don't care to belong to a club
|
||||
that accepts people like me as a member.</quote>
|
||||
(Groucho Marx)</para></blockquote>
|
||||
|
||||
<para>
|
||||
This section describes what happens when a user logs
|
||||
in or out. The various interactions of background processes,
|
||||
log files, configuration files, and so on are described in
|
||||
some detail.
|
||||
</para>
|
||||
|
||||
<sect1 id="login-via-terminal">
|
||||
<title>Logins via terminals</title>
|
||||
|
||||
<para><xref linkend="terminal-logins"> shows how logins happen via
|
||||
terminals. First, <command>init</command> makes sure there is
|
||||
a <command>getty</command> program for the terminal connection
|
||||
(or console). <command>getty</command> listens at the terminal
|
||||
and waits for the user to notify that he is ready to login in
|
||||
(this usually means that the user must type something). When it
|
||||
notices a user, <command>getty</command> outputs a welcome message
|
||||
(stored in <filename>/etc/issue</filename>), and prompts for
|
||||
the username, and finally runs the <command>login</command>
|
||||
program. <command>login</command> gets the username as a
|
||||
parameter, and prompts the user for the password. If these
|
||||
match, <command>login</command> starts the shell configured
|
||||
for the user; else it just exits and terminates the process
|
||||
(perhaps after giving the user another chance at entering the
|
||||
username and password). <command>init</command> notices that
|
||||
the process terminated, and starts a new <command>getty</command>
|
||||
for the terminal.
|
||||
</para>
|
||||
|
||||
<figure id="terminal-logins-table" float="1">
|
||||
<title>Logins via terminals: the interaction of
|
||||
<command>init</command>,
|
||||
<command>getty</command>, <command>login</command>, and the
|
||||
shell.</title>
|
||||
<graphic fileref="logins-via-terminals.png">
|
||||
</figure>
|
||||
|
||||
<para> Note that the only new process is the
|
||||
one created by <command>init</command> (using the
|
||||
<function>fork</function> system call); <command>getty</command>
|
||||
and <command>login</command> only replace the program running in
|
||||
the process (using the <function>exec</function> system call).
|
||||
</para>
|
||||
|
||||
<para> A separate program, for noticing the user, is needed
|
||||
for serial lines, since it can be (and traditionally was)
|
||||
complicated to notice when a terminal becomes active.
|
||||
<command>getty</command> also adapts to the speed and other
|
||||
settings of the connection, which is important especially for
|
||||
dial-in connections, where these parameters may change from call
|
||||
to call. </para>
|
||||
|
||||
<para> There are several versions of <command>getty</command>
|
||||
and <command>init</command> in use, all with their good and
|
||||
bad points. It is a good idea to learn about the versions on
|
||||
your system, and also about the other versions (you could use the
|
||||
Linux Software Map to search them). If you don't have dial-ins,
|
||||
you probably don't have to worry about <command>getty</command>,
|
||||
but <command>init</command> is still important. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="login-via-network">
|
||||
<title>Logins via the network</title>
|
||||
|
||||
<para>Two computers in the same network are usually linked via a
|
||||
single physical cable. When they communicate over the network,
|
||||
the programs in each computer that take part in the communication
|
||||
are linked via a <glossterm>virtual connection</glossterm>, a sort
|
||||
of imaginary cable. As far as the programs at either end of the
|
||||
virtual connection are concerned, they have a monopoly on their
|
||||
own cable. However, since the cable is not real, only imaginary,
|
||||
the operating systems of both computers can have several virtual
|
||||
connections share the same physical cable. This way, using just
|
||||
a single cable, several programs can communicate without having
|
||||
to know of or care about the other communications. It is even
|
||||
possible to have several computers use the same cable; the virtual
|
||||
connections exist between two computers, and the other computers
|
||||
ignore those connections that they don't take part in. </para>
|
||||
|
||||
<para> That's a complicated and over-abstracted description of
|
||||
the reality. It might, however, be good enough to understand
|
||||
the important reason why network logins are somewhat different
|
||||
from normal logins. The virtual connections are established
|
||||
when there are two programs on different computers that wish
|
||||
to communicate. Since it is in principle possible to login
|
||||
from any computer in a network to any other computer, there is
|
||||
a huge number of potential virtual communications. Because of
|
||||
this, it is not practical to start a <command>getty</command>
|
||||
for each potential login. </para>
|
||||
|
||||
<para> There is a single process inetd (corresponding to
|
||||
<command>getty</command>) that handles all network logins.
|
||||
When it notices an incoming network login (i.e., it notices
|
||||
that it gets a new virtual connection to some other computer),
|
||||
it starts a new process to handle that single login. The original
|
||||
process remains and continues to listen for new logins. </para>
|
||||
|
||||
<para> To make things a bit more complicated, there is
|
||||
more than one communication protocol for network logins.
|
||||
The two most important ones are <command>telnet</command> and
|
||||
<command>rlogin</command>. In addition to logins, there are many
|
||||
other virtual connections that may be made (for FTP, Gopher, HTTP,
|
||||
and other network services). It would be ineffective to have a
|
||||
separate process listening for a particular type of connection,
|
||||
so instead there is only one listener that can recognize the type
|
||||
of the connection and can start the correct type of program to
|
||||
provide the service. This single listener is called
|
||||
<command>inetd</command>;
|
||||
see the <citetitle>Linux Network Administrators' Guide</citetitle>
|
||||
for more information. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="what-login-does">
|
||||
<title>What <command>login</command> does</title>
|
||||
|
||||
<para>The <command>login</command> program takes care of
|
||||
authenticating the user (making sure that the username and
|
||||
password match), and of setting up an initial environment for
|
||||
the user by setting permissions for the serial line and starting
|
||||
the shell. </para>
|
||||
|
||||
<para> Part of the initial setup is outputting the contents of
|
||||
the file <filename>/etc/motd</filename> (short for message of the
|
||||
day) and checking for electronic mail. These can be disabled
|
||||
by creating a file called <filename>.hushlogin</filename> in
|
||||
the user's home directory. </para>
|
||||
|
||||
<para> If the file <filename>/etc/nologin</filename>
|
||||
exists, logins are disabled. That file is typically
|
||||
created by <command>shutdown</command> and relatives.
|
||||
<command>login</command> checks for this file, and will
|
||||
refuse to accept a login if it exists. If it does exist,
|
||||
<command>login</command> outputs its contents to the terminal
|
||||
before it quits. </para>
|
||||
|
||||
<para> <command>login</command> logs all failed login attempts in
|
||||
a system log file (via <command>syslog</command>). It also logs
|
||||
all logins by root. Both of these can be useful when tracking
|
||||
down intruders. </para>
|
||||
|
||||
<para> Currently logged in people are listed in
|
||||
<filename>/var/run/utmp</filename>. This file is valid only
|
||||
until the system is next rebooted or shut down; it is cleared
|
||||
when the system is booted. It lists each user and the terminal
|
||||
(or network connection) he is using, along with some other useful
|
||||
information. The <command>who</command>, <command>w</command>,
|
||||
and other similar commands look in <filename>utmp</filename>
|
||||
to see who are logged in. </para>
|
||||
|
||||
<para> All successful logins are recorded into
|
||||
<filename>/var/log/wtmp</filename>. This file will grow without
|
||||
limit, so it must be cleaned regularly, for example by having
|
||||
a weekly <command>cron</command> job to clear it.
|
||||
The <command>last</command> command browses
|
||||
<filename>wtmp</filename>. </para>
|
||||
|
||||
<para> Both <filename>utmp</filename> and
|
||||
<filename>wtmp</filename> are in a binary format (see the
|
||||
<filename>utmp</filename> manual page); it is unfortunately not
|
||||
convenient to examine them without special programs. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="X-xdm">
|
||||
<title>X and xdm</title>
|
||||
|
||||
<para> XXX X implements logins via xdm; also: xterm -ls </para>
|
||||
|
||||
<para>TO BE ADDED</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="access-control">
|
||||
<title>Access control</title>
|
||||
|
||||
<para> The user database is traditionally contained in the
|
||||
<filename>/etc/passwd</filename> file. Some systems use
|
||||
<glossterm>shadow passwords</glossterm>, and have moved the
|
||||
passwords to <command>/etc/shadow</command>. Sites with many
|
||||
computers that share the accounts use NIS or some other method
|
||||
to store the user database; they might also automatically copy
|
||||
the database from one central location to all other computers.
|
||||
</para>
|
||||
|
||||
<para> The user database contains not only the passwords, but
|
||||
also some additional information about the users, such as their
|
||||
real names, home directories, and login shells. This other
|
||||
information needs to be public, so that anyone can read it.
|
||||
Therefore the password is stored encrypted. This does have
|
||||
the drawback that anyone with access to the encrypted password
|
||||
can use various cryptographic methods to guess it, without
|
||||
trying to actually log into the computer. Shadow passwords try
|
||||
to avoid this by moving the password into another file, which
|
||||
only root can read (the password is still stored encrypted).
|
||||
However, installing shadow passwords later onto a system that
|
||||
did not support them can be difficult. </para>
|
||||
|
||||
<para> With or without passwords, it is important to make
|
||||
sure that all passwords in a system are good, i.e., not easily
|
||||
guessed. The <command>crack</command> program can be used
|
||||
to crack passwords; any password it can find is by definition
|
||||
not a good one. While <command>crack</command> can be run
|
||||
by intruders, it can also be run by the system administrator
|
||||
to avoid bad passwords. Good passwords can also be enforced
|
||||
by the <command>passwd</command> program; this is in fact more
|
||||
effective in CPU cycles, since cracking passwords requires quite
|
||||
a lot of computation. </para>
|
||||
|
||||
<para> The user group database is kept in
|
||||
<filename>/etc/group</filename>; for systems with shadow
|
||||
passwords, there can be a <filename>/etc/shadow.group</filename>.
|
||||
</para>
|
||||
|
||||
<para> root usually can't login via most terminals
|
||||
or the network, only via terminals listed in the
|
||||
<filename>/etc/securetty</filename> file. This makes it necessary
|
||||
to get physical access to one of these terminals. It is, however,
|
||||
possible to log in via any terminal as any other user, and use
|
||||
the <command>su</command> command to become root. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="shell-startup">
|
||||
<title>Shell startup</title>
|
||||
|
||||
<para> When an interactive login shell starts, it automatically
|
||||
executes one or more pre-defined files. Different shells execute
|
||||
different files; see the documentation of each shell for further
|
||||
information. </para>
|
||||
|
||||
<para> Most shells first run some global file, for example, the
|
||||
Bourne shell (<command>/bin/sh</command>) and its derivatives
|
||||
execute <filename>/etc/profile</filename>; in addition,
|
||||
they execute <filename>.profile</filename> in the user's
|
||||
home directory. <filename>/etc/profile</filename> allows the
|
||||
system administrator to have set up a common user environment,
|
||||
especially by setting the <envar>PATH</envar> to include local
|
||||
command directories in addition to the normal ones. On the other
|
||||
hand, <filename>.profile</filename> allows the user to customize
|
||||
the environment to his own tastes by overriding, if necessary,
|
||||
the default environment. </para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,382 @@
|
|||
<chapter id="managing-users">
|
||||
<title>Managing user accounts</title>
|
||||
|
||||
<blockquote><para><quote>The similarities of sysadmins and drug
|
||||
dealers: both measure stuff in Ks, and both have users.</quote>
|
||||
(Old, tired computer joke.)</para></blockquote>
|
||||
|
||||
<para> This chapter explains how to create new user accounts,
|
||||
how to modify the properties of those accounts, and how to remove
|
||||
the accounts. Different Linux systems have different tools for
|
||||
doing this.</para>
|
||||
|
||||
<sect1 id="account">
|
||||
<title>What's an account?</title>
|
||||
|
||||
<para> When a computer is used by many people it is usually
|
||||
necessary to differentiate between the users, for example, so that
|
||||
their private files can be kept private. This is important even
|
||||
if the computer can only be used by a single person at a time,
|
||||
as with most microcomputers. Thus, each user is given a unique
|
||||
username, and that name is used to log in.</para>
|
||||
|
||||
<para> There's more to a user than just a name, however. An
|
||||
<glossterm>account</glossterm> is all the files, resources,
|
||||
and information belonging to one user. The term hints at banks,
|
||||
and in a commercial system each account usually has some money
|
||||
attached to it, and that money vanishes at different speeds
|
||||
depending on how much the user stresses the system. For example,
|
||||
disk space might have a price per megabyte and day, and processing
|
||||
time might have a price per second. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="adduser">
|
||||
<title>Creating a user</title>
|
||||
|
||||
<para> The Linux kernel itself treats users are mere numbers.
|
||||
Each user is identified by a unique integer, the <glossterm>user
|
||||
id</glossterm> or <glossterm>uid</glossterm>, because numbers are
|
||||
faster and easier for a computer to process than textual names.
|
||||
A separate database outside the kernel assigns a textual name,
|
||||
the <glossterm>username</glossterm>, to each user id. The database
|
||||
contains additional information as well. </para>
|
||||
|
||||
<para> To create a user, you need to add information about
|
||||
the user to the user database, and create a home directory for
|
||||
him. It may also be necessary to educate the user, and set up
|
||||
a suitable initial environment for him. </para>
|
||||
|
||||
<para> Most Linux distributions come with a program for
|
||||
creating accounts. There are several such programs available.
|
||||
Two command line alternatives are <command>adduser</command>
|
||||
and <command>useradd</command>; there may be a GUI tool as well.
|
||||
Whatever the program, the result is that there is little if
|
||||
any manual work to be done. Even if the details are many and
|
||||
intricate, these programs make everything seem trivial. However,
|
||||
<xref linkend="manual-adduser"> describes how to do it by hand.
|
||||
</para>
|
||||
|
||||
<sect2 id="etc-passwd">
|
||||
<title><filename>/etc/passwd</filename> and other informative
|
||||
files</title>
|
||||
|
||||
<para> The basic user database in a Unix system is the text file,
|
||||
<filename>/etc/passwd</filename> (called the <glossterm>password
|
||||
file</glossterm>), which lists all valid usernames and their
|
||||
associated information. The file has one line per username,
|
||||
and is divided into seven colon-delimited fields:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Username.</para></listitem>
|
||||
<listitem><para>Previously this was where the user's password was stored.
|
||||
</para></listitem>
|
||||
<listitem><para>Numeric user id.</para></listitem>
|
||||
<listitem><para>Numeric group id.</para></listitem>
|
||||
<listitem><para>Full name or other description of
|
||||
account.</para></listitem>
|
||||
<listitem><para>Home directory.</para></listitem>
|
||||
<listitem><para>Login shell (program to run at
|
||||
login).</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
The format is explained in more detail on the
|
||||
<filename>passwd</filename> manual page. </para>
|
||||
|
||||
<para>
|
||||
Most Linux systems use <glossterm>shadow passwords</glossterm>.
|
||||
As mentioned, previously passwords were stored in the
|
||||
<filename>/etc/passwd</filename> file. This newer method
|
||||
of storing the password: the encrypted
|
||||
password is stored in a separate file,
|
||||
<filename>/etc/shadow</filename>,
|
||||
which only root can read. The <filename>/etc/passwd</filename>
|
||||
file only contains a special marker in the second field.
|
||||
Any program that needs to verify a user is setuid, and
|
||||
can therefore access the shadow password file. Normal
|
||||
programs, which only use the other fields in the password
|
||||
file, can't get at the password.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="uid-gid">
|
||||
<title>Picking numeric user and group ids</title>
|
||||
|
||||
<para> On most systems it doesn't matter what the numeric user
|
||||
and group ids are, but if you use the Network filesystem (NFS),
|
||||
you need to have the same uid and gid on all systems. This
|
||||
is because NFS also identifies users with the numeric uids.
|
||||
If you aren't using NFS, you can let your account creation tool
|
||||
pick them automatically. </para>
|
||||
|
||||
<para> If you are using NFS, you'll have to be invent a mechanism
|
||||
for synchronizing account information. One alternative is to
|
||||
the NIS system (see XXX network-admin-guide). </para>
|
||||
|
||||
<para> However, you should try to avoid re-using numeric uids
|
||||
(and textual usernames), because the new owner of the uid (or
|
||||
username) may get access to the old owner's files (or mail,
|
||||
or whatever). </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<!--
|
||||
%\subsection{Managing groups}
|
||||
%
|
||||
% \meta Debian creates a new group for each user; give reason for
|
||||
this;
|
||||
% give reasons against.
|
||||
-->
|
||||
|
||||
<sect2 id="etc-skel">
|
||||
<title>Initial environment: <filename>/etc/skel</filename></title>
|
||||
|
||||
<para> When the home directory for a new user is created, it is
|
||||
initialized with files from the <filename>/etc/skel</filename>
|
||||
directory. The system administrator can create files in
|
||||
<filename>/etc/skel</filename> that will provide a nice
|
||||
default environment for users. For example, he might create a
|
||||
<filename>/etc/skel/.profile</filename> that sets the EDITOR
|
||||
environment variable to some editor that is friendly towards
|
||||
new users. </para>
|
||||
|
||||
<para> However, it is usually best to try to keep
|
||||
<filename>/etc/skel</filename> as small as possible, since it
|
||||
will be next to impossible to update existing users' files. For
|
||||
example, if the name of the friendly editor changes, all existing
|
||||
users would have to edit their <filename>.profile</filename>. The
|
||||
system administrator could try to do it automatically, with a
|
||||
script, but that is almost certain going to break someone's file.
|
||||
</para>
|
||||
|
||||
<para> Whenever possible, it is better to put global configuration
|
||||
into global files, such as <filename>/etc/profile</filename>. This
|
||||
way it is possible to update it without breaking users'
|
||||
own setups. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="manual-adduser">
|
||||
<title>Creating a user by hand</title>
|
||||
|
||||
<para> To create a new account manually, follow these steps:
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para> Edit <filename>/etc/passwd</filename> with
|
||||
<command>vipw</command> and add a new line for the new account. Be
|
||||
careful with the syntax. <emphasis>Do not edit directly with an
|
||||
editor!</emphasis> <command>vipw</command> locks the file, so
|
||||
that other commands won't try to update it at the same time. You
|
||||
should make the password field be `<literal>*</literal>', so
|
||||
that it is impossible to log in. </para></listitem>
|
||||
|
||||
<listitem><para> Similarly, edit <filename>/etc/group</filename>
|
||||
with <command>vigr</command>, if you need to create a new group
|
||||
as well. </para></listitem>
|
||||
|
||||
<listitem><para> Create the home directory of the user with
|
||||
<command>mkdir</command>. </para></listitem>
|
||||
|
||||
<listitem><para> Copy the files from
|
||||
<filename>/etc/skel</filename> to the new home directory.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> Fix ownerships and permissions with
|
||||
<command>chown</command> and <command>chmod</command>. The
|
||||
<option>-R</option> option is most useful. The correct
|
||||
permissions vary a little from one site to another, but usually
|
||||
the following commands do the right thing:
|
||||
|
||||
<screen>
|
||||
<userinput>cd /home/newusername
|
||||
chown -R username.group .
|
||||
chmod -R go=u,go-w .
|
||||
chmod go= .</userinput>
|
||||
</screen>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> Set the password with <command>passwd</command>.
|
||||
</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para> After you set the password in the last step, the account
|
||||
will work. You shouldn't set it until everything else has been
|
||||
done, otherwise the user may inadvertently log in while you're
|
||||
still copying the files. </para>
|
||||
|
||||
<para>
|
||||
It is sometimes necessary to create dummy
|
||||
accounts
|
||||
that are not used by people. For example, to set up an anonymous
|
||||
FTP server (so that anyone can download files from it, without
|
||||
having to get an account first), you need to create an account
|
||||
called ftp. In such cases, it is usually not necessary to set
|
||||
the password (last step above). Indeed, it is better not to, so
|
||||
that no-one can use the account, unless they first become root,
|
||||
since root can become any user. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<!--
|
||||
%\section{Educating a new user}
|
||||
%
|
||||
% \meta
|
||||
% make sure they know how to get help
|
||||
% large sites might want to write a small booklet (or even just
|
||||
% a couple of pages) with important stuff: how to log in
|
||||
% and out, how to change password, which systems there are,
|
||||
% how to use mail, list of people that answer questions
|
||||
-->
|
||||
|
||||
<sect1 id="user-properties">
|
||||
<title>Changing user properties</title>
|
||||
|
||||
<para>
|
||||
There are a few commands for changing various
|
||||
properties of an account (i.e., the relevant field
|
||||
in <filename>/etc/passwd</filename>):
|
||||
|
||||
<glosslist>
|
||||
<glossentry><glossterm><command>chfn</command></glossterm>
|
||||
<glossdef><para> Change the full name field.
|
||||
</para></glossdef></glossentry>
|
||||
<glossentry><glossterm><command>chsh</command></glossterm>
|
||||
<glossdef><para> Change the login shell.
|
||||
</para></glossdef></glossentry>
|
||||
<glossentry><glossterm><command>passwd</command></glossterm>
|
||||
<glossdef><para>Change the password.
|
||||
</para></glossdef></glossentry>
|
||||
</glosslist>
|
||||
|
||||
The super-user may use these commands to change the properties
|
||||
of any account. Normal users can only change the properties
|
||||
of their own account. It may sometimes be necessary to disable
|
||||
these commands (with <command>chmod</command>) for normal users,
|
||||
for example in an environment with many novice users. </para>
|
||||
|
||||
<para>
|
||||
Other tasks need to be done by hand. For example, to
|
||||
change the username, you need to edit
|
||||
<filename>/etc/passwd</filename>
|
||||
directly (with <command>vipw</command>, remember). Likewise, to add
|
||||
or remove the user to more groups, you need to edit
|
||||
<filename>/etc/group</filename> (with <command>vigr</command>). Such
|
||||
tasks tend to
|
||||
be rare, however, and should be done with caution: for
|
||||
example, if
|
||||
you change the username, e-mail will no longer reach the
|
||||
user, unless you also create a mail alias.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="deluser">
|
||||
<title>Removing a user</title>
|
||||
|
||||
<para> To remove a user, you first remove all
|
||||
his files, mailboxes, mail aliases, print jobs,
|
||||
<command>cron</command> and <command>at</command> jobs,
|
||||
and all other references to the user. Then you remove the
|
||||
relevant lines from <filename>/etc/passwd</filename> and
|
||||
<filename>/etc/group</filename> (remember to remove the username
|
||||
from all groups it's been added to). It may be a good idea to
|
||||
first disable the account (see below), before you start removing
|
||||
stuff, to prevent the user from using the account while it is
|
||||
being removed. </para>
|
||||
|
||||
<para>
|
||||
Remember that users may have files outside their home
|
||||
directory. The <command>find</command> command can find them:
|
||||
|
||||
<screen>
|
||||
find / -user username
|
||||
</screen>
|
||||
|
||||
However, note that the above command will take a
|
||||
<emphasis>long</emphasis> time, if you have large disks. If you
|
||||
mount network disks, you need to be careful so that you won't
|
||||
trash the network or the server. </para>
|
||||
|
||||
<para> Some Linux distributions come with special
|
||||
commands to do this; look for <command>deluser</command> or
|
||||
<command>userdel</command>. However, it is easy to do it by
|
||||
hand as well, and the commands might not do everything. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="disable-user">
|
||||
<title>Disabling a user temporarily</title>
|
||||
|
||||
<para> It is sometimes necessary to temporarily disable an
|
||||
account, without removing it. For example, the user might not
|
||||
have paid his fees, or the system administrator may suspect that
|
||||
a cracker has got the password of that account. </para>
|
||||
|
||||
<para> The best way to disable an account is to change its shell
|
||||
into a special program that just prints a message. This way,
|
||||
whoever tries to log into the account, will fail, and will
|
||||
know why. The message can tell the user to contact the system
|
||||
administrator so that any problems may be dealt with. </para>
|
||||
|
||||
<para>
|
||||
It would also be possible to change the username
|
||||
or password to something else, but then the user
|
||||
won't know what is going on. Confused users mean more
|
||||
work.
|
||||
</para>
|
||||
|
||||
<para> A simple way to create the special programs is to write
|
||||
`tail scripts':
|
||||
|
||||
<screen>
|
||||
#!/usr/bin/tail +2
|
||||
This account has been closed due to a security breach.
|
||||
Please call 555-1234 and wait for the men in black to arrive.
|
||||
</screen>
|
||||
|
||||
The first two characters (`<literal>#!</literal>') tell the
|
||||
kernel that the rest of the line is a command that needs to be
|
||||
run to interpret this file. The <command>tail</command> command
|
||||
in this case outputs everything except the first line to the
|
||||
standard output. </para>
|
||||
|
||||
<para>
|
||||
If user billg is suspected of a security breach,
|
||||
the system administrator would do something like this:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>chsh -s
|
||||
/usr/local/lib/no-login/security billg</userinput>
|
||||
<prompt>#</prompt> <userinput>su - tester</userinput>
|
||||
This account has been closed due to a security breach.
|
||||
Please call 555-1234 and wait for the men in black to arrive.
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
The purpose of the <command>su</command> is to test that the
|
||||
change worked, of course. </para>
|
||||
|
||||
<para> Tail scripts should be kept in a separate directory,
|
||||
so that their names don't interfere with normal user commands.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<!--
|
||||
%\section{Accounting}
|
||||
%
|
||||
% \meta
|
||||
% sac et al
|
||||
-->
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,531 @@
|
|||
<chapter id="backups-intro">
|
||||
<title>Backups</title>
|
||||
|
||||
<blockquote><para><literallayout>
|
||||
Hardware is indeterministically reliable.
|
||||
Software is deterministically unreliable.
|
||||
People are indeterministically unreliable.
|
||||
Nature is deterministically reliable.
|
||||
</literallayout></para></blockquote>
|
||||
|
||||
<para> This chapter explains about why, how, and when to make
|
||||
backups, and how to restore things from backups.</para>
|
||||
|
||||
<sect1 id="backups">
|
||||
<title>On the importance of being backed up</title>
|
||||
|
||||
<para> Your data is valuable. It will cost you time and effort
|
||||
re-create it, and that costs money or at least personal grief
|
||||
and tears; sometimes it can't even be re-created, e.g., if it
|
||||
is the results of some experiments. Since it is an investment,
|
||||
you should protect it and take steps to avoid losing it. </para>
|
||||
|
||||
<para> There are basically four reasons why you might lose data:
|
||||
hardware failures, software bugs, human action, or natural
|
||||
disasters. Although modern hardware tends to be quite reliable, it
|
||||
can still break seemingly spontaneously. The most critical piece
|
||||
of hardware for storing data is the hard disk, which relies on
|
||||
tiny magnetic fields remaining intact in a world filled with
|
||||
electromagnetic noise. Modern software doesn't even tend to
|
||||
be reliable; a rock solid program is an exception, not a rule.
|
||||
Humans are quite unreliable, they will either make a mistake, or
|
||||
they will be malicious and destroy data on purpose. Nature might
|
||||
not be evil, but it can wreak havoc even when being good. All in
|
||||
all, it is a small miracle that anything works at all. </para>
|
||||
|
||||
<para> Backups are a way to protect the investment in data.
|
||||
By having several copies of the data, it does not matter as much
|
||||
if one is destroyed (the cost is only that of the restoration
|
||||
of the lost data from the backup). </para>
|
||||
|
||||
<para> It is important to do backups properly. Like everything
|
||||
else that is related to the physical world, backups will fail
|
||||
sooner or later. Part of doing backups well is to make sure
|
||||
they work; you don't want to notice that your backups didn't work.
|
||||
Adding insult to injury, you might have a bad crash just as
|
||||
you're making the backup; if you have only one backup medium,
|
||||
it might destroyed as well, leaving you with the smoking ashes
|
||||
of hard work.
|
||||
Or you might notice, when trying to restore, that you forgot to
|
||||
back up something important, like the user database on a 15000
|
||||
user site. Best of all, all your backups might be working
|
||||
perfectly, but the last known tape drive reading the kind of
|
||||
tapes you used was the one that now has a bucketful of water
|
||||
in it. </para>
|
||||
|
||||
<para> When it comes to backups, paranoia is in the job
|
||||
description. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backup-media">
|
||||
<title>Selecting the backup medium</title>
|
||||
|
||||
<para> The most important decision regarding backups is the choice
|
||||
of backup medium. You need to consider cost, reliability, speed,
|
||||
availability, and usability. </para>
|
||||
|
||||
<para> Cost is important, since you should preferably have
|
||||
several times more backup storage than what you need for the data.
|
||||
A cheap medium is usually a must. </para>
|
||||
|
||||
<para> Reliability is extremely important, since a broken
|
||||
backup can make a grown man cry. A backup medium must be able
|
||||
to hold data without corruption for years. The way you use the
|
||||
medium affects it reliability as a backup medium. A hard disk
|
||||
is typically very reliable, but as a backup medium it is not
|
||||
very reliable, if it is in the same computer as the disk you
|
||||
are backing up. </para>
|
||||
|
||||
<para> Speed is usually not very important, if backups can be done
|
||||
without interaction. It doesn't matter if a backup takes two
|
||||
hours, as long as it needs no supervision. On the other hand,
|
||||
if the backup can't be done when the computer would otherwise
|
||||
be idle, then speed is an issue. </para>
|
||||
|
||||
<para> Availability is obviously necessary, since you can't
|
||||
use a backup medium if it doesn't exist. Less obvious is the
|
||||
need for the medium to be available even in the future, and on
|
||||
computers other than your own. Otherwise you may not be able
|
||||
to restore your backups after a disaster. </para>
|
||||
|
||||
<para> Usability is a large factor in how often backups are made.
|
||||
The easier it is to make backups, the better. A backup medium
|
||||
mustn't be hard or boring to use. </para>
|
||||
|
||||
<para> The typical alternatives are floppies and tapes.
|
||||
Floppies are very cheap, fairly reliable, not very fast,
|
||||
very available, but not very usable for large amounts of data.
|
||||
Tapes are cheap to somewhat expensive, fairly reliable, fairly
|
||||
fast, quite available, and, depending on the size of the tape,
|
||||
quite comfortable. </para>
|
||||
|
||||
<para> There are other alternatives. They are usually not very
|
||||
good on availability, but if that is not a problem, they can
|
||||
be better in other ways. For example, magneto-optical disks
|
||||
can have good sides of both floppies (they're random access,
|
||||
making restoration of a single file quick) and tapes (contain
|
||||
a lot of data). </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backup-tools">
|
||||
<title>Selecting the backup tool</title>
|
||||
|
||||
<para> There are many tools that can be used to make
|
||||
backups. The traditional UNIX tools used for backups
|
||||
are <command>tar</command>, <command>cpio</command>, and
|
||||
<command>dump</command>. In addition, there are large number
|
||||
of third party packages (both freeware and commercial) that
|
||||
can be used. The choice of backup medium can affect the choice
|
||||
of tool. </para>
|
||||
|
||||
<para> <command>tar</command> and <command>cpio</command> are
|
||||
similar, and mostly equivalent from a backup point of view.
|
||||
Both are capable of storing files on tapes, and retrieving
|
||||
files from them. Both are capable of using almost any media,
|
||||
since the kernel device drivers take care of the low level
|
||||
device handling and the devices all tend to look alike to user
|
||||
level programs. Some UNIX versions of <command>tar</command>
|
||||
and <command>cpio</command> may have problems with unusual files
|
||||
(symbolic links, device files, files with very long pathnames, and
|
||||
so on), but the Linux versions should handle all files correctly.
|
||||
</para>
|
||||
|
||||
<para> <command>dump</command> is different in that it reads
|
||||
the filesystem directly and not via the filesystem. It is
|
||||
also written specifically for backups; <command>tar</command>
|
||||
and <command>cpio</command> are really for archiving files,
|
||||
although they work for backups as well. </para>
|
||||
|
||||
<para> Reading the filesystem directly has some advantages.
|
||||
It makes it possible to back files up without affecting their time
|
||||
stamps; for <command>tar</command> and <command>cpio</command>,
|
||||
you would have to mount the filesystem read-only first.
|
||||
Directly reading the filesystem is also more effective, if
|
||||
everything needs to be backed up, since it can be done with
|
||||
much less disk head movement. The major disadvantage is that
|
||||
it makes the backup program specific to one filesystem type;
|
||||
the Linux <command>dump</command> program understands the ext2
|
||||
filesystem only. </para>
|
||||
|
||||
<para> <command>dump</command> also directly supports
|
||||
backup levels (which we'll be discussing below); with
|
||||
<command>tar</command> and <command>cpio</command> this has to
|
||||
be implemented with other tools. </para>
|
||||
|
||||
<para> A comparison of the third party backup tools is beyond
|
||||
the scope of this book. The Linux Software Map lists many of
|
||||
the freeware ones. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="simple-backups">
|
||||
<title>Simple backups</title>
|
||||
|
||||
<para> A simple backup scheme is to back up everything once,
|
||||
then back up everything that has been modified since the
|
||||
previous backup. The first backup is called a <glossterm>full
|
||||
backup</glossterm>, the subsequent ones are <glossterm>incremental
|
||||
backups</glossterm>. A full backup is often more laborious
|
||||
than incremental ones, since there is more data to write to the
|
||||
tape and a full backup might not fit onto one tape (or floppy).
|
||||
Restoring from incremental backups can be many times more work
|
||||
than from a full one. Restoration can be optimized so that
|
||||
you always back up everything since the previous full backup;
|
||||
this way, backups are a bit more work, but there should never
|
||||
be a need to restore more than a full backup and an incremental
|
||||
backup. </para>
|
||||
|
||||
<para> If you want to make backups every day and have six
|
||||
tapes, you could use tape 1 for the first full backup (say, on
|
||||
a Friday), and tapes 2 to 5 for the incremental backups (Monday
|
||||
through Thursday). Then you make a new full backup on tape 6
|
||||
(second Friday), and start doing incremental ones with tapes 2
|
||||
to 5 again. You don't want to overwrite tape 1 until you've got
|
||||
a new full backup, lest something happens while you're making
|
||||
the full backup. After you've made a full backup to tape 6,
|
||||
you want to keep tape 1 somewhere else, so that when your other
|
||||
backup tapes are destroyed in the fire, you still have at least
|
||||
something left. When you need to make the next full backup,
|
||||
you fetch tape 1 and leave tape 6 in its place. </para>
|
||||
|
||||
<para> If you have more than six tapes, you can use the extra
|
||||
ones for full backups. Each time you make a full backup, you
|
||||
use the oldest tape. This way you can have full backups from
|
||||
several previous weeks, which is good if you want to find an old,
|
||||
now deleted file, or an old version of a file. </para>
|
||||
|
||||
<sect2 id="tar-backups">
|
||||
<title>Making backups with <command>tar</command></title>
|
||||
|
||||
<para>
|
||||
A full backup can easily be made with <command>tar</command>:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar --create --file /dev/ftape
|
||||
/usr/src</userinput>
|
||||
<computeroutput>tar: Removing leading / from absolute path names in
|
||||
the archive</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
The example above uses the GNU version of <command>tar</command>
|
||||
and its long option names. The traditional version of
|
||||
<command>tar</command> only understands single character
|
||||
options. The GNU version can also handle backups that don't
|
||||
fit on one tape or floppy, and also very long paths; not all
|
||||
traditional versions can do these things. (Linux only uses
|
||||
GNU <command>tar</command>.) </para>
|
||||
|
||||
<para> If your backup doesn't fit on one tape, you need to use
|
||||
the <option>--multi-volume</option> (<option>-M</option>) option:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar -cMf /dev/fd0H1440
|
||||
/usr/src</userinput>
|
||||
<computeroutput>tar: Removing leading / from absolute path names in
|
||||
the archive
|
||||
Prepare volume #2 for /dev/fd0H1440 and hit return:</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
Note that you should format the floppies before you begin the
|
||||
backup, or else use another window or virtual terminal and do
|
||||
it when <command>tar</command> asks for a new floppy. </para>
|
||||
|
||||
<para> After you've made a backup, you should check that it is OK,
|
||||
using the <option>--compare</option> (<option>-d</option>) option:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar --compare --verbose -f
|
||||
/dev/ftape</userinput>
|
||||
<computeroutput>usr/src/
|
||||
usr/src/linux
|
||||
usr/src/linux-1.2.10-includes/
|
||||
....</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
Failing to check a backup means that you will not notice that your
|
||||
backups aren't working until after you've lost the original data.
|
||||
</para>
|
||||
|
||||
<para> An incremental backup can be done with
|
||||
<command>tar</command> using the <option>--newer</option>
|
||||
(<option>-N</option>) option:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar --create --newer '8 Sep 1995'
|
||||
--file /dev/ftape /usr/src
|
||||
--verbose</userinput>
|
||||
<computeroutput>tar: Removing leading / from absolute path names in
|
||||
the archive
|
||||
usr/src/
|
||||
usr/src/linux-1.2.10-includes/
|
||||
usr/src/linux-1.2.10-includes/include/
|
||||
usr/src/linux-1.2.10-includes/include/linux/
|
||||
usr/src/linux-1.2.10-includes/include/linux/modules/
|
||||
usr/src/linux-1.2.10-includes/include/asm-generic/
|
||||
usr/src/linux-1.2.10-includes/include/asm-i386/
|
||||
usr/src/linux-1.2.10-includes/include/asm-mips/
|
||||
usr/src/linux-1.2.10-includes/include/asm-alpha/
|
||||
usr/src/linux-1.2.10-includes/include/asm-m68k/
|
||||
usr/src/linux-1.2.10-includes/include/asm-sparc/
|
||||
usr/src/patch-1.2.11.gz</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
Unfortunately, <command>tar</command> can't notice when a file's
|
||||
inode information has changed, for example, that its permission
|
||||
bits have been changed, or when its name has been changed.
|
||||
This can be worked around using <command>find</command> and
|
||||
comparing current filesystem state with lists of files that have
|
||||
been previously backed up. Scripts and programs for doing this
|
||||
can be found on Linux ftp sites. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="tar-restore">
|
||||
<title>Restoring files with <command>tar</command></title>
|
||||
|
||||
<para> The <option>--extract</option> (<option>-x</option>)
|
||||
option for <command>tar</command> extracts files:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar --extract --same-permissions
|
||||
--verbose --file
|
||||
/dev/fd0H1440</userinput>
|
||||
<computeroutput>usr/src/
|
||||
usr/src/linux
|
||||
usr/src/linux-1.2.10-includes/
|
||||
usr/src/linux-1.2.10-includes/include/
|
||||
usr/src/linux-1.2.10-includes/include/linux/
|
||||
usr/src/linux-1.2.10-includes/include/linux/hdreg.h
|
||||
usr/src/linux-1.2.10-includes/include/linux/kernel.h
|
||||
...</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
You also extract only specific files or directories (which
|
||||
includes all their files and subdirectories) by naming on the
|
||||
command line:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar xpvf /dev/fd0H1440
|
||||
usr/src/linux-1.2.10-includes/include/linux/hdreg.h</userinput>
|
||||
<computeroutput>usr/src/linux-1.2.10-includes/include/linux/hdreg.h</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
Use the <option>--list</option> (<option>-t</option>) option,
|
||||
if you just want to see what files are on a backup volume:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>tar --list --file
|
||||
/dev/fd0H1440</userinput>
|
||||
<computeroutput>usr/src/
|
||||
usr/src/linux
|
||||
usr/src/linux-1.2.10-includes/
|
||||
usr/src/linux-1.2.10-includes/include/
|
||||
usr/src/linux-1.2.10-includes/include/linux/
|
||||
usr/src/linux-1.2.10-includes/include/linux/hdreg.h
|
||||
usr/src/linux-1.2.10-includes/include/linux/kernel.h
|
||||
...</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
Note that <command>tar</command> always reads the backup volume
|
||||
sequentially, so for large volumes it is rather slow. It is not
|
||||
possible, however, to use random access database techniques when
|
||||
using a tape drive or some other sequential medium. </para>
|
||||
|
||||
<para> <command>tar</command> doesn't handle deleted files
|
||||
properly. If you need to restore a filesystem from a full and
|
||||
an incremental backup, and you have deleted a file between
|
||||
the two backups, it will exist again after you have done the
|
||||
restore. This can be a big problem, if the file has sensitive
|
||||
data that should no longer be available. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="multi-level-backups">
|
||||
<title>Multilevel backups</title>
|
||||
|
||||
<para> The simple backup method outlined in the previous section
|
||||
is often quite adequate for personal use or small sites. For more
|
||||
heavy duty use, multilevel backups are more appropriate. </para>
|
||||
|
||||
<para> The simple method has two backup levels: full and
|
||||
incremental backups. This can be generalized to any number of
|
||||
levels. A full backup would be level 0, and the different levels
|
||||
of incremental backups levels 1, 2, 3, etc. At each incremental
|
||||
backup level you back up everything that has changed since the
|
||||
previous backup at the same or a previous level. </para>
|
||||
|
||||
<para> The purpose for doing this is that it allows a longer
|
||||
<glossterm>backup history</glossterm> cheaply. In the example in
|
||||
the previous section, the backup history went back to the previous
|
||||
full backup. This could be extended by having more tapes, but
|
||||
only a week per new tape, which might be too expensive. A longer
|
||||
backup history is useful, since deleted or corrupted files are
|
||||
often not noticed for a long time. Even a version of a file that
|
||||
is not very up to date is better than no file at all. </para>
|
||||
|
||||
<para> With multiple levels the backup history can be extended
|
||||
more cheaply. For example, if we buy ten tapes, we could use
|
||||
tapes 1 and 2 for monthly backups (first Friday each month),
|
||||
tapes 3 to 6 for weekly backups (other Fridays; note that there
|
||||
can be five Fridays in one month, so we need four more tapes),
|
||||
and tapes 7 to 10 for daily backups (Monday to Thursday).
|
||||
With only four more tapes, we've been able to extend the backup
|
||||
history from two weeks (after all daily tapes have been used)
|
||||
to two months. It is true that we can't restore every version
|
||||
of each file during those two months, but what we can restore
|
||||
is often good enough. </para>
|
||||
|
||||
<para><xref linkend="backup-history-timeline"> shows which backup
|
||||
level is used each day, and which backups can be restored from
|
||||
at the end of the month. </para>
|
||||
|
||||
<figure id="backup-history-timeline" float="1">
|
||||
<title>A sample multilevel backup schedule.</title>
|
||||
<graphic fileref="backup-timeline.png">
|
||||
</figure>
|
||||
|
||||
<para> Backup levels can also be used to keep filesystem
|
||||
restoration time to a minimum. If you have many incremental
|
||||
backups with monotonously growing level numbers, you need to
|
||||
restore all of them if you need to rebuild the whole filesystem.
|
||||
Instead you can use level numbers that aren't monotonous, and
|
||||
keep down the number of backups to restore. </para>
|
||||
|
||||
<para> To minimize the number of tapes needed to restore, you
|
||||
could use a smaller level for each incremental tape. However,
|
||||
then the time to make the backups increases (each backup copies
|
||||
everything since the previous full backup). A better scheme is
|
||||
suggested by the <command>dump</command> manual page and described
|
||||
by the table XX (efficient-backup-levels). Use the following
|
||||
succession of backup levels: 3, 2, 5, 4, 7, 6, 9, 8, 9, etc.
|
||||
This keeps both the backup and restore times low. The most you
|
||||
have to backup is two day's worth of work. The number of tapes
|
||||
for a restore depends on how long you keep between full backups,
|
||||
but it is less than in the simple schemes. </para>
|
||||
|
||||
<table id="efficient-backup-levels">
|
||||
<title>Efficient backup scheme using many backup levels</title>
|
||||
<tgroup cols=4>
|
||||
<thead>
|
||||
<row><entry>Tape</entry> <entry>Level</entry> <entry>Backup
|
||||
(days)</entry> <entry>Restore
|
||||
tapes</entry></row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row><entry>1</entry> <entry>0</entry> <entry>n/a</entry>
|
||||
<entry>1</entry></row>
|
||||
<row><entry>2</entry> <entry>3</entry> <entry>1</entry> <entry>1,
|
||||
2</entry></row>
|
||||
<row><entry>3</entry> <entry>2</entry> <entry>2</entry> <entry>1,
|
||||
3</entry></row>
|
||||
<row><entry>4</entry> <entry>5</entry> <entry>1</entry> <entry>1, 2,
|
||||
4</entry></row>
|
||||
<row><entry>5</entry> <entry>4</entry> <entry>2</entry> <entry>1, 2,
|
||||
5</entry></row>
|
||||
<row><entry>6</entry> <entry>7</entry> <entry>1</entry> <entry>1, 2,
|
||||
5, 6</entry></row>
|
||||
<row><entry>7</entry> <entry>6</entry> <entry>2</entry> <entry>1, 2,
|
||||
5, 7</entry></row>
|
||||
<row><entry>8</entry> <entry>9</entry> <entry>1</entry> <entry>1, 2,
|
||||
5, 7, 8</entry></row>
|
||||
<row><entry>9</entry> <entry>8</entry> <entry>2</entry> <entry>1, 2,
|
||||
5, 7, 9</entry></row>
|
||||
<row><entry>10</entry> <entry>9</entry> <entry>1</entry> <entry>1, 2,
|
||||
5, 7, 9, 10</entry></row>
|
||||
<row><entry>11</entry> <entry>9</entry> <entry>1</entry> <entry>1, 2,
|
||||
5, 7, 9, 10,
|
||||
11</entry></row>
|
||||
<row><entry>...</entry> <entry>9</entry> <entry>1</entry> <entry>1,
|
||||
2, 5, 7, 9, 10, 11,
|
||||
...</entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para> A fancy scheme can reduce the amount of labor needed, but
|
||||
it does mean there are more things to keep track of. You must
|
||||
decide if it is worth it. </para>
|
||||
|
||||
<para> <command>dump</command> has built-in support for backup
|
||||
levels. For <command>tar</command> and <command>cpio</command>
|
||||
it must be implemented with shell scripts. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="what-to-backup">
|
||||
<title>What to back up</title>
|
||||
|
||||
<para> You want to back up as much as possible. The major
|
||||
exception is software that can be easily reinstalled,
|
||||
but even they may have configuration files that it is
|
||||
important to back up, lest you need to do all the work to
|
||||
configure them all over again. Another major exception is
|
||||
the <filename>/proc</filename> filesystem; since that only
|
||||
contains data that the kernel always generates automatically,
|
||||
it is never a good idea to back it up. Especially the
|
||||
<filename>/proc/kcore</filename> file is unnecessary, since it
|
||||
is just an image of your current physical memory; it's pretty
|
||||
large as well. </para>
|
||||
|
||||
<para> Gray areas include the news spool, log files, and many
|
||||
other things in <filename>/var</filename>. You must decide what
|
||||
you consider important. </para>
|
||||
|
||||
<para> The obvious things to back up are user files
|
||||
(<filename>/home</filename>) and system configuration files
|
||||
(<filename>/etc</filename>, but possibly other things scattered
|
||||
all over the filesystem). </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="compressed-backups">
|
||||
<title>Compressed backups</title>
|
||||
|
||||
<para> Backups take a lot of space, which can cost quite
|
||||
a lot of money. To reduce the space needed, the backups
|
||||
can be compressed. There are several ways of doing this.
|
||||
Some programs have support for for compression built in; for
|
||||
example, the <option>--gzip</option> (<option>-z</option>)
|
||||
option for GNU <command>tar</command> pipes the whole backup
|
||||
through the <command>gzip</command> compression program, before
|
||||
writing it to the backup medium. </para>
|
||||
|
||||
<para> Unfortunately, compressed backups can cause trouble.
|
||||
Due to the nature of how compression works, if a single bit is
|
||||
wrong, all the rest of the compressed data will be unusable.
|
||||
Some backup programs have some built in error correction, but no
|
||||
method can handle a large number of errors. This means that if
|
||||
the backup is compressed the way GNU <command>tar</command> does
|
||||
it, with the whole output compressed as a unit, a single error
|
||||
makes all the rest of the backup lost. Backups must be reliable,
|
||||
and this method of compression is not a good idea. </para>
|
||||
|
||||
<para> An alternative way is to compress each file separately.
|
||||
This still means that the one file is lost, but all other files
|
||||
are unharmed. The lost file would have been corrupted anyway,
|
||||
so this situation is not much worse than not using compression
|
||||
at all. The <command>afio</command> program (a variant of
|
||||
<command>cpio</command>) can do this. </para>
|
||||
|
||||
<para>
|
||||
Compression takes some time, which may make the backup program
|
||||
unable to write data fast enough for a tape drive.
|
||||
This can be avoided by buffering the output (either internally, if
|
||||
the backup program if smart enough, or by using another program),
|
||||
but even that might not work well enough. This should only be
|
||||
a problem on slow computers. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,11 @@
|
|||
<chapter id="task-automation">
|
||||
<title>Task Automation --To Be Added</title>
|
||||
|
||||
<blockquote><para><quote>Never put off until tomorrow what you can do
|
||||
the day after tomorrow.<quote>Mark Twain</para><blockquote>
|
||||
|
||||
<para>Basic discussion on scripting, cron & at - refer to
|
||||
other HOWTO's for details. Discuss non-crontab cron jobs
|
||||
such at those in the /etc directory.</para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,528 @@
|
|||
<chapter id="keeping-time">
|
||||
<title>Keeping Time</title>
|
||||
|
||||
<blockquote><para><quote>Time is an illusion. Lunchtime double
|
||||
so.</quote> (Douglas Adams.)</para></blockquote>
|
||||
|
||||
<para> This chapter explains how a Linux system keeps time,
|
||||
and what you need to do to avoid causing trouble. Usually,
|
||||
you don't need to do anything about time, but it is good to
|
||||
understand it.</para>
|
||||
|
||||
<sect1 id="localtime">
|
||||
<title>The concept of localtime</title>
|
||||
|
||||
<para> Time measurement is based on mostly regular natural
|
||||
phenomena, such as alternating light and dark periods caused
|
||||
by the rotation of the planet. The total time taken by two
|
||||
successive periods is constant, but the lengths of the light
|
||||
and dark period vary. One simple constant is noon. </para>
|
||||
|
||||
<para> Noon is the time of the day when the Sun is at its
|
||||
highest position. Since (according to recent research) the Earth is
|
||||
round, noon happens at different times in different places. This
|
||||
leads to the concept of <glossterm>local time</glossterm>. Humans
|
||||
measure time in many units, most of which are tied to natural
|
||||
phenomena like noon. As long as you stay in the same place,
|
||||
it doesn't matter that local times differ. </para>
|
||||
|
||||
<para> As soon as you need to communicate with distant places,
|
||||
you'll notice the need for a common time. In modern times,
|
||||
most of the places in the world communicate with most other
|
||||
places in the world, so a global standard for measuring time
|
||||
has been defined. This time is called <glossterm>universal
|
||||
time</glossterm> (UT or UTC, formerly known as Greenwich Mean Time
|
||||
or GMT, since it used to be local time in Greenwich, England).
|
||||
When people with different local times need to communicate,
|
||||
they can express times in universal time, so that there is no
|
||||
confusion about when things should happen. </para>
|
||||
|
||||
<para> Each local time is called a time zone. While geography
|
||||
would allow all places that have noon at the same time have the
|
||||
same time zone, politics makes it difficult. For various reasons,
|
||||
many countries use <glossterm>daylight savings time</glossterm>,
|
||||
that is, they move their clocks to have more natural light
|
||||
while they work, and then move the clocks back during winter.
|
||||
Other countries do not do this. Those that do, do not agree when
|
||||
the clocks should be moved, and they change the rules from year
|
||||
to year. This makes time zone conversions definitely non-trivial.
|
||||
</para>
|
||||
|
||||
<para> Time zones are best named by the location or by telling
|
||||
the difference between local and universal time. In the US
|
||||
and some other countries, the local time zones have a name and
|
||||
a three letter abbreviation. The abbreviations are not unique,
|
||||
however, and should not be used unless the country is also named.
|
||||
It is better to talk about the local time in, say, Helsinki,
|
||||
than about East European time, since not all countries in Eastern
|
||||
Europe follow the same rules. </para>
|
||||
|
||||
<para> Linux has a time zone package that knows about all
|
||||
existing time zones, and that can easily be updated when the
|
||||
rules change. All the system administrator needs to do is to
|
||||
select the appropriate time zone. Also, each user can set his
|
||||
own time zone; this is important since many people work with
|
||||
computers in different countries over the Internet. When the
|
||||
rules for daylight savings time change in your local time zone,
|
||||
make sure you'll upgrade at least that part of your Linux system.
|
||||
Other than setting the system time zone and upgrading the time
|
||||
zone data files, there is little need to bother about time.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="hw-sw-clocks">
|
||||
<title>The hardware and software clocks</title>
|
||||
|
||||
<para> A personal computer has a battery driven hardware clock.
|
||||
The battery ensures that the clock will work even if the rest of
|
||||
the computer is without electricity. The hardware clock can be
|
||||
set from the BIOS setup screen or from whatever operating system
|
||||
is running. </para>
|
||||
|
||||
<para> The Linux kernel keeps track of time independently from
|
||||
the hardware clock. During the boot, Linux sets its own clock
|
||||
to the same time as the hardware clock. After this, both clocks
|
||||
run independently. Linux maintains its own clock because looking
|
||||
at the hardware is slow and complicated. </para>
|
||||
|
||||
<para> The kernel clock always shows universal time. This way,
|
||||
the kernel does not need to know about time zones at all. The
|
||||
simplicity results in higher reliability and makes it easier
|
||||
to update the time zone information. Each process handles time
|
||||
zone conversions itself (using standard tools that are part of
|
||||
the time zone package). </para>
|
||||
|
||||
<para> The hardware clock can be in local time or in universal
|
||||
time. It is usually better to have it in universal time,
|
||||
because then you don't need to change the hardware clock when
|
||||
daylight savings time begins or ends (UTC does not have DST).
|
||||
Unfortunately, some PC operating systems, including MS-DOS,
|
||||
Windows, and OS/2, assume the hardware clock shows local time.
|
||||
Linux can handle either, but if the hardware clock shows local
|
||||
time, then it must be modified when daylight savings time begins
|
||||
or ends (otherwise it wouldn't show local time). </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="showing-setting-time">
|
||||
<title>Showing and setting time</title>
|
||||
|
||||
<para> In Linux, the system time zone is determined
|
||||
by the symbolic link <filename>/etc/localtime</filename>.
|
||||
This link points to a time zone data file that describes
|
||||
the local time zone. The time zone data files are located at
|
||||
either <filename>/usr/lib/zoneinfo</filename> or
|
||||
<filename>/usr/share/zoneinfo</filename> depending on what distribution
|
||||
of Linux you use.</para>
|
||||
|
||||
<para> For example, on a SuSE system located in New Jersey the
|
||||
<filename>/etc/localtime</filename> link would point to
|
||||
<filename>/usr/share/zoneinfo/US/Eastern</filename>. On a Debian system
|
||||
the <filename>/etc/localtime</filename> link would point to
|
||||
<filename>/usr/lib/zoneinfo/US/Eastern</filename>.</para>
|
||||
|
||||
<para> If you fail to find the <filename>zoneinfo</filename>
|
||||
directory in either the <filename>/usr/lib</filename> or
|
||||
<filename>/usr/share</filename> directories, either do a
|
||||
<command>find /usr -print | grep zoneinfo</command> or consult
|
||||
your distribution's documentation.
|
||||
</para>
|
||||
|
||||
<para> What happens when you have a users located in a different
|
||||
timezone? A user can change his private time zone by setting the
|
||||
TZ environment variable. If it is unset, the system time zone
|
||||
is assumed. The syntax of the TZ variable is described in the
|
||||
<function>tzset</function> manual page. </para>
|
||||
|
||||
<para>
|
||||
The <command>date</command> command shows the current date and
|
||||
time.
|
||||
|
||||
For example:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>date</userinput>
|
||||
<computeroutput>Sun Jul 14 21:53:41 EET DST 1996</computeroutput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
That time is Sunday, 14th of July, 1996, at about ten before
|
||||
ten at the evening, in the time zone called ``EET DST''
|
||||
(which might be East European Daylight Savings Time).
|
||||
<command>date</command> can also show the universal time:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>date -u</userinput>
|
||||
<computeroutput>Sun Jul 14 18:53:42 UTC 1996</computeroutput>
|
||||
<prompt>$</prompt>
|
||||
</screen>
|
||||
|
||||
<command>date</command> is also used to set the kernel's software
|
||||
clock:
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>date 07142157</userinput>
|
||||
<computeroutput>Sun Jul 14 21:57:00 EET DST 1996</computeroutput>
|
||||
<prompt>#</prompt> <userinput>date</userinput>
|
||||
<computeroutput>Sun Jul 14 21:57:02 EET DST 1996</computeroutput>
|
||||
<prompt>#</prompt>
|
||||
</screen>
|
||||
|
||||
See the <command>date</command> manual page for more details;
|
||||
the syntax is a bit arcane. Only root can set the time.
|
||||
While each user can have his own time zone, the clock is the
|
||||
same for everyone. </para>
|
||||
|
||||
<para>Beware of the <command>time</command> command. This is not
|
||||
used to get the system time. Instead it's used to time how long
|
||||
something takes. Refer the the time man page.</para>
|
||||
|
||||
<para> <command>date</command> only shows or sets the software
|
||||
clock. The <command>clock</command> commands synchronizes
|
||||
the hardware and software clocks. It is used when the system
|
||||
boots, to read the hardware clock and set the software clock.
|
||||
If you need to set both clocks, you first set the software clock
|
||||
with <command>date</command>, and then the hardware clock with
|
||||
<command>clock -w</command>. </para>
|
||||
|
||||
<para> The <option>-u</option> option to <command>clock</command>
|
||||
tells it that the hardware clock is in universal time.
|
||||
You <emphasis>must</emphasis> use the <option>-u</option>
|
||||
option correctly. If you don't, your computer will be quite
|
||||
confused about what the time is. </para>
|
||||
|
||||
<para> The clocks should be changed with care. Many parts of a
|
||||
Unix system require the clocks to work correctly. For example,
|
||||
the <command>cron</command> daemon runs commands periodically.
|
||||
If you change the clock, it can be confused of whether
|
||||
it needs to run the commands or not. On one early Unix
|
||||
system, someone set the clock twenty years into the future,
|
||||
and <command>cron</command> wanted to run all the periodic
|
||||
commands for twenty years all at once. Current versions of
|
||||
<command>cron</command> can handle this correctly, but you should
|
||||
still be careful. Big jumps or backward jumps are more dangerous
|
||||
than smaller or forward ones. </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="clock-wrong">
|
||||
<title>When the clock is wrong</title>
|
||||
|
||||
<para> The Linux software clock is not always accurate. It is
|
||||
kept running by a periodic <glossterm>timer interrupt</glossterm>
|
||||
generated by PC hardware. If the system has too many processes
|
||||
running, it may take too long to service the timer interrupt, and
|
||||
the software clock starts slipping behind. The hardware clock
|
||||
runs independently and is usually more accurate. If you boot
|
||||
your computer often (as is the case for most systems that aren't
|
||||
servers), it will usually keep fairly accurate time. </para>
|
||||
|
||||
<para> If you need to adjust the hardware clock, it is usually
|
||||
simplest to reboot, go into the BIOS setup screen, and do it
|
||||
from there. This avoids all trouble that changing system time
|
||||
might cause. If doing it via BIOS is not an option, set the new
|
||||
time with <command>date</command> and <command>clock</command>
|
||||
(in that order), but be prepared to reboot, if some part of the
|
||||
system starts acting funny. </para>
|
||||
|
||||
<para> Another method would be to use either <command>hwclock -w</command>
|
||||
or <command>hwclock --systohc</command> to sync the hardware clock
|
||||
to the software clock. If you want to sync your software clock to your
|
||||
hardware clock then you would use <command>hwclock -s</command> or
|
||||
<command>hwclock --hwtosys</command>. For more information on this
|
||||
command read <command>man hwclock</command>.</para>
|
||||
|
||||
<!-- Commented out to add NTP info.
|
||||
<para> A networked computer (even if just over the modem) can
|
||||
check its own clock automatically, by comparing it to some other
|
||||
computer's time. If the other computer is known to keep very
|
||||
accurate time, then both computers will keep accurate time.
|
||||
This can be done by using the <command>rdate</command> and
|
||||
<command>netdate</command> commands. Both check the time of a
|
||||
remote computer (<command>netdate</command> can handle several
|
||||
remote computers), and set the local computer's time to that.
|
||||
By running one these commands regularly, your computer will keep
|
||||
as accurate time as the remote computer. </para>
|
||||
|
||||
<para> XXX say something intelligent about NTP </para> -->
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ntp">
|
||||
<title>NTP - Network Time Protocol</title>
|
||||
|
||||
<para> A networked computer (even if just over a modem) can
|
||||
check its own clock automatically by comparing it to the time
|
||||
on another computer known to keep accurate time. Network Time
|
||||
Protocol (or NTP) does exactly that. It is a method of verifying
|
||||
and correcting your computer's time by synchronizing it with a
|
||||
another system. With NTP your system's time can be maintained
|
||||
to within milliseconds of Coordinated Universal Time. Visit
|
||||
<ulink url="http://www.time.gov/about.html/">
|
||||
http://www.time.gov/about.html</ulink> for more info.
|
||||
</para>
|
||||
|
||||
<para> For more casual Linux users, this is just a nice luxury.
|
||||
At my home all our clocks are set based upon what my Linux system
|
||||
says the time is. For larger organizations this "luxury" can
|
||||
become essential. Being able to search log files for events based
|
||||
upon time can make life a lot easier and take a lot of the "guess work"
|
||||
out of debugging.
|
||||
</para>
|
||||
|
||||
|
||||
<para> Another example of how important NTP can be is with a SAN.
|
||||
Some SAN's require NTP be configured and running properly to allow
|
||||
for proper synchronization over filesystem usage, and proper
|
||||
timestamp control. Some SANs (and some applications) can become
|
||||
confused when dealing with files that have timestamps that are in
|
||||
the future.
|
||||
</para>
|
||||
|
||||
<para> Most Linux distributions come with a NTP package of some kind,
|
||||
either a .deb or .rpm package. You can use that to install NTP, or you
|
||||
can download the source files from <ulink url="http://www.ntp.org/downloads.html">
|
||||
http://www.ntp.org/downloads.html</ulink> and compile it yourself. Either way,
|
||||
the basic configuration is the same.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basic-ntp-config">
|
||||
<title>Basic NTP configuration</title>
|
||||
<para>The NTP program is configured using either the
|
||||
<filename>/etc/ntp.conf </filename> or <filename>/etc/xntp.conf</filename>
|
||||
file depending on what distribution of Linux you have. I won't go
|
||||
into too much detail on how to configure NTP. Instead I'll just
|
||||
cover the basics.</para>
|
||||
|
||||
<para>An example of a basic ntp.conf file would look like:
|
||||
|
||||
<screen>
|
||||
<computeroutput># --- GENERAL CONFIGURATION ---
|
||||
server aaa.bbb.ccc.ddd
|
||||
server 127.127.1.0
|
||||
fudge 127.127.1.0 stratum 10
|
||||
|
||||
# Drift file.
|
||||
|
||||
driftfile /etc/ntp/drift
|
||||
</computeroutput>
|
||||
</para>
|
||||
|
||||
<para>The most basic ntp.conf file will simply list 2 servers, one
|
||||
that it wishes to synchronize with, and a pseudo IP address for
|
||||
itself (in this case 127.127.1.0). The pseudo IP is used in case of
|
||||
network problems or if the remote NTP server goes down. NTP will
|
||||
synchronize against itself until the it can start synchronizing with
|
||||
the remote server again. It is recommended that you list at
|
||||
least 2 remote servers that you can synchronize against. One will
|
||||
act as a primary server and the other as a backup.</para>
|
||||
|
||||
<para>You should also list a location for a drift file. Over time
|
||||
NTP will "learn" the system clock's error rate and automatically
|
||||
adjust for it.</para>
|
||||
|
||||
<para>The restrict option can be used to provide better control and
|
||||
security over what NTP can do, and who can effect it. For example:
|
||||
|
||||
<screen>
|
||||
<computeroutput># Prohibit general access to this service.
|
||||
restrict default ignore
|
||||
|
||||
# Permit systems on this network to synchronize with this
|
||||
# time service. But not modify our time.
|
||||
restrict aaa.bbb.ccc.ddd nomodify
|
||||
|
||||
# Allow the following unrestricted access to ntpd
|
||||
|
||||
restrict aaa.bbb.ccc.ddd
|
||||
restrict 127.0.0.1
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
It is advised that you wait until you have NTP working properly before
|
||||
adding the restrict option. You can accidental restrict yourself from
|
||||
synchronizing and waste time debugging why.
|
||||
</para>
|
||||
|
||||
<para>NTP slowly corrects your systems time. Be patient! A simple test
|
||||
is to change your system clock by 10 minutes before you go to bed and then
|
||||
check it when you get up. The time should be correct.</para>
|
||||
|
||||
<para>Many people get the idea that instead of running the NTP
|
||||
daemon, they should just setup a <command>cron</command> job
|
||||
job to periodically run the <command>ntpdate</command> command.
|
||||
There are 2 main disadvantages of using using this method.</para>
|
||||
|
||||
<para>The first is that <command>ntpdate</command> does a "brute force"
|
||||
method of changing the time. So if your computer's time is off my 5
|
||||
minutes, it immediately corrects it. In some environments, this can
|
||||
cause problems if time drastically changes. For example, if you are
|
||||
using time sensitive security software, you can inadvertently kill
|
||||
someones access. The NTP daemon slowly changes the time to avoid
|
||||
causing this kind of disruption.</para>
|
||||
|
||||
<para>The other reason is that the NTP daemon can be configured to
|
||||
try to learn your systems <glossterm>time drift</glossterm> and
|
||||
then automatically adjust for it.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ntp-toolkit">
|
||||
<title>NTP Toolkit</title>
|
||||
<para>There are a number of utilities available to check if
|
||||
NTP is doing it's job. The <command>ntpq -p</command> command
|
||||
will print out your system's current time status.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntpq -p</userinput>
|
||||
<computeroutput> remote refid st t when poll reach delay offset jitter
|
||||
==============================================================================
|
||||
*cudns.cit.corne ntp0.usno.navy. 2 u 832 1024 377 43.208 0.361 2.646
|
||||
LOCAL(0) LOCAL(0) 10 l 13 64 377 0.000 0.000 0.008
|
||||
</computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para> The <command>ntpdc -c loopinfo</command> will display
|
||||
how far off the system time is in seconds, based upon the last time
|
||||
the remote server was contacted.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntpdc -c loopinfo</userinput>
|
||||
<computeroutput>offset: -0.004479 s
|
||||
frequency: 133.625 ppm
|
||||
poll adjust: 30
|
||||
watchdog timer: 404 s
|
||||
</computeroutput>
|
||||
</para>
|
||||
|
||||
<para><command>ntpdc -c kerninfo</command> will display
|
||||
the current remaining correction.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntpdc -c kerninfo</userinput>
|
||||
<computeroutput>pll offset: -0.003917 s
|
||||
pll frequency: 133.625 ppm
|
||||
maximum error: 0.391414 s
|
||||
estimated error: 0.003676 s
|
||||
status: 0001 pll
|
||||
pll time constant: 6
|
||||
precision: 1e-06 s
|
||||
frequency tolerance: 512 ppm
|
||||
pps frequency: 0.000 ppm
|
||||
pps stability: 512.000 ppm
|
||||
pps jitter: 0.0002 s
|
||||
calibration interval: 4 s
|
||||
calibration cycles: 0
|
||||
jitter exceeded: 0
|
||||
stability exceeded: 0
|
||||
calibration errors: 0
|
||||
</computeroutput>
|
||||
</para>
|
||||
|
||||
<para> A slightly more different version of
|
||||
<command>ntpdc -c kerninfo</command> is <command>ntptime</command>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntptime</userinput>
|
||||
<computeroutput>ntp_gettime() returns code 0 (OK)
|
||||
time c35e2cc7.879ba000 Thu, Nov 13 2003 11:16:07.529, (.529718),
|
||||
maximum error 425206 us, estimated error 3676 us
|
||||
ntp_adjtime() returns code 0 (OK)
|
||||
modes 0x0 (),
|
||||
offset -3854.000 us, frequency 133.625 ppm, interval 4 s,
|
||||
maximum error 425206 us, estimated error 3676 us,
|
||||
status 0x1 (PLL),
|
||||
time constant 6, precision 1.000 us, tolerance 512 ppm,
|
||||
pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
|
||||
intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
|
||||
</computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para> Yet another way to see how well NTP is working is
|
||||
with the <command>ntpdate -d</command> command. This will
|
||||
contact an NTP server and determine the time difference
|
||||
but not change your system's time.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntpdate -d 132.236.56.250</userinput>
|
||||
<computeroutput>13 Nov 14:43:17 ntpdate[29631]: ntpdate 4.1.1c-rc1@1.836 Thu Feb 13 12:17:20 EST 2003 (1)
|
||||
transmit(132.236.56.250)
|
||||
receive(132.236.56.250)
|
||||
transmit(132.236.56.250)
|
||||
receive(132.236.56.250)
|
||||
transmit(132.236.56.250)
|
||||
receive(132.236.56.250)
|
||||
transmit(132.236.56.250)
|
||||
receive(132.236.56.250)
|
||||
transmit(132.236.56.250)
|
||||
server 132.236.56.250, port 123
|
||||
stratum 2, precision -17, leap 00, trust 000
|
||||
refid [192.5.41.209], delay 0.06372, dispersion 0.00044
|
||||
transmitted 4, in filter 4
|
||||
reference time: c35e5998.4a46cfc8 Thu, Nov 13 2003 14:27:20.290
|
||||
originate timestamp: c35e5d55.d69a6f82 Thu, Nov 13 2003 14:43:17.838
|
||||
transmit timestamp: c35e5d55.d16fc9bc Thu, Nov 13 2003 14:43:17.818
|
||||
filter delay: 0.06522 0.06372 0.06442 0.06442
|
||||
0.00000 0.00000 0.00000 0.00000
|
||||
filter offset: 0.000036 0.001020 0.000527 0.000684
|
||||
0.000000 0.000000 0.000000 0.000000
|
||||
delay 0.06372, dispersion 0.00044
|
||||
offset 0.001020
|
||||
|
||||
13 Nov 14:43:17 ntpdate[29631]: adjust time server 132.236.56.250 offset 0.001020 sec
|
||||
</computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para> If you want actually watch the system
|
||||
synchronize you can use <command>ntptrace</command>.
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntptrace 132.236.56.250</userinput>
|
||||
<computeroutput>cudns.cit.cornell.edu: stratum 2, offset -0.003278, synch distance 0.02779
|
||||
truetime.ntp.com: stratum 1, offset -0.014363, synch distance 0.00000, refid 'ACTS'</computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
<!-- for reference
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput></userinput>
|
||||
<computeroutput></computeroutput>
|
||||
</screen>
|
||||
-->
|
||||
|
||||
<para>If you need your system time synchronized immediately
|
||||
you can use the <command>ntpdate remote-servername</command>
|
||||
to force a synchronization. No waiting!
|
||||
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>ntpdate 132.236.56.250</userinput>
|
||||
13 Nov 14:56:28 ntpdate[29676]: adjust time server 132.236.56.250 offset -0.003151 sec
|
||||
<computeroutput></computeroutput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ntp-servers">
|
||||
<title>Some known NTP servers</title>
|
||||
<para>A list of public NTP servers can be obtained from:
|
||||
<ulink url="http://www.eecis.udel.edu/~mills/ntp/servers.html/">
|
||||
http://www.eecis.udel.edu/~mills/ntp/servers.html</ulink>. Please read
|
||||
the usage information on the page prior so using a server. Not all
|
||||
servers have the available bandwidth to allow a large number of systems
|
||||
synchronizing against them. Therefore it is a good idea to contact
|
||||
a system's administrator prior to using his/her server for NTP services.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ntp-links">
|
||||
<title>NTP Links</title>
|
||||
<para>More detailed information on NTP can be obtained from the
|
||||
NTP homepage:<ulink url="http://www.ntp.org/">http://www.ntp.org</ulink>.
|
||||
</para>
|
||||
|
||||
<para>Or from <ulink url="http://www.ntp.org/ntpfaq/NTP-a-faq.htm">
|
||||
http://www.ntp.org/ntpfaq/NTP-a-faq.htm</ulink></para>
|
||||
</sect1>
|
||||
</chapter>
|
|
@ -0,0 +1,4 @@
|
|||
<chapter id="system-logs">
|
||||
<title>System Logs --To Be Added</title>
|
||||
<para>Log info, rotation, monitoring, etc..</para>
|
||||
</chapter>
|
|
@ -0,0 +1,10 @@
|
|||
<chapter id="system-updates">
|
||||
<title>System Updates --To Be Added</title>
|
||||
|
||||
<blockquote><para><quote>A lie gets halfway around the world before
|
||||
the truth has a chance to get its pants on.</quote> Winston Churchill
|
||||
</para></blockquote>
|
||||
|
||||
<para>Discussion on how and when to update the system.</para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,11 @@
|
|||
<chapter id="kernel">
|
||||
<title>The Linux Kernel Source</title>
|
||||
|
||||
<blockquote><para><quote>Black holes are where God divided by zero.
|
||||
</quote> Steven Wright</para></blockquote>
|
||||
|
||||
<para>BASIC info on the kernel source and compiling it. It will
|
||||
also provide some info on kdb debugger. Refer
|
||||
to other kernel HOWTO's for more info.</para>
|
||||
|
||||
</chapter>
|
|
@ -0,0 +1,28 @@
|
|||
<!-- Open Source Chapter. Do not release until more work has been done to
|
||||
it. The goal of this chapter will be to provide an introduction to
|
||||
the concepts of the "Open Source Community" and encourage others to
|
||||
participate in their own ways.
|
||||
<chapter id="open-source">
|
||||
<title>Open Source Software</title>
|
||||
<blockquote><para><quote>If you have an apple and I have an apple and we
|
||||
exchange these apples then you and I will still each have one apple.
|
||||
But if you have an idea and I have an idea and we exchange these
|
||||
ideas, then each of us will have two ideas.</quote> G. Bernard Shaw</para>
|
||||
</blockquote>
|
||||
|
||||
<blockquote><para><quote>The basic idea behind open source is very simple:
|
||||
When programmers can read, redistribute, and modify the source code for a
|
||||
piece of software, the software evolves. People improve it, people adapt it,
|
||||
people fix bugs. And this can happen at a speed that, if one is used to the
|
||||
slow pace of conventional software development, seems astonishing.</quote>
|
||||
Taken from the Open Source Initiative website <ulink url="www.opensource.com">
|
||||
http://www.opensource.com/</ulink></para></blockquote>
|
||||
|
||||
<para> What does it mean to be Open Source? Open Source means many things,
|
||||
but primarily it means the sharing of ideas. Creating something and
|
||||
letting the world learn from it, use it, and change it. Almost everything
|
||||
created for Linux, including applications, documentation, and the Linux
|
||||
Operating System itself are released as Open Source. Please remember to
|
||||
share what you know and learn with others, so that we all can benefit.</para>
|
||||
</chapter>
|
||||
-->
|
|
@ -0,0 +1,275 @@
|
|||
<chapter id="finding-help">
|
||||
<title>Finding Help</title>
|
||||
|
||||
<blockquote><para><quote>Help me if you can I'm feeling down. And I do
|
||||
appreciate you being 'round.</quote> - The
|
||||
Beatles</para></blockquote>
|
||||
|
||||
<para>Help is out there. You just have to know where to look. With
|
||||
Linux there are an amazing number of places you can go. There are
|
||||
mailing lists, IRC channels, web pages with public forums, and many
|
||||
other resources available. This chapter will try to help you get the
|
||||
most out of your quest for help.</para>
|
||||
|
||||
<sect1 id="newsgroups-mailling-lists">
|
||||
<title>Newsgroups and Mailing Lists</title>
|
||||
<para>
|
||||
This guide cannot teach you everything about Linux. There
|
||||
just isn't enough space. It is almost inevitable that at some point
|
||||
you will find something you need to do, that isn't covered in
|
||||
this (or any other) document at the LDP.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One of the nicest things about Linux is the large number of forums
|
||||
devoted to it. There are forums relating to almost all facets of
|
||||
Linux ranging from newbie FAQs to in depth kernel development issues.
|
||||
|
||||
To receive the most from them, there are a few things you can do.
|
||||
</para>
|
||||
|
||||
<sect2 id="right-forum">
|
||||
<title>Finding The Right Forum</title>
|
||||
<para>
|
||||
The first thing to do is to find an appropriate forum. There are many
|
||||
newsgroups and mailing lists devoted to Linux, so try to find and use
|
||||
the one which most closely matches your question. For example, there
|
||||
isn't much point in you asking a question about sendmail in a forum
|
||||
devoted to Linux kernel development. At best the people there will
|
||||
think you are stupid and you will get few responses, at worst you may
|
||||
receive lots of highly insulting replies (flames). A quick look
|
||||
through the newsgroups available finds comp.mail.sendmail, which
|
||||
looks like an appropriate place to ask a sendmail question. Your news
|
||||
client probably has a list of the newsgroups available to you, but if
|
||||
not then a full list of newsgroups is available at <ulink
|
||||
url="http://groups.google.com/groups?group=*">
|
||||
http://groups.google.com/groups?group=*</ulink>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="before-you-post">
|
||||
<title>Before You Post</title>
|
||||
<para>
|
||||
Now that you have found your appropriate forum, you may think you are
|
||||
ready to post your question. Stop. You aren't ready yet. Have you already
|
||||
looked for the answer yourself? There are a huge number of HOWTOs and
|
||||
FAQs available, if any of them relate to the thing you are having a
|
||||
problem with then <emphasis>read them first</emphasis>. Even if they
|
||||
don't contain the answer to your problem, what they will do is give you a
|
||||
better understanding of the subject area, and that understanding will
|
||||
allow you to ask a more informed and sensible question. There are also archives
|
||||
of newsgroups and mailing lists and it is entirely possible that your
|
||||
question has been asked and answered previously. <ulink
|
||||
url="http://www.google.com">http://www.google.com</ulink> or a similar
|
||||
search engine should be something you try <emphasis>before</emphasis>
|
||||
posting a question.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="writing-your-post">
|
||||
<title>Writing Your Post</title>
|
||||
<para>Okay, you have found your appropriate forum, you have read the
|
||||
relevant HOWTOs and FAQs, you have searched the web, but you still
|
||||
have not found the answer you need. Now you can start writing your post.
|
||||
It is always a good idea to make it clear that you already have read
|
||||
up on the subject by saying something like ``I have read the
|
||||
Winmodem-HOWTO and the PPP FAQ, but neither contained what I was looking for,
|
||||
searching for `Winmodem Linux PPP Setup' on google didn't return
|
||||
anything of use either''. This shows you to be someone who is willing to make
|
||||
an effort rather than a lazy idiot who requires spoonfeeding. The former
|
||||
is likely to receive help if anyone knows the answer, the latter
|
||||
is likely to meet with either stony silence or outright
|
||||
derision.</para>
|
||||
|
||||
<para>Write in clear, grammatical and correctly spelt English. This
|
||||
is incredibly important. It marks you as a precise and considered
|
||||
thinker. There are no such words as ``u'' or ``b4.'' Try to make yourself look
|
||||
like an educated and intelligent person rather than an idiot. It will
|
||||
help. I promise.</para>
|
||||
|
||||
<para>Similarly do not type in all capitals LIKE THIS. That is
|
||||
considered shouting and looks very rude.</para>
|
||||
|
||||
<para>Provide clear details stating what the problem is and what you
|
||||
have already tried to do to fix it. A question like ``My linux has stopped
|
||||
working, what can I do?'' is totally useless. Where has it stopped
|
||||
working? In what way has it stopped working? You need to be as
|
||||
precise as possible. There are limits however. Try not to include irrelevant
|
||||
information either. If you are having problems with your mail client
|
||||
it is unlikely that a dump of your kernel boot log
|
||||
(<command>dmesg</command>) would be of help.<para>
|
||||
|
||||
<para>Don't ask for replies by private email. The point of most Linux
|
||||
forums is that everybody can learn something from each other. Asking
|
||||
for private replies simply removes value from the newsgroup or mailing
|
||||
list.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="formatting-your-post">
|
||||
<title>Formatting Your Post</title>
|
||||
<para> Do not post in HTML. Many Linux users have mail clients which
|
||||
can't easily read HTML email. Whilst with some effort, they
|
||||
<emphasis>can</emphasis> read HTML email, they usually don't. If you
|
||||
send them HTML mail it often gets deleted unread. Send plain text
|
||||
emails, they will reach a wider audience that way.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="follow-up">
|
||||
<title>Follow Up</title>
|
||||
<para>After your problem has been solved, post a short followup
|
||||
explaining what the problem was and how you solved it. People will
|
||||
appreciate this as it not only gives a sense of closure about the
|
||||
problem but also helps the next time someone has a similar question. When they
|
||||
look at the archives of the newsgroup or mailing list, they will see
|
||||
you had the same problem, the discussion that followed your question and
|
||||
your final solution.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="getting-help-more-info">
|
||||
<title>More Information</title>
|
||||
<para>This short guide is simply a paraphrase
|
||||
and summary of the excellent (and more detailed) document ``How To
|
||||
Ask Questions The Smart Way'' by Eric S Raymond. <ulink
|
||||
url="http://www.catb.org/~esr/faqs/smart-questions.html">
|
||||
http://www.catb.org/~esr/faqs/smart-questions.html</ulink>. It is
|
||||
recommend that you read it before you post anything. It will help
|
||||
you formulate your question to maximize your
|
||||
chances of getting the answer you are looking for.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="irc">
|
||||
<title>IRC</title>
|
||||
<para>IRC (Internet Relay Chat) is not covered in the Eric Raymond
|
||||
document, but IRC can also be an excellent way of finding the answers you need.
|
||||
However it does require some practice in asking questions in the right way.
|
||||
Most IRC networks have busy #linux channels and if the answer to your question
|
||||
is contained in the man pages, or in the HOWTOs then expect to be told
|
||||
to go read them. The rule about typing in clear and grammatical English
|
||||
still applies.</para>
|
||||
|
||||
<para>Most of what has been said about newsgroups and mailing lists
|
||||
is still relevant for IRC, with a the following additions</para>
|
||||
|
||||
<sect2 id="colours">
|
||||
<title>Colours</title>
|
||||
<para>Do not use colours, bold, underline or strange (non ASCII)
|
||||
characters. This breaks some older terminals and is just plain ugly
|
||||
to look at. If you arrive in a channel and start spewing colour or bold
|
||||
then expect to be kicked out.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="be-polite">
|
||||
<title>Be Polite</title>
|
||||
<para>Remember you are not entitled to an answer. If you ask the
|
||||
question in the right way then you will probably get one, but you have
|
||||
no right to get one. The people in Linux IRC channels are all there
|
||||
on their own time, nobody is paying them, especially not you.</para>
|
||||
|
||||
<para>Be polite. Treat others as you would like to be
|
||||
treated. If you think people are not being polite to you then don't
|
||||
start calling them names or getting annoyed, become even politer.
|
||||
This makes them look foolish rather than dragging you down to their level.</para>
|
||||
|
||||
<para>Don't go slapping anyone with large trouts. Would you believe
|
||||
this has been done before once or twice? And that we it wasn't
|
||||
funny the first time?</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="type-properly">
|
||||
<title>Type Properly, in English</title>
|
||||
<para>Most #linux channels are English channels. Speak English whilst
|
||||
in them. Most of the larger IRC networks also have #linux channel in
|
||||
other languages, for example the French language channel might be
|
||||
called #linuxfr, the Spanish one might be #linuxes or #linuxlatino.
|
||||
If you can't find the right channel then asking in the main #linux
|
||||
channel (preferably in English) should help you find the one you are looking
|
||||
for.</para>
|
||||
|
||||
<para>Do not type like a ``1337 H4X0R d00d!!!''. Even if other people
|
||||
are. It looks silly and thereby makes you look silly. At best you
|
||||
will only look like an idiot, at worst you will be derided then kicked
|
||||
out.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="port-scanning">
|
||||
<title>Port scanning</title>
|
||||
<para>Never <emphasis>ever</emphasis> ask anyone to port scan you, or
|
||||
try to ``hack'' you. This is inviolable. There is no way of knowing that
|
||||
you are who you say you are, or that the IP that you are connected
|
||||
from belongs to you. Don't put people in the position where they have to
|
||||
say no to a request like this.</para>
|
||||
|
||||
<para><emphasis>Don't ever port scan anyone</emphasis>, even if they
|
||||
ask you to. You have no way to tell
|
||||
that they are who they say they are or that the IP they are connected
|
||||
from is their own IP. In some jurisdictions port scanning may be illegal
|
||||
and it is certainly against the Terms of Service of most ISPs.
|
||||
Most people log TCP connections, they will notice they are being
|
||||
scanned. Most people <emphasis>will</emphasis> report you to your ISP
|
||||
for this (it is trivial to find out who that is).</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="keep-in-channel">
|
||||
<title>Keep it in the Channel</title>
|
||||
<para>Don't /msg anyone unless they ask you to. It diminishes the
|
||||
usefulness of the channel and some people just prefer that
|
||||
you not do it.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Stay On Topic</title>
|
||||
<para>Stay on topic. The channel is a ``Linux'' channel, not a ``What
|
||||
Uncle Bob Got Up To Last Weekend'' channel. Even if you see other
|
||||
people being off topic, this does not mean that you should be. They
|
||||
are probably channel regulars and different conventions apply to
|
||||
them.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mass-ctcp">
|
||||
<title>CTCPs</title>
|
||||
<para>If you are thinking of mass CTCP pinging the channel or CTCP
|
||||
version or CTCP anything, then think again. It is liable to get you
|
||||
kicked out very quickly.</para>
|
||||
|
||||
<para>If you are not familiar with IRC, CTCP stands for Client To
|
||||
Client Protocol. It is a method whereby you can find out things
|
||||
about other peoples' clients. See the documentation for your IRC
|
||||
for more details.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="hacking">
|
||||
<title>Hacking, Cracking, Phreaking, Warezing</title>
|
||||
<para>Don't ask about exploits, unless you are looking for a further
|
||||
way to be unceremoniously kicked out.</para>
|
||||
|
||||
<para>Don't be in hacker/cracker/phreaker/warezer channels whilst in a
|
||||
#linux channel. For some reason the people in charge of #linux
|
||||
channels seem to hate people who like causing destruction to people's machines
|
||||
or who like to steal software. Can't imagine why.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="round-up">
|
||||
<title>Round Up</title>
|
||||
<para>Apologies if that seems like a lot of DON'Ts, and very few DOs.
|
||||
The DOs were already pretty much covered in the section on newsgroups and
|
||||
mailing lists.</para>
|
||||
|
||||
<para>Probably the best thing you can do is to go into a #linux
|
||||
channel, sit there and watch, getting the feel for a half hour before
|
||||
you say anything. This can help you to recognize the correct tone you
|
||||
should be using.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="further-reading">
|
||||
<title>Further Reading</title>
|
||||
<para>There are excellent FAQs about how to get the most of IRC #linux
|
||||
channels. Most #linux channels have an FAQ and/or set or channel
|
||||
rules. How to find this will usually be in the channel topic (which you can
|
||||
see at any time using the <command>/topic</command> command. Make sure
|
||||
you read the rules if there are any and follow them. One fairly generic
|
||||
set of rules and advice is the ``Undernet #linux FAQ'' which can be found
|
||||
at <ulink url="http://linuxfaq.quartz.net.nz">http://linuxfaq.quartz.net.nz
|
||||
</ulink>.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,568 @@
|
|||
<glossary id="glossary">
|
||||
<title>Glossary (DRAFT, but not for long hopefully)</title>
|
||||
|
||||
<blockquote><para><quote>The Librarian of the Unseen University
|
||||
had unilaterally decided to aid comprehension
|
||||
by producing an Orang-utan/Human Dictionary.
|
||||
He'd been working on it for three months.
|
||||
It wasn't easy. He'd got as far as `Oook.'</quote>
|
||||
(Terry Pratchett, ``Men At Arms'')</para></blockquote>
|
||||
|
||||
<para> This is a short list of word definitions for concepts
|
||||
relating to Linux and system administration. </para>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>CMOS RAM</glossterm>
|
||||
<glossdef><para>
|
||||
CMOS stands for "Complementary Metal Oxide Semiconductor".
|
||||
It is a complex technology, but put very simply it is a type
|
||||
of transistor which maintains its state even if computer is
|
||||
powered off. This is due to a small battery on the motherboard.
|
||||
As a result, it does not lose what was stored on it when the
|
||||
power is switched off.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>account</glossterm>
|
||||
<glossdef><para>
|
||||
A Unix system gives users <glossterm>accounts</glossterm>. It
|
||||
gives them a username and a password with which to log on to the
|
||||
account. A home directory in which to store files is usually
|
||||
provided, and permissions to access hardware and software. These
|
||||
things taken as a whole are an <glossterm>account</glossterm>.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>application program</glossterm>
|
||||
<glossdef><para>
|
||||
Software that does something useful. The results of using an
|
||||
application program is what the computer was bought for.
|
||||
See also system program, operating system.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>bad block</glossterm>
|
||||
<glossdef><para>
|
||||
A block (usually one sector on a disk) that cannot reliably hold
|
||||
data.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>bad sector</glossterm>
|
||||
<glossdef><para>
|
||||
Similar to <glossterm>bad block</glossterm> but more precise in
|
||||
the case where a block and a sector may be of differing sizes.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>boot sector</glossterm>
|
||||
<glossdef><para>
|
||||
Usually the first sector on any given partition. It contains
|
||||
a very short program (on the order of a few hundred bytes) which
|
||||
will load and start running the operating system proper.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>booting</glossterm>
|
||||
<glossdef><para>
|
||||
Everything that happens between the time the computer is
|
||||
switched on and it is ready to accept commands/input from
|
||||
the user is known as <glossterm>booting</glossterm>.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>bootstrap loader</glossterm>
|
||||
<glossdef><para>
|
||||
A very small program (usually residing in ROM) which reads
|
||||
a fixed location on a disk (eg. the <glossterm>MBR</glossterm>)
|
||||
and passes control over to it. The data residing on that fixed
|
||||
location is, in general, slightly bigger and more sophisticated,
|
||||
and it then takes responsibility for loading the actual operating
|
||||
system and passing control to it.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>cylinder</glossterm>
|
||||
<glossdef><para>
|
||||
The set of <glossterm>tracks</glossterm> on a multi-headed disk
|
||||
that may be accessed without head movement. In other words the
|
||||
tracks which are the same distance from the spindle about which
|
||||
the disk <glossterm>platters</glossterm> rotate. Placing data
|
||||
that is more likely to be accessed at the same time on the same
|
||||
cylinder can reduce the access time significantly as moving the
|
||||
read-write heads is slow compared to the speed with which the
|
||||
disks rotate.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>daemon</glossterm>
|
||||
<glossdef><para>
|
||||
A process lurking in the background, usually unnoticed, until
|
||||
something triggers it into action. For example, the
|
||||
<command>update</command>
|
||||
daemon wakes up every thirty seconds or so to flush the buffer
|
||||
cache, and the <command>sendmail</command> daemon awakes whenever
|
||||
someone sends mail.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>daylight savings time</glossterm>
|
||||
<glossdef><para>
|
||||
A time of the year during which clocks are set forward one hour.
|
||||
Widely used around the world in summer so that evenings have more
|
||||
daylight than they would otherwise.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>disk controller</glossterm>
|
||||
<glossdef><para>
|
||||
A hardware circuit which translates instructions about disk access
|
||||
from the operating system to the physical disk. This provides a
|
||||
layer of abstraction that means that an operating system does not
|
||||
need to know how to talk to the many different types of disks, but
|
||||
only needs to know about the (comparatively low) number of types of
|
||||
disk controller. Common disk controller types are IDE and SCSI.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>emergency boot floppy</glossterm>
|
||||
<glossdef><para>
|
||||
A floppy disk which can be used to boot the system even
|
||||
if the hard disk has suffered damage on its filesystem.
|
||||
Most linux distributions offer to make one of these during
|
||||
installation, this is highly recommended. If your Linux
|
||||
distribution does not offer this facility then read the
|
||||
Boot floppy HOWTO, available at the LDP (**Find URL to cite**).
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>fibre channel</glossterm>
|
||||
<glossdef><para>
|
||||
A high speed networking protocol primarily used in Storage
|
||||
Area Networks. Unlike it's name suggests, fibre channel can be
|
||||
ran over fiber optic, or copper cables.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>filesystem</glossterm>
|
||||
<glossdef><para>
|
||||
A term which is used for two purposes and which can have two
|
||||
subtly different meanings. It is either the collection of
|
||||
files and directories on a drive (whether hard drive, floppy,
|
||||
Cd-ROM, etc). Or it is the markers put onto the disk media
|
||||
which the OS uses to decide where to write files to (inodes,
|
||||
blocks, superblocks etc). The actual meaning can almost
|
||||
always be inferred from context.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>formatting</glossterm>
|
||||
<glossdef><para>
|
||||
Strictly, formatting is organizing and marking the surface of
|
||||
a disk into <glossterm>tracks</glossterm>, <glossterm>sectors
|
||||
</glossterm>, and <glossterm>cylinders</glossterm>. It is also
|
||||
sometimes (incorrectly) a term used to signify the action of
|
||||
writing a <glossterm>filesystem</glossterm> to a disk (especially
|
||||
in the MS Windows/MS DOS world).
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>fragmented</glossterm>
|
||||
<glossdef><para>
|
||||
When a file is not written to a disk in contiguous <glossterm>
|
||||
blocks</glossterm>. If there is not enough free space to write
|
||||
a full file to a disk in one continuous stream of <glossterm>
|
||||
blocks</glossterm> then the file gets split up between two or
|
||||
more parts of the disk surface. This is known as <glossterm>
|
||||
fragmenting</glossterm> and can make the time for loading a
|
||||
file longer as the disk has to seek for the rest of the file.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>full backup</glossterm>
|
||||
<glossdef><para>
|
||||
Taking a copy of the whole filesystem to a backup media
|
||||
(eg tape, floppy, or CD).
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>geometry</glossterm>
|
||||
<glossdef><para>
|
||||
How many cylinders, sectors per cylinder and heads a disk
|
||||
drive has.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>high level formatting</glossterm>
|
||||
<glossdef><para>
|
||||
An incorrect term for writing a filesystem to a disk. Often
|
||||
used in the MS Windows and MS DOS world.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>incremental backups</glossterm>
|
||||
<glossdef><para>
|
||||
A backup of what has changed in a filesystem since the last
|
||||
<glossterm>full backup</glossterm>. <glossterm>Incremental
|
||||
backups</glossterm> if used sensibly as part of a backup regime,
|
||||
can save a lot of time and effort in maintaining a backup of data.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>inode</glossterm>
|
||||
<glossdef><para>
|
||||
A data structure holding information about files in a Unix
|
||||
file system. There is an inode for each file and a file is
|
||||
uniquely identified by the file system on which it resides
|
||||
and its inode number on that system. Each inode contains
|
||||
the following information: the device where the inode resides,
|
||||
locking information, mode and type of file, the number of links
|
||||
to the file, the owner's user and group ids, the number of bytes
|
||||
in the file, access and modification times, the time the inode
|
||||
itself was last modified and the addresses of the file's
|
||||
blocks on disk. A Unix directory is an association between
|
||||
file leafnames and inode numbers. A file's inode number
|
||||
can be found using the "-i" switch to ls.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>iSCSI</glossterm>
|
||||
<glossdef><para>
|
||||
A network storage protocol that enables the sending of SCSI commands
|
||||
over a TCP/IP network. Primarily used in Storage Area Networks.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>kernel</glossterm>
|
||||
<glossdef><para>
|
||||
Part of an operating system that implements the interaction with
|
||||
hardware and the sharing of resources. See also system program.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>local time</glossterm>
|
||||
<glossdef><para>
|
||||
The official time in a local region (adjusted for location around
|
||||
the Earth); established by law or custom.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>logical partition</glossterm>
|
||||
<glossdef><para>
|
||||
A partition inside an <glossterm>extended partition</glossterm>,
|
||||
which is ``logical'' in that it does not exist in reality,
|
||||
but only inside the logical structure of the software.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>logical volume manager (LVM)</glossterm>
|
||||
<glossdef><para>
|
||||
A collection of programs that allow larger physical
|
||||
disks to be reassembled into "logical" disks that can be shrunk or
|
||||
expanded as data needs change.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>low level formatting</glossterm>
|
||||
<glossdef><para>
|
||||
Synonymous with <glossterm>formatting</glossterm> and used in
|
||||
the MS DOS world so differentiate from creating a filesystem
|
||||
which is also known as formatting sometimes.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>mail transfer agent</glossterm>
|
||||
<glossdef><para>
|
||||
(MTA) The program responsible for delivering e-mail messages.
|
||||
Upon receiving a message from a <glossterm>mail user agent
|
||||
</glossterm> or another MTA it stores it temporarily locally
|
||||
and analyzes the recipients and either delivers it (local
|
||||
addressee) or forwards it to another MTA. In either case
|
||||
it may edit and/or add to the message headers. A widely used
|
||||
MTA for Unix is sendmail.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>mail user agent</glossterm>
|
||||
<glossdef><para>
|
||||
(MUA) The program that allows the user to compose and read
|
||||
electronic mail messages. The MUA provides the interface
|
||||
between the user and the <glossterm>mail transfer agent
|
||||
</glossterm>. Outgoing mail is eventually handed over to an
|
||||
MTA for delivery while the incoming messages are picked up
|
||||
from where the MTA left it (although MUAs running on
|
||||
single-user machines may pick up mail using POP).
|
||||
Examples of MUAs are pine, elm and mutt.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>master boot record</glossterm>
|
||||
<glossdef><para>
|
||||
(MBR) The first logical sector on a disk, this is (usually)
|
||||
where the BIOS looks to load a small program that will boot
|
||||
the computer.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>network file system</glossterm>
|
||||
<glossdef><para>
|
||||
(NFS) A protocol developed by Sun Microsystems, and defined in
|
||||
RFC 1094 (FIND URL), which allows a computer to access files
|
||||
over a network as if they were on its local disks.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>operating system</glossterm>
|
||||
<glossdef><para>
|
||||
Software that shares a computer system's resources (processor,
|
||||
memory, disk space, network bandwidth, and so on) between
|
||||
users and the application programs they run. Controls access
|
||||
to the system to provide security. See also kernel, system program,
|
||||
application program.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>partition</glossterm>
|
||||
<glossdef><para>
|
||||
A logical section of a disk. Each partition normally has its
|
||||
own file system. Unix tends to treat partitions as though
|
||||
they were separate physical entities.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>password file</glossterm>
|
||||
<glossdef><para>
|
||||
A file that holds usernames and information about their accounts
|
||||
like their password. On Unix systems this file is usually
|
||||
<filename>/etc/passwd</filename>. On most modern Linux systems
|
||||
the <filename>/etc/passwd</filename> file does not actually hold
|
||||
password data. That tends to be held in a different file <filename>
|
||||
/etc/shadow</filename> for security reasons. See manual pages
|
||||
passwd(5) and shadow(5) for more information.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>physical extents</glossterm>
|
||||
<glossdef><para>
|
||||
A term used to describe a the chunks a physical volume is broken
|
||||
down into when using the Logical Volume Manager.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>physical volume</glossterm>
|
||||
<glossdef><para>
|
||||
A term used an actual disk partition, usually in reference to the
|
||||
logical volume manager.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>platters</glossterm>
|
||||
<glossdef><para>
|
||||
A physical disk inside a hard drive. Usually a hard drive is
|
||||
made up of multiple physical disks stacked up on top of each
|
||||
other. One individual disk is known as a <glossterm>platter
|
||||
</glossterm>.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>power on self test</glossterm>
|
||||
<glossdef><para>
|
||||
(POST) A series of diagnostic tests which are run when a computer
|
||||
is powered on. Typically this might include testing the memory,
|
||||
testing that the hardware configuration is the same as the last
|
||||
saved configuration, checking that any floppy drives, or hard
|
||||
drives which are known about by the BIOS are installed and working.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>print queue</glossterm>
|
||||
<glossdef><para>
|
||||
A file (or set of files) which the print <glossterm>daemon
|
||||
<glossterm> uses so that applications which wish to use the
|
||||
printer do not have to wait until the print job they have sent
|
||||
is finished before they can continue. It also allows multiple
|
||||
users to share a printer.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>read-write head</glossterm>
|
||||
<glossdef><para>
|
||||
A tiny electromagnetic coil and metal pole used to write and read
|
||||
magnetic patterns on a disk. These coils move laterally against
|
||||
the rotary motion on the <glossterm>platters</glossterm>.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>root filesystem</glossterm>
|
||||
<glossdef><para>
|
||||
The parent of all the other filesystems mounted in a Unix filesystem
|
||||
tree. Mounted as / it might have other filesystems mounted on it
|
||||
(/usr for example). If the root filesystem cannot be mounted then the
|
||||
<glossterm>kernel</glossterm> will panic and the system will not be
|
||||
able to continue <glossterm>booting</glossterm>
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>run level</glossterm>
|
||||
<glossdef><para>
|
||||
Linux has up to 10 runlevels (0-9) available (of which usually only
|
||||
the first 7 are defined). Each runlevel may start a different set
|
||||
of services, giving multiple different configurations in the same
|
||||
system. Runlevel 0 is defined as ``system halt'', runlevel 1 is
|
||||
defined as ``<glossterm>single user mode</glossterm>'', and runlevel
|
||||
6 is defined as ``reboot system''. The remaining runlevels can,
|
||||
theoretically, be defined by the system administrator in any way.
|
||||
However most distributions provide some other predefined runlevels.
|
||||
For example, runlevel 2 might be defined as ``multi-user console'',
|
||||
and runlevel 5 as ``multi-user X-Window system''. These definitions
|
||||
vary considerably from distribution to distribution, so please check
|
||||
the documentation for your own distribution.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>sectors</glossterm>
|
||||
<glossdef><para>
|
||||
The minimum <glossterm>track</glossterm> length that can be
|
||||
allocated
|
||||
to store data. This is usually (but not always) 512 bytes.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>shadow passwords</glossterm>
|
||||
<glossdef><para>
|
||||
Because the <glossterm>password file</glossterm> on Unix systems
|
||||
often
|
||||
needs to be world readable it usually does not actually contain the
|
||||
encrypted passwords for users' accounts. Instead a shadow file is
|
||||
employed (which is not world readable) which holds the encrypted
|
||||
passwords for users' accounts.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>single user mode</glossterm>
|
||||
<glossdef><para>
|
||||
Usually runlevel 1. A runlevel where logins are not allowed except
|
||||
by the root account. Used either for system repairs (if the
|
||||
filesystem is partially damaged it may still be possible to boot into
|
||||
runlevel 1 and repair it), or for moving filesystems around between
|
||||
partitions. These are just two examples. Any task that requires a
|
||||
system where only one person can write to a disk at a time is a
|
||||
candidate for requiring runlevel 1.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>spool</glossterm>
|
||||
<glossdef><para>
|
||||
To send a file (or other data) to a queue. Generally used in
|
||||
conjunction with printers, but might also be used for other
|
||||
things (mail for example). The term is reported to be an acronym
|
||||
for ``Simultaneous Peripheral Operation On-Line'', but according
|
||||
to the <ulink url="http://www.tuxedo.org/~esr/jargon">Jargon File
|
||||
</ulink> it may have been a backronym (something made up later
|
||||
for effect).
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>system call</glossterm>
|
||||
<glossdef><para>
|
||||
The services provided by the kernel to application programs,
|
||||
and the way in which they are invoked. See section 2 of the
|
||||
manual pages.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>swap space</glossterm>
|
||||
<glossdef><para>
|
||||
Space on a disk in which the system can write portions of memory
|
||||
to. Usually this is a dedicated partition, but it may also be
|
||||
a swapfile.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>system program</glossterm>
|
||||
<glossdef><para>
|
||||
Programs that implement high level functionality of an operating
|
||||
system, i.e., things that aren't directly dependent on the
|
||||
hardware. May sometimes require special privileges to run
|
||||
(e.g., for delivering electronic mail), but often just commonly
|
||||
thought of as part of the system (e.g., a compiler). See also
|
||||
application program, kernel, operating system.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>time drift</glossterm>
|
||||
<glossdef><para>
|
||||
This is a term for a computers inaccuracy at keeping track of time.
|
||||
All computers have some rate of error when keeping time. With newer
|
||||
computers this rate of error is extremely small.</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>track</glossterm>
|
||||
<glossdef><para>
|
||||
The part of a disk <glossterm>platter</glossterm> which passes
|
||||
under one <glossterm>read-write head</glossterm> while the head
|
||||
is stationary but the disk is spinning. Each track is divided
|
||||
into <glossterm>sectors</glossterm>, and a vertical collection of
|
||||
tracks is a <glossterm>cylinder</glossterm>
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>volume group</glossterm>
|
||||
<glossdef><para>
|
||||
A collection of physical volumes broken down into physical
|
||||
extents, and available for use in logical partitions.
|
||||
</para></glossdef>
|
||||
</glossentry
|
||||
</glossary>
|
|
@ -0,0 +1,122 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
|
||||
<!ENTITY ch00 SYSTEM "ch00.sgml">
|
||||
<!ENTITY ch01 SYSTEM "ch01.sgml">
|
||||
<!ENTITY ch02 SYSTEM "ch02.sgml">
|
||||
<!ENTITY ch03 SYSTEM "ch03.sgml">
|
||||
<!ENTITY ch04 SYSTEM "ch04.sgml">
|
||||
<!ENTITY ch05 SYSTEM "ch05.sgml">
|
||||
<!ENTITY ch06 SYSTEM "ch06.sgml">
|
||||
<!ENTITY ch07 SYSTEM "ch07.sgml">
|
||||
<!ENTITY ch08 SYSTEM "ch08.sgml">
|
||||
<!ENTITY ch09 SYSTEM "ch09.sgml">
|
||||
<!ENTITY ch10 SYSTEM "ch10.sgml">
|
||||
<!ENTITY ch11 SYSTEM "ch11.sgml">
|
||||
<!ENTITY ch12 SYSTEM "ch12.sgml">
|
||||
<!ENTITY ch13 SYSTEM "ch13.sgml">
|
||||
<!ENTITY ch14 SYSTEM "ch14.sgml">
|
||||
<!ENTITY ch15 SYSTEM "ch15.sgml">
|
||||
<!ENTITY ch16 SYSTEM "ch16.sgml">
|
||||
<!ENTITY ch17 SYSTEM "ch17.sgml">
|
||||
<!ENTITY ch18 SYSTEM "ch18.sgml">
|
||||
<!ENTITY ch19 SYSTEM "ch19.sgml">
|
||||
<!ENTITY app01 SYSTEM "app01.sgml">
|
||||
<!ENTITY glos SYSTEM "glos.sgml">
|
||||
<!ENTITY genind SYSTEM "genindex.sgml">
|
||||
]>
|
||||
|
||||
<book id="index">
|
||||
<title>Linux System Administrators Guide</title>
|
||||
<bookinfo>
|
||||
<date>$Date$</date>
|
||||
<keywordset>
|
||||
<keyword>Linux Documentation</keyword>
|
||||
<keyword>GFDL</keyword>
|
||||
<keyword>Linux Documentation Project</keyword>
|
||||
</keywordset>
|
||||
<title>The Linux System Administrator's Guide</title>
|
||||
<subtitle>Version 0.9</subtitle>
|
||||
<author>
|
||||
<firstname>Lars</firstname>
|
||||
<surname>Wirzenius</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>Email address removed by request</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Joanna</firstname>
|
||||
<surname>Oja</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>Current email address unknown</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Stephen</firstname>
|
||||
<surname>Stafford</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>stephen@clothcat.demon.co.uk.NOSPAM</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Alex</firstname>
|
||||
<surname>Weeks</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>draxeman@gmail.com.NOSPAM</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<abstract>
|
||||
<para>An introduction to system administration of a
|
||||
Linux system for novices.</para> </abstract>
|
||||
|
||||
<legalnotice id="legal-notice">
|
||||
|
||||
<para>Copyright 1993--1998 Lars Wirzenius.</para>
|
||||
<para>Copyright 1998--2001 Joanna Oja.</para>
|
||||
<para>Copyright 2001--2003 Stephen Stafford.</para>
|
||||
<para>Copyright 2003--2004 Stephen Stafford & Alex Weeks.</para>
|
||||
<para>Copyright 2004--Present Alex Weeks.</para>
|
||||
|
||||
<para>Trademarks are owned by their owners.</para>
|
||||
|
||||
<para>Permission is granted to copy, distribute and/or modify this
|
||||
document under the terms of the GNU Free Documentation License,
|
||||
Version 1.2 or any later version published by the Free Software
|
||||
Foundation; with no Invariant Sections, no Front-Cover Texts, and no
|
||||
Back-Cover Texts. A copy of the license is included in the section
|
||||
entitled "GNU Free Documentation License".</para>
|
||||
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
&ch00;
|
||||
&ch01;
|
||||
&ch02;
|
||||
&ch03;
|
||||
&ch04;
|
||||
&ch05;
|
||||
&ch06;
|
||||
&ch07;
|
||||
&ch08;
|
||||
&ch09;
|
||||
&ch10;
|
||||
&ch11;
|
||||
&ch12;
|
||||
&ch13;
|
||||
&ch14;
|
||||
&ch15;
|
||||
&ch16;
|
||||
&ch17;
|
||||
&ch18;
|
||||
&ch19;
|
||||
&app01;
|
||||
&glos;
|
||||
&genind;
|
||||
</book>
|
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue