File: sag.sgml

package info (click to toggle)
sysadmin-guide 0.7-1
links: PTS
area: main
in suites: woody
size: 776 kB
ctags: 14
sloc: makefile: 76; sh: 22
file content (7826 lines) | stat: -rw-r--r-- 328,046 bytes
<!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
]>

<book>
  <bookinfo>
   <date>$Date: 2001/11/06 11:26:32 $</date>
   <title>The Linux System Administrator's Guide</title>
    <subtitle>Version 0.7</subtitle>
    <author>
    	<firstname>Lars</firstname>
    	<surname>Wirzenius</surname>
	<affiliation>
		<address>
		<email>liw@iki.fi</email>
		</address>
	</affiliation>
    </author>
    <author>
    	<firstname>Joanna</firstname>
    	<surname>Oja</surname>
	<affiliation>
		<address>
		<email>viu@iki.fi</email>
		</address>
	</affiliation>
    </author>
    <author>
    	<firstname>Stephen</firstname>
	<surname>Stafford</surname>
	<affiliation>
		<address>
		<email>stephen@clothcat.demon.co.uk</email>
		</address>
	</affiliation>
     </author>


    <abstract> 
    <para>An introduction to system administration of a 
Linux system for novices.</para> </abstract>

    <legalnotice>

	<para>Copyright 1993--1998 Lars Wirzenius.</para>
	<para>Copyright 1998--2001 Joanna Oja.</para>
	<para>Copyright 2001 Stephen Stafford.</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.1; with no Invariant Sections, with no Front-Cover Texts,
	and with no Back-Cover Texts.  A copy of the license is included in
	the section entitled "GNU Free Documentation
	License".</para>

    </legalnotice>
    
  </bookinfo>
  
  <toc></toc>

<preface> <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.linuxdoc.org/">http://www.linuxdoc.org/</ulink>, or
	at the home page of this book at <ulink
	url="http://people.debian.org/~bagpuss/">http://people.debian.org/~ba
	gpuss/</ulink>.
	Available are at least Postscript and TeX .DVI formats.</para>
</preface>


<chapter>
<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.</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.
		
		<footnote><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, they will be self evident
		</para></footnote>
	</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 and so are mostly not 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>
</chapter>

<chapter>
<title>About This Book</title>
<sect1>
<title>Acknowledgements</title>
<sect2><title>Joanna's acknowledgements</title>

	<para>Lars has tried to make this manual as good as possible
	and I would like, as a current maintainer, to keep up the good
	work. I would really like to hear from you if you have any
	ideas on how to make it better. Bad language, factual errors,
	ideas for new areas to cover, rewritten sections, information
	about how various UNIX versions do things, I am interested in
	all of it. My contact information is available via the World
	Wide Web at <ulink url="http://www.iki.fi/viu/">
	http://www.iki.fi/viu/</ulink>.
	</para>
	
	<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&auml;nen, Philippe Steindl,
	G.B. Stotte.  My apologies to anyone I have forgotten.</para>
</sect2>

<sect2><title>Stephen's acknowledgements</title>
	<para>As the newest maintainer 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</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>
	
	<para>The current web home of the guide is 
	<ulink url="http://people.debian.org/~bagpuss">
	http://people.debian.org/~bagpuss
	</ulink></para>
</sect1>

<sect1>
<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>stephen@clothcat.demon.co.uk</email></para>

	<para>URLs are expressed as: <ulink
	url="http://www.linuxdoc.org">http://www.linuxdoc.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>
</chapter>

<chapter>
<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>
<title>Various parts of an operating system</title>

	<para>A UNIX operating system consists
	of a <glossterm>kernel</glossterm> and some
	<glossterm>system programs</glossterm>.  There are also some
	<glossterm>application programs</glossterm> for doing work.
	The kernel is the heart of the operating system.
	
		<footnote><para>In fact, it is often mistakenly considered
		to be the operating system itself, but it is not.
		An operating system provides many more services than a
		plain kernel.</footnote>
		
	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.
		<footnote><para>I always think of this as a form of encapsulation
		which may help those of you with an object oriented programming
		background to visualise it better.</para></footnote>
	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 categorisers.</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>
