An introduction to system administration of a Linux system for novices.
Copyright 1993−−1998 Lars Wirzenius.
Copyright 1998−−2001 Joanna Oja.
Copyright 2001−−2003 Stephen Stafford.
Copyright 2003−−2004 Stephen Stafford & Alex Weeks.
Copyright 2004−−Present Alex Weeks.
Trademarks are owned by their owners.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no
Invariant Sections, no Front−Cover Texts, and no Back−Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
The Linux System Administrator's Guide
Table of Contents
About This Book.................................................................................................................................................1
Chapter 5. Using Disks and Other Storage Media.........................................................................................25
5.1. Two kinds of devices......................................................................................................................25
5.2. Hard disks.......................................................................................................................................26
5.3. Storage Area Networks − Draft......................................................................................................28
6.6. The buffer cache.............................................................................................................................56
Chapter 7. System Monitoring.........................................................................................................................58
7.1. System Resources...........................................................................................................................58
7.1.1. The top command..................................................................................................................58
7.1.2. The iostat command..............................................................................................................59
7.1.3. The ps command...................................................................................................................60
7.1.4. The vmstat command............................................................................................................61
7.1.5. The lsof command.................................................................................................................61
7.1.6. Finding More Utilities...........................................................................................................62
9.1. init comes first................................................................................................................................70
9.2. Configuring init to start getty: the /etc/inittab file..........................................................................70
9.3. Run levels.......................................................................................................................................71
9.4. Special configuration in /etc/inittab................................................................................................73
9.5. Booting in single user mode...........................................................................................................73
Chapter 10. Logging In And Out.....................................................................................................................75
10.1. Logins via terminals......................................................................................................................75
10.2. Logins via the network..................................................................................................................76
10.3. What login does............................................................................................................................77
10.4. X and xdm.....................................................................................................................................78
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the
former." Albert Einstein
1. Acknowledgments
1.1. Joanna's acknowledgments
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.
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.
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.
Many useful comments have been sent by a large number of people. My miniature black hole of an archive
doesn't let me find all their names, but some of them are, in alphabetical order: Paul Caprioli, Ales Cepek,
Marie−France Declerfayt, Dave Dobson, Olaf Flebbe, Helmut Geyer, Larry Greenfield and his father, Stephen
Harris, Jyrki Havia, Jim Haynes, York Lam, Timothy Andrew Lister, Jim Lynch, Michael J. Micek, Jacob
Navia, Dan Poirier, Daniel Quinlan, Jouni K Seppänen, Philippe Steindl, G.B. Stotte. My apologies to anyone
I have forgotten.
1.2. Stephen's acknowledgments
I would like to thank Lars and Joanna for their hard work on the guide.
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: <bagpuss@debian.org.NOSPAM>. 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 :)
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.
About This Book1
The Linux System Administrator's Guide
1.3. Alex's Acknowledgments
I would like to thank Lars, Joanna, and Stephen for all the great work that they have done on this document
over the years. I only hope that my contribution will be worthy of continuing the work they started.
Like the previous maintainers, I openly welcome any comments, suggestions, complains, corrections, or any
other form of feedback you may have. This document can only benefit from the suggestions of those who use
it.
There have been many people who have helped me on my journey through the "Windows−Free" world, the
person I feel I need to thank the most is my first true UN*X mentor, Mike Velasco. Back in a time before
SCO became a "dirty word", Mike helped me on the path of tar's, cpio's, and many, many man pages. Thanks
Mike! You are the 'Sofa King'.
2. Revision History
Revision History
Revision 0.72001−12−03Revised by: SS
Revision 0.82003−11−18Revised by: AW
Added a section on NTP1.
Cleaned some SGML2.
Added ext3 to the filesystem section3.
Revision 0.9Revised by: AW
Cleaned some SGML code, changed doctype to lds.dsl, and added id tags1.
Updated section on filesystem types, and Filesystem comparison2.
Updated partition type section3.
Updated section on creating partitions4.
Wrote section on Logical Volume Manager (LVM)5.
Updated section on space allocation6.
Added chapter on System Monitoring7.
Added more command line utilities8.
Verified Device list9.
Modified email address for Authors10.
Added references to more in−depth documents where applicable11.
Added notes on upcoming sections12.
Indexed chapters 1 − 4, & part of 513.
Updated Misc Information throughout the book14.
3. Source and pre−formatted versions available
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 http://www.tldp.org/, or at the home page of this book at
http://www.draxeman/sag.html. This book is available in at least it's SGML source, as well as, HTML and
PDF formats. Other formats may be available.
About This Book2
The Linux System Administrator's Guide
4. Typographical Conventions
Throughout this book, I have tried to use uniform typographical conventions. Hopefully they aid readability.
If you can suggest any improvements please contact me.
Filenames are expressed as: /usr/share/doc/foo.
Command names are expressed as: fsck
Email addresses are expressed as: <user@domain.com>
URLs are expressed as: http://www.tldp.org
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.
About This Book3
Chapter 1. Introduction
"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."
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.
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.
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.
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 apropos
command can be used. Consult its manual page for more details.
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.
There is no one official Linux distribution, so different people have different setups and many people have a
setup they have built up themselves. This book is not targeted at any one distribution. Distributions can and do
vary considerably. When possible, differences have been noted and alternatives given. For a list of
distributions and some of their differences see
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions.
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.
Understanding is the key to success with Linux. This book could just provide recipes, but what would you do
when confronted by a problem this book had no recipe for? If the book can provide understanding, then
recipes are not required. The answers will be self evident.
Chapter 1. Introduction4
The Linux System Administrator's Guide
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.
One particular point where corners have been cut is that many things that are already well documented in
other freely available manuals are not always covered here. This applies especially to program specific
documentation, such as all the details of using mkfs. 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.
1.1. Linux or GNU/Linux, that is the question.
Many people feel that Linux should really be called GNU/Linux. This is because Linux is only the kernel, not
the applications that run on it. Most of the basic command line utilities were written by the Free Software
Foundation while developing their GNU operating system. Among those utilities are some of the most basic
commands like cp, mv lsof, and dd.
In a nutshell, what happened was, the FSF started developing GNU by writing things like compliers, C
libraries, and basic command line utilities before the kernel. Linus Torvalds, started Linux by writing the
Linux kernel first and using applications written for GNU.
I do not feel that this is the proper forum to debate what name people should use when referring to Linux. I
mention it here, because I feel it is important to understand the relationship between GNU and Linux, and to
also explain why some Linux is sometimes referred to as GNU/Linux. The document will be simply referring
to it as Linux.
GNU's side of the issue is discussed on their website:
The relationship − http://www.gnu.org/gnu/linux−and−gnu.html
Why Linux should be GNU/Linux − http://www.gnu.org/gnu/why−gnu−linux.html
Microsoft, Windows, Windows NT, Windows 2000, and Windows XP are trademarks and/or registered
trademarks of Microsoft Corporation.
Chapter 1. Introduction5
The Linux System Administrator's Guide
Red Hat is a trademark of Red Hat, Inc., in the United States and other countries.
SuSE is a trademark of Novell.
Linux is a registered trademark of Linus Torvalds.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open
Company Ltd.
GNU is a registered trademark of the Free Software Foundation.
Other product names mentioned herein may be trademarks and/or registered trademarks of their respective
companies.
Chapter 1. Introduction6
Chapter 2. Overview of a Linux System
"God saw everything that he had made, and saw that it was very good. " −− Bible King James
Version. Genesis 1:31
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.
2.1. Various parts of an operating system
UNIX and 'UNIX−like' operating systems (such as Linux) consist of a kernel and some system programs.
There are also some application programs for doing work. The kernel is the heart of the operating system. In
fact, it is often mistakenly considered to be the operating system itself, but it is not. An operating system
provides provides many more services than a plain kernel.
It keeps track of files on the disk, starts programs and runs them concurrently, assigns memory and other
resources to various processes, receives packets from and sends packets to the network, and so on. The kernel
does very little by itself, but it provides tools with which all services can be built. It also prevents anyone from
accessing the hardware directly, forcing everyone to use the tools it provides. This way the kernel provides
some protection for users from each other. The tools provided by the kernel are used via system calls. See
manual page section 2 for more information on these.
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
user mode. 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; mount is a system program. The
difference is often somewhat blurry, however, and is important only to compulsive categorizers.
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.
2.2. Important parts of the kernel
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. Figure 2−1 shows
some of them.
Figure 2−1. Some of the more important parts of the Linux kernel
Chapter 2. Overview of a Linux System7
The Linux System Administrator's Guide
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.
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 `initialize the
drive', `read sector N', and `write sector N'.
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 virtual filesystem (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.
A more in−depth discussion of kernel internals can be found at http://www.tldp.org/LDP/lki/index.html. This
document was written for the 2.4 kernel. When I find one for the 2.6 kernel, I will list it here.
2.3. Major services in a UNIX system
This section describes some of the more important UNIX services, but without much detail. They are
described more thoroughly in later chapters.
Chapter 2. Overview of a Linux System8
The Linux System Administrator's Guide
2.3.1. init
The single most important service in a UNIX system is provided by init init is started as the first process of
every UNIX system, as the last thing the kernel does when it boots. When init starts, it continues the boot
process by doing various startup chores (checking and mounting filesystems, starting daemons, etc).
The exact list of things that init does depends on which flavor it is; there are several to choose from. init
usually provides the concept of single user mode, in which no one can log in and root uses a shell at the
console; the usual mode is called multiuser mode. Some flavors generalize this as run levels; 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.
Linux allows for up to 10 runlevels, 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 3 is defined as "multi user"
because it is the runlevel that the system boot into under normal day to day conditions. Runlevel 5 is typically
the same as 3 except that a GUI gets started also. 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 /etc/inittab usually will give some hint what the predefined
runlevels are and what they have been defined as.
In normal operation, init makes sure getty is working (to allow users to log in) and to adopt orphan processes
(processes whose parent has died; in UNIX all processes must be in a single tree, so orphans must be
adopted).
When the system is shut down, it is init 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.
2.3.2. Logins from terminals
Logins from terminals (via serial lines) and the console (when not running X) are provided by the getty
program. init starts a separate instance of getty for each terminal upon which logins are to be allowed. getty
reads the username and runs the loginprogram, which reads the password. If the username and password are
correct, login runs the shell. When the shell terminates, i.e., the user logs out, or when login terminated
because the username and password didn't match, init notices this and starts a new instance of getty. The
kernel has no notion of logins, this is all handled by the system programs.
2.3.3. Syslog
The kernel and many system programs 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 syslog . 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.
Chapter 15 will provide more on this.
Chapter 2. Overview of a Linux System9
The Linux System Administrator's Guide
2.3.4. Periodic command execution: cron and at
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 (/tmp and
/var/tmp) from old files, to keep the disks from filling up, since not all programs clean up after themselves
correctly.
The cron service is set up to do this. Each user can have a crontab file, where she lists the commands she
wishes to execute and the times they should be executed. The cron daemon takes care of starting the
commands when specified.
The at service is similar to cron, but it is once only: the command is executed at the given time, but it is not
repeated.
We will go more into this later. See the manual pages cron(1), crontab(1), crontab(5), at(1) and atd(8) for
more in depth information.
Chapter 13 will cover this.
2.3.5. Graphical user interface
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.
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.
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.
2.3.6. Networking
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.
UNIX operating systems have many networking features. Most basic services (filesystems, printing, backups,
etc) can be done over the network. This can make system administration easier, since it allows centralized
administration, while still reaping in the benefits of microcomputing and distributed computing, such as lower
costs and better fault tolerance.
However, this book merely glances at networking; see the Linux Network Administrators' Guide
http://www.tldp.org/LDP/nag2/index.html for more information, including a basic description of how
networks operate.
Chapter 2. Overview of a Linux System10
The Linux System Administrator's Guide
2.3.7. Network logins
Network logins work a little differently than normal logins. For each person logging in via the network there
is a separate virtual network connection, and there can be any number of these depending on the available
bandwidth. It is therefore not possible to run a separate getty for each possible virtual connection. There are
also several different ways to log in via a network, telnet and ssh being the major ones in TCP/IP networks.
These days many Linux system administrators consider telnet and rlogin to be insecure and prefer ssh, 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 ssh rather than telnet or rlogin.
Network logins have, instead of a herd of gettys, a single daemon per way of logging in (telnet and ssh 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 getty.
2.3.8. Network file systems
One of the more useful things that can be done with networking services is sharing files via a network file
system. Depending on your network this could be done over the Network File System (NFS), or over the
Common Internet File System (CIFS). NFS is typically a 'UNIX' based service. In Linux, NFS is supported by
the kernel. CIFS however is not. In Linux, CIFS is supported by Samba http://www.samba.org.
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.
This will be covered in more detail in Section 5.4.
2.3.9. Mail
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.
Each user has an incoming mailbox (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.
The mail system consists of many programs. The delivery of mail to local or remote mailboxes is done by one
program (the mail transfer agent (MTA) , e.g., sendmail or postfix ), while the programs users use are many
and varied (mail user agent (MUA) , e.g., pine , or evolution . The mailboxes are usually stored in
/var/spool/mail until the user's MUA retrieves them.
For more information on setting up and running mail services you can read the Mail Administrator HOWTO
at http://www.tldp.org/HOWTO/Mail−Administrator−HOWTO.html, or visit the sendmail or postfix's
website. http://www.sendmail.org/, or http://www.postfix.org/ .
Chapter 2. Overview of a Linux System11
The Linux System Administrator's Guide
2.3.10. Printing
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 print queue: all print jobs are put into a queue and
whenever the printer is done with one job, the next one is sent to it automatically. This relieves the users from
organizing the print queue and fighting over control of the printer. Instead, they form a new queue at 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.
The print queue software also spools 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.
You can refer to the Printing−HOWTO located at
http://www.tldp.org/HOWTO/Printing−HOWTO/index.html for more help in setting up printers.
2.3.11. The filesystem layout
The filesystem is divided into many parts; usually along the lines of a root filesystem with /bin , /lib ,
/etc , /dev , and a few others; a /usr filesystem with programs and unchanging data; /var filesystem
with changing data (such as log files); and a /home 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.
Chapter 3 describes the filesystem layout in some little detail; the Filesystem Hierarchy Standard . covers it in
somewhat more detail. This can be found on the web at: http://www.pathname.com/fhs/
Chapter 2. Overview of a Linux System12
Chapter 3. Overview of the Directory Tree
" Two days later, there was Pooh, sitting on his branch, dangling his legs, and there, beside
him, were four pots of honey..." (A.A. Milne)
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.
3.1. Background
This chapter is loosely based on the Filesystems Hierarchy Standard (FHS). version 2.1, which attempts to set
a standard for how the directory tree in a Linux system is organized. 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 standardized 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.
This chapter is not as detailed as the FHS. A system administrator should also read the full FHS for a
complete understanding.
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.
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 (/ ), /usr , /var , and /home filesystems (see Figure 3−1). 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.
Figure 3−1. Parts of a Unix directory tree. Dashed lines indicate partition limits.
The roles of the different parts of the directory tree are described below.
Chapter 3. Overview of the Directory Tree13
The Linux System Administrator's Guide
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.
The /usr filesystem contains all commands, libraries, manual pages, and other unchanging files
•
needed during normal operation. No files in /usr 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 /usr). It can make administration easier (only the master /usr
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.
The /var 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 /var has
been somewhere below /usr , but that made it impossible to mount /usr read−only.
The /home 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 /home
might have to be broken across several filesystems, which requires adding an extra naming level
below /home, for example /home/students and /home/staff.
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 names work; even if, say, /var and /usr are actually on the same partition,
the names /usr/lib/libc.a and /var/log/messages must work, for example by moving files
below /var into /usr/var, and making /var a symlink to /usr/var.
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).
3.2. The root filesystem
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.
The root directory generally doesn't contain any files, except perhaps on older systems where the standard
boot image for the system, usually called /vmlinuz was kept there. (Most distributions have moved those
files the the /boot directory. Otherwise, all files are kept in subdirectories under the root filesystem:
/bin
Chapter 3. Overview of the Directory Tree14
Commands needed during bootup that might be used by normal users (probably after bootup).
/sbin
Like /bin, but the commands are not intended for normal users, although they may use them if
necessary and allowed. /sbin is not usually in the default path of normal users, but will be in root's
default path.
/etc
Configuration files specific to the machine.
/root
The home directory for user root. This is usually not accessible to other users on the system
/lib
Shared libraries needed by the programs on the root filesystem.
/lib/modules
Loadable kernel modules, especially those that are needed to boot the system when recovering from
disasters (e.g., network and filesystem drivers).
/dev
Device files. These are special files that help the user interface with the various devices on the system.
/tmp
Temporary files. As the name suggests, programs running often store temporary files in here.
/boot
Files used by the bootstrap loader, e.g., LILO or GRUB. 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. 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 lilo manual page for more details.
/mnt
Mount point for temporary mounts by the system administrator. Programs aren't supposed to mount
on /mnt automatically. /mnt might be divided into subdirectories (e.g., /mnt/dosa might be the
floppy drive using an MS−DOS filesystem, and /mnt/exta might be the same with an ext2
filesystem).
/proc, /usr, /var, /home
Mount points for the other filesystems. Although /proc does not reside on any disk in reality it is
still mentioned here. See the section about /proc later in the chapter.
The Linux System Administrator's Guide
3.3. The /etc directory
The /etc maintains 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 /etc as well, and are described in the Networking Administrators' Guide.
/etc/rc or /etc/rc.d or /etc/rc?.d
Scripts or directories of scripts to run at startup or when changing the run level. See Section 2.3.1 for
further information.
/etc/passwd
The user database, with fields giving the username, real name, home directory, and other information
about each user. The format is documented in the passwd manual page.
/etc/shadow
/etc/shadow is an encrypted file the holds user passwords.
/etc/fdprm
Chapter 3. Overview of the Directory Tree15
The Linux System Administrator's Guide
Floppy disk parameter table. Describes what different floppy disk formats look like. Used by
setfdprm . See the setfdprm manual page for more information.
/etc/fstab
Lists the filesystems mounted automatically at startup by the mount −a command (in /etc/rc or
equivalent startup file). Under Linux, also contains information about swap areas used automatically
by swapon −a . See Section 5.10.7 and the mount manual page for more information. Also fstab
usually has its own manual page in section 5.
/etc/group
Similar to /etc/passwd, but describes groups instead of users. See the group manual page in
section 5 for more information.
/etc/inittab
Configuration file for init.
/etc/issue
Output by getty before the login prompt. Usually contains a short description or welcoming message
to the system. The contents are up to the system administrator.
/etc/magic
The configuration file for file. Contains the descriptions of various file formats based on which file
guesses the type of the file. See the magic and file manual pages for more information.
/etc/motd
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.
/etc/mtab
List of currently mounted filesystems. Initially set up by the bootup scripts, and updated automatically
by the mount command. Used when a list of mounted filesystems is needed, e.g., by the df command.
/etc/login.defs
Configuration file for the login command. The login.defs file usually has a manual page in
section 5.
/etc/printcap
Like /etc/termcap /etc/printcap , but intended for printers. However it uses different
syntax. The printcap has a manual page in section 5.
/etc/profile, /etc/bash.rc, /etc/csh.cshrc
Files executed at login or startup time by the Bourne, BASH , or C shells. These allow the system
administrator to set global defaults for all users. Users can also create individual copies of these in
their home directory to personalize their environment. See the manual pages for the respective shells.
/etc/securetty
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 su or sudo to gain root privileges.
/etc/shells
Lists trusted shells. The chsh command allows users to change their login shell only to shells listed in
this file. ftpd, is the server process that provides FTP services for a machine, will check that the user's
shell is listed in /etc/shells and will not let people log in unless the shell is listed there.
/etc/termcap
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 /etc/termcap. As a result most programs work with most kinds of terminals. See
the termcap, curs_termcap, and terminfo manual pages for more information.
Chapter 3. Overview of the Directory Tree16
The Linux System Administrator's Guide
3.4. The /dev directory
The /dev directory contains the special device files for all the devices. The device files are created during
installation, and later with the /dev/MAKEDEV script. The /dev/MAKEDEV.local 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
MAKEDEV, such as device files for some non−standard device driver).
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.
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.
/dev/dsp
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.
/dev/fd0
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.
/dev/fb0
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 standardized. The framebuffer is a character device and is on
major node 29 and minor 0.
/dev/hda
/dev/hda is the master IDE drive on the primary IDE controller. /dev/hdb the slave drive on the
primary controller. /dev/hdc , and /dev/hdd 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 /dev/hdc9 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 hda is at minor 0 and the slave drive
hdb is at minor 64. For each partition inside the drive add the partition number to the minor minor
node number for the drive. For example /dev/hdb5 is major 3, minor 69 (64 + 5 = 69). Drives on
the secondary interface are handled the same way, but with major node 22.
/dev/ht0
The first IDE tape drive. Subsequent drives are numbered ht1 etc. They are character devices on
major node 37 and start at minor node 0 for ht0 1 for ht1 etc.
/dev/js0
The first analogue joystick. Subsequent joysticks are numbered js1, js2 etc. Digital joysticks are
called djs0, djs1 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.
/dev/lp0
The first parallel printer device. Subsequent printers are numbered lp1, lp2 etc. They are character
devices on major mode 6 and minor nodes starting at 0 and numbered sequentially.
/dev/loop0
Chapter 3. Overview of the Directory Tree17
The Linux System Administrator's Guide
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 mount command. Refer to the manual pages for mount and losetup.
The loopback devices are block devices on major node 7 and with minor nodes starting at 0 and
numbered sequentially.
/dev/md0
First metadisk group. Metadisks are related to RAID (Redundant Array of Independent Disks)
devices. Please refer to the most current RAID HOWTO at the LDP for more details. This can be
found at http://www.tldp.org/HOWTO/Software−RAID−HOWTO.html. Metadisk devices are block
devices on major node 9 with minor nodes starting at 0 and numbered sequentially.
/dev/mixer
This is part of the OSS (Open Sound System) driver. Refer to the OSS documentation at
http://www.opensound.com for more details. It is a character device on major node 14, minor node 0.
/dev/null
The bit bucket. A black hole where you can send data for it never to be seen again. Anything sent to
/dev/null 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.
/dev/psaux
The PS/2 mouse port. This is a character device on major node 10, minor node 1.
/dev/pda
Parallel port IDE disks. These are named similarly to disks on the internal IDE controllers
(/dev/hd*). They are block devices on major node 45. Minor nodes need slightly more explanation
here. The first device is /dev/pda 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). /dev/pdb minor nodes start at 16, /dev/pdc
at 32 and /dev/pdd at 48. So for example the minor node number for /dev/pdc6 would be 38
(32 + 6 = 38). This scheme limits you to 4 parallel disks of 15 partitions each.
/dev/pcd0
Parallel port CD ROM drives. These are numbered from 0 onwards. All are block devices on major
node 46. /dev/pcd0 is on minor node 0 with subsequent drives being on minor nodes 1, 2, 3 etc.
/dev/pt0
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 /dev/pt0, 1 for
/dev/pt1, and so on.
/dev/parport0
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.
/dev/random or /dev/urandom
These are kernel random number generators. /dev/random 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.
/dev/urandom 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 /dev/random, if speed is more
important then /dev/urandom works fine. They are character devices on major node 1 with minor
nodes 8 for /dev/random and 9 for /dev/urandom.
/dev/sda
Chapter 3. Overview of the Directory Tree18
The Linux System Administrator's Guide
The first SCSI drive on the first SCSI bus. The following drives are named similar to IDE drives.
/dev/sdb is the second SCSI drive, /dev/sdc is the third SCSI drive, and so forth.
/dev/ttyS0
The first serial port. Many times this it the port used to connect an external modem to your system.
/dev/zero
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.
3.5. The /usr filesystem.
The /usr filesystem is often large, since all programs are installed there. All files in /usr usually come
from a Linux distribution; locally installed programs and other stuff goes below /usr/local. 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 /usr are listed below (some of the
less important directories have been dropped; see the FSSTND for more information).
/usr/X11R6.
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 /usr/X11R6 similar
to that below /usr itself.
/usr/bin.
Almost all user commands. Some commands are in /bin or in /usr/local/bin.
/usr/sbin
System administration commands that are not needed on the root filesystem, e.g., most server
programs.
/usr/share/man, /usr/share/info, /usr/share/doc
Manual pages, GNU Info documents, and miscellaneous other documentation files, respectively.
/usr/include
Header files for the C programming language. This should actually be below /usr/lib for
consistency, but the tradition is overwhelmingly in support for this name.
/usr/lib
Unchanging data files for programs and subsystems, including some site−wide configuration files.
The name lib comes from library; originally libraries of programming subroutines were stored in
/usr/lib.
/usr/local
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.
3.6. The /var filesystem
The /var 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.
/var/cache/man
A cache for man pages that are formatted on demand. The source for manual pages is usually stored
in /usr/share/man/man?/ (where ? is the manual section. See the manual page for man in
section 7); some manual pages might come with a pre−formatted version, which might be stored in
Chapter 3. Overview of the Directory Tree19
/usr/share/man/cat* . Other manual pages need to be formatted when they are first viewed;
the formatted version is then stored in /var/cache/man so that the next person to view the same
page won't have to wait for it to be formatted.
/var/games
Any variable data belonging to games in /usr should be placed here. This is in case /usr is mounted
read only.
/var/lib
Files that change while the system is running normally.
/var/local
Variable data for programs that are installed in /usr/local (i.e., programs that have been installed
by the system administrator). Note that even locally installed programs should use the other /var
directories if they are appropriate, e.g., /var/lock.
/var/lock
Lock files. Many programs follow a convention to create a lock file in /var/lock 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.
/var/log
Log files from various programs, especially login(/var/log/wtmp, which logs all logins and
logouts into the system) and syslog(/var/log/messages, where all kernel and system program
message are usually stored). Files in /var/log can often grow indefinitely, and may require
cleaning at regular intervals.
/var/mail
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 /var/spool/mail.
/var/run
Files that contain information about the system that is valid until the system is next booted. For
example, /var/run/utmp contains information about people currently logged in.
/var/spool
Directories for news, printer queues, and other queued work. Each different spool has its own
subdirectory below /var/spool, e.g., the news spool is in /var/spool/news . Note that some
installations which are not fully compliant with the latest version of the FHS may have user mailboxes
under /var/spool/mail.
/var/tmp
Temporary files that are large or that need to exist for a longer time than what is allowed for /tmp .
(Although the system administrator might not allow very old files in /var/tmp either.)
The Linux System Administrator's Guide
3.7. The /proc filesystem
The /proc 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 /proc filesystem is described in
more detail in the proc manual page.
/proc/1
A directory with information about process number 1. Each process has a directory below /proc
with the name being its process identification number.
/proc/cpuinfo
Information about the processor, such as its type, make, model, and performance.
/proc/devices
List of device drivers configured into the currently running kernel.
Chapter 3. Overview of the Directory Tree20
/proc/dma
Shows which DMA channels are being used at the moment.
/proc/filesystems
Filesystems configured into the kernel.
/proc/interrupts
Shows which interrupts are in use, and how many of each there have been.
/proc/ioports
Which I/O ports are in use at the moment.
/proc/kcore
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 /proc takes up any disk space at all.)
/proc/kmsg
Messages output by the kernel. These are also routed to syslog.
/proc/ksyms
Symbol table for the kernel.
/proc/loadavg
The `load average' of the system; three meaningless indicators of how much work the system has to
do at the moment.
/proc/meminfo
Information about memory usage, both physical and swap.
/proc/modules
Which kernel modules are loaded at the moment.
/proc/net
Status information about network protocols.
/proc/self
A symbolic link to the process directory of the program that is looking at /proc. When two
processes look at /proc, they get different links. This is mainly a convenience to make it easier for
programs to get at their process directory.
/proc/stat
Various statistics about the system, such as the number of page faults since the system was booted.
/proc/uptime
The time the system has been up.
/proc/version
The kernel version.
The Linux System Administrator's Guide
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 freeprogram reads /proc/meminfo converts the amounts
given in bytes to kilobytes (and adds a little more information, as well).
Chapter 3. Overview of the Directory Tree21
Chapter 4. Hardware, Devices, and Tools
"Knowledge speaks, but wisdom listens." Jimi Hendrix
This chapter gives an overview of what a device file is, and how to create one. The canonical list of device
files is /usr/src/linux/Documentation/devices.txt if you have the Linux kernel source code
installed on your system. The devices listed here are correct as of kernel version 2.6.8.
4.1. Hardware Utilities
4.1.1. The MAKEDEV Script
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 MAKEDEV
script. This script is usually located in /dev/MAKEDEV but might also have a copy (or a symbolic link) in
/sbin/MAKEDEV. If it turns out not to be in your path then you will need to specify the path to it explicitly.
This will create the device file /dev/ttyS0 with major node 4 and minor node 64 as a character device
with access permissions 0660 with owner root and group dialout.
ttyS0 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.
4.1.2. The mknod command
MAKEDEV is the preferred way of creating device files which are not present. However sometimes the
MAKEDEV script will not know about the device file you wish to create. This is where the mknod command
comes in. In order to use mknod you need to know the major and minor node numbers for the device you
wish to create. The devices.txt file in the kernel source documentation is the canonical source of this
information.
To take an example, let us suppose that our version of the MAKEDEV script does not know how to create the
/dev/ttyS0 device file. We need to use mknod to create it. We know from looking at the devices.txt
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.
# mknod /dev/ttyS0 c 4 64
# chown root.dialout /dev/ttyS0
# chmod 0644 /dev/ttyS0
# ls −l /dev/ttyS0
crw−rw−−−− 1 root dialout 4, 64 Oct 23 18:23 /dev/ttyS0
Chapter 4. Hardware, Devices, and Tools22
Loading...
+ 100 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.