<title>Important parts of the kernel</title>

	<para>The Linux kernel 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"></graphic>
		</figure>

	<para>Probably the most important parts of the kernel (nothing else
	works without them) are memory management and 
	process management.  Memory management takes care of assigning
	memory areas and swap space areas to processes, parts of the
	kernel, and for the buffer cache.  Process management 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 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 `initialise 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> (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>

</sect1>

<sect1>
<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>
<title><command>init</command></title>

	<para>The single most important service in a UNIX system is
	provided by <command>init</command>.  <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 flavour it is; there are several to choose
	from.  <command>init</command> usually provides the concept of
	<glossterm>single user mode</glossterm>, in which no one can
	log in and root uses a shell at the console; the usual mode is
	called <glossterm>multiuser mode</glossterm>.  Some flavours
	generalise 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>, 0-9, but usually only some of
	these are defined by default.  Runlevel 0 is defined as ``system
	halt''.  Runlevel 1 is defined as ``single user mode''.
	Runlevel 6 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> usually will
	give some hint what the predefined runlevels are and what they
	have been defined as.</para>

	<para>In normal operation, <command>init</command> makes sure
	<command>getty</command> 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>
<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>
	program.  <command>init</command> 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> 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>
<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>.  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>
	
</sect2>

<sect2>
<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> service is set up to do this.
	Each user can have a <filename>crontab</filename> 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> 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>See the manual pages cron(1), crontab(1), crontab(5), at(1) and
	atd(8) for more in depth information.</para>
</sect2>

<sect2>
<title>Graphical user interface</title>

	<para>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 (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, icewm,
	blackbox and windowmaker.  There are also two popular desktop
	managers, KDE and Gnome.</para>

</sect2>

<sect2>
<title>Networking</title>

	<para>Networking 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 centralised 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.linuxdoc.org/LDP/nag2/index.html">
	http://www.linuxdoc.org/LDP/nag2/index.html</ulink> for
	more information, including a basic description of how networks
	operate.</para>

</sect2>

<sect2>
<title>Network logins</title>

	<para>Network logins work a little differently than normal logins.
	There is a separate physical serial line for each terminal via
	which it is possible to log in.  For each person logging in via
	the network, there is a separate virtual network connection,
	and there can be any number of these.
	
		<footnote><para>Well, at least there can be many.  Network
		bandwidth still being a scarce resource, there is still
		some practical upper limit to the number of concurrent
		logins via one network connection.  </para></footnote>
		
	It is therefore not possible to run a separate
	<command>getty</command> for each possible virtual connection.
	There are also several different ways to log in via a network,
	<command>telnet</command> and <command>rlogin</command> being
	the major ones in TCP/IP networks.
		<footnote><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></footnote>
	</para>

	<para>Network logins have, instead of a herd of
	<command>getty</command>s, a single daemon per way of logging in
	(<command>telnet</command> and <command>rlogin</command> 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>
<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>.  The one usually used is called the
	Network File System, or NFS, developed by Sun.</para>

	<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>Another popular way of sharing files is Samba <ulink
	url="http://www.samba.org">http://www.samba.org</ulink>.  This
	protocol allows the sharing of files with MS Windows machines
	(via Network Neighbourhood).  It also allows the sharing of
	printers across machines.</para>
</sect2>

<sect2>
<title>Mail</title>
	<para>Electronic mail 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), 
	e.g., <command>sendmail</command>
	or <command>smail</command>), while the programs users use
	are many and varied (<glossterm>mail user agent</glossterm> (MUA),
	e.g., <command>pine</command>, <command>mutt</command>
	or <command>elm</command>).  The mailboxes are usually stored
	in <filename>/var/spool/mail</filename>.</para>

</sect2>

<sect2>
<title>Printing</title>
	<para>Only one person can use a printer 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>: 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 organising
	the print queue and fighting over control of the printer.
		<footnote><para>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></footnote>
	</para>

	<para>The print queue software also <glossterm>spools</glossterm>
	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>

</sect2>

<sect2>
<title>The filesystem layout</title>
	<para>The filesystem is divided into many parts;
	usually along the lines of a root filesystem with
	<filename>/bin</filename>, <filename>/lib</filename>,
	<filename>/etc</filename>, <filename>/dev</filename>, and
	a few others; a <filename>/usr</filename> filesystem with
	programs and unchanging data; a <filename>/var</filename>
	filesystem with changing data (such as log files); and a
	<filename>/home</filename> filesystem 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 covers it
	in somewhat more detail.
		<footnote><para><ulink url="http://www.pathname.com/fhs/">
		http://www.pathname.com/fhs/</ulink></para></footnote>
	</para>
</sect2>
</sect1>
</chapter>


<chapter id="dir-tree-overview">
<title>Overview of the Directory Tree</title>

	<blockquote><para><quote> Two days later, there was Pooh, sitting
	on his branch, dangling his legs, and there, beside him, were
	four pots of honey...</quote> (A.A. Milne) </para></blockquote>

	<para>This chapter describes the important parts of a standard Linux
	directory tree, based on the Filesystem Hierarchy Standard. It
	outlines the normal way of breaking the directory tree into separate
	filesystems with different purposes and gives the motivation behind
	this particular split.  Not all Linux distributions follow this
	standard slavishly, but it is generic enough to give you an
	overview.</para>

<sect1>
<title>Background</title>

	<para>This chapter is loosely based on the <citetitle>Filesystems
	Hierarchy Standard</citetitle> (FHS)
       	    <footnote><para><ulink url="hhtp://www.pathname.com/fhs/">
	    http://www.pathname.com/fhs/</ulink></para></footnote>	
	version 2.1, which attempts to
	set a standard for how the directory tree in a Linux
	    
	    <footnote><para>Or any Unix like system.  For example the BSD
	    derivatives.</para></footnote> 

	system is organised. Such a standard has the advantage that it will
	be easier to write or port software for Linux, and to administer
	Linux machines, since everything should be in standardised places.
	There is no authority behind the standard that forces anyone to
	comply with it, but it has gained the support of many Linux
	distributions. It is not a good idea to break with the FHS without
	very compelling reasons.  The FHS attempts to follow Unix tradition
	and current trends, making Linux systems familiar to those with
	experience with other Unix systems, and vice versa.</para>

	<para>This chapter is not as detailed as the FHS.  A system
	administrator should also read the full FHS for a complete
	understanding.</para>

	<para>This chapter does not explain all files in detail. The
	intention is not to describe every file, but to give an overview of
	the system from a filesystem point of view. Further information on
	each file is available elsewhere in this manual or in the Linux
	manual pages.</para>

	<para>The full directory tree is intended to be breakable into
	smaller parts, each capable of being on its own disk or partition,
	to accommodate to disk size limits and to ease backup and other
	system administration tasks.  The major parts are the root
	(<filename>/</filename>), <filename>/usr</filename>,
	<filename>/var</filename>, and <filename>/home</filename>
	filesystems (see <xref linkend="fstree">).  Each part has a
	different purpose. The directory tree has been designed so that it
	works well in a network of Linux machines which may share some parts
	of the filesystems over a read-only device (e.g., a CD-ROM), or over
	the network with NFS.</para>

		<figure id="fstree" float="1"> <title>Parts of a Unix
		directory tree. Dashed lines indicate partition 
		limits.</title> <graphic fileref="fstree"></graphic>
		</figure>
	
	<para>The roles of the different parts of the directory tree are
	described below.

	<itemizedlist>
	
		<listitem> <para>The root filesystem is specific for
		each machine (it is generally stored on a local disk,
		although it could be a ramdisk or network drive as well) and
		contains the files that are necessary for booting the system
		up, and to bring it up to such a state that the other
		filesystems may be mounted.  The contents of the root
		filesystem will therefore be sufficient for the single user
		state.	It will also contain tools for fixing a broken
		system, and for recovering lost files
		from backups.</para> </listitem>

		<listitem><para> The <filename>/usr</filename> filesystem
		contains all commands, libraries, manual pages, and other
		unchanging files needed during normal operation. No files in
		<filename>/usr</filename> should be specific for any given
		machine, nor should they be modified during normal use. This
		allows the files to be shared over the network, which can be
		cost-effective since it saves disk space (there can easily
		be hundreds of megabytes, increasingly multiple gigabytes in
		<filename>/usr</filename>).  It can make administration
		easier (only the master <filename>/usr</filename> needs to
		be changed when updating an application, not each machine
		separately) to have /usr network mounted.  Even if the
		filesystem is on a local disk, it could be mounted
		read-only, to lessen the chance of filesystem corruption 
		during a crash.</para></listitem>

		<listitem><para>The <filename>/var</filename>
		filesystem contains files that change, such as spool
		directories (for mail, news, printers, etc), log files,
		formatted manual pages, and temporary files. Traditionally
		everything in <filename>/var</filename> has been somewhere
		below <filename>/usr</filename>, but that made it impossible
		to mount <filename>/usr</filename>
		read-only.<para></listitem>

		<listitem><para> The <filename>/home</filename>
		filesystem contains the users' home directories, i.e., all
		the real data on the system.  Separating home directories to
		their own directory tree or filesystem makes backups easier;
		the other parts often do not have to be backed up, or at
		least not as often as they seldom change. A big
		<filename>/home</filename> might have to be broken across
		several filesystems, which requires adding an extra naming
		level below <filename>/home</filename>, for example
		<filename>/home/students</filename> and
		<filename>/home/staff</filename>.</para></listitem>

	</itemizedlist> </para>

	<para>Although the different parts have been called filesystems
	above, there is no requirement that they actually be on separate
	filesystems.  They could easily be kept in a single one if the
	system is a small single-user system and the user wants to keep
	things simple.	The directory tree might also be divided into
	filesystems differently, depending on how large the disks are, and
	how space is allocated for various purposes.  The important part,
	though, is that all the standard <emphasis>names</emphasis> work;
	even if, say, <filename>/var</filename> and
	<filename>/usr</filename> are actually on the same partition, the
	names <filename>/usr/lib/libc.a</filename> and
	<filename>/var/log/messages</filename> must work, for example by
	moving files below <filename>/var</filename> into
	<filename>/usr/var</filename>, and making <filename>/var</filename>
	a symlink to
	<filename>/usr/var</filename>.</para>

	<para>The Unix filesystem structure groups files according to 
	purpose, i.e., all commands are in one place, all data files in
	another, documentation in a third, and so on.  An alternative would
	be to group files files according to the program they belong to,
	i.e., all Emacs files would be in one directory, all TeX in another,
	and so on.  The problem with the latter approach is that it makes it
	difficult to share files (the program directory often contains both
	static and sharable and changing and non-sharable files), and
	sometimes to even find the files (e.g., manual pages in a huge
	number of places, and making the manual page programs find all of
	them is a maintenance
	nightmare).</para>

</sect1>

<sect1>
<title>The root filesystem</title>

	<para>The root filesystem should generally be small, since
	it contains very critical files and a small, infrequently
	modified filesystem has a better chance of not getting corrupted.
	A corrupted root filesystem will generally mean that the system
	becomes unbootable except with special measures (e.g., from a
	floppy), so you don't want to risk it.</para>

	<para>The root directory generally doesn't contain any files, except
	perhaps the standard boot image for the system, usually called
	<filename>/vmlinuz</filename>.  All other files are in 
	subdirectories in the root filesystems:

	<glosslist>

	<glossentry>
	<glossterm><filename>/bin</filename></glossterm>
	
		<glossdef><para>Commands needed during bootup
		that might be used by normal users (probably after
		bootup).</para></glossdef></glossentry>

	<glossentry> 
	<glossterm><filename>/sbin</filename></glossterm>

		<glossdef><para>Like <filename>/bin</filename>, but the
		commands are not intended for normal users, although they
		may use them if necessary and allowed.
		<filename>/sbin</filename> is not usually in the default
		path of normal users, but will be in root's default
		path.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc</filename></glossterm>
	
		<glossdef><para>Configuration files specific to the
		machine.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/root</filename></glossterm>

	        <glossdef><para>The home directory for user root.  This is
		usually not accessible to other users on the
		system</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/lib</filename></glossterm>

                <glossdef><para>Shared libraries needed by the programs on
		the root filesystem.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/lib/modules</filename></glossterm>

		<glossdef><para>Loadable kernel modules, especially those
		that are needed to boot the system when recovering from
		disasters (e.g., network and filesystem
		drivers).</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/dev</filename></glossterm>

                <glossdef><para>Device files.  Some of the more commonly
		used device files are examined in <xref linkend="device-list">
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/tmp</filename></glossterm>

		<glossdef><para>Temporary files.  Programs running after
		bootup should use <filename>/var/tmp</filename>, not
		<filename>/tmp</filename>, since the former is probably on a
		disk with more space.  Often /tmp will be a symbolic link to
		/var/tmp.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/boot</filename></glossterm>
		<glossdef><para>Files used by the bootstrap loader,
		e.g., LILO.  Kernel images are often kept here instead
		of in the root directory.  If there are many kernel
		images, the directory can easily grow rather big, and it
		might be better to keep it in a separate filesystem.
		Another reason would be to make sure the kernel
		images are within the first 1024 cylinders of an IDE
		disk.

		        <footnote><para>This 1024 cylinder limit is no
			longer true in most cases.  With modern BIOSes and
			later versions of LILO (the LInux LOader) the 1024
			cylinder limit can be passed with logical block
			addressing (LBA).  See the <command>lilo</command>
			manual page for more details.</para></footnote>
			
	       </para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/mnt</filename></glossterm>
		<glossdef><para>Mount point for temporary mounts by
		the system administrator.  Programs aren't supposed to mount
		on <filename>/mnt</filename> automatically.
		<filename>/mnt</filename> might be divided into
		subdirectories (e.g., <filename>/mnt/dosa</filename> might
		be the floppy drive using an MS-DOS filesystem, and
		<filename>/mnt/exta</filename> might be the same
		with an ext2 filesystem).</para></glossdef></glossentry>

	<glossentry> <glossterm><filename>/proc</filename>,
	<filename>/usr</filename>, <filename>/var</filename>,
	<filename>/home</filename></glossterm>

	<glossdef><para>Mount points
	for the other filesystems.

	        <footnote><para>Although <filename>/proc</filename> does not
		reside on any disk in reality.  See the section about
		<filename>/proc</filename> later in the
		chapter.</para></footnote>

	</para></glossdef></glossentry>

	</glosslist>
	</para>

</sect1>

<sect1>
<title>The <filename>/etc</filename> directory</title>

	<para>The <filename>/etc</filename> directory contains a lot
	of files.  Some of them are described below.  For others, you
	should determine which program they belong to and read the manual
	page for that program.	Many networking configuration files are
	in <filename>/etc</filename> as well, and are described in the
	<citetitle>Networking Administrators' Guide</citetitle>.

	<glosslist>
	
	<glossentry>
	<glossterm><filename>/etc/rc</filename> or 
<filename>/etc/rc.d</filename> or 
<filename>/etc/rc?.d</filename></glossterm>
		<glossdef><para>Scripts or directories of scripts
		to run at startup or when changing the run level.
		See <xref linkend="init"> for further
		information.  </para></glossdef></glossentry>

	<glossentry> 
	<glossterm><filename>/etc/passwd</filename></glossterm>

		<glossdef><para>The user database, with fields giving the
		username, real name, home directory, encrypted password, and
		other information about each user. The format is documented
		in the <command>passwd</command> manual page.  The encrypted
		passwords are much more commonly found in the
		<filename>/etc/shadow</filename> these days.  This means
		that almost everything about the user
		<emphasis>except</emphasis> the password is stored in the
		<filename>passwd</filename> file.  History and convention
		make a name change undesirable.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/fdprm</filename></glossterm>
		<glossdef><para>Floppy disk parameter table.
		Describes what different floppy disk formats look
		like.  Used by <command>setfdprm</command>.  See the
		<command>setfdprm</command> manual page for more
		information.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/fstab</filename></glossterm>

		<glossdef><para>Lists the filesystems mounted automatically
		at startup by the <command>mount -a</command> command (in
		<filename>/etc/rc</filename> or equivalent startup file).
		Under Linux, also contains information about swap areas used
		automatically by <command>swapon -a</command>.  See <xref
		linkend="mount-and-umount"> and the <command>mount</command>
		manual page for more information.  Also
		<filename>fstab</filename> usually has its own manual page in
		section 5. </para></glossdef></glossentry>

	<glossentry> 
	<glossterm><filename>/etc/group</filename></glossterm>

		<glossdef><para>Similar to <filename>/etc/passwd</filename>,
		but describes groups instead of users.  See the
		<filename>group</filename> manual page in section 5 for more
		information. </para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/inittab</filename></glossterm>
		<glossdef><para>Configuration file for
		<command>init</command>.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/issue</filename></glossterm>
		<glossdef><para>Output by <command>getty</command> before
		the login prompt.  Usually contains a short description or
		welcoming message to the system.  The contents are up to
		the system administrator.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/magic</filename></glossterm>
		<glossdef><para>The configuration file
		for <command>file</command>.  Contains the
		descriptions of various file formats based on
		which <command>file</command> guesses the type of
		the file.  See the <filename>magic</filename> and
		<command>file</command> manual pages for more information.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/motd</filename></glossterm>
		
		<glossdef><para>The message of the day, automatically
		output after a successful login.  Contents are up to the
		system administrator.  Often used for getting information
		to every user, such as warnings about planned downtimes.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/mtab</filename></glossterm>
		
		<glossdef><para>List of currently mounted filesystems.
		Initially set up by the bootup scripts, and updated
		automatically by the <command>mount</command>
		command.  Used when a list of mounted filesystems is
		needed, e.g., by the <command>df</command> command.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/shadow</filename></glossterm>

		<glossdef><para>Shadow password file on systems with shadow
		password software installed. Shadow passwords move the
		encrypted password from <filename>/etc/passwd</filename>
		into <filename>/etc/shadow</filename>; the latter is not
		readable by anyone except root.  This makes it harder to
		crack passwords.  If your distribution gives you a choice
		(many do) of whether or not to use shadow passwords then you
		are highly recommended to do
		so.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/login.defs</filename></glossterm>

		<glossdef><para>Configuration file for the
		<command>login</command> command.  The
		<filename>login.defs</filename> file usually has a manual
		page in section 5. </para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/printcap</filename></glossterm>

		<glossdef><para>Like <filename>/etc/termcap</filename>, but
		intended for printers.  However it uses different syntax.
		The <filename>printcap</filename> has a manual page in
		section 5. </para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/profile</filename>, 
<filename>/etc/csh.login</filename>, 
<filename>/etc/csh.cshrc</filename></glossterm>
		<glossdef><para>Files executed at login or startup time
		by the Bourne or C shells.  These allow the system
		administrator to set global defaults for all users.
		See the manual pages for the respective shells.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/securetty</filename></glossterm>

		<glossdef><para>Identifies secure terminals, i.e., the
		terminals from which root is allowed to log in. Typically
		only the virtual consoles are listed, so that it becomes
		impossible (or at least harder) to gain superuser privileges
		by breaking into a system over a modem or a network.  Do not
		allow root logins over a network.  Prefer to log in as an
		unprivileged user and use <command>su</command> or
		<command>sudo</command> to gain root
		privileges.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/etc/shells</filename></glossterm>
		<glossdef><para>Lists trusted shells.  The
		<command>chsh</command> command allows users to change
		their login shell only to shells listed in this file.
		<command>ftpd</command>, the server process that provides
		FTP services for a machine, will check that the user's
		shell is listed in <filename>/etc/shells</filename>
		and will not let people log in unless the shell is
		listed there.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/etc/termcap</filename></glossterm>
		<glossdef><para>The terminal capability database.
		Describes by what ``escape sequences'' various terminals
		can be controlled.  Programs are written so that instead
		of directly outputting an escape sequence that only
		works on a particular brand of terminal, they look up
		the correct sequence to do whatever it is they want to
		do in <filename>/etc/termcap</filename>.  As a result
		most programs work with most kinds of terminals.
		See the <filename>termcap</filename>, curs_termcap,
		and <filename>terminfo</filename> manual pages for
		more information.  </para></glossdef></glossentry>

	</glosslist>
	</para>

</sect1>

<sect1>
<title>The <filename>/dev</filename> directory</title>

	<para>The <filename>/dev</filename> directory contains
	the special device files for all the devices.  The device files are
	named using special conventions; these are described in <xref
	linkend="device-list">.  The device files are created during
	installation, and later with the <command>/dev/MAKEDEV</command>
	script. The <command>/dev/MAKEDEV.local</command> is a script
	written by the system administrator that creates local-only device
	files or links (i.e. those that are not part of the standard
	<command>MAKEDEV</command>, such as device files for some
	non-standard device driver).</para>
	
</sect1>

<sect1>
<title>The <filename>/usr</filename> filesystem</title>

	<para>The <filename>/usr</filename> filesystem is often
	large, since all programs are installed there.	All files
	in <filename>/usr</filename> usually come from a Linux
	distribution; locally installed programs and other stuff goes
	below <filename>/usr/local</filename>.	This makes it possible
	to update the system from a new version of the distribution,
	or even a completely new distribution, without having to
	install all programs again.  Some of the subdirectories of
	<filename>/usr</filename> are listed below (some of the less
	important directories have been dropped; see the FSSTND for
	more information).

	<glosslist>
	
	<glossentry>
	<glossterm><filename>/usr/X11R6</filename></glossterm>

		<glossdef><para>The X Window System, all files. To simplify
		the development and installation of X, the X files have not
		been integrated into the rest of the system.  There is a
		directory tree below <filename>/usr/X11R6</filename> similar
		to that below <filename>/usr</filename> itself.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/usr/bin</filename></glossterm>

		<glossdef><para>Almost all user commands. Some commands are
		in <filename>/bin</filename> or in
		<filename>/usr/local/bin</filename>.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/usr/sbin</filename></glossterm>

		<glossdef><para>System administration commands that are not
		needed on the root filesystem, e.g., most server programs.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/usr/share/man</filename>, 
<filename>/usr/share/info</filename>, 
<filename>/usr/share/doc</filename></glossterm>

		<glossdef><para>Manual pages, GNU Info documents, and
		miscellaneous other documentation files, respectively.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/usr/include</filename></glossterm>
		<glossdef><para>Header files for the C
		programming language.  This should actually be below
		<filename>/usr/lib</filename> for consistency, but the
		tradition is overwhelmingly in support for this name.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/usr/lib</filename></glossterm>
		<glossdef><para>Unchanging data files for programs and
		subsystems, including some site-wide configuration
		files.	The name <filename>lib</filename> comes from library;
		originally libraries of programming subroutines
		were stored in <filename>/usr/lib</filename>.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/usr/local</filename></glossterm>

		<glossdef><para>The place for locally installed software and
		other files.  Distributions may not install anything in
		here.  It is reserved solely for the use of the local
		administrator.  This way he can be absolutely certain that
		no updates or upgrades to his distribution will overwrite
		any extra software he has installed
		locally.</para></glossdef></glossentry>

	</glosslist></para>

</sect1>

<sect1>
<title>The <filename>/var</filename> filesystem</title>

	<para>The <filename>/var</filename> contains data that is changed
	when the system is running normally.  It is specific for each
	system, i.e., not shared over the network with other computers.

	<glosslist>
	
	<glossentry>
	<glossterm><filename>/var/cache/man</filename></glossterm>

		<glossdef><para>A cache for man pages that are formatted on
		demand.  The source for manual pages is usually stored in
		<filename>/usr/share/man/man?/</filename> (where ? is the
		manual section.  See the manual page for
		<command>man</command> in section 7); some manual pages
		might come with a pre-formatted version, which might be
		stored in <filename>/usr/share/man/cat*</filename>. Other
		manual pages need to be formatted when they are first
		viewed; the formatted version is then stored in
		<filename>/var/cache/man</filename> so that the next person
		to view the same page won't have to wait for it to be
		formatted. </para></glossdef></glossentry>

        <glossentry>
	<glossterm><filename>/var/games</filename></glossterm>

	        <glossdef><para>Any variable data belonging to games in
		<filename>/usr</filename> should be placed here.  This is in
		case /usr is mounted read only.
		</para></glossdef></glossentry>


	<glossentry>
	<glossterm><filename>/var/lib</filename></glossterm>

		<glossdef><para>Files that change while the system is
		running normally.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/var/local</filename></glossterm>
		<glossdef><para>Variable data for programs that are
		installed in <filename>/usr/local</filename> (i.e.,
		programs that have been installed by the system
		administrator).  Note that even locally installed
		programs should use the other <filename>/var</filename>
		directories if they are appropriate, e.g.,
		<filename>/var/lock</filename>.</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/var/lock</filename></glossterm>
		<glossdef><para>Lock files.  Many programs
		follow a convention to create a lock file in
		<filename>/var/lock</filename> to indicate that they
		are using a particular device or file.	Other programs
		will notice the lock file and won't attempt to use the
		device or file.</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/var/log</filename></glossterm>

		<glossdef><para>Log files from various programs, especially
		<command>login</command>
		(<filename>/var/log/wtmp</filename>, which logs all logins
		and logouts into the system) and <command>syslog</command>
		(<filename>/var/log/messages</filename>, where all kernel
		and system program message are usually stored). Files in
		<filename>/var/log</filename> can often grow indefinitely,
		and may require cleaning at regular
		intervals.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/var/mail</filename></glossterm>

	        <glossdef><para>This is the FHS approved location for user
		mailbox files.  Depending on how far your distribution has
		gone towards FHS compliance, these files may still be held
		in <filename>/var/spool/mail</filename>.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/var/run</filename></glossterm>
		<glossdef><para>Files that contain information about the
		system that is valid until the system is next booted.
		For example, <filename>/var/run/utmp</filename>
		contains information about people currently logged
		in.</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/var/spool</filename></glossterm>

		<glossdef><para>Directories for news, printer queues, and
		other queued work. Each different spool has its own
		subdirectory below <filename>/var/spool</filename>, e.g.,
		the news spool is in <filename>/var/spool/news</filename>.
		Note that some installations which are not fully compliant
		with the latest version of the FHS may have user mailboxes
		under <filename>/var/spool/mail</filename>.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/var/tmp</filename></glossterm>
		<glossdef><para>Temporary files that are large
		or that need to exist for a longer time than
		what is allowed for <filename>/tmp</filename>.
		(Although the system administrator might not allow
		very old files in <filename>/var/tmp</filename>
		either.)</para></glossdef></glossentry>

	</glosslist></para>

</sect1>

<sect1>
<title>The <filename>/proc</filename> filesystem</title>

	<para>The <filename>/proc</filename> filesystem contains a
	illusionary filesystem.  It does not exist on a disk. Instead, the
	kernel creates it in memory.  It is used to provide information
	about the system (originally about processes, hence the name).  Some
	of the more important files and directories are explained below.
	The <filename>/proc</filename> filesystem is described in more
	detail in the <filename>proc</filename> manual page.

	<glosslist>
	
	<glossentry>
	<glossterm><filename>/proc/1</filename></glossterm>
		<glossdef><para>A directory with information about
		process number 1.  Each process has a directory below
		<filename>/proc</filename> with the name being its process
		identification number.	</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/proc/cpuinfo</filename></glossterm>
		<glossdef><para>Information about the processor,
		such as its type, make, model, and performance.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/devices</filename></glossterm>
		<glossdef><para>List of device drivers configured into the
		currently running kernel.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/dma</filename></glossterm>
		<glossdef><para>Shows which DMA channels are being used
		at the moment.	</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/filesystems</filename></glossterm>
		<glossdef><para>Filesystems configured into the kernel.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/interrupts</filename></glossterm>
		<glossdef><para>Shows which interrupts are
		in use, and how many of each there have been.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/ioports</filename></glossterm>
		<glossdef><para>Which I/O ports are in use at the moment.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/kcore</filename></glossterm>
		<glossdef><para>An image of the physical memory of
		the system.  This is exactly the same size as your
		physical memory, but does not really take up that much
		memory; it is generated on the fly as programs access it.
		(Remember: unless you copy it elsewhere, nothing under
		<filename>/proc</filename> takes up any disk space
		at all.)  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/kmsg</filename></glossterm>
		<glossdef><para>Messages output by the kernel.
		These are also routed to <command>syslog</command>.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/ksyms</filename></glossterm>
		<glossdef><para>Symbol table for the kernel.
		</para></glossdef></glossentry>	
	
	<glossentry>
	<glossterm><filename>/proc/loadavg</filename></glossterm>
		<glossdef><para>The `load average' of the system; three
		meaningless indicators of how much work the system has
		to do at the moment.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/meminfo</filename></glossterm>
		<glossdef><para>Information about memory usage, both
		physical and swap.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/modules</filename></glossterm>
		<glossdef><para>Which kernel modules are loaded at
		the moment.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/net</filename></glossterm>
		<glossdef><para>Status information about network
		protocols.  </para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/self</filename></glossterm>
		<glossdef><para>A symbolic link to the process
		directory of the program that is looking at
		<filename>/proc</filename>.  When two processes look at
		<filename>/proc</filename>, they get different links.
		This is mainly a convenience to make it easier
		for programs to get at their process directory.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/stat</filename></glossterm>
		<glossdef><para>Various statistics about the system, such
		as the number of page faults since the system was booted.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/uptime</filename></glossterm>
		<glossdef><para>The time the system has been up.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/proc/version</filename></glossterm>
		<glossdef><para>The kernel version.
		</para></glossdef></glossentry>
	
	</glosslist></para>

	<para>Note that while the above files tend to be easily readable
	text files, they can sometimes be formatted in a way that is not
	easily digestible.  There are many commands that do little more than
	read the above files and format them for easier understanding. For
	example, the <command>free</command> program reads
	<filename>/proc/meminfo</filename> and converts the amounts given in
	bytes to kilobytes (and adds a little more information, as
	well).</para>

</sect1>

</chapter>

<chapter id="device-list">
<title>Device Files</title>

<para>This chapter gives an overview of what a device file is, and how to
create one.  It also lists some of the more common device files.  The
canonical list of device files is
<filename>/usr/src/linux/Documentation/devices.txt</filename> if you have
the Linux kernel source code installed on your system.  The devices listed
here are correct as of kernel version 2.2.17.</para>

<sect1>
<title>The <command>MAKEDEV</command> 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>
	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>
</sect1>

<sect1>
<title>The <command>mknod</command> command</title>

	<para><command>MAKEDEV</command> 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> 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> script does not know how to create the
	<filename>/dev/ttyS0</filename> device file.  We need to use
	<command>mknod</command> to create it.  We know from looking at the
	<filename>devices.txt</filename> file 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> script, but it suffices to illustrate
	the point.</para>
</sect1> 

<sect1>
<title>Device List</title>

	<para>This list which follows is by no means exhaustive or as
	detailed as it could be.  Many of these device files will need
	support compiled into your kernel for the hardware.  Read the kernel
	documentation to find details of any particular device.</para>
	
	<para>If you think there are other devices which should be included here but
	aren't then let me know.  I will try to include them in the next revision.</para>

        <glosslist>
	<glossentry>
	<glossterm><filename>/dev/dsp</filename></glossterm>

	    <glossdef><para>Digital Signal Processor.  Basically this forms
	    the interface between software which produces sound and your
	    soundcard.  It is a character device on major node 14 and minor
	    3.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/fd0</filename></glossterm>

	    <glossdef><para>The first floppy drive.  If you are lucky enough
	    to have several drives then they will be numbered sequentially.
	    It is a character device on major node 2 and minor
	    0.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/fb0</filename></glossterm>

	    <glossdef><para>The first framebuffer device. A framebuffer is
	    an abstraction layer between software and graphics hardware.
	    This means that applications do not need to know about what kind
	    of hardware you have but merely how to communicate with the
	    framebuffer driver's API (Application Programming Interface)
	    which is well defined and standardised.  The framebuffer is a
	    character device and is on major node 29 and minor
	    0.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/hda</filename></glossterm>

	    <glossdef><para><filename>/dev/hda</filename> is the master IDE
	    drive on the primary IDE controller.
	    <filename>/dev/hdb</filename> is the slave drive on the primary
	    controller.  <filename>/dev/hdc</filename> and
	    <filename>/dev/hdd</filename> are the master and slave devices
	    on the secondary controller respectively.  Each disk is divided
	    into partitions. Partitions 1-4 are primary partitions and
	    partitions 5 and above are logical partitions inside extended
	    partitions.  Therefore the device file which references each
	    partition is made up of several parts.  For example
	    <filename>/dev/hdc9</filename> references partition 9 (a logical
	    partition inside an extended partition type) on the master IDE
	    drive on the secondary IDE controller.  The major and minor node
	    numbers are somewhat complex.  For the first IDE controller all
	    partitions are block devices on major node 3.  The master drive
	    <filename>hda</filename> is at minor 0 and the slave drive
	    <filename>hdb</filename> is at minor 64.  For each partition
	    inside the drive add the partition number to the minor node
	    number for the drive.  For example
	    <filename>/dev/hdb5</filename> is major 3, minor 69 (64 + 5 =
	    69). Drives on the secondary interface are handled the same way,
	    but with major node 22.</para></glossdef></glossentry>

        <glossentry>
	<glossterm><filename>/dev/ht0</filename></glossterm>

	    <glossdef><para>The first IDE tape drive.  Subsequent drives are
	    numbered <filename>ht1</filename> etc.  They are character
	    devices on major node 37 and start at minor node 0 for
	    <filename>ht0</filename> 1 for <filename>ht1</filename>
	    etc.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/dev/js0</filename></glossterm>

	    <glossdef><para>The first analogue joystick.  Subsequent joysticks
	    are numbered <filename>js1</filename>, <filename>js2</filename>
	    etc.  Digital joysticks are called <filename>djs0</filename>,
	    <filename>djs1</filename> and so on.  They are character devices
	    on major node 15.  The analogue joysticks start at minor node 0
	    and go up to 127 (more than enough for even the most fanatic
	    gamer). Digital joysticks start at minor node
	    128.</para></glossdef></glossentry>

	<glossentry>
	<glossterm><filename>/dev/lp0</filename></glossterm>

	    <glossdef><para>The first parallel printer device.  Subsequent
	    printers are numbered <filename>lp1</filename>,
	    <filename>lp2</filename> etc.  They are character devices on
	    major mode 6 and minor nodes starting at 0 and numbered
	    sequentially.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/loop0</filename></glossterm>

	    <glossdef><para>The first loopback device.  Loopback devices are
	    used for mounting filesystems which are not located on other
	    block devices such as disks.  For example if you wish to mount
	    an iso9660 CD ROM image without burning it to CD then you need
	    to use a loopback device to do so.  This is usually transparent
	    to the user and is handled by the <command>mount</command>
	    command.  Refer to the manual pages for <command>mount</command>
	    and <command>losetup</command>.  The loopback devices are block
	    devices on major node 7 and with minor nodes starting at 0 and
	    numbered sequentially.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/md0</filename></glossterm>

	    <glossdef><para>First metadisk group.  Metadisks are related to
	    RAID (Redundant Array of Independent Disks) devices.  Please
	    refer to the various RAID HOWTOs at the LDP for more details.
	    Metadisk devices are block devices on major node 9 with minor
	    nodes starting at 0 and numbered
	    sequentially.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/mixer</filename></glossterm>

	    <glossdef><para>This is part of the OSS (Open Sound System)
	    driver. Refer to the OSS documentation at <ulink
	    url="http://www.opensound.com">http://www.opensound.com</ulink>
	    for more details.  It is a character device on major node 14,
	    minor node 0.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/null</filename></glossterm>

	    <glossdef><para>The bit bucket.  A black hole where you can send
	    data for it never to be seen again.  Anything sent to
	    <filename>/dev/null</filename> will disappear.  This can be
	    useful if, for example, you wish to run a command but not have
	    any feedback appear on the terminal.  It is a character device
	    on major node 1 and minor node 3.</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><filename>/dev/psaux</filename></glossterm>

	    <glossdef><para>The PS/2 mouse port.  This is a character device
	    on major node 10, minor node 1.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/pda</filename></glossterm>

	    <glossdef><para>Parallel port IDE disks.  These are named
	    similarly to disks on the internal IDE controllers
	    (<filename>/dev/hd*</filename>).  They are block devices on major
	    node 45. Minor nodes need slightly more explanation here.  The
	    first device is <filename>/dev/pda</filename> and it is on minor
	    node 0.  Partitions on this device are found by adding the
	    partition number to the minor number for the device.  Each
	    device is limited to 15 partitions each rather than 63 (the
	    limit for internal IDE disks).  <filename>/dev/pdb</filename>
	    minor nodes start at 16, <filename>/dev/pdc</filename> at 32 and
	    <filename>/dev/pdd</filename> at 48.  So for example the minor
	    node number for <filename>/dev/pdc6</filename> would be 38 (32 +
	    6 = 38).  This scheme limits you to 4 parallel disks of 15
	    partitions each.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/pcd0</filename></glossterm>

	    <glossdef><para>Parallel port CD ROM drives.  These are numbered
	    from 0 onwards.  All are block devices on major node 46.
	    <filename>/dev/pcd0</filename> is on minor node 0 with
	    subsequent drives being on minor nodes 1, 2, 3
	    etc.</para></glossdef></glossentry>


        <glossentry>
	<glossterm><filename>/dev/pt0</filename></glossterm>
	
	    <glossdef><para>Parallel port tape devices.  Tapes do not have
	    partitions so these are just numbered sequentially.  They are
	    character devices on major node 96.  The minor node numbers
	    start from 0 for <filename>/dev/pt0</filename>, 1 for
	    <filename>/dev/pt1</filename>, and so on.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/parport0</filename></glossterm>
	
	    <glossdef><para>The raw parallel ports.  Most devices which are
	    attached to parallel ports have their own drivers.  This is a
	    device to access the port directly.  It is a character device on
	    major node 99 with minor node 0.  Subsequent devices after the
	    first are numbered sequentially incrementing the minor
	    node.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/random</filename> or <filename>/dev/urandom</filename></glossterm>
	
	    <glossdef><para>These are kernel random number generators.
	    <filename>/dev/random</filename> is a non-deterministic
	    generator which means that the value of the next number cannot
	    be guessed from the preceding ones.  It uses the entropy of the
	    system hardware to generate numbers.  When it has no more
	    entropy to use then it must wait until it has collected more
	    before it will allow any more numbers to be read from it.
	    <filename>/dev/urandom</filename> works similarly.  Initially it
	    also uses the entropy of the system hardware, but when there is
	    no more entropy to use it will continue to return numbers using
	    a pseudo random number generating formula.  This is considered
	    to be less secure for vital purposes such as cryptographic key
	    pair generation.  If security is your overriding concern then
	    use <filename>/dev/random</filename>, if speed is more important
	    then <filename>/dev/urandom</filename> works fine.  They are
	    character devices on major node 1 with minor nodes 8 for
	    <filename>/dev/random</filename> and 9 for
	    <filename>/dev/urandom</filename>.</para></glossdef></glossentry>
	    
	<glossentry>
	<glossterm><filename>/dev/zero</filename></glossterm>
	
	    <glossdef><para>This is a simple way of getting many 0s.  Every
	    time you read from this device it will return 0.  This can be
	    useful sometimes, for example when you want a file of fixed
	    length but don't really care what it contains.  It is a
	    character device on major node 1 and minor node
	    5.</para></glossdef></glossentry>
	

</glosslist>	
	    
</sect1>

</chapter>


<chapter>
<title>Using Disks and Other Storage Media</title>

	<blockquote><para><quote>On a clear disk you can seek forever.
	</quote></para></blockquote>

<!--
% the following metas need too much work for the next version
%
%	\meta copying a directory/disk verbatim
%
%	\meta disaster recovery: program to scan for ext2 superblocks
%
%	\meta explain lost+found; how to fix a filesystem; what to do when
%	there is a bad block; identifying the file that has the bad block
%	
%	\meta chart that shows characteristics of various fs: max size,
%	max file size, usable as root, max name length, speed, support
%
%	\meta 
%	Recovering from a bad MBR or super block.
%	Manually remounting (ro->rw, rw->ro, when, why)
%	automounting
%	MD patches
%	Why does Linux read/write disk in background?
%	how to mount a dos disk so that everyone can access it?
%	supermount
%	ide disks map away bad sectors (until they're too many, then
%	use badblocks)
%	mounting: mountee root becomes mount point, e.g. 
permissions/ownership
%	linux has maximum of 15 partitions (not inherent in partition
%		scheme!)
%	max ext2 part size is 2TB, file 2 GB
%	ext2 fragmentation
%	list important device files for disks et al as a table
-->

        <para>When you install or upgrade your system, you need to do a
        fair amount of work on your disks.  You have to make filesystems on
	your disks so that files can be stored on them and reserve
        space for the different parts of your system.</para>

        <para>This chapter explains all these initial activities.  Usually,
        once you get your system set up, you won't have to go through the
	work again, except for using floppies.  You'll need to come back to
	this chapter if you add a new disk or want to fine-tune your disk usage.<para>

        <para>The basic tasks in administering disks are:

	<itemizedlist>

	<listitem><para>
        Format your disk.  This does various things to prepare it for use,
	such as checking for bad sectors.  (Formatting is nowadays
	not necessary for most hard disks.)</para></listitem>

	<listitem><para>
        Partition a hard disk, if you want to use it for several activities
	that aren't supposed to interfere with one another. One reason for
	partitioning is to store different operating systems on the same
	disk.  Another reason is to keep user files separate from system
	files, which simplifies back-ups and helps protect the system files
	from corruption.
	</para></listitem>

	<listitem><para>
        Make a filesystem (of a suitable type) on each disk or partition.
	The disk means nothing to Linux until you make a filesystem; then
	files can be created and accessed on it.
	</para></listitem>

	<listitem><para>
        Mount different filesystems to form a single tree structure, either
	automatically, or manually as needed.  (Manually mounted filesystems
	usually need to be unmounted manually as well.)
	</para></listitem>

	</itemizedlist>

	<para><xref linkend="memory-management"> contains information
	about virtual memory and disk caching, of which you also need
	to be aware when using disks.</para>

<sect1>
<title>Two kinds of devices</title>

	<para>UNIX, and therefore Linux, recognises two different
	kinds of device: random-access block devices (such as disks), and
	character devices (such as tapes and serial lines), some of which
	may be serial, and some random-access.  Each supported device is
	represented in the filesystem as a <glossterm>device
	file</glossterm>.  When you read or write a device file, the data
	comes from or goes to the device it represents.  This way no special
	programs (and no special application programming methodology, such
	as catching interrupts or polling a serial port) are necessary to
	access devices; for example, to send a file to the printer, one
	could just say

<screen>
<prompt>$</prompt> <userinput>cat filename &gt; /dev/lp1</userinput>
<prompt>$</prompt>
</screen>

	and the contents of the file are printed (the file must, of course,
	be in a form that the printer understands).  However, since it is
	not a good idea to have several people cat their files to the
	printer at the same time, one usually uses a special program to send
	the files to be printed (usually <command>lpr</command>). This
	program makes sure that only one file is being printed at a time,
	and will automatically send files to the printer as soon as it
	finishes with the previous file.  Something similar is needed for
	most devices.  In fact, one seldom needs to worry
	about device files at all.</para>

	<para>Since devices show up as files in the filesystem (in the
	<filename>/dev</filename> directory), it is easy to see just what
	device files exist, using <command>ls</command> or another suitable
	command.  In the output of <command>ls -l</command>, the first
	column contains the type of the file and its permissions.  For
	example, inspecting a serial device might give

<screen>
<prompt>$</prompt> <userinput>ls -l /dev/ttyS0</userinput>
<computeroutput>crw-rw-r--    1 root     dialout    4,  64 Aug 19 18:56 /dev/ttyS0</computeroutput>
<prompt>$</prompt>
</screen>

	The first character in the first column, i.e.,
	`<literal>c</literal>' in <literal>crw-rw-rw-</literal> above, tells
	an informed user the type of the file, in this case a character
	device.  For ordinary files, the first character is
	`<literal>-</literal>', for directories it is
	`<literal>d</literal>', and for block devices
	`<literal>b</literal>'; see the <command>ls</command> man page
	for further information.</para>

	<para>Note that usually all device files exist even though the
	device itself might be not be installed.  So just because you have a
	file <filename>/dev/sda</filename>, it doesn't mean that you really
	do have an SCSI hard disk.  Having all the device files makes the
	installation programs simpler, and makes it easier to add new
	hardware (there is no need to find out the correct parameters
	for and create the device files for the new device).</para>

</sect1>

<sect1>
<title>Hard disks</title>

	<para>This subsection introduces terminology related to hard
	disks.	If you already know the terms and concepts, you can skip
	this subsection.</para>

	<para>See <xref linkend="hd-schematic"> for a schematic picture
	of the important parts in a hard disk.	A hard disk consists of one
	or more circular <glossterm>platters</glossterm>,
	
		<footnote><para>The platters are made of a hard
		substance, e.g., aluminium, which gives the hard disk
		its name.</para></footnote>
		
	of which either or both <glossterm>surfaces</glossterm> are coated
	with a magnetic substance used for recording the data.	For each
	surface, there is a <glossterm>read-write head</glossterm> that
	examines or alters the recorded data.  The platters rotate on a
	common axis; typical rotation speed is 5400 or 7200 rotations per
	minute, although high-performance hard disks have higher speeds and
	older disks may have lower speeds. The heads move along the radius
	of the platters; this movement combined with the rotation of the
	platters allows the head to access all parts of the surfaces.</para>

	<para>The processor (CPU) and the actual disk communicate through
	a <glossterm>disk controller</glossterm>.  This relieves the rest of
	the computer from knowing how to use the drive, since the
	controllers for different types of disks can be made to use the same
	interface towards the rest of the computer.  Therefore, the computer
	can say just ``hey disk, give me what I want'', instead of a long
	and complex series of electric signals to move the head to the
	proper location and waiting for the correct position to come under
	the head and doing all the other unpleasant stuff necessary. (In
	reality, the interface to the controller is still complex, but much
	less so than it would otherwise be.) The controller may also do
	other things, such as caching, or automatic bad sector 
	replacement.</para>

	<para>The above is usually all one needs to understand about the
	hardware.  There are also other things, such as the motor that
	rotates the platters and moves the heads, and the electronics that
	control the operation of the mechanical parts, but they are mostly
	not relevant for understanding the working principles of a hard 
	disk.</para>

	<para>The surfaces are usually divided into concentric rings,
	called <glossterm>tracks</glossterm>, and these in turn are divided
	into <glossterm>sectors</glossterm>.  This division is used to
	specify locations on the hard disk and to allocate disk space to
	files.  To find a given place on the hard disk, one might say
	``surface 3, track 5, sector 7''.  Usually the number of sectors is
	the same for all tracks, but some hard disks put more sectors in
	outer tracks (all sectors are of the same physical size, so more of
	them fit in the longer outer tracks). Typically, a sector will hold
	512 bytes of data.  The disk itself
	can't handle smaller amounts of data than one sector.</para>

		<figure id="hd-schematic" float="1">
		<title>A schematic picture of a hard disk.</title>
		<graphic fileref="hd-schematic"></graphic>
		</figure>

	<para>Each surface is divided into tracks (and sectors) in
	the same way.  This means that when the head for one surface is on a
	track, the heads for the other surfaces are also on the
	corresponding tracks.  All the corresponding tracks taken together
	are called a <glossterm>cylinder</glossterm>.	It takes time to
	move the heads from one track (cylinder) to another, so by placing
	the data that is often accessed together (say, a file) so that it is
	within one cylinder, it is not necessary to move the heads to read
	all of it.  This improves performance. It is not always possible to
	place files like this; files that are stored in several places on
	the disk are called
	<glossterm>fragmented</glossterm>.</para>

	<para>The number of surfaces (or heads, which is the same thing),
	cylinders, and sectors vary a lot; the specification of the number
	of each is called the <glossterm>geometry</glossterm> of a hard
	disk.  The geometry is usually stored in a special, battery-powered
	memory location called the <glossterm>CMOS RAM</glossterm>, from
	where the operating system can fetch it during bootup or driver 
	initialisation.</para>

	<para>Unfortunately, the BIOS
	
		<footnote><para>The BIOS is some built-in software stored on
		ROM chips.  It takes care, among other things, of the
		initial stages of booting.</para></footnote>
		
	has a design limitation, which makes it impossible to specify a
	track number that is larger than 1024 in the CMOS RAM, which is too
	little for a large hard disk.  To overcome this, the hard disk
	controller lies about the geometry, and <glossterm>translates the
	addresses</glossterm> given by the computer into something that fits
	reality.  For example, a hard disk might have 8 heads, 2048 tracks,
	and 35 sectors per track.
	
		<footnote><para>The numbers are completely
		imaginary.</para></footnote>
		
	Its controller could lie to the computer and claim that it has 16
	heads, 1024 tracks, and 35 sectors per track, thus not exceeding the
	limit on tracks, and translates the address that the computer gives
	it by halving the head number, and doubling the track number.  The
	mathematics can be more complicated in reality, because the numbers
	are not as nice as here (but again, the details are not relevant for
	understanding the principle). This translation distorts the
	operating system's view of how the disk is organised, thus making it
	impractical to use the all-data-on-one-cylinder trick to boost 
	performance.</para>

	<para>The translation is only a problem for IDE disks.	SCSI disks
	use a sequential sector number (i.e., the controller translates a
	sequential sector number to a head, cylinder, and sector triplet),
	and a completely different method for the CPU to talk with the
	controller, so they are insulated from the problem. Note, however,
	that the computer might not know the real geometry of an SCSI disk 
	either.</para>

	<para>Since Linux often will not know the real geometry of a disk,
	its filesystems don't even try to keep files within a single
	cylinder.  Instead, it tries to assign sequentially numbered sectors
	to files, which almost always gives similar performance. The issue
	is further complicated by on-controller caches, and automatic 
	prefetches done by the controller.</para>

	<para>Each hard disk is represented by a separate device
	file.  There can (usually) be only two or four IDE hard disks. These
	are known as <filename>/dev/hda</filename>,
	<filename>/dev/hdb</filename>, <filename>/dev/hdc</filename>, and
	<filename>/dev/hdd</filename>, respectively.  SCSI hard disks are
	known as <filename>/dev/sda</filename>,
	<filename>/dev/sdb</filename>, and so on.  Similar naming
	conventions exist for other hard disk types; see <xref
	linkend="device-list"> for more information.  Note that the device
	files for the hard disks give access to the entire disk, with no
	regard to partitions (which will be discussed below), and it's easy
	to mess up the partitions or the data in them if you aren't careful.
	The disks' device files are usually used only to get access to the
	master boot record (which will also be discussed below).</para>

</sect1>

<sect1>
<title>Floppies</title>

	<para>A floppy disk consists of a flexible membrane covered on one
	or both sides with similar magnetic substance as a hard disk. The
	floppy disk itself doesn't have a read-write head, that is included
	in the drive.  A floppy corresponds to one platter in a hard disk,
	but is removable and one drive can be used to access different
	floppies, and the same floppy can be read by many drives, whereas
	the hard disk is one indivisible unit.</para>

	<para>Like a hard disk, a floppy is divided into tracks and sectors
	(and the two corresponding tracks on either side of a floppy
	form a cylinder), but there are many fewer of them than on a
	hard disk.</para>

	<para>A floppy drive can usually use several different types of disks;
	for example, a 3.5 inch drive can use both 720 kB and 1.44 MB disks.
	Since the drive has to operate a bit differently and the operating
	system must know how big the disk is, there are many device files
	for floppy drives, one per combination of drive and disk type.
	Therefore, <filename>/dev/fd0H1440</filename> is the first floppy 
	drive (fd0), which must be a 3.5 inch drive, using a 3.5 inch, high
	density disk (H) of size 1440 kB (1440), i.e., a normal 3.5 inch HD
	floppy.
	</para>

	<para>The names for floppy drives are complex, however, and Linux
	therefore has a special floppy device type that automatically
	detects the type of the disk in the drive.  It works by trying to
	read the first sector of a newly inserted floppy using different
	floppy types until it finds the correct one. This naturally requires
	that the floppy is formatted first. The automatic devices are called
	<filename>/dev/fd0</filename>, <filename>/dev/fd1</filename>, and so 
	on.</para>

	<para>The parameters the automatic device uses to access a disk can
	also be set using the program <command>setfdprm</command>.  This can
	be useful if you need to use disks that do not follow any usual
	floppy sizes, e.g., if they have an unusual number of sectors, or if
	the autodetecting for some reason fails and the proper device file is 
	missing.</para>

	<para>Linux can handle many nonstandard floppy disk formats
	in addition to all the standard ones.  Some of these require using
	special formatting programs.  We'll skip these disk types for now,
	but in the mean time you can examine the
	<filename>/etc/fdprm</filename> file.  It specifies the settings
	that <command>setfdprm</command> recognises.</para>

	<para>The operating system must know when a disk has been changed in
	a floppy drive, for example, in order to avoid using cached data
	from the previous disk.  Unfortunately, the signal line that is used
	for this is sometimes broken, and worse, this won't always be
	noticeable when using the drive from within MS-DOS. If you are
	experiencing weird problems using floppies, this might be the
	reason.  The only way to correct it is to repair the floppy drive.</para>

</sect1>

<sect1>
<title>CD-ROMs</title>

	<para>A CD-ROM drive uses an optically read, plastic coated disk.
	The information is recorded on the surface of the disk
	
		<footnote><para>That is, the surface inside the disk, on 
		the metal disk inside the plastic coating.</para></footnote>
		
	in small `holes' aligned along a spiral from the centre to the edge.
	The drive directs a laser beam along the spiral to read the disk.
	When the laser hits a hole, the laser is reflected in one way; when
	it hits smooth surface, it is reflected in another way.  This makes
	it easy to code bits, and therefore information.  The rest is easy, 
	mere mechanics.</para>

	<para>CD-ROM drives are slow compared to hard disks.  Whereas a
	typical hard disk will have an average seek time less than 15
	milliseconds, a fast CD-ROM drive can use tenths of a second for
	seeks.  The actual data transfer rate is fairly high at hundreds of
	kilobytes per second.  The slowness means that CD-ROM drives are not
	as pleasant to use as hard disks (some Linux distributions provide
	`live' filesystems on CD-ROMs, making it unnecessary to copy the
	files to the hard disk, making installation easier and saving a lot
	of hard disk space), although it is still possible.  For installing
	new software, CD-ROMs are very good, since maximum speed is not
	essential during installation.</para>

	<para>There are several ways to arrange data on a CD-ROM.  The most
	popular one is specified by the international standard ISO 9660.
	This standard specifies a very minimal filesystem, which is even
	more crude than the one MS-DOS uses.  On the other hand, it is so
	minimal that every operating system should be able to map it to its 
	native system.</para>

	<para>For normal UNIX use, the ISO 9660 filesystem is not usable, so
	an extension to the standard has been developed, called the Rock
	Ridge extension.  Rock Ridge allows longer filenames, symbolic
	links, and a lot of other goodies, making a CD-ROM look more or less
	like any contemporary UNIX filesystem. Even better, a Rock Ridge
	filesystem is still a valid ISO 9660 filesystem, making it usable by
	non-UNIX systems as well. Linux supports both ISO 9660 and the Rock
	Ridge extensions;  the extensions are recognised and used 
	automatically.</para>

	<para>The filesystem is only half the battle, however.  Most CD-ROMs 
	contain data that requires a special program to access, and most of
	these programs do not run under Linux (except, possibly, under
	dosemu, the Linux MS-DOS emulator, or wine, the Windows emulator.
	
	        <footnote><para>Ironically perhaps, wine actually stands
		for ``Wine Is Not an Emulator''.  Wine, more strictly, is an
		API (Application Program Interface) replacement. Please see
		the wine documentation at <ulink
		url="http://www.winehq.com">http://www.winehq.com</ulink>
		for more information.</para></footnote>
	
	There is also VMWare, a commercial product which emulates an
	entire x86 machine in software

                <footnote><para>See the VMWare website, <ulink
		url="http://www.vmware.com">http://www.vmware.com</ulink>
		for more information.</para></footnote>)
	
	.</para>

	<para>A CD-ROM drive is accessed via the corresponding device file.
	There are several ways to connect a CD-ROM drive to the computer:
	via SCSI, via a sound card, or via EIDE.  The hardware hacking
	needed to do this is outside the scope of this book, but the
	type of connection decides the device file.</para>
	
</sect1>

<sect1>
<title>Tapes</title>

	<para>A tape drive uses a tape, similar
	
		<footnote><para>But completely
		different, of course.</para></footnote>
		
	to cassettes used for music.  A tape is serial in nature, which
	means that in order to get to any given part of it, you first have
	to go through all the parts in between.  A disk can be accessed
	randomly, i.e., you can jump directly to any place on the disk.
	The serial access of tapes makes them slow.</para>

	<para>On the other hand, tapes are relatively cheap to make,
	since they do not need to be fast.  They can also easily be made
	quite long, and can therefore contain a large amount of data. This
	makes tapes very suitable for things like archiving and backups,
	which do not require large speeds, but benefit from
	low costs and large storage capacities.</para>

</sect1>

<sect1>
<title>Formatting</title>

	<para><glossterm>Formatting</glossterm> is the process of writing marks 
	on the magnetic media that are used to mark tracks and sectors.
	Before a disk is formatted, its magnetic surface is a complete mess
	of magnetic signals.  When it is formatted, some order is brought
	into the chaos by essentially drawing lines where the tracks go, and
	where they are divided into sectors.  The actual details are not
	quite exactly like this, but that is irrelevant.  What is important
	is that a disk cannot be used unless it has been formatted.</para>

	<para>The terminology is a bit confusing here: in MS-DOS and MS 
	Windows, the word formatting is used to cover also the process of
	creating a filesystem (which will be discussed below).  There, the
	two processes are often combined, especially for floppies.  When the
	distinction needs to be made, the real formatting is called
	<glossterm>low-level formatting</glossterm>, while making the 
	filesystem is called <glossterm>high-level formatting</glossterm>.
	In UNIX circles, the two are called formatting and making a
	filesystem, so that's what is used in this book as well.</para>

	<para>For IDE and some SCSI disks the formatting is actually
	done at the factory and doesn't need to be repeated; hence most
	people rarely need to worry about it.  In fact, formatting a hard
	disk can cause it to work less well, for example because a disk
	might need to be formatted in some very special way to
	allow automatic bad sector replacement to work.</para>

	<para>Disks that need to be or can be formatted often require a
	special program anyway, because the interface to the formatting
	logic inside the drive is different from drive to drive. The
	formatting program is often either on the controller BIOS, or is
	supplied as an MS-DOS program; neither of these can easily
	be used from within Linux.</para>

	<para>During formatting one might encounter bad spots on the
	disk, called <glossterm>bad blocks</glossterm> or <glossterm>bad
	sectors</glossterm>.  These are sometimes handled by the drive
	itself, but even then, if more of them develop, something needs to
	be done to avoid using those parts of the disk.  The logic to do
	this is built into the filesystem; how to add the information into
	the filesystem is described below.  Alternatively, one might create
	a small partition that covers just the bad part of the disk; this
	approach might be a good idea if the bad spot is very large, since
	filesystems can sometimes have trouble with very large bad areas.</para>

	<para>Floppies are formatted with <command>fdformat</command>.  The 
	floppy device file to use is given as the parameter.  For example,
	the following command would format a high density, 3.5 inch floppy
	in the first floppy drive:

        <screen>
	<prompt>$</prompt> <userinput>fdformat /dev/fd0H1440</userinput>
	<computeroutput>Double-sided, 80 tracks, 18 sec/track. Total capacity 
	1440 kB.</computeroutput>
	<computeroutput>Formatting ... done</computeroutput>
	<computeroutput>Verifying ... done</computeroutput>
	<prompt>$</prompt>
	</screen>

	Note that if you want to use an autodetecting device (e.g.,
	<filename>/dev/fd0</filename>), you <emphasis>must</emphasis> set 
	the parameters of the device with <command>setfdprm</command> first.
	To achieve the same effect as above, one would have to do the
	following:

        <screen>
	<prompt>$</prompt> <userinput>setfdprm /dev/fd0 1440/1440</userinput>
	<prompt>$</prompt> <userinput>fdformat /dev/fd0</userinput>
	<computeroutput>Double-sided, 80 tracks, 18 sec/track. Total capacity 
	1440 kB.</computeroutput>
	<computeroutput>Formatting ... done</computeroutput>
	<computeroutput>Verifying ... done</computeroutput>
	<prompt>$</prompt>
	</screen>

	It is usually more convenient to choose the correct device file that
	matches the type of the floppy.  Note that it is unwise to format
	floppies to contain more information than what they are
	designed for.</para>

	<para><command>fdformat</command> will also validate the floppy, 
	i.e., check it for bad blocks.  It will try a bad block several
	times (you can usually hear this, the drive noise changes
	dramatically). If the floppy is only marginally bad (due to dirt on
	the read/write head, some errors are false signals),
	<command>fdformat</command> won't complain, but a real error will
	abort the validation process. The kernel will print log messages for
	each I/O error it finds; these will go to the console or, if
	<command>syslog</command> is being used, to the file
	<filename>/usr/log/messages</filename>.  <command>fdformat</command>
	itself won't tell where the error is (one usually doesn't care,
	floppies are cheap enough that a bad one is automatically thrown
	away).

        <screen>
	<prompt>$</prompt> <userinput>fdformat /dev/fd0H1440</userinput>
	<computeroutput>Double-sided, 80 tracks, 18 sec/track. Total capacity 
	1440 kB.</computeroutput>
	<computeroutput>Formatting ... done</computeroutput>
	<computeroutput>Verifying ... read: Unknown error</computeroutput>
	<prompt>$</prompt>
	</screen>

	The <command>badblocks</command> command can be used to search any 
	disk or partition for bad blocks (including a floppy).  It does not
	format the disk, so it can be used to check even existing
	filesystems.  The example below checks a 3.5 inch floppy with two
	bad blocks.

        <screen>
	<prompt>$</prompt> <userinput>badblocks /dev/fd0H1440 1440</userinput>
	<computeroutput>718</computeroutput>
	<computeroutput>719</computeroutput>
	<prompt>$</prompt>
	</screen>

	<command>badblocks</command> outputs the block numbers of the bad
	blocks it finds.  Most filesystems can avoid such bad blocks. They
	maintain a list of known bad blocks, which is initialised when the
	filesystem is made, and can be modified later.	The initial search
	for bad blocks can be done by the <command>mkfs</command> command
	(which initialises the filesystem), but later checks should be done
	with <command>badblocks</command> and the new blocks should be added
	with <command>fsck</command>.	We'll describe
	<command>mkfs</command>
	and <command>fsck</command> later.</para>

	<para>Many modern disks automatically notice bad blocks, and attempt
	to fix them by using a special, reserved good block instead. This is
	invisible to the operating system.  This feature should be
	documented in the disk's manual, if you're curious if it is
	happening.  Even such disks can fail, if the number of bad blocks
	grows too large, although chances are that by then the disk
	will be so rotten as to be unusable.</para>

</sect1>

<sect1>
<title>Partitions</title>

	<para>A hard disk can be divided into several
	<glossterm>partitions</glossterm>.  Each partition functions as if
	it were a separate hard disk.  The idea is that if you have one hard
	disk, and want to have, say, two operating systems on it, you can
	divide the disk into two partitions.  Each operating system uses its
	partition as it wishes and doesn't touch the other ones.  This way
	the two operating systems can co-exist peacefully on the same hard
	disk. Without partitions one would have to buy a hard disk for each 
	operating system.</para>

	<para>Floppies are not usually partitioned.  There is no technical reason
	against this, but since they're so small, partitions would be useful
	only very rarely.  CD-ROMs are usually also not partitioned, since
	it's easier to use them as one big disk, and there is seldom a need
	to have several operating systems on one.</para>

<sect2>
<title>The MBR, boot sectors and partition table</title>

	<para>The information about how a hard disk has been partitioned
	is stored in its first sector (that is, the first sector of the
	first track on the first disk surface).  The first sector is the
	<glossterm>master boot record</glossterm> (MBR) of the disk; this is
	the sector that the BIOS reads in and starts when the machine is
	first booted.  The master boot record contains a small program that
	reads the partition table, checks which partition is active (that
	is, marked bootable), and reads the first sector of that partition,
	the partition's <glossterm>boot sector</glossterm> (the MBR is also
	a boot sector, but it has a special status and therefore a special
	name).  This boot sector contains another small program that reads
	the first part of the operating system stored on that partition
	(assuming it is bootable), and then starts it.</para>

	<para>The partitioning scheme is not built into the hardware, or
	even into the BIOS.  It is only a convention that many operating
	systems follow.  Not all operating systems do follow it, but they
	are the exceptions.  Some operating systems support partitions, but
	they occupy one partition on the hard disk, and use their internal
	partitioning method within that partition.  The latter type exists
	peacefully with other operating systems (including Linux), and does
	not require any special measures, but an operating system that
	doesn't support partitions cannot co-exist on the same disk with any 
	other operating system.</para>

	<para>As a safety precaution, it is a good idea to write down the
	partition table on a piece of paper, so that if it ever corrupts you
	don't have to lose all your files.  (A bad partition table can be
	fixed with <command>fdisk</command>).  The relevant information is
	given by the <command>fdisk -l</command> command:

        <screen>
	<prompt>$</prompt> <userinput>fdisk -l /dev/hda</userinput>
	<computeroutput></computeroutput>
	<computeroutput>Disk /dev/hda: 15 heads, 57 sectors, 790 cylinders</computeroutput>
	<computeroutput>Units = cylinders of 855 * 512 bytes</computeroutput>
	<computeroutput></computeroutput>
	<computeroutput>   Device Boot  Begin   Start     End  Blocks   Id  System</computeroutput>
	<computeroutput>/dev/hda1           1       1      24   10231+  82  Linux swap</computeroutput>
	<computeroutput>/dev/hda2          25      25      48   10260   83  Linux native</computeroutput>
	<computeroutput>/dev/hda3          49      49     408  153900   83  Linux native</computeroutput>
	<computeroutput>/dev/hda4         409     409     790  163305    5  Extended</computeroutput>
	<computeroutput>/dev/hda5         409     409     744  143611+  83  Linux native</computeroutput>
	<computeroutput>/dev/hda6         745     745     790   19636+  83  Linux native</computeroutput>
	<prompt>$</prompt>
	</screen>

</sect2>

<sect2>
<title>Extended and logical partitions</title>

	<para>The original partitioning scheme for PC hard disks allowed
	only four partitions.  This quickly turned out to be too little in
	real life, partly because some people want more than four operating
	systems (Linux, MS-DOS, OS/2, Minix, FreeBSD, NetBSD, or Windows/NT,
	to name a few), but primarily because sometimes it is a good idea to
	have several partitions for one operating system.  For example, swap
	space is usually best put in its own partition for Linux instead of
	in the main Linux partition for reasons of speed (see below).</para>

	<para>To overcome this design problem, <glossterm>extended 
	partitions</glossterm> were invented.  This trick allows
	partitioning a <glossterm>primary partition</glossterm> into
	sub-partitions.  The primary partition thus subdivided is the
	<glossterm>extended partition</glossterm>; the sub-partitions are
	<glossterm>logical partitions</glossterm>.  They behave like primary
	partitions, but are created differently.  There is no speed
	difference between them.</para>

	<para>The partition structure of a hard disk might look like that
	in <xref linkend="hard-disk-layout">.  The disk is divided into
	three primary partitions, the second of which is divided into two
	logical partitions.  Part of the disk is not partitioned at all.
	The disk as a whole and each primary partition has a boot sector.</para>

		<figure id="hard-disk-layout" float="1">
		<title>A sample hard disk partitioning.</title>
		<graphic fileref="hd-layout"></graphic>
		</figure>

</sect2>

<sect2>
<title>Partition types</title>

	<para>The partition tables (the one in the MBR, and the ones for
	extended partitions) contain one byte per partition that identifies
	the type of that partition.  This attempts to identify the operating
	system that uses the partition, or what it uses it for.  The purpose
	is to make it possible to avoid having two operating systems
	accidentally using the same partition.  However, in reality,
	operating systems do not really care about the partition type byte;
	e.g., Linux doesn't care at all what it is.  Worse, some of them use
	it incorrectly; e.g., at least some versions of DR-DOS ignore the
	most significant bit of the byte, while others don't.</para>

	<para>There is no standardisation agency to specify what each byte
	value means, but some commonly accepted ones are included in in
	<xref linkend="partition-ids">.  A more complete list is available
	in the Linux <command>fdisk</command> program.</para>

	<table id="partition-ids"> 
	<title>Partition types (from the Linux <command>fdisk</command> program).</title>
	
	<tgroup cols=6>
	<tbody>
	
	<row>
	<entry>0</entry> <entry>Empty</entry>
	<entry>40</entry> <entry>Venix 80286</entry>
	<entry>94</entry> <entry>Amoeba BBT</entry>
	</row>
	
	<row>
	<entry>1</entry> <entry>DOS 12-bit FAT</entry>
	<entry>51</entry> <entry>Novell?</entry>
	<entry>a5</entry> <entry>BSD/386</entry>
	</row>
	
	<row>
	<entry>2</entry> <entry>XENIX root</entry>
	<entry>52</entry> <entry>Microport</entry>
	<entry>b7</entry> <entry>BSDI fs</entry>
	</row>
	
	<row>
	<entry>3</entry> <entry>XENIX usr</entry>
	<entry>63</entry> <entry>GNU HURD</entry>
	<entry>b8</entry> <entry>BSDI swap</entry>
	</row>
	
	<row>
	<entry>4</entry> <entry>DOS 16-bit FAT &lt;32M</entry>
	<entry>64</entry> <entry>Novell</entry>
	<entry>c7</entry> <entry>Syrinx</entry>
	</row>
	
	<row>
	<entry>5</entry> <entry>Extended</entry>
	<entry>75</entry> <entry>PC/IX</entry>
	<entry>db</entry> <entry>CP/M</entry>
	</row>
	
	<row>
	<entry>6</entry> <entry>DOS 16-bit &gt;=32M</entry>
	<entry>80</entry> <entry>Old MINIX</entry>
	<entry>e1</entry> <entry>DOS access</entry>
	</row>
	
	<row>
	<entry>7</entry> <entry>OS/2 HPFS</entry>
	<entry>81</entry> <entry>Linux/MINIX</entry>
	<entry>e3</entry> <entry>DOS R/O</entry>
	</row>
	
	<row>
	<entry>8</entry> <entry>AIX</entry>
	<entry>82</entry> <entry>Linux swap</entry>
	<entry>f2</entry> <entry>DOS secondary</entry>
	</row>
	
	<row>
	<entry>9</entry> <entry>AIX bootable</entry>
	<entry>83</entry> <entry>Linux native</entry>
	<entry>ff</entry> <entry>BBT</entry>
	</row>
	
	<row>
	<entry>a</entry> <entry>OS/2 Boot Manager</entry>
	<entry>93</entry> <entry>Amoeba</entry>
	<entry></entry> <entry></entry>
	</row>
	
	</tbody>
	</tgroup>
	</table>

</sect2>

<sect2>
<title>Partitioning a hard disk</title>

	<para>There are many programs for creating and removing
	partitions.  Most operating systems have their own, and it can be a
	good idea to use each operating system's own, just in case it does
	something unusual that the others can't. Many of the programs are
	called <command>fdisk</command>, including the Linux one, or
	variations thereof.  Details on using the Linux
	<command>fdisk</command> are given on its man page.  The
	<command>cfdisk</command> command is similar to
	<command>fdisk</command>, but has a nicer (full screen) user 
	interface.</para>

	<para>When using IDE disks, the boot partition (the partition
	with the bootable kernel image files) must be completely within the
	first 1024 cylinders.  This is because the disk is used via the BIOS
	during boot (before the system goes into protected mode), and BIOS
	can't handle more than 1024 cylinders. It is sometimes possible to
	use a boot partition that is only partly within the first 1024
	cylinders.  This works as long as all the files that are read with
	the BIOS are within the first 1024 cylinders.  Since this is
	difficult to arrange, it is <emphasis>a very bad idea</emphasis> to
	do it; you never know when a kernel update or disk defragmentation
	will result in an unbootable system.  Therefore, make sure your boot
	partition is completely within the first 1024 cylinders
		
		<footnote><para>This may no longer be true with newer
		versions of LILO that support LBA (Logical Block
		Addressing).  Consult the documentation for your
		distribution to see if it has a version of LILO where
		LBA is supported.</para></footnote>
	
	.</para>

	<para>Some newer versions of the BIOS and IDE disks can, in fact,
	handle disks with more than 1024 cylinders.  If you have such a
	system, you can forget about the problem; if you aren't quite
	sure of it, put it within the first 1024 cylinders.</para>

	<para>Each partition should have an even number of sectors,
	since the Linux filesystems use a 1 kilobyte block size, i.e., two
	sectors.  An odd number of sectors will result in the last sector
	being unused.  This won't result in any problems, but it is ugly,
	and some versions of <command>fdisk</command> will warn about it.</para>

	<para>Changing a partition's size usually requires first backing up
	everything you want to save from that partition (preferably the
	whole disk, just in case), deleting the partition, creating new
	partition, then restoring everything to the new partition. If the
	partition is growing, you may need to adjust the sizes (and backup and 
	restore) of the adjoining partitions as well.</para>

	<para>Since changing partition sizes is painful, it is preferable to
	get the partitions right the first time, or have an effective and
	easy to use backup system.  If you're installing from a media that
	does not require much human intervention (say, from CD-ROM, as
	opposed to floppies), it is often easy to play with different
	configuration at first. Since you don't already have data to back
	up, it is not so painful to modify partition sizes several times.</para>

	<para>There is a program for MS-DOS, called
	<command>fips</command>
		
		<footnote><para>The <command>fips</command> program is
		included in most Linux distributions.  The commercial
		partition manager ``Partition Magic'' also has a similar
		facility but with a nicer interface.  Please do remember
		that partitioning is dangerous.  Make
		<emphasis>sure</emphasis> you have a recent backup of
		any important data before you try changing partition
		sizes ``on the fly''.  The GNU program
		<command>parted</command> can resize other types of
		partitions as well as MS-DOS, but sometimes in a limited
		manner.  Consult the <command>parted</command> documentation
		before using it, better safe than sorry.
		</para></footnote>
	
	, which resizes an MS-DOS partition without requiring the backup and
	restore, but for other filesystems it is still necessary.</para>

</sect2>

<sect2>
<title>Device files and partitions</title>

	<para>Each partition and extended partition has its own
	device file.  The naming convention for these files is that a
	partition's number is appended after the name of the whole disk,
	with the convention that 1-4 are primary partitions (regardless of
	how many primary partitions there are) and number greater than 5 are
	logical partitions (regardless of within which primary partition
	they reside).  For example, <filename>/dev/hda1</filename> is the
	first primary partition on the first IDE hard disk, and
	<filename>/dev/sdb7</filename> is the third extended partition on
	the second SCSI hard disk.</para>

</sect2>

</sect1>

<sect1>
<title>Filesystems</title>

<sect2>
<title>What are filesystems?</title>

	<para>A <glossterm>filesystem</glossterm> is the methods and
	data structures that an operating system uses to keep track of files
	on a disk or partition; that is, the way the files are organised on
	the disk.  The word is also used to refer to a partition or disk
	that is used to store the files or the type of the filesystem.
	Thus, one might say ``I have two filesystems'' meaning one has two
	partitions on which one stores files, or that one is using the
	``extended filesystem'', meaning the type of the filesystem.</para>

        <para>The difference between a disk or partition and the 
	filesystem it contains is important.  A few programs (including,
	reasonably enough, programs that create filesystems) operate
	directly on the raw sectors of a disk or partition; if there is an
	existing file system there it will be destroyed or seriously
	corrupted.  Most programs operate on a filesystem, and therefore
	won't work on a partition that doesn't contain one (or that contains 
	one of the wrong type).</para>

	<para>Before a partition or disk can be used as a filesystem, it
	needs to be initialised, and the bookkeeping data structures need to
	be written to the disk.  This process is called
	<glossterm>making a filesystem</glossterm>.</para>

	<para>Most UNIX filesystem types have a similar general
	structure, although the exact details vary quite a bit. The central
	concepts are <glossterm>superblock</glossterm>,
	<glossterm>inode</glossterm>, <glossterm>data block</glossterm>,
	<glossterm>directory block</glossterm>, and <glossterm>indirection
	block</glossterm>.  The superblock contains information about the
	filesystem as a whole, such as its size (the exact information here
	depends on the filesystem).  An inode contains all information about
	a file, except its name.  The name is stored in the directory,
	together with the number of the inode. A directory entry consists of
	a filename and the number of the inode which represents the file.
	The inode contains the numbers of several data blocks, which are
	used to store the data in the file.  There is space only for a few
	data block numbers in the inode, however, and if more are needed,
	more space for pointers to the data blocks is allocated dynamically.
	These dynamically allocated blocks are indirect blocks; the name
	indicates that in order to find the data block, one has to find
	its number in the indirect block first.</para>

	<para>UNIX filesystems usually allow one to create a
	<glossterm>hole</glossterm> in a file (this is done with the 
	<function>lseek()</function> system call; check the manual page),
	which means that the filesystem just pretends that at a particular
	place in the file there is just zero bytes, but no actual disk
	sectors are reserved for that place in the file (this means that the
	file will use a bit less disk space). This happens especially often
	for small binaries, Linux shared libraries, some databases, and a
	few other special cases.  (Holes are implemented by storing a
	special value as the address of the data block in the indirect block
	or inode.  This special address means that no data block is
	allocated for that part of the file, ergo, there is a hole in the 
	file.)</para>

</sect2>

<sect2>
<title>Filesystems galore</title>

	<para>Linux supports several types of filesystems.  As of this
	writing the most important ones are:

	<glosslist>
	<glossentry>
	<glossterm>minix</glossterm>
		<glossdef><para>The oldest, presumed to be the most 
		reliable, but quite limited in features (some time stamps
		are missing, at most 30 character filenames) and restricted
		in capabilities (at most 64 MB per filesystem).
		</para></glossdef></glossentry>
		
	<glossentry>
	<glossterm>xia</glossterm>
		<glossdef><para>A modified version of the minix filesystem 
		that lifts the limits on the filenames and filesystem sizes,
		but does not otherwise introduce new features.  It is not
		very popular, but is reported to work very well.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm>ext2</glossterm>
		<glossdef><para>The most featureful of the native Linux 
		filesystems, currently also the most popular one.  It is
		designed to be easily upwards compatible, so that new
		versions of the filesystem code do not require re-making the
		existing filesystems.</para></glossdef></glossentry>

	<glossentry>
	<glossterm>ext</glossterm>
		<glossdef><para>An older version of ext2 that wasn't upwards
		compatible.  It is hardly ever used in new installations any
		more, and most people have converted to ext2.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm>reiserfs</glossterm>
	        <glossdef><para>A more robust filesystem.  Journalling is
		used which makes data loss less likely.  Journalling is a
		mechanism whereby a record is kept of transaction which are
		to be performed, or which have been performed.  This allows
		the filesystem to reconstruct itself fairly easily after
		damage caused by, for example, improper
		shutdowns.</para></glossdef></glossentry>

	</glosslist>
	</para>

	<para>In addition, support for several foreign filesystem exists,
	to make it easier to exchange files with other operating systems.
	These foreign filesystems work just like native ones, except that
	they may be lacking in some usual UNIX features, or have curious
	limitations, or other oddities.

	<glosslist>

	<glossentry>
	<glossterm>msdos</glossterm>
		<glossdef><para>Compatibility with MS-DOS (and OS/2 and
		Windows NT) FAT filesystems.</para></glossdef></glossentry>

	<glossentry>
	<glossterm>umsdos</glossterm>
		<glossdef><para>Extends the msdos filesystem driver under
		Linux to get long filenames, owners, permissions, links, and
		device files. This allows a normal msdos filesystem to be
		used as if it were a Linux one, thus removing the need for a
		separate partition for Linux.</para></glossdef></glossentry>
		
	<glossentry>
	<glossterm>vfat</glossterm>
		<glossdef><para>This is an extension of the FAT filesystem
		known as FAT32.  It supports larger disk sizes than FAT.
		Most MS Windows disks are vfat.</para></glossdef>
	</glossentry>

	<glossentry>
	<glossterm>iso9660</glossterm>
		<glossdef><para>The standard CD-ROM filesystem; the popular
		Rock Ridge extension to the CD-ROM standard that allows
		longer file names is supported automatically.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm>nfs</glossterm>
		<glossdef><para>A networked filesystem that allows sharing a
		filesystem between many computers to allow easy access to
		the files from all of them.</para></glossdef></glossentry>

	<glossentry>
	<glossterm>smbfs</glossterm>
		<glossdef><para>A networks filesystem which allows sharing
		of a filesystem with an MS Windows computer.  It is
		compatible with the Windows file sharing protocols.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm>hpfs</glossterm>
		<glossdef><para>The OS/2 filesystem.
		</para></glossdef></glossentry>

	<glossentry>
	<glossterm>sysv</glossterm>
		<glossdef><para>SystemV/386, Coherent, and Xenix filesystems.
		</para></glossdef></glossentry>

	</glosslist>
	</para>

	<para>The choice of filesystem to use depends on the situation.  If
	compatibility or other reasons make one of the non-native
	filesystems necessary, then that one must be used.  If one can
	choose freely, then it is probably wisest to use ext2, since it has
	all the features but does not suffer from lack of performance.</para>

	<para>There is also the proc filesystem, usually accessible as
	the <filename>/proc</filename> directory, which is not really a
	filesystem at all, even though it looks like one.  The proc
	filesystem makes it easy to access certain kernel data structures,
	such as the process list (hence the name). It makes these data
	structures look like a filesystem, and that filesystem can be
	manipulated with all the usual file tools.  For example, to get a
	listing of all processes one might use the command

<screen>
<prompt>$</prompt> <userinput>ls -l /proc</userinput>
<computeroutput>total 0
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95
dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99
-r--r--r--   1 root     root            0 Jan 31 20:37 devices
-r--r--r--   1 root     root            0 Jan 31 20:37 dma
-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems
-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts
-r--------   1 root     root      8654848 Jan 31 20:37 kcore
-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg
-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms
-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg
-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo
-r--r--r--   1 root     root            0 Jan 31 20:37 modules
dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self
-r--r--r--   1 root     root            0 Jan 31 20:37 stat
-r--r--r--   1 root     root            0 Jan 31 20:37 uptime
-r--r--r--   1 root     root            0 Jan 31 20:37 
version</computeroutput>
<prompt>$</prompt>
</screen>

	(There will be a few extra files that don't correspond to
	processes, though.  The above example has been shortened.)</para>

	<para>Note that even though it is called a filesystem, no part of 
	the proc filesystem touches any disk.  It exists only in the
	kernel's imagination.  Whenever anyone tries to look at any part of
	the proc filesystem, the kernel makes it look as if the part existed
	somewhere, even though it doesn't.  So, even though there is a
	multi-megabyte <filename>/proc/kcore</filename> file, it doesn't
	take any disk space. </sect2>

<sect2>
<title>Which filesystem should be used?</title>

	<para>There is usually little point in using many different
	filesystems.  Currently, ext2fs is the most popular one, and it is
	probably the wisest choice.  Depending on the overhead for
	bookkeeping structures, speed, (perceived) reliability,
	compatibility, and various other reasons, it may be advisable to use
	another file system.  This needs to be decided on a case-by-case
	basis.
		<footnote><para>Currently there are several filesystems vying
		for replacement of ext2, these include reiserfs and ext3.
		They include ``journalling''.  A definition and explanation
		of journalling is outside the (current) scope of this book,
		but put very simply it is a mechanism whereby the filesystem
		is more robust against power failure, or other inelegant
		shutdowns.  This makes data loss far less likely and so not
		surprisingly it is looking like it will be the standard
		in Linux filesystems eventually.</para></footnote>
	</para>
	
</sect2>

<sect2>
<title>Creating a filesystem</title>

	<para>Filesystems are created, i.e., initialised, with the 
	<command>mkfs</command> command.  There is actually a separate
	program for each filesystem type.  <command>mkfs</command> is just a
	front end that runs the appropriate program depending on the desired
	filesystem type.  The type is selected with the 
	<option>-t fstype</option> option.</para>

	<para>The programs called by <command>mkfs</command> have slightly
	different command line interfaces.  The common and most important
	options are summarised below; see the manual pages for more.

	<glosslist>
	<glossentry>
	<glossterm><option>-t fstype</option></glossterm>
		<glossdef><para>
		Select the type of the filesystem.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm><option>-c</option></glossterm>
		<glossdef><para>
		 Search for bad blocks and initialise the bad
		block list accordingly.
		</para></glossdef></glossentry>
	
	<glossentry>
	<glossterm>-l filename</glossterm>
		<glossdef><para>
		Read the initial bad block list from the name file.
		</para></glossdef></glossentry>
	</glosslist>
	</para>

	<para>To create an ext2 filesystem on a floppy, one would give the
	following commands:

<screen>
<prompt>$</prompt> <userinput>fdformat -n /dev/fd0H1440</userinput>
<computeroutput>Double-sided, 80 tracks, 18 sec/track. Total capacity 
1440 kB.
Formatting ... done</computeroutput>
<prompt>$</prompt> <userinput>badblocks /dev/fd0H1440 1440 $>$ 
bad-blocks</userinput>
<prompt>$</prompt> <userinput>mkfs -t ext2 -l bad-blocks 
/dev/fd0H1440</userinput>
<computeroutput>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done</computeroutput>
<prompt>$</prompt>
</screen>

	First, the floppy was formatted (the <option>-n</option> option
	prevents validation, i.e., bad block checking).  Then bad blocks
	were searched with <command>badblocks</command>, with the output
	redirected to a file, <filename>bad-blocks</filename>.	Finally, the
	filesystem was created, with the bad block list initialised
	by whatever <command>badblocks</command> found.</para>

	<para>The <option>-c</option> option could have been used with
	<command>mkfs</command> instead of <command>badblocks</command>
	and a separate file.  The example below does that.

<screen>
<prompt>$</prompt> <userinput>mkfs -t ext2 -c 
/dev/fd0H1440</userinput>
<computeroutput>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Checking for bad blocks (read-only test): done
Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done</computeroutput>
<prompt>$</prompt>
</screen>

	The <option>-c</option> option is more convenient than a separate 
	use of <command>badblocks</command>, but
	<command>badblocks</command> is necessary for checking
	after the filesystem has been created.</para>
	
	<para>The process to prepare filesystems on hard disks or
	partitions is the same as for floppies, except that the formatting
	isn't needed.</para>

</sect2>

<sect2 id="mount-and-umount">
<title>Mounting and unmounting</title>

	<para>Before one can use a filesystem, it has to be 
	<glossterm>mounted</glossterm>. The operating system then does
	various bookkeeping things to make sure that everything works. Since
	all files in UNIX are in a single directory tree, the mount
	operation will make it look like the contents of the new filesystem
	are the contents of an existing subdirectory in some already mounted
	filesystem.</para>

	<para>For example, <xref linkend="hd-mount-root"> shows three
	separate filesystems, each with their own root directory. When the
	last two filesystems are mounted below <filename>/home</filename>
	and <filename>/usr</filename>, respectively, on the first 
	filesystem, we can get a single directory tree, as in
	<xref linkend="hd-mount-all">.</para>

		<figure id="hd-mount-root" float="1">
		<title>Three separate filesystems.</title>
		<graphic fileref="hd-mount-separate"></graphic>
		</figure>

		<figure id="hd-mount-all" float="1">
		<title><filename>/home</filename> and <filename>/usr</filename> 
		have been 
		mounted.</title>
		<graphic fileref="hd-mount-mounted"></graphic>
		</figure>

	<para>The mounts could be done as in the following example:

<screen>
<prompt>$</prompt> <userinput>mount /dev/hda2 /home</userinput>
<prompt>$</prompt> <userinput>mount /dev/hda3 /usr</userinput>
<prompt>$</prompt>
</screen>

	The <command>mount</command> command takes two arguments. The first
	one is the device file corresponding to the disk or partition
	containing the filesystem.  The second one is the directory below
	which it will be mounted.  After these commands the contents of the
	two filesystems look just like the contents of the
	<filename>/home</filename> and <filename>/usr</filename>
	directories, respectively.  One would then say that
	``<filename>/dev/hda2</filename> <glossterm>is mounted
	on</glossterm> <filename>/home</filename>'', and similarly for
	<filename>/usr</filename>.  To look at either filesystem, one would
	look at the contents of the directory on which it has been mounted,
	just as if it were any other directory.  Note the difference between
	the device file, <filename>/dev/hda2</filename>, and the mounted-on
	directory, <filename>/home</filename>.  The device file gives access
	to the raw contents of the disk, the mounted-on directory gives
	access to the files on the disk.  The mounted-on directory is called
	the <glossterm>mount point</glossterm>.</para>

	<para>Linux supports many filesystem types.  
	<command>mount</command> tries to guess the type of the filesystem.
	You can also use the <option>-t fstype</option> option to specify
	the type directly; this is sometimes necessary, since the heuristics
	<command>mount</command> uses do not always work.  For example, to
	mount an MS-DOS floppy, you could use the following command:

        <screen>
	<prompt>$</prompt> <userinput>mount -t msdos /dev/fd0 
	/floppy</userinput>
	<prompt>$</prompt>
	</screen>
	
	</para>

	<para>The mounted-on directory need not be empty, although it
	must exist.  Any files in it, however, will be inaccessible by name
	while the filesystem is mounted.  (Any files that have already been
	opened will still be accessible.  Files that have hard links from
	other directories can be accessed using those names.) There is no
	harm done with this, and it can even be useful.  For instance, some
	people like to have <filename>/tmp</filename> and
	<filename>/var/tmp</filename> synonymous, and make 
	<filename>/tmp</filename> be a symbolic link to
	<filename>/var/tmp</filename>.	When the system is booted, before
	the <filename>/var</filename> filesystem is mounted, a 
	<filename>/var/tmp</filename> directory residing on the root
	filesystem is used instead.  When <filename>/var</filename> is
	mounted, it will make the <filename>/var/tmp</filename> directory 
	on the root filesystem inaccessible.  If
	<filename>/var/tmp</filename> didn't exist on the root filesystem,
	it would be impossible to use temporary files
	before mounting <filename>/var</filename>.</para>

	<para>If you don't intend to write anything to the filesystem, use
	the <option>-r</option> switch for <command>mount</command> to do a 
	<glossterm>read-only mount</glossterm>.  This will make the kernel
	stop any attempts at writing to the filesystem, and will also stop
	the kernel from updating file access times in the inodes.  Read-only
	mounts are necessary for unwritable media, e.g., CD-ROMs.</para>

	<para>The alert reader has already noticed a slight
	logistical problem.  How is the first filesystem (called the 
	<glossterm>root filesystem</glossterm>, because it contains the root
	directory) mounted, since it obviously can't be mounted on another
	filesystem? Well, the answer is that it is done by magic.
	
		<footnote><para>For more
		information, see the kernel source or the Kernel Hackers'
		Guide.</para></footnote>
		
	The root filesystem is magically mounted at boot time, and one can
	rely on it to always be mounted. If the root filesystem can't be
	mounted, the system does not boot. The name of the filesystem that
	is magically mounted as root is either compiled into the kernel, or
	set using LILO or <command>rdev</command>.</para>

	<para>The root filesystem is usually first mounted read-only.
	The startup scripts will then run <command>fsck</command> to verify
	its validity, and if there are no problems, they will
	<glossterm>re-mount</glossterm> it so that writes will also be
	allowed.  <command>fsck</command> must not be run on a mounted
	filesystem, since any changes to the filesystem while
	<command>fsck</command> is running <emphasis>will</emphasis> cause
	trouble. Since the root filesystem is mounted read-only while
	it is being checked, <command>fsck</command> can fix any problems
	without worry, since the remount operation will flush
	any metadata that the filesystem keeps in memory.</para>

	<para>On many systems there are other filesystems that should
	also be mounted automatically at boot time.  These are specified
	in the <filename>/etc/fstab</filename> file; see the fstab man
	page for details on the format.  The details of exactly when the
	extra filesystems are mounted depend on many factors, and can be
	configured by each administrator if need be; see
	<xref linkend="boots-and-shutdowns">.</para>

	<para>When a filesystem no longer needs to be mounted, it can be
	unmounted with <command>umount</command>.
	
		<footnote><para>It should of course be
		<command>unmount</command>, but the n mysteriously disappeared in
		the 70s, and hasn't been seen since.  Please return it to Bell
		Labs, NJ, if you find it.</footnote>
		
	<command>umount</command> takes one argument:
	either the device file or the mount point.  
	For example, to unmount the directories of
	the previous example, one could use the commands

<screen>
<prompt>$</prompt> <userinput>umount /dev/hda2</userinput>
<prompt>$</prompt> <userinput>umount /usr</userinput>
<prompt>$</prompt>
</screen>
	</para>

	<para>See the man page for further instructions on how to
	use the command.  It is imperative that you always unmount a mounted
	floppy.  <emphasis>Don't just pop the floppy out of the
	drive!</emphasis> Because of disk caching, the data is not
	necessarily written to the floppy until you unmount it, so removing
	the floppy from the drive too early might cause the contents to
	become garbled.  If you only read from the floppy, this is not very
	likely, but if you write, even accidentally,
	the result may be catastrophic.</para>

	<para>Mounting and unmounting requires super user privileges, i.e.,
	only root can do it.  The reason for this is that if any user can
	mount a floppy on any directory, then it is rather easy to create a
	floppy with, say, a Trojan horse disguised as
	<filename>/bin/sh</filename>, or any other often used program.  
	However, it is often necessary to allow users to use floppies, and
	there are several ways to do this:

	<itemizedlist>

	<listitem><para>Give the users the root password.  This is
	obviously bad security, but is the easiest solution.  It works well
	if there is no need for security anyway, which is the case
	on many non-networked, personal systems.</para></listitem>

	<listitem><para>Use a program such as <command>sudo</command> to 
	allow users to use mount.  This is still bad security, but doesn't
	directly give super user privileges to everyone.
		
		<footnote><para>It requires several seconds of hard
		thinking on the users' behalf.  Furthermore
		<command>sudo</command> can be configured to only allow
		users to execute certain commands.  See the sudo(8),
		sudoers(5), and visudo(8) manual pages.
		</para></footnote>
	
	</para></listitem>
	
	<listitem><para>Make the users use <command>mtools</command>, a 
	package for manipulating MS-DOS filesystems, without mounting them.
	This works well if MS-DOS floppies are all that is needed, but is
	rather awkward otherwise.
	</para></listitem>

	<listitem><para>List the floppy devices and their allowable mount 
	points together with the suitable options in 
	<filename>/etc/fstab</filename>.

	</itemizedlist>

	The last alternative can be implemented by adding a line like the
	following to the <filename>/etc/fstab</filename> file:

        <screen>
	/dev/fd0            /floppy      msdos   user,noauto      0     0
	</screen>

	The columns are: device file to mount, directory to mount on,
	filesystem type, options, backup frequency (used by
	<command>dump</command>), and <command>fsck</command> pass number
	(to specify the order in which filesystems should be checked
	upon boot; 0 means no check).</para>

	<para>The <option>noauto</option> option stops this mount to be done
	automatically when the system is started (i.e., it stops
	<command>mount -a</command> from mounting it).  The 
	<option>user</option> option allows any user to mount the
	filesystem, and, because of security reasons, disallows execution of
	programs (normal or setuid) and interpretation of device files from
	the mounted filesystem. After this, any user can mount a floppy with
	an msdos filesystem with the following command:

        <screen>
	<prompt>$</prompt> <userinput>mount /floppy</userinput>
	<prompt>$</prompt>
	</screen>

	The floppy can (and needs to, of course) be unmounted with
	the corresponding <command>umount</command> command.</para>

	<para>If you want to provide access to several types of floppies,
	you need to give several mount points.  The settings can be
	different for each mount point.  For example, to give access to both
	MS-DOS and ext2 floppies, you could have the following to lines in
	<filename>/etc/fstab</filename>:

        <screen>
	/dev/fd0    /dosfloppy    msdos   user,noauto  0  0
	/dev/fd0    /ext2floppy   ext2    user,noauto  0  0
	</screen>

	For MS-DOS filesystems (not just floppies), you probably want to
	restrict access to it by using the <option>uid</option>,
	<option>gid</option>, and <option>umask</option> filesystem options,
	described in detail on the <command>mount</command> manual page.  If
	you aren't careful, mounting an MS-DOS filesystem gives everyone at
	least read access to the files in it, which
	is not a good idea.</para>

</sect2>

<sect2>
<title>Checking filesystem integrity with 
<command>fsck</command></title>

	<para>Filesystems are complex creatures, and as such, they
	tend to be somewhat error-prone.  A filesystem's correctness and
	validity can be checked using the <command>fsck</command> command.
	It can be instructed to repair any minor problems it finds, and to
	alert the user if there any unrepairable problems.  Fortunately, the
	code to implement filesystems is debugged quite effectively, so
	there are seldom any problems at all, and they are usually caused by
	power failures, failing hardware, or operator errors;
	for example, by not shutting down the system properly.</para>

	<para>Most systems are setup to run <command>fsck</command>
	automatically at boot time, so that any errors are detected (and
	hopefully corrected) before the system is used.  Use of a corrupted
	filesystem tends to make things worse: if the data structures are
	messed up, using the filesystem will probably mess them up even
	more, resulting in more data loss. However, <command>fsck</command>
	can take a while to run on big filesystems, and since errors almost
	never occur if the system has been shut down properly, a couple of
	tricks are used to avoid doing the checks in such cases.  The first
	is that if the file <filename>/etc/fastboot</filename> exists, no
	checks are made.  The second is that the ext2 filesystem has a
	special marker in its superblock that tells whether the filesystem
	was unmounted properly after the previous mount.  This allows
	<command>e2fsck</command> (the version of <command>fsck</command>
	for the ext2 filesystem) to avoid checking the filesystem if the
	flag indicates that the unmount was done (the assumption being that
	a proper unmount indicates no problems).  Whether the
	<filename>/etc/fastboot</filename> trick works on your system
	depends on your startup scripts, but the ext2 trick works every time
	you use <command>e2fsck</command>. It has to be explicitly bypassed
	with an option to <command>e2fsck</command> to be avoided.	(See
	the <command>e2fsck</command> man page for
	details on how.)</para>

	<para>The automatic checking only works for the
	filesystems that are mounted automatically at boot time. Use
	<command>fsck</command> manually to check other filesystems,
	e.g., floppies.</para>

	<para>If <command>fsck</command> finds unrepairable problems,
	you need either in-depth knowledge of how filesystems work in
	general, and the type of the corrupt filesystem in particular, or
	good backups.  The latter is easy (although sometimes tedious) to
	arrange, the former can sometimes be arranged via a friend, the
	Linux newsgroups and mailing lists, or some other source of support,
	if you don't have the know-how yourself.  I'd like to tell you more
	about it, but my lack of education and experience in this regard
	hinders me.  The <command>debugfs</command>
	program by Theodore Ts'o should be useful.</para>

	<para><command>fsck</command> must only be run on unmounted
	filesystems, never on mounted filesystems (with the exception of the
	read-only root during startup).  This is because it accesses the raw
	disk, and can therefore modify the filesystem without the operating
	system realizing it.	There <emphasis>will</emphasis>
	be trouble, if the operating system is confused.</para>
	
</sect2>

<sect2> 
<title>Checking for disk errors with <command>badblocks</command></title>

	<para>It can be a good idea to periodically check for bad blocks.
	This is done with the <command>badblocks</command> command.  It 
	outputs a list of the numbers of all bad blocks it can find.  This
	list can be fed to <command>fsck</command> to be recorded in the
	filesystem data structures so that the operating system won't try to
	use the bad blocks for storing data. The following example will show
	how this could be done.

        <screen>
	<prompt>$</prompt> <userinput>badblocks /dev/fd0H1440 1440 &gt; 
	bad-blocks</userinput>
	<prompt>$</prompt> <userinput>fsck -t ext2 -l bad-blocks 
	/dev/fd0H1440</userinput>
	<computeroutput>Parallelising fsck version 0.5a (5-Apr-94)
	e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
	Pass 1: Checking inodes, blocks, and sizes
	Pass 2: Checking directory structure
	Pass 3: Checking directory connectivity
	Pass 4: Check reference counts.
	Pass 5: Checking group summary information.
	
	/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****
	/dev/fd0H1440: 11/360 files, 63/1440 blocks</computeroutput>
	<prompt>$</prompt>
	</screen>

	If badblocks reports a block that was already used,
	<command>e2fsck</command> will try to move the block to another
	place.	If the block was really bad, not just marginal, the
	contents of the file may be corrupted.</para>

</sect2>

<sect2>
<title>Fighting fragmentation</title>

	<para>When a file is written to disk, it can't always be written
	in consecutive blocks.  A file that is not stored in consecutive
	blocks is <glossterm>fragmented</glossterm>.  It takes longer to
	read a fragmented file, since the disk's read-write head will have
	to move more.  It is desirable to avoid fragmentation, although it
	is less of a problem in a system with a good buffer
	cache with read-ahead.</para>

	<para>The ext2 filesystem attempts to keep fragmentation at a
	minimum, by keeping all blocks in a file close together, even if
	they can't be stored in consecutive sectors.  Ext2 effectively
	always allocates the free block that is nearest to other blocks in a
	file.  For ext2, it is therefore seldom necessary to worry about
	fragmentation.  There is a program for defragmenting an ext2
	filesystem called, strangely enough, <command>defrag</command>
		
		<footnote><para>
		<ulink url="http://www.go.dlr.de/linux/src/defrag-0.73.tar.gz">
		http://www.go.dlr.de/linux/src/defrag-0.73.tar.gz</ulink>
		</para></footnote>
	.</para>

	<para>There are many MS-DOS defragmentation programs that
	move blocks around in the filesystem to remove fragmentation. For
	other filesystems, defragmentation must be done by backing up the
	filesystem, re-creating it, and restoring the files from backups.
	Backing up a filesystem before defragmenting is a good idea for all
	filesystems, since many things can go wrong
	during the defragmentation.</para>

</sect2>

<sect2>
<title>Other tools for all filesystems</title>

	<para>Some other tools are also useful for managing filesystems.
	<command>df</command> shows the free disk space on one or more
	filesystems; <command>du</command> shows how much disk space a
	directory and all its files contain.  These can be used to hunt down
	disk space wasters.  Both have manual pages which detail
	the (many) options which can be used.</para>

	<para><command>sync</command> forces all unwritten blocks
	in the buffer cache (see <xref linkend="buffer-cache">) to be
	written to disk.  It is seldom necessary to do this by hand; the
	daemon process <command>update</command> does this automatically.
	It can be useful in catastrophes, for example if
	<command>update</command> or its helper process
	<command>bdflush</command> dies, or if you must turn off power
	<emphasis>now</emphasis> and can't wait for
	<command>update</command> to run.  Again, there are manual pages.
	The <command>man</command> is your very best friend in linux.  Its
	cousin <command>apropos</command> is also very useful when you don't
	know what the name of the command you want
	is.</para>

</sect2>

<sect2>
<title>Other tools for the ext2 filesystem</title>

	<para>In addition to the filesystem creator 
	(<command>mke2fs</command>) and checker (<command>e2fsck</command>)
	accessible directly or via the filesystem type independent front
	ends, the ext2
	filesystem has some additional tools that can be useful.</para>

	<para><command>tune2fs</command> adjusts filesystem parameters.  
	Some of the more interesting parameters are:

	<itemizedlist>
	
	<listitem><para>
	A maximal mount count.  <command>e2fsck</command> enforces a check 
	when filesystem has been mounted too many times, even if the clean
	flag is set.  For a system that is used for developing or testing
	the system, it might be a good idea to reduce this limit.
	</para></listitem>
	
	<listitem><para>
	A maximal time between checks.  <command>e2fsck</command> can also 
	enforce a maximal time between two checks, even if the clean flag is
	set, and the filesystem hasn't been mounted very often.  This can be
	disabled, however.
	</para></listitem>
	
	<listitem><para>
	Number of blocks reserved for root.  Ext2 reserves some blocks for
	root so that if the filesystem fills up, it is still possible to do
	system administration without having to delete anything.  The
	reserved amount is by default 5 percent, which on most disks isn't
	enough to be wasteful.  However, for floppies there is no point in
	reserving any blocks.
	</para></listitem>

	</itemizedlist>
	
	See the <command>tune2fs</command> manual page for more
	information.</para>

	<para><command>dumpe2fs</command> shows information about an ext2 
	filesystem, mostly from the superblock.  <xref
	linkend="dumpe2fs-output"> shows a sample output.  Some of the
	information in the output is technical and requires understanding of
	how the filesystem works (see appendix XXX ext2fspaper), but much of
	it is readily understandable even for layadmins.</para>

<figure id="dumpe2fs-output" float="1">
<title>Sample output from <command>dumpe2fs</command></title>

<literallayout>
dumpe2fs 0.5b, 11-Mar-95 for EXT2 FS 0.5a, 94/10/23
Filesystem magic number:  0xEF53
Filesystem state:         clean
Errors behavior:          Continue
Inode count:              360
Block count:              1440
Reserved block count:     72
Free blocks:              1133
Free inodes:              326
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         360
Last mount time:          Tue Aug  8 01:52:52 1995
Last write time:          Tue Aug  8 01:53:28 1995
Mount count:              3
Maximum mount count:      20
Last checked:             Tue Aug  8 01:06:31 1995
Check interval:           0
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Group 0:
  Block bitmap at 3, Inode bitmap at 4, Inode table at 5
  1133 free blocks, 326 free inodes, 2 directories
  Free blocks: 307-1439
  Free inodes: 35-360
</literallayout>
</figure>

	<para><command>debugfs</command> is a filesystem debugger.
	It allows direct access to the filesystem data structures stored on
	disk and can thus be used to repair a disk that is so broken that
	<command>fsck</command> can't fix it automatically. It has also been
	known to be used to recover deleted files. However,
	<command>debugfs</command> very much requires that you understand
	what you're doing; a failure to understand can
	destroy all your data.</para>

	<para><command>dump</command> and <command>restore</command> can be 
	used to back up an ext2 filesystem.  They are ext2 specific versions
	of the traditional UNIX backup tools.  See <xref linkend="backups">
	for more information on backups.</para>

</sect2>

</sect1>

<sect1>
<title>Disks without filesystems</title>

	<para>Not all disks or partitions are used as filesystems.
	A swap partition, for example, will not have a filesystem on it.
	Many floppies are used in a tape-drive emulating fashion, so that a
	<command>tar</command> (tape archive) or other file is written 
	directly on the raw disk, without a filesystem.  Linux boot floppies
	don't
	contain a filesystem, only the raw kernel.</para>

	<para>Avoiding a filesystem has the advantage of making more of
	the disk usable, since a filesystem always has some bookkeeping
	overhead.  It also makes the disks more easily compatible with other
	systems: for example, the <command>tar</command> file format is the
	same on all systems, while filesystems are different on most
	systems.  You will quickly get used to disks without filesystems if
	you need them.  Bootable Linux floppies
	also do not necessarily have a filesystem, although they may.</para>

	<para>One reason to use raw disks is to make image copies of them.
	For instance, if the disk contains a partially damaged filesystem,
	it is a good idea to make an exact copy of it before trying to fix
	it, since then you can start again if your fixing breaks things even
	more.  One way to do this is to use <command>dd</command>:

        <screen>
	<prompt>$</prompt> <userinput>dd if=/dev/fd0H1440 
	of=floppy-image</userinput>
	<computeroutput>2880+0 records in
	2880+0 records out</computeroutput>
	<prompt>$</prompt> <userinput>dd if=floppy-image 
	of=/dev/fd0H1440</userinput>
	<computeroutput>2880+0 records in
	2880+0 records out</computeroutput>
	<prompt>$</prompt>
	</screen>

	The first <command>dd</command> makes an exact image of the floppy
	to the file <filename>floppy-image</filename>, the second one writes
	the image to the floppy.  (The user has presumably switched the
	floppy before the second command.	Otherwise the
	command pair is of doubtful usefulness.)</para>

</sect1>

<sect1>
<title>Allocating disk space</title>

<sect2>
<title>Partitioning schemes</title>

	<para>It is not easy to partition a disk in the best possible way.
	Worse, there is no universally correct way to do it; there are
	too many factors involved.</para>

	<para>The traditional way is to have a (relatively) small
	root filesystem, which contains <filename>/bin</filename>,
	<filename>/etc</filename>, <filename>/dev</filename>,
	<filename>/lib</filename>, <filename>/tmp</filename>, and other
	stuff that is needed to get the system up and running.	This way,
	the root filesystem (in its own partition or on its own disk) is all
	that is needed to bring up the system.  The reasoning is that if the
	root filesystem is small and is not heavily used, it is less likely
	to become corrupt when the system crashes, and you will therefore
	find it easier to fix any problems caused by the crash.  Then you
	create separate partitions or use separate disks for the directory
	tree below <filename>/usr</filename>, the users' home directories
	(often under <filename>/home</filename>), and the swap space.
	Separating the home directories (with the users' files) in their own
	partition makes backups easier, since it is usually not necessary to
	backup programs (which reside below <filename>/usr</filename>).  In
	a networked environment it is also possible to share
	<filename>/usr</filename> among several machines (e.g., by using
	NFS), thereby reducing the total disk space required by several tens
	or hundreds of megabytes times
	the number of machines.</para>

	<para>The problem with having many partitions is that it splits
	the total amount of free disk space into many small pieces.
	Nowadays, when disks and (hopefully) operating systems are more
	reliable, many people prefer to have just one partition that holds
	all their files.  On the other hand, it can be less
	painful to back up (and restore) a small partition.</para>
	
<!--
%	\meta more reasons for many partitions: users/temp files/spools
%	can't fill up all disks, readonly partitions less likely to 
corrupt, 
%	fsck is faster, limits losses a filesystem goes really wrong,
%	logging must not be disturbed, boots from >1023 cylinders do not
%	work on all BIOSs, /usr/local won't be disturbed by an upgrade,
%	easy to divide backup on many tapes, spare (scratch) partition for
%	experimentation (e.g., a new Linux distribution), scratch can
%	also be used to backup root during upgrades
-->

	<para>For a small hard disk (assuming you don't do kernel
	development), the best way to go is probably to have just one
	partition.  For large hard disks, it is probably better to have a
	few large partitions, just in case something does go wrong.  (Note
	that `small' and `large' are used in a relative sense here; your
	needs for disk space
	decide what the threshold is.)</para>

	<para>If you have several disks, you might wish to have the
	root filesystem (including <filename>/usr</filename>) on one,
	and the users' home directories on another.</para>

	<para>It is a good idea to be prepared to experiment a bit
	with different partitioning schemes (over time, not just while first
	installing the system).  This is a bit of work, since it essentially
	requires you to install the system from scratch several times
		<footnote><para>
		This is not actually true, it is possible to move partitions
		and mountpoints without reinstalling, but it is (currently)
		beyond the scope of this book to explain how.  It is on the
		TODO list to write a section on this.  If you have
		experience and knowledge in this area then perhaps you could
		write it for me and save me the bother? :)
		</para></footnote>
	, but it is the only way to be sure you do
	it right.</para>

</sect2>

<sect2>
<title>Space requirements</title>

	<para>The Linux distribution you install will give some indication
	of how much disk space you need for various configurations. Programs
	installed separately may also do the same.  This will help you plan
	your disk space usage, but you should prepare for the future and
	reserve some extra space for things you will
	notice later that you need.</para>

	<para>The amount you need for user files depends on what your
	users wish to do.  Most people seem to need as much space for their
	files as possible, but the amount they will live happily with varies
	a lot.  Some people do only light text processing and will survive
	nicely with a few megabytes, others do heavy
	image processing and will need gigabytes.</para>

	<para>By the way, when comparing file sizes given in
	kilobytes or megabytes and disk space given in megabytes, it can be
	important to know that the two units can be different. Some disk
	manufacturers like to pretend that a kilobyte is 1000 bytes and a
	megabyte is 1000 kilobytes, while all the rest of the computing
	world uses 1024 for both factors.  Therefore, my 345 MB hard disk
	was really a 330 MB hard disk.</para>

	<para>Swap space allocation is discussed in <xref
	linkend="swap-allocation">.</para>

</sect2>

<sect2>
<title>Examples of hard disk allocation</title>

	<para>I used to have a 109 MB hard disk.  Now I am using a 330 MB
	hard disk.  I'll explain how and why I partitioned those
	disks.</para>

	<para>The 109 MB disk I partitioned in a lot of ways, when my
	needs and the operating systems I used changed; I'll explain
	two typical scenarios.	First, I used to run MS-DOS together
	with Linux.  For that, I needed about 20 MB of hard disk, or
	just enough to have MS-DOS, a C compiler, an editor, a few other
	utilities, the program I was working on, and enough free disk
	space to not feel claustrophobic.  For Linux, I had a 10 MB swap
	partition, and the rest, or 79 MB, was a single partition with all
	the files I had under Linux.  I experimented with having separate
	root, <filename>/usr</filename>, and <filename>/home</filename>
	partitions, but there was never enough free disk space in one
	piece to do much interesting.</para>

	<para>When I didn't need MS-DOS anymore, I repartitioned the
	disk so that I had a 12 MB swap partition, and again had the
	rest as a single filesystem.</para>

	<para>The 330 MB disk is partitioned into several partitions, like
	this:

		<informaltable>
		<tgroup cols=2>
		<tbody>
		<row> <entry>5 MB</entry> <entry>root filesystem</entry> </row>
	 	<row> <entry> 10 MB</entry> <entry>swap partition</entry> </row>
		<row> <entry>180 MB</entry> <entry><filename>/usr</filename> 
		filesystem</entry> 
		</row>
		<row> <entry>120 MB</entry> <entry><filename>/home</filename> 
		filesystem</entry> 
		</row>
	 	<row> <entry> 15 MB</entry> <entry>scratch partition</entry> </row>
		</tbody>
		</tgroup>
		</informaltable>

	The scratch partition is for playing around with things that
	require their own partition, e.g., trying different Linux
	distributions, or comparing speeds of filesystems.  When not
	needed for anything else, it is used as swap space (I like to
	have a lot of open windows).
	
		<footnote><para>This section is somewhat out of date.  Most people 
		these days have disks that stretch into the multiple
		Gigabytes.  It is still quite scalable (just multiply by
		some factor to make it fit your hardware) for the moment
		though, updating it to take
		account of larger disks is planned.</para></footnote>
	</para>
</sect2>

<sect2>
<title>Adding more disk space for Linux</title>

	<para>Adding more disk space for Linux is easy, at least after the
	hardware has been properly installed  (the hardware installation
	is outside the scope of this book).  You format it if necessary,
	then create the partitions and filesystem as described above,
	and add the proper lines to <filename>/etc/fstab</filename>
	so that it is mounted automatically.</para>

</sect2>

<sect2>
<title>Tips for saving disk space</title>

	<para>The best tip for saving disk space is to avoid installing
	unnecessary programs.  Most Linux distributions have an
	option to install only part of the packages they contain,
	and by analysing your needs you might notice that you don't
	need most of them.  This will help save a lot of disk space,
	since many programs are quite large.  Even if you do need a
	particular package or program, you might not need all of it.
	For example, some on-line documentation might be unnecessary,
	as might some of the Elisp files for GNU Emacs, some of the
	fonts for X11, or some of the libraries for programming.</para>

	<para>If you cannot uninstall packages, you might look into
	compression.  Compression programs such as <command>gzip</command>
	or <command>zip</command> will compress (and uncompress)
	individual files or groups of files.  The <command>gzexe</command>
	system will compress and uncompress programs invisibly to the
	user (unused programs are compressed, then uncompressed as they
	are used).  The experimental DouBle system will compress all
	files in a filesystem, invisibly to the programs that use them.
	(If you are familiar with products such as Stacker for MS-DOS 
	or DriveSpace for Windows, the principle is the same.)</para>

</sect2>

</sect1>

</chapter>


<chapter id="memory-management">
<title>Memory Management</title>

	<blockquote><para><quote>Minnet, jag har tappat mitt minne,
	&auml;r jag svensk eller finne, kommer inte ih&aring;g...</quote>
	(Bosse &Ouml;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>
<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.
	
		<footnote><para>Thus quite needlessly annoying a
		number of computer scientists greatly.
		</para></footnote>
	</para>

</sect1>

<sect1>
<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
	about 127 MB (for various technical reasons, the actual limit
	is (4096-10) * 8 * 4096 = 133890048$ bytes, or
	127.6875 megabytes).  You can, however, use up to
	8 swap spaces simultaneously, for a total of almost
	1 GB.

		<footnote><para>A gigabyte here, a gigabyte there, pretty
		soon we start talking about real memory.</para></footnote>
	</para>
	<para>This is actually no longer true, this section is slated
	for a rewrite Real Soon Now (tm).  With newer kernels and versions
	of the <command>mkswap</command> command the actual limit depends on
	architecture.  For i386 and compatibles it is 2Gigabytes, other
	architectures vary.  Consult the mkswap(8) manual page for more
	details.</para>

</sect1>

<sect1>
<title>Using a swap space</title>

	<para>An initialised 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>
<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 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
	
		<footnote><para>Except a RAM disk, for obvious
		reasons.</para></footnote>
		
	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 (see <xref
	linkend="boots-and-shutdowns">), 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 signalled 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>

</chapter>

<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>
<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
	
		<footnote><para>On early computers, it wasn't enough
		to merely turn on the computer, you had to manually load the
		operating system as well.  These new-fangled thing-a-ma-jigs do
		it all by themselves.</para></footnote>
		
	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 initialises 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>
<title>The boot process in closer look</title>

	<para>You can boot Linux either from a floppy or from the hard
	disk.  The installation section in the Installation and 
	Getting Started guide (XXX citation)
	tells you how to install Linux so you can boot it the way
	you want to.</para>

	<para>When a PC is booted, the BIOS will do various tests to
	check that everything looks all right,
	
		<footnote><para>This is called
		the <glossterm>power on self test</glossterm>, or 
		<glossterm>POST</glossterm> for short.</para></footnote>
		
	and will then start the actual booting.  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.</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 LILO.  (The details
	about how to do this are irrelevant for this discussion, however;
	see the LILO documentation for more information; it is most
	thorough.)</para>

	<para>When booting with LILO, it will normally go right ahead
	and read in and boot the default kernel.  It is also possible
	to configure LILO 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 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, LILO can be configured so that it
	will always ask, with an optional timeout that will cause the
	default kernel to be booted.</para>
	
	<para>With LILO, it is also possible to give a <glossterm>kernel
	command line argument</glossterm>, after the name of the kernel
	or operating system.</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.  However, it can be more troublesome to install
	the system to boot from the hard disk, so many people will first
	boot from floppy, then, when the system is otherwise installed
	and working well, will install LILO and start booting from the
	hard disk.</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
	recognises 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 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 LILO.	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>

</sect1>

<sect1>
<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>Some people like to shut down using the command
	<command>sync</command>
	
		<footnote><para><command>sync</command> flushes the
		buffer cache.  </para></footnote>
		
	three times, waiting for the disk I/O to stop, then turn off
	the power.  If there are no running programs, this is about
	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>
<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>
<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>
<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 <citetitle>Bootdisk HOWTO</citetitle> by Graham
	Chapman (XXX citation) contains instructions for doing this.
	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>

<chapter id="init">
<title><command>init</command></title>

	<para>

	<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>
<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 initialised 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.
	
		<footnote><para><command>init</command> itself is not
		allowed to die. You can't kill <command>init</command>
		even with SIGKILL.  </para></footnote>
	
	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>
<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;
	
		<footnote><para>Using the command <command>kill -HUP
		1</command> as root, for example </para></footnote>
		
	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.
	
		<footnote><para>Different versions of
		<command>getty</command> are run differently. Consult
		your manual page, and make sure it is the correct
		manual page.</para></footnote>
	</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>
<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, see <xref linkend="run-levels">.  There is no consensus of 
how to use the
	user defined run levels (2 through 5). 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>
	
		<table id="run-levels">
		<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-5</entry> <entry>Normal operation (user 
defined).</entry> </row>
		<row> <entry>6</entry> <entry>Reboot.</entry> </row>
		</tbody>
		</tgroup>
		</table>

	<para>Run levels 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>
<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>
<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,
	
		<footnote><para>It probably shouldn't be used for playing
		<command>nethack</command>.</para></footnote>
		
	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>

<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>
<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" 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"></graphic>
		</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>
<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 recognise 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>
<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.
	
		<footnote><para>Good Linux distributions do this out
		of the box.</para></footnote>
		
	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>
<title>X and xdm</title>

	<para> XXX X implements logins via xdm; also: xterm -ls </para>

</sect1>

<sect1>
<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>
<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 customise
	the environment to his own tastes by overriding, if necessary,
	the default environment.  </para>

</chapter>


<chapter>
<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>
<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.
	
		<footnote><para>It might be quite embarrassing if my
		sister could read my love letters.</para></footnote>
		
	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>
<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>
<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>Password, in an encrypted form.</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> Any user on the system may read the password file,
	so that they can, for example, learn the name of another user.
	This means that the password (the second field) is also available
	to everyone. The password file encrypts the password, so in
	theory there is no problem.  However, the encryption is breakable,
	especially if the password is weak (e.g., it is short or it can
	be found in a dictionary).  Therefore it is not a good idea to
	have the password in the password file.  </para>
	
	<para>
	Many Linux systems have <glossterm>shadow passwords</glossterm>. 
This is
	an alternative way 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.
	
		<footnote><para>Yes, this means that the
		password file has all the information about a user
		<emphasis>except</emphasis> his password. The wonder
		of development.</para></footnote>

	</para>
	
</sect2>

<sect2>
<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 synchronising 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>
<title>Initial environment: <filename>/etc/skel</filename></title>

	<para> When the home directory for a new user is created, it is
	initialised 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
	
		<footnote><para>Surreal users?</para></footnote>
		
	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>
<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.
	
		<footnote><para>The user's name might change due to
		marriage, for example, and he might want to have his
		username reflect his new name.</para></footnote>
		
	</para>
	
</sect1>

<sect1>
<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>
<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.
	
		<footnote><para>But they can be <emphasis>so</emphasis>
		fun, if you're a BOFH.</para></footnote>

	</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>

<chapter id="backups">
<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>
<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.
	
		<footnote><para>The fifth reason is ``something
		else''.</para></footnote>
		
	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.
	
		<footnote><para>Don't laugh.  This has happened to
		several people.</para></footnote>
		
	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.
	
		<footnote><para>Been there, done that...</para></footnote>
		
	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>
<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>
<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>
<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 labourious
	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 optimised 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>
<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>
<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>
<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 generalised 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"></graphic>
		</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 minimise 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 labour 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>
<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,
	
		<footnote><para>You get to decide what's easy.
		Some people consider installing from dozens of floppies
		easy.</para></footnote>

	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>
<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.
	
		<footnote><para>If a tape drive doesn't data fast enough,
		it has to stop; this makes backups even slower, and can
		be bad for the tape and the drive.</para></footnote>
		
	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>

<chapter>
<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>
<title>Time zones</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 the Earth is round,
	
		<footnote><para>According to
		recent research.</para></footnote>
		
	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>
<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>
<title>Showing and setting time</title>

	<para> In the Debian system, the system time zone is determined
	by the symbolic link <filename>/etc/localtime</filename>.
	This link points at a time zone data file that describes
	the local time zone.  The time zone data files are stored in
	<filename>/usr/lib/zoneinfo</filename>.  Other Linux distributions
	may do this differently.  </para>
	
	<para> 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.
	
		<footnote><para>Beware of the <command>time</command> command, 
which does
		not show the current time.</para></footnote>
		
	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>
Sun Jul 14 18:53:42 UTC 1996
<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> <command>date</command> only shows or sets the software
	clock.	The <command>clock</command> commands synchronises
	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>
<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> 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>

</chapter>

<chapter>
<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> 

<sect1>
<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>
<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>
<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>
<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>
<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>
<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>
<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.tuxedo.org/~esr/faqs/smart-questions.html">
http://www.tuxedo.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 maximise your
chances of getting the answer you are looking for.</para>
</sect2>
</sect1>

<sect1>
<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 manpages, 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>
<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><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><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><title>Port scanning</title>
<para>Never <emphasis>ever</emphasis> as 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><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><title>CTCPs</title>
<para>If you are thinking of mass CTCP 
	<footnote><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 client for more
	details</para></footnote>
pinging the channel or CTCP
version or CTCP anything, then think again.  It is liable to get you
kicked out very quickly.</para>
</sect2>

<sect2><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><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 recognise the correct tone you
should be using.</para>
</sect2>

<sect2>
<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>

<appendix id="gfdl">
<title>GNU Free Documentation License</title>
<!-- - GNU Project - Free Software Foundation (FSF) -->
<!-- LINK REV="made" HREF="mailto:webmasters@gnu.org" -->


  <!-- sect1>
    <title>GNU Free Documentation License</title -->

    <para>Version 1.1, March 2000</para>

    <blockquote>
      <para>Copyright (C) 2000  Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.</para>
    </blockquote>

  <sect1 label="0">
    <title>PREAMBLE</title>

    <para>The purpose of this License is to make a manual, textbook,
    or other written 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>
  </sect1>

  <sect1 label="1">
    <title>APPLICABILITY AND DEFINITIONS</title>

    <para>This License applies to any manual or other work that
    contains a notice placed by the copyright holder saying it can be
    distributed under the terms of this License.  The "Document",
    below, refers to any such manual or work.  Any member of the
    public is a licensee, and is addressed as "you".</para>

    <para>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>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.
    (For example, 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>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.</para>

    <para>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.</para>

    <para>A "Transparent" copy of the Document means a
    machine-readable copy, represented in a format whose specification
    is available to the general public, whose contents can be viewed
    and edited directly and 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 has been designed to thwart or discourage subsequent
    modification by readers is not Transparent.  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 designed for human modification.
    Opaque formats include PostScript, PDF, 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 produced by some word
    processors for output purposes only.</para>

    <para>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>
  </sect1>

  <sect1 label="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>
  </sect1>

  <sect1 label="3">
    <title>COPYING IN QUANTITY</title>

    <para>If you publish printed copies 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 publicly-accessible
    computer-network location containing a complete Transparent copy
    of the Document, free of added material, which the general
    network-using public has access to download anonymously at no
    charge using public-standard network protocols.  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>
  </sect1>

  <sect1 label="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 numeration="upperalpha">
      <listitem><para>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.</para>
      </listitem>

      <listitem><para>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 less than
      five).</para>
      </listitem>

      <listitem><para>State on the Title page
      the name of the publisher of the Modified Version, as the
      publisher.</para>
      </listitem>

      <listitem><para>Preserve all the
      copyright notices of the Document.</para>
      </listitem>

      <listitem><para>Add an appropriate
      copyright notice for your modifications adjacent to the other
      copyright notices.</para>
      </listitem>

      <listitem><para>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 Addendum below.</para>
      </listitem>

      <listitem><para>Preserve in that license
      notice the full lists of Invariant Sections and required Cover
      Texts given in the Document's license notice.</para>
      </listitem>

      <listitem><para>Include an unaltered
      copy of this License.</para>
      </listitem>

      <listitem><para>Preserve the section
      entitled "History", and 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.</para>
      </listitem>

      <listitem><para>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.</para>
      </listitem>

      <listitem><para>In any section entitled
      "Acknowledgements" or "Dedications", preserve the section's
      title, and preserve in the section all the substance and tone of
      each of the contributor acknowledgements and/or dedications
      given therein.</para>
      </listitem>

      <listitem><para>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.</para>
      </listitem>

      <listitem><para>Delete any section
      entitled "Endorsements".  Such a section may not be included in
      the Modified Version.</para>
      </listitem>

      <listitem><para>Do not retitle any
      existing section as "Endorsements" or to conflict in title with
      any Invariant Section.</para>
      </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>
  </sect1>

  <sect1 label="5">
    <title>COMBINING DOCUMENTS</title>

    <para>You may combine the Document with other documents released
    under this License, under the terms defined in section 4 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.</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>
  </sect1>

  <sect1 label="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>
  </sect1>

  <sect1 label="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, does not as a whole count as a
    Modified Version of the Document, provided no compilation
    copyright is claimed for the compilation.  Such a compilation is
    called an "aggregate", and this License does not apply to the
    other self-contained works thus compiled with the Document, on
    account of their being thus compiled, if they 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 quarter of the entire aggregate, the Document's Cover Texts
    may be placed on covers that surround only the Document within the
    aggregate.  Otherwise they must appear on covers around the whole
    aggregate.</para>
  </sect1>

  <sect1 label="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 provided that you also
    include the original English version of this License.  In case of
    a disagreement between the translation and the original English
    version of this License, the original English version will
    prevail.</para>
  </sect1>

  <sect1 label="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>
  </sect1>

  <sect1 label="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 <ulink
    
url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.</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>
  </sect1>

  <sect1 label="">
    <title>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><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.1
      or any later version published by the Free Software Foundation;
      with the Invariant Sections being LIST THEIR TITLES, with the
      Front-Cover Texts being LIST, and with the Back-Cover Texts 
being LIST.
      A copy of the license is included in the section entitled "GNU
      Free Documentation License".
</para></blockquote>

    <para>If you have no Invariant Sections, write "with no Invariant
    Sections" instead of saying which ones are invariant.  If you have
    no Front-Cover Texts, write "no Front-Cover Texts" instead of
    "Front-Cover Texts being LIST"; likewise for Back-Cover
    Texts.</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>
  </sect1>

</appendix>




<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 there is no 
	power flowing, so it provides a sort of static RAM.  ie RAM 
	which does not lose what it was	storing 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>file system</glossterm>
	<glossdef><para>
	The methods and data structures that an operating 
	system uses to keep track of files on a disk or partition;
	the way the files are organised on the disk.  Also used about
	a partition or disk that is used to store the files
	or the type of the filesystem.
	</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>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 organising 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>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>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 analyses 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>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>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>
	

</glossary>


</book>