2675 lines
96 KiB
XML
2675 lines
96 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD$
|
|
-->
|
|
|
|
<chapter id="basics">
|
|
<chapterinfo>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Chris</firstname>
|
|
<surname>Shumway</surname>
|
|
<contrib>Rewritten by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
<!-- 10 Mar 2000 -->
|
|
</chapterinfo>
|
|
|
|
<title>UNIX Basics</title>
|
|
|
|
<sect1 id="basics-synopsis">
|
|
<title>Synopsis</title>
|
|
|
|
<para>This chapter covers the basic commands and functionality of
|
|
the &os; operating system. Much of this material is relevant
|
|
for any &unix;-like operating system. New &os; users are
|
|
encouraged to read through this chapter carefully.</para>
|
|
|
|
<para>After reading this chapter, you will know:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>How to use the <quote>virtual consoles</quote> of
|
|
&os;.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How &unix; file permissions and &os; file flags
|
|
work.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The default &os; file system layout.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The &os; disk organization.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How to mount and unmount file systems.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>What processes, daemons, and signals are.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>What a shell is, and how to change your default login
|
|
environment.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How to use basic text editors.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>What devices and device nodes are.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>What binary format is used under &os;.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How to read manual pages for more information.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="consoles">
|
|
<title>Virtual Consoles and Terminals</title>
|
|
|
|
<indexterm><primary>virtual consoles</primary></indexterm>
|
|
<indexterm><primary>terminals</primary></indexterm>
|
|
|
|
<para>&os; can be used in various ways. One of them is typing
|
|
commands to a text terminal. A lot of the flexibility and power
|
|
of a &unix; operating system is readily available at your hands
|
|
when using &os; this way. This section describes what
|
|
<quote>terminals</quote> and <quote>consoles</quote> are, and
|
|
how you can use them in &os;.</para>
|
|
|
|
<sect2 id="consoles-intro">
|
|
<title>The Console</title>
|
|
|
|
<indexterm><primary>console</primary></indexterm>
|
|
|
|
<para>Unless &os; has been configured to automatically start
|
|
a graphical environment during startup, the system will boot
|
|
into a command line login prompt, as seen in this
|
|
example:</para>
|
|
|
|
<screen>FreeBSD/amd64 (pc3.example.org) (ttyv0)
|
|
|
|
login:</screen>
|
|
|
|
<para>The first line contains some information about the
|
|
system. The <literal>amd64</literal> indicates that the
|
|
system in this example is running a 64-bit version of &os;.
|
|
The hostname is <hostid>pc3.example.org</hostid>, and
|
|
<devicename>ttyv0</devicename> indicates that this is the
|
|
system console.</para>
|
|
|
|
<para>The second line is the login prompt. The next section
|
|
describes how to log into &os; at this prompt.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="consoles-login">
|
|
<title>Logging into &os;</title>
|
|
|
|
<para>&os; is a multiuser, multiprocessing system. This is
|
|
the formal description that is usually given to a system that
|
|
can be used by many different people, who simultaneously run a
|
|
lot of programs on a single machine.</para>
|
|
|
|
<para>Every multiuser system needs some way to distinguish one
|
|
<quote>user</quote> from the rest. In &os; (and all the
|
|
&unix;-like operating systems), this is accomplished by
|
|
requiring that every user must <quote>log into</quote> the
|
|
system before being able to run programs. Every user has a
|
|
unique name (the <quote>username</quote>) and a personal,
|
|
secret key (the <quote>password</quote>). &os; will ask
|
|
for these two before allowing a user to run any
|
|
programs.</para>
|
|
|
|
<indexterm><primary>startup scripts</primary></indexterm>
|
|
<para>When a &os; system boots, startup scripts are
|
|
automatically executed in order to prepare the system and to
|
|
start any services which have been configured to start at
|
|
system boot. Once the system finishes running its startup
|
|
scripts, it will present a login prompt:</para>
|
|
|
|
<screen>login:</screen>
|
|
|
|
<para>Type the username that was configured during <link
|
|
linkend="bsdinstall-addusers">system installation</link> and
|
|
press <keycap>Enter</keycap>. Then enter the password
|
|
associated with the username and press <keycap>Enter</keycap>.
|
|
The password is <emphasis>not echoed</emphasis> for security
|
|
reasons.</para>
|
|
|
|
<para>Once the correct password is input, the message of
|
|
the day (<acronym>MOTD</acronym>) will be displayed followed
|
|
by a command prompt (a <literal>#</literal>,
|
|
<literal>$</literal>, or <literal>%</literal> character). You
|
|
are now logged into the &os; console and ready to try the
|
|
available commands.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="consoles-virtual">
|
|
<title>Virtual Consoles</title>
|
|
|
|
<para>&os; can be configured to provide many virtual consoles
|
|
for inputting commands. Each virtual console has its own
|
|
login prompt and output channel, and &os; takes care of
|
|
properly redirecting keyboard input and monitor output as you
|
|
switch between virtual consoles.</para>
|
|
|
|
<para>Special key combinations have been reserved by &os; for
|
|
switching consoles.<footnote>
|
|
<para>Refer to &man.syscons.4;, &man.atkbd.4;,
|
|
&man.vidcontrol.1; and &man.kbdcontrol.1; for a more
|
|
technical description of the &os; console and its keyboard
|
|
drivers.</para></footnote>. Use
|
|
<keycombo><keycap>Alt</keycap><keycap>F1</keycap></keycombo>,
|
|
<keycombo><keycap>Alt</keycap><keycap>F2</keycap></keycombo>,
|
|
through
|
|
<keycombo><keycap>Alt</keycap><keycap>F8</keycap></keycombo>
|
|
to switch to a different virtual console in &os;.</para>
|
|
|
|
<para>When switching from one console to the next, &os; takes
|
|
care of saving and restoring the screen output. The result is
|
|
an <quote>illusion</quote> of having multiple
|
|
<quote>virtual</quote> screens and keyboards that can be used
|
|
to type commands for &os; to run. The programs that are
|
|
launched in one virtual console do not stop running when that
|
|
console is not visible because the user has switched to a
|
|
different virtual console.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="consoles-ttys">
|
|
<title>The <filename>/etc/ttys</filename> File</title>
|
|
|
|
<para>By default, &os; is configured to start eight virtual
|
|
consoles. The configuration can be customized to start
|
|
more or fewer virtual consoles. To change the number of and
|
|
the settings of the virtual consoles, edit
|
|
<filename>/etc/ttys</filename>.</para>
|
|
|
|
<para>Each uncommented line in <filename>/etc/ttys</filename>
|
|
(lines that do not start with a <literal>#</literal>
|
|
character) contains settings for a single terminal or virtual
|
|
console. The default version configures nine virtual
|
|
consoles, and enables eight of them. They are the lines that
|
|
start with <literal>ttyv</literal>:</para>
|
|
|
|
<programlisting># name getty type status comments
|
|
#
|
|
ttyv0 "/usr/libexec/getty Pc" cons25 on secure
|
|
# Virtual terminals
|
|
ttyv1 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv2 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv3 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv4 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv5 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv6 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv7 "/usr/libexec/getty Pc" cons25 on secure
|
|
ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure</programlisting>
|
|
|
|
<para>For a detailed description of every column in this file
|
|
and the available options for the virtual consoles, refer to
|
|
&man.ttys.5;.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="consoles-singleuser">
|
|
<title>Single User Mode Console</title>
|
|
|
|
<para>A detailed description of <quote>single user mode</quote>
|
|
can be found <link linkend="boot-singleuser">here</link>.
|
|
There is only one console when &os; is in single user mode as
|
|
no other virtual consoles are available in this mode. The
|
|
settings for single user mode are found in this section of
|
|
<filename>/etc/ttys</filename>:</para>
|
|
|
|
<programlisting># name getty type status comments
|
|
#
|
|
# If console is marked "insecure", then init will ask for the root password
|
|
# when going to single-user mode.
|
|
console none unknown off secure</programlisting>
|
|
|
|
<note>
|
|
<para>As the comments above the <literal>console</literal>
|
|
line indicate, editing <literal>secure</literal> to
|
|
<literal>insecure</literal> will prompt for the
|
|
<username>root</username> password when booting into single
|
|
user mode. The default setting enters single user mode
|
|
without prompting for a password.</para>
|
|
|
|
<para><emphasis>Be careful when changing this setting to
|
|
<literal>insecure</literal></emphasis>. If you ever
|
|
forget the <username>root</username> password, booting into
|
|
single user mode is still possible, but may be difficult for
|
|
someone who is not comfortable with the &os; booting
|
|
process.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="consoles-vidcontrol">
|
|
<title>Changing Console Video Modes</title>
|
|
|
|
<para>The &os; console default video mode may be adjusted to
|
|
1024x768, 1280x1024, or any other size supported by the
|
|
graphics chip and monitor. To use a different video mode
|
|
load the <literal>VESA</literal> module:</para>
|
|
|
|
<screen>&prompt.root; <userinput>kldload vesa</userinput></screen>
|
|
|
|
<para>To determine which video modes are supported by the
|
|
hardware, use &man.vidcontrol.1;. To get a list of supported
|
|
video modes issue the following:</para>
|
|
|
|
<screen>&prompt.root; <userinput>vidcontrol -i mode</userinput></screen>
|
|
|
|
<para>The output of this command lists the video modes that
|
|
are supported by the hardware. To select a new video mode,
|
|
specify the mode using &man.vidcontrol.1; as the
|
|
<username>root</username> user:</para>
|
|
|
|
<screen>&prompt.root; <userinput>vidcontrol MODE_279</userinput></screen>
|
|
|
|
<para>If the new video mode is acceptable, it can be permanently
|
|
set on boot by adding it to
|
|
<filename>/etc/rc.conf</filename>:</para>
|
|
|
|
<programlisting>allscreens_flags="MODE_279"</programlisting>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="permissions">
|
|
<title>Permissions</title>
|
|
|
|
<indexterm><primary>UNIX</primary></indexterm>
|
|
|
|
<para>&os;, being a direct descendant of BSD &unix;, is based
|
|
on several key &unix; concepts. The first and most pronounced
|
|
is that &os; is a multi-user operating system that can handle
|
|
several users working simultaneously on completely unrelated
|
|
tasks. The system is responsible for properly sharing and
|
|
managing requests for hardware devices, peripherals, memory, and
|
|
CPU time fairly to each user.</para>
|
|
|
|
<para>Because the system is capable of supporting multiple users,
|
|
everything the system manages has a set of permissions governing
|
|
who can read, write, and execute the resource. These
|
|
permissions are stored as three octets broken into three pieces,
|
|
one for the owner of the file, one for the group that the file
|
|
belongs to, and one for everyone else. This numerical
|
|
representation works like this:</para>
|
|
|
|
<indexterm><primary>permissions</primary></indexterm>
|
|
<indexterm>
|
|
<primary>file permissions</primary>
|
|
</indexterm>
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Value</entry>
|
|
<entry>Permission</entry>
|
|
<entry>Directory Listing</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>0</entry>
|
|
<entry>No read, no write, no execute</entry>
|
|
<entry><literal>---</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>No read, no write, execute</entry>
|
|
<entry><literal>--x</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>No read, write, no execute</entry>
|
|
<entry><literal>-w-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>No read, write, execute</entry>
|
|
<entry><literal>-wx</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Read, no write, no execute</entry>
|
|
<entry><literal>r--</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>Read, no write, execute</entry>
|
|
<entry><literal>r-x</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Read, write, no execute</entry>
|
|
<entry><literal>rw-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>Read, write, execute</entry>
|
|
<entry><literal>rwx</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<indexterm>
|
|
<primary><command>ls</command></primary>
|
|
</indexterm>
|
|
<indexterm><primary>directories</primary></indexterm>
|
|
|
|
<para>Use the <option>-l</option> argument to &man.ls.1; to view a
|
|
long directory listing that includes a column of information
|
|
about a file's permissions for the owner, group, and everyone
|
|
else. For example, a <command>ls -l</command> in an arbitrary
|
|
directory may show:</para>
|
|
|
|
<screen>&prompt.user; <userinput>ls -l</userinput>
|
|
total 530
|
|
-rw-r--r-- 1 root wheel 512 Sep 5 12:31 myfile
|
|
-rw-r--r-- 1 root wheel 512 Sep 5 12:31 otherfile
|
|
-rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt</screen>
|
|
|
|
<para>The first (leftmost) character in the first column indicates
|
|
whether this file is a regular file, a directory, a special
|
|
character device, a socket, or any other special pseudo-file
|
|
device. In this example, the <literal>-</literal> indicates a
|
|
regular file. The next three characters, <literal>rw-</literal>
|
|
in this example, give the permissions for the owner of the file.
|
|
The next three characters, <literal>r--</literal>, give the
|
|
permissions for the group that the file belongs to. The final
|
|
three characters, <literal>r--</literal>, give the permissions
|
|
for the rest of the world. A dash means that the permission is
|
|
turned off. In this example, the permissions are set so the
|
|
owner can read and write to the file, the group can read the
|
|
file, and the rest of the world can only read the file.
|
|
According to the table above, the permissions for this file
|
|
would be <literal>644</literal>, where each digit represents the
|
|
three parts of the file's permission.</para>
|
|
|
|
<para>How does the system control permissions on devices? &os;
|
|
treats most hardware devices as a file that programs can open,
|
|
read, and write data to. These special device files are
|
|
stored in <filename class="directory">/dev/</filename>.</para>
|
|
|
|
<para>Directories are also treated as files. They have read,
|
|
write, and execute permissions. The executable bit for a
|
|
directory has a slightly different meaning than that of files.
|
|
When a directory is marked executable, it means it is possible
|
|
to change into that directory using
|
|
<application>cd</application>. This also means that it is
|
|
possible to access the files within that directory, subject to
|
|
the permissions on the files themselves.</para>
|
|
|
|
<para>In order to perform a directory listing, the read permission
|
|
must be set on the directory. In order to delete a file that
|
|
one knows the name of, it is necessary to have write
|
|
<emphasis>and</emphasis> execute permissions to the directory
|
|
containing the file.</para>
|
|
|
|
<para>There are more permission bits, but they are primarily used
|
|
in special circumstances such as setuid binaries and sticky
|
|
directories. For more information on file permissions and how
|
|
to set them, refer to &man.chmod.1;.</para>
|
|
|
|
<sect2>
|
|
<sect2info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
<surname>Rhodes</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</sect2info>
|
|
|
|
<title>Symbolic Permissions</title>
|
|
|
|
<indexterm>
|
|
<primary>permissions</primary>
|
|
<secondary>symbolic</secondary>
|
|
</indexterm>
|
|
|
|
<para>Symbolic permissions use characters instead of octal
|
|
values to assign permissions to files or directories.
|
|
Symbolic permissions use the syntax of (who) (action)
|
|
(permissions), where the following values are
|
|
available:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Option</entry>
|
|
<entry>Letter</entry>
|
|
<entry>Represents</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>(who)</entry>
|
|
<entry>u</entry>
|
|
<entry>User</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(who)</entry>
|
|
<entry>g</entry>
|
|
<entry>Group owner</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(who)</entry>
|
|
<entry>o</entry>
|
|
<entry>Other</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(who)</entry>
|
|
<entry>a</entry>
|
|
<entry>All (<quote>world</quote>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(action)</entry>
|
|
<entry>+</entry>
|
|
<entry>Adding permissions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(action)</entry>
|
|
<entry>-</entry>
|
|
<entry>Removing permissions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(action)</entry>
|
|
<entry>=</entry>
|
|
<entry>Explicitly set permissions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(permissions)</entry>
|
|
<entry>r</entry>
|
|
<entry>Read</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(permissions)</entry>
|
|
<entry>w</entry>
|
|
<entry>Write</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(permissions)</entry>
|
|
<entry>x</entry>
|
|
<entry>Execute</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(permissions)</entry>
|
|
<entry>t</entry>
|
|
<entry>Sticky bit</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(permissions)</entry>
|
|
<entry>s</entry>
|
|
<entry>Set UID or GID</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>These values are used with &man.chmod.1;, but with
|
|
letters instead of numbers. For example, the following
|
|
command would block other users from accessing
|
|
<replaceable>FILE</replaceable>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>chmod go= FILE</userinput></screen>
|
|
|
|
<para>A comma separated list can be provided when more than one
|
|
set of changes to a file must be made. For example, the
|
|
following command removes the group and
|
|
<quote>world</quote> write permission on
|
|
<replaceable>FILE</replaceable>, and adds the execute
|
|
permissions for everyone:</para>
|
|
|
|
<screen>&prompt.user; <userinput>chmod go-w,a+x <replaceable>FILE</replaceable></userinput></screen>
|
|
|
|
<!--
|
|
<para>Most users will not notice this, but it should be pointed
|
|
out that using the octal method will only set or assign
|
|
permissions to a file; it does not add or delete them.</para>
|
|
-->
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<sect2info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
<surname>Rhodes</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</sect2info>
|
|
|
|
<title>&os; File Flags</title>
|
|
|
|
<para>In addition to file permissions, &os; supports the use of
|
|
<quote>file flags</quote>. These flags add an additional
|
|
level of security and control over files, but not
|
|
directories. With file flags, even
|
|
<username>root</username> can be prevented from removing or
|
|
altering files.</para>
|
|
|
|
<para>File flags are modified using &man.chflags.1;. For
|
|
example, to enable the system undeletable flag on the file
|
|
<filename>file1</filename>, issue the following
|
|
command:</para>
|
|
|
|
<screen>&prompt.root; <userinput>chflags sunlink <filename>file1</filename></userinput></screen>
|
|
|
|
<para>To disable the system undeletable flag, put a
|
|
<quote>no</quote> in front of the
|
|
<option>sunlink</option>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>chflags nosunlink <filename>file1</filename></userinput></screen>
|
|
|
|
<para>To view the flags of a file, use <option>-lo</option> with
|
|
&man.ls.1;:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ls -lo <filename>file1</filename></userinput></screen>
|
|
|
|
<programlisting>-rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 file1</programlisting>
|
|
|
|
<para>Several file flags may only added or removed by the
|
|
<username>root</username> user. In other cases, the file
|
|
owner may set its file flags. Refer to &man.chflags.1; and
|
|
&man.chflags.2; for more information.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<sect2info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
<surname>Rhodes</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</sect2info>
|
|
|
|
<title>The <literal>setuid</literal>, <literal>setgid</literal>,
|
|
and <literal>sticky</literal> Permissions</title>
|
|
|
|
<para>Other than the permissions already discussed, there are
|
|
three other specific settings that all administrators should
|
|
know about. They are the <literal>setuid</literal>,
|
|
<literal>setgid</literal>, and <literal>sticky</literal>
|
|
permissions.</para>
|
|
|
|
<para>These settings are important for some &unix; operations
|
|
as they provide functionality not normally granted to normal
|
|
users. To understand them, the difference between the real
|
|
user ID and effective user ID must be noted.</para>
|
|
|
|
<para>The real user ID is the <acronym>UID</acronym> who owns
|
|
or starts the process. The effective <acronym>UID</acronym>
|
|
is the user ID the process runs as. As an example,
|
|
&man.passwd.1; runs with the real user ID when a user changes
|
|
their password. However, in order to update the password
|
|
database, the command runs as the effective ID of the
|
|
<username>root</username> user. This allows users to change
|
|
their passwords without seeing a
|
|
<errorname>Permission Denied</errorname> error.</para>
|
|
|
|
<para>The setuid permission may be set by prefixing a permission
|
|
set with the number four (4) as shown in the following
|
|
example:</para>
|
|
|
|
<screen>&prompt.root; <userinput>chmod 4755 suidexample.sh</userinput></screen>
|
|
|
|
<para>The permissions on
|
|
<filename><replaceable>suidexample.sh</replaceable></filename>
|
|
now look like the following:</para>
|
|
|
|
<programlisting>-rwsr-xr-x 1 trhodes trhodes 63 Aug 29 06:36 suidexample.sh</programlisting>
|
|
|
|
<para>Note that a <literal>s</literal> is now part of the
|
|
permission set designated for the file owner, replacing the
|
|
executable bit. This allows utilities which need elevated
|
|
permissions, such as <command>passwd</command>.</para>
|
|
|
|
<note>
|
|
<para>The <literal>nosuid</literal> &man.mount.8; option will
|
|
cause such binaries to silently fail without alerting
|
|
the user. That option is not completely reliable as a
|
|
<literal>nosuid</literal> wrapper may be able to circumvent
|
|
it.</para>
|
|
</note>
|
|
|
|
<para>To view this in real time, open two terminals. On
|
|
one, start the <command>passwd</command> process as a normal
|
|
user. While it waits for a new password, check the process
|
|
table and look at the user information for
|
|
<command>passwd</command>:</para>
|
|
|
|
<para>In terminal A:</para>
|
|
|
|
<screen>Changing local password for trhodes
|
|
Old Password:</screen>
|
|
|
|
<para>In terminal B:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ps aux | grep passwd</userinput></screen>
|
|
|
|
<screen>trhodes 5232 0.0 0.2 3420 1608 0 R+ 2:10AM 0:00.00 grep passwd
|
|
root 5211 0.0 0.2 3620 1724 2 I+ 2:09AM 0:00.01 passwd</screen>
|
|
|
|
<para>As stated above, the <command>passwd</command> is run
|
|
by a normal user, but is using the effective
|
|
<acronym>UID</acronym> of <username>root</username>.</para>
|
|
|
|
<para>The <literal>setgid</literal> permission performs the
|
|
same function as the <literal>setuid</literal> permission;
|
|
except that it alters the group settings. When an application
|
|
or utility executes with this setting, it will be granted the
|
|
permissions based on the group that owns the file, not the
|
|
user who started the process.</para>
|
|
|
|
<para>To set the <literal>setgid</literal> permission on a
|
|
file, provide <command>chmod</command> with a leading two
|
|
(2):</para>
|
|
|
|
<screen>&prompt.root; <userinput>chmod 2755 sgidexample.sh</userinput></screen>
|
|
|
|
<para>In the following listing, notice that the
|
|
<literal>s</literal> is now in the field designated for the
|
|
group permission settings:</para>
|
|
|
|
<screen>-rwxr-sr-x 1 trhodes trhodes 44 Aug 31 01:49 sgidexample.sh</screen>
|
|
|
|
<note>
|
|
<para>In these examples, even though the shell script in
|
|
question is an executable file, it will not run with
|
|
a different <acronym>EUID</acronym> or effective user ID.
|
|
This is because shell scripts may not access the
|
|
&man.setuid.2; system calls.</para>
|
|
</note>
|
|
|
|
<para>The <literal>setuid</literal> and
|
|
<literal>setgid</literal> permission bits may lower system
|
|
security, by allowing for elevated permissions. The third
|
|
special permission, the <literal>sticky bit</literal>, can
|
|
strengthen the security of a system.</para>
|
|
|
|
<para>When the <literal>sticky bit</literal> is set on a
|
|
directory, it allows file deletion only by the file owner.
|
|
This is useful to prevent file deletion in public directories,
|
|
such as <filename class="directory">/tmp</filename>, by users
|
|
who do not own the file. To utilize this permission, prefix
|
|
the permission set with a one (1):</para>
|
|
|
|
<screen>&prompt.root; <userinput>chmod 1777 /tmp</userinput></screen>
|
|
|
|
<para>The <literal>sticky bit</literal> permission will display
|
|
as a <literal>t</literal> at the very end of the permission
|
|
set:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ls -al / | grep tmp</userinput></screen>
|
|
|
|
<screen>drwxrwxrwt 10 root wheel 512 Aug 31 01:49 tmp</screen>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="dirstructure">
|
|
<title>Directory Structure</title>
|
|
|
|
<indexterm><primary>directory hierarchy</primary></indexterm>
|
|
|
|
<para>The &os; directory hierarchy is fundamental to obtaining
|
|
an overall understanding of the system. The most important
|
|
directory is root or, <quote>/</quote>. This directory is the
|
|
first one mounted at boot time and it contains the base system
|
|
necessary to prepare the operating system for multi-user
|
|
operation. The root directory also contains mount points for
|
|
other file systems that are mounted during the transition to
|
|
multi-user operation.</para>
|
|
|
|
<para>A mount point is a directory where additional file systems
|
|
can be grafted onto a parent file system (usually the root file
|
|
system). This is further described in <xref
|
|
linkend="disk-organization"/>. Standard mount points
|
|
include <filename class="directory">/usr/</filename>,
|
|
<filename class="directory">/var/</filename>,
|
|
<filename class="directory">/tmp/</filename>,
|
|
<filename class="directory">/mnt/</filename>, and
|
|
<filename class="directory">/cdrom/</filename>. These
|
|
directories are usually referenced to entries in
|
|
<filename>/etc/fstab</filename>. This file is a table of
|
|
various file systems and mount points and is read by the system.
|
|
Most of the file systems in <filename>/etc/fstab</filename> are
|
|
mounted automatically at boot time from the script &man.rc.8;
|
|
unless their entry includes <option>noauto</option>. Details
|
|
can be found in <xref linkend="disks-fstab"/>.</para>
|
|
|
|
<para>A complete description of the file system hierarchy is
|
|
available in &man.hier.7;. The following table provides a brief
|
|
overview of the most common directories.</para>
|
|
|
|
<para>
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Directory</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="top">
|
|
<row>
|
|
<entry><filename class="directory">/</filename></entry>
|
|
<entry>Root directory of the file system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/bin/</filename></entry>
|
|
<entry>User utilities fundamental to both single-user
|
|
and multi-user environments.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/boot/</filename></entry>
|
|
<entry>Programs and configuration files used during
|
|
operating system bootstrap.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/boot/defaults/</filename></entry>
|
|
<entry>Default boot configuration files. Refer to
|
|
&man.loader.conf.5; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/dev/</filename></entry>
|
|
<entry>Device nodes. Refer to &man.intro.4; for
|
|
details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/</filename></entry>
|
|
<entry>System configuration files and scripts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/defaults/</filename></entry>
|
|
<entry>Default system configuration files. Refer to
|
|
&man.rc.8; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/mail/</filename></entry>
|
|
<entry>Configuration files for mail transport agents
|
|
such as &man.sendmail.8;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/namedb/</filename></entry>
|
|
<entry><command>named</command> configuration files.
|
|
Refer to &man.named.8; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/periodic/</filename></entry>
|
|
<entry>Scripts that run daily, weekly, and monthly,
|
|
via &man.cron.8;. Refer to &man.periodic.8; for
|
|
details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/etc/ppp/</filename></entry>
|
|
<entry><command>ppp</command> configuration files as
|
|
described in &man.ppp.8;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/mnt/</filename></entry>
|
|
<entry>Empty directory commonly used by system
|
|
administrators as a temporary mount point.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/proc/</filename></entry>
|
|
<entry>Process file system. Refer to &man.procfs.5;,
|
|
&man.mount.procfs.8; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/rescue/</filename></entry>
|
|
<entry>Statically linked programs for emergency
|
|
recovery as described in &man.rescue.8;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/root/</filename></entry>
|
|
<entry>Home directory for the <username>root</username>
|
|
account.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/sbin/</filename></entry>
|
|
<entry>System programs and administration utilities
|
|
fundamental to both single-user and multi-user
|
|
environments.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/tmp/</filename></entry>
|
|
<entry>Temporary files which are usually
|
|
<emphasis>not</emphasis> preserved across a system
|
|
reboot. A memory-based file system is often mounted
|
|
at <filename class="directory">/tmp</filename>. This
|
|
can be automated using the tmpmfs-related variables of
|
|
&man.rc.conf.5; or with an entry in
|
|
<filename>/etc/fstab</filename>; refer to
|
|
&man.mdmfs.8; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/</filename></entry>
|
|
<entry>The majority of user utilities and
|
|
applications.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/bin/</filename></entry>
|
|
<entry>Common utilities, programming tools, and
|
|
applications.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/include/</filename></entry>
|
|
<entry>Standard C include files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/lib/</filename></entry>
|
|
<entry>Archive libraries.</entry>
|
|
</row>
|
|
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/libdata/</filename></entry>
|
|
<entry>Miscellaneous utility data files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/libexec/</filename></entry>
|
|
<entry>System daemons and system utilities executed
|
|
by other programs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/local/</filename></entry>
|
|
<entry>Local executables and libraries. Also used as
|
|
the default destination for the &os; ports
|
|
framework. Within <filename>/usr/local</filename>,
|
|
the general layout sketched out by &man.hier.7; for
|
|
<filename>/usr</filename> should be used. Exceptions
|
|
are the man directory, which is directly under
|
|
<filename>/usr/local</filename> rather than under
|
|
<filename>/usr/local/share</filename>, and the ports
|
|
documentation is in
|
|
<filename>share/doc/<replaceable>port</replaceable></filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/obj/</filename></entry>
|
|
<entry>Architecture-specific target tree produced by
|
|
building the <filename>/usr/src</filename>
|
|
tree.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/ports/</filename></entry>
|
|
<entry>The &os; Ports Collection (optional).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/sbin/</filename></entry>
|
|
<entry>System daemons and system utilities executed
|
|
by users.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/share/</filename></entry>
|
|
<entry>Architecture-independent files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/usr/src/</filename></entry>
|
|
<entry>BSD and/or local source files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/</filename></entry>
|
|
<entry>Multi-purpose log, temporary, transient, and
|
|
spool files. A memory-based file system is sometimes
|
|
mounted at <filename
|
|
class="directory">/var</filename>. This can be
|
|
automated using the varmfs-related variables in
|
|
&man.rc.conf.5; or with an entry in
|
|
<filename>/etc/fstab</filename>; refer to
|
|
&man.mdmfs.8; for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/log/</filename></entry>
|
|
<entry>Miscellaneous system log files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/mail/</filename></entry>
|
|
<entry>User mailbox files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/spool/</filename></entry>
|
|
<entry>Miscellaneous printer and mail system spooling
|
|
directories.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/tmp/</filename></entry>
|
|
<entry>Temporary files which are usually preserved
|
|
across a system reboot, unless
|
|
<filename class="directory">/var</filename> is a
|
|
memory-based file system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename
|
|
class="directory">/var/yp/</filename></entry>
|
|
<entry>NIS maps.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable></para>
|
|
</sect1>
|
|
|
|
<sect1 id="disk-organization">
|
|
<title>Disk Organization</title>
|
|
|
|
<para>The smallest unit of organization that &os; uses to find
|
|
files is the filename. Filenames are case-sensitive, which
|
|
means that <filename>readme.txt</filename> and
|
|
<filename>README.TXT</filename> are two separate files. &os;
|
|
does not use the extension of a file to determine whether the
|
|
file is a program, document, or some other form of data.</para>
|
|
|
|
<para>Files are stored in directories. A directory may contain no
|
|
files, or it may contain many hundreds of files. A directory
|
|
can also contain other directories, allowing you to build up a
|
|
hierarchy of directories within one another in order to organize
|
|
data.</para>
|
|
|
|
<para>Files and directories are referenced by giving the file or
|
|
directory name, followed by a forward slash,
|
|
<literal>/</literal>, followed by any other directory names that
|
|
are necessary. For example, if the directory
|
|
<filename>foo</filename> contains a directory
|
|
<filename>bar</filename> which contains the file
|
|
<filename>readme.txt</filename>, the full name, or
|
|
<firstterm>path</firstterm>, to the file is
|
|
<filename>foo/bar/readme.txt</filename>. Note that this is
|
|
different from &windows; which uses
|
|
<literal>\</literal> to separate file and directory
|
|
names. &os; does not use drive letters, or other drive names in
|
|
the path. For example, you would not type
|
|
<filename>c:/foo/bar/readme.txt</filename> on &os;.</para>
|
|
|
|
<para>Directories and files are stored in a file system. Each
|
|
file system contains exactly one directory at the very top
|
|
level, called the <firstterm>root directory</firstterm> for that
|
|
file system. This root directory can contain other
|
|
directories. One file system is designated the
|
|
<firstterm>root file system</firstterm> or <literal>/</literal>.
|
|
Every other file system is <firstterm>mounted</firstterm> under
|
|
the root file system. No matter how many disks you have on your
|
|
&os; system, every directory appears to be part of the same
|
|
disk.</para>
|
|
|
|
<para>Suppose you have three file systems, called
|
|
<literal>A</literal>, <literal>B</literal>, and
|
|
<literal>C</literal>. Each file system has one root directory,
|
|
which contains two other directories, called
|
|
<literal>A1</literal>, <literal>A2</literal> (and likewise
|
|
<literal>B1</literal>, <literal>B2</literal> and
|
|
<literal>C1</literal>, <literal>C2</literal>).</para>
|
|
|
|
<para>Call <literal>A</literal> the root file system. If you used
|
|
<command>ls</command> to view the contents of this directory you
|
|
would see two subdirectories, <literal>A1</literal> and
|
|
<literal>A2</literal>. The directory tree looks like
|
|
this:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/example-dir1" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"> /
|
|
|
|
|
+--- A1
|
|
|
|
|
`--- A2</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>A file system must be mounted on to a directory in another
|
|
file system. When mounting file system
|
|
<literal>B</literal> on to the directory <literal>A1</literal>,
|
|
the root directory of <literal>B</literal> replaces
|
|
<literal>A1</literal>, and the directories in
|
|
<literal>B</literal> appear accordingly:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/example-dir2" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"> /
|
|
|
|
|
+--- A1
|
|
| |
|
|
| +--- B1
|
|
| |
|
|
| `--- B2
|
|
|
|
|
`--- A2</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>Any files that are in the <literal>B1</literal> or
|
|
<literal>B2</literal> directories can be reached with the path
|
|
<filename>/A1/B1</filename> or <filename>/A1/B2</filename> as
|
|
necessary. Any files that were in <filename>/A1</filename> have
|
|
been temporarily hidden. They will reappear if
|
|
<literal>B</literal> is <firstterm>unmounted</firstterm> from
|
|
A.</para>
|
|
|
|
<para>If <literal>B</literal> had been mounted on
|
|
<literal>A2</literal> then the diagram would look like
|
|
this:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/example-dir3" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"> /
|
|
|
|
|
+--- A1
|
|
|
|
|
`--- A2
|
|
|
|
|
+--- B1
|
|
|
|
|
`--- B2</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>and the paths would be <filename>/A2/B1</filename> and
|
|
<filename>/A2/B2</filename> respectively.</para>
|
|
|
|
<para>File systems can be mounted on top of one another.
|
|
Continuing the last example, the <literal>C</literal> file
|
|
system could be mounted on top of the <literal>B1</literal>
|
|
directory in the <literal>B</literal> file system, leading to
|
|
this arrangement:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/example-dir4" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"> /
|
|
|
|
|
+--- A1
|
|
|
|
|
`--- A2
|
|
|
|
|
+--- B1
|
|
| |
|
|
| +--- C1
|
|
| |
|
|
| `--- C2
|
|
|
|
|
`--- B2</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>Or <literal>C</literal> could be mounted directly on to the
|
|
<literal>A</literal> file system, under the
|
|
<literal>A1</literal> directory:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/example-dir5" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"> /
|
|
|
|
|
+--- A1
|
|
| |
|
|
| +--- C1
|
|
| |
|
|
| `--- C2
|
|
|
|
|
`--- A2
|
|
|
|
|
+--- B1
|
|
|
|
|
`--- B2</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>This is similar, although not identical, to a &ms-dos;
|
|
<command>join</command>.</para>
|
|
|
|
<para>Typically you create file systems when installing &os;
|
|
and decide where to mount them, and then never change them
|
|
unless you add a new disk.</para>
|
|
|
|
<para>It is entirely possible to have one large root file system,
|
|
and not need to create any others. There are some drawbacks to
|
|
this approach, and one advantage.</para>
|
|
|
|
<itemizedlist>
|
|
<title>Benefits of Multiple File Systems</title>
|
|
|
|
<listitem>
|
|
<para>Different file systems can have different
|
|
<firstterm>mount options</firstterm>. For example, the root
|
|
file system can be mounted read-only, making it impossible
|
|
for users to inadvertently delete or edit a critical file.
|
|
Separating user-writable file systems, such as
|
|
<filename>/home</filename>, from other file systems allows
|
|
them to be mounted <firstterm>nosuid</firstterm>. This
|
|
option prevents the
|
|
<firstterm>suid</firstterm>/<firstterm>guid</firstterm> bits
|
|
on executables stored on the file system from taking effect,
|
|
possibly improving security.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>&os; automatically optimizes the layout of files on a
|
|
file system, depending on how the file system is being used.
|
|
So a file system that contains many small files that are
|
|
written frequently will have a different optimization to one
|
|
that contains fewer, larger files. By having one big file
|
|
system this optimization breaks down.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>&os;'s file systems are very robust should you lose
|
|
power. However, a power loss at a critical point could
|
|
still damage the structure of the file system. By splitting
|
|
data over multiple file systems it is more likely that the
|
|
system will still come up, making it easier to restore from
|
|
backup as necessary.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<itemizedlist>
|
|
<title>Benefit of a Single File System</title>
|
|
|
|
<listitem>
|
|
<para>File systems are a fixed size. If you create a file
|
|
system when you install &os; and give it a specific size,
|
|
you may later discover that you need to make the partition
|
|
bigger. This is not easily accomplished without backing up,
|
|
recreating the file system with the new size, and then
|
|
restoring the backed up data.</para>
|
|
|
|
<important>
|
|
<para>&os; features the &man.growfs.8; command, which
|
|
makes it possible to increase the size of file system on
|
|
the fly, removing this limitation.</para>
|
|
</important>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>File systems are contained in partitions. This does not
|
|
have the same meaning as the common usage of the term partition
|
|
(for example, &ms-dos; partition), because of &os;'s &unix;
|
|
heritage. Each partition is identified by a letter from
|
|
<literal>a</literal> through to <literal>h</literal>. Each
|
|
partition can contain only one file system, which means that
|
|
file systems are often described by either their typical mount
|
|
point in the file system hierarchy, or the letter of the
|
|
partition they are contained in.</para>
|
|
|
|
<para>&os; also uses disk space for <firstterm>swap
|
|
space</firstterm> to provide
|
|
<firstterm>virtual memory</firstterm>. This allows your
|
|
computer to behave as though it has much more memory than it
|
|
actually does. When &os; runs out of memory, it moves some of
|
|
the data that is not currently being used to the swap space, and
|
|
moves it back in (moving something else out) when it needs
|
|
it.</para>
|
|
|
|
<para>Some partitions have certain conventions associated with
|
|
them.</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<colspec colwidth="1*"/>
|
|
<colspec colwidth="5*"/>
|
|
|
|
<thead>
|
|
<row>
|
|
<entry>Partition</entry>
|
|
<entry>Convention</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody valign="top">
|
|
<row>
|
|
<entry><literal>a</literal></entry>
|
|
<entry>Normally contains the root file system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>b</literal></entry>
|
|
<entry>Normally contains swap space.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>c</literal></entry>
|
|
<entry>Normally the same size as the enclosing slice.
|
|
This allows utilities that need to work on the entire
|
|
slice, such as a bad block scanner, to work on the
|
|
<literal>c</literal> partition. You would not normally
|
|
create a file system on this partition.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>d</literal></entry>
|
|
<entry>Partition <literal>d</literal> used to have a
|
|
special meaning associated with it, although that is now
|
|
gone and <literal>d</literal> may work as any normal
|
|
partition.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>Each partition-that-contains-a-file-system is stored in what
|
|
&os; calls a <firstterm>slice</firstterm>. Slice is
|
|
&os;'s term for what the common call partitions, and again,
|
|
this is because of &os;'s &unix; background. Slices are
|
|
numbered, starting at 1, through to 4.</para>
|
|
|
|
<indexterm><primary>slices</primary></indexterm>
|
|
<indexterm><primary>partitions</primary></indexterm>
|
|
<indexterm><primary>dangerously dedicated</primary></indexterm>
|
|
|
|
<para>Slice numbers follow the device name, prefixed with an
|
|
<literal>s</literal>, starting at 1. So
|
|
<quote>da0<emphasis>s1</emphasis></quote> is the first slice on
|
|
the first SCSI drive. There can only be four physical slices on
|
|
a disk, but you can have logical slices inside physical slices
|
|
of the appropriate type. These extended slices are numbered
|
|
starting at 5, so <quote>ad0<emphasis>s5</emphasis></quote> is
|
|
the first extended slice on the first IDE disk. These devices
|
|
are used by file systems that expect to occupy a slice.</para>
|
|
|
|
<para>Slices, <quote>dangerously dedicated</quote> physical
|
|
drives, and other drives contain
|
|
<firstterm>partitions</firstterm>, which are represented as
|
|
letters from <literal>a</literal> to <literal>h</literal>. This
|
|
letter is appended to the device name, so
|
|
<quote>da0<emphasis>a</emphasis></quote> is the a partition on
|
|
the first da drive, which is <quote>dangerously
|
|
dedicated</quote>. <quote>ad1s3<emphasis>e</emphasis></quote> is
|
|
the fifth partition in the third slice of the second IDE disk
|
|
drive.</para>
|
|
|
|
<para>Finally, each disk on the system is identified. A disk name
|
|
starts with a code that indicates the type of disk, and then a
|
|
number, indicating which disk it is. Unlike slices, disk
|
|
numbering starts at 0. Common codes that you will see are
|
|
listed in <xref linkend="basics-dev-codes"/>.</para>
|
|
|
|
<para>When referring to a partition, include the disk name,
|
|
<literal>s</literal>, the slice number, and then the partition
|
|
letter. Examples are shown in <xref
|
|
linkend="basics-disk-slice-part"/>.</para>
|
|
|
|
<para><xref linkend="basics-concept-disk-model"/> shows a
|
|
conceptual model of a disk layout.</para>
|
|
|
|
<para>When installing &os;, configure the disk slices, create
|
|
partitions within the slice to be used for &os;, create a file
|
|
system or swap space in each partition, and decide where each
|
|
file system will be mounted.</para>
|
|
|
|
<table frame="none" pgwide="1" id="basics-dev-codes">
|
|
<title>Disk Device Codes</title>
|
|
|
|
<tgroup cols="2">
|
|
<colspec colwidth="1*"/>
|
|
<colspec colwidth="5*"/>
|
|
|
|
<thead>
|
|
<row>
|
|
<entry>Code</entry>
|
|
<entry>Meaning</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><devicename>ad</devicename></entry>
|
|
<entry>ATAPI (IDE) disk</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><devicename>da</devicename></entry>
|
|
<entry>SCSI direct access disk</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><devicename>acd</devicename></entry>
|
|
<entry>ATAPI (IDE) CDROM</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><devicename>cd</devicename></entry>
|
|
<entry>SCSI CDROM</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><devicename>fd</devicename></entry>
|
|
<entry>Floppy disk</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="basics-disk-slice-part">
|
|
<title>Sample Disk, Slice, and Partition Names</title>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<colspec colwidth="1*"/>
|
|
<colspec colwidth="5*"/>
|
|
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Meaning</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>ad0s1a</literal></entry>
|
|
<entry>The first partition (<literal>a</literal>) on the
|
|
first slice (<literal>s1</literal>) on the first IDE
|
|
disk (<literal>ad0</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>da1s2e</literal></entry>
|
|
|
|
<entry>The fifth partition (<literal>e</literal>) on the
|
|
second slice (<literal>s2</literal>) on the second
|
|
SCSI disk (<literal>da1</literal>).</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</example>
|
|
|
|
<example id="basics-concept-disk-model">
|
|
<title>Conceptual Model of a Disk</title>
|
|
|
|
<para>This diagram shows &os;'s view of the first IDE disk
|
|
attached to the system. Assume that the disk is 4 GB in
|
|
size, and contains two 2 GB slices (&ms-dos; partitions).
|
|
The first slice contains a &ms-dos; disk,
|
|
<devicename>C:</devicename>, and the second slice contains a
|
|
&os; installation. This example &os; installation has
|
|
three data partitions, and a swap partition.</para>
|
|
|
|
<para>The three partitions will each hold a file system.
|
|
Partition <literal>a</literal> will be used for the root file
|
|
system, <literal>e</literal> for the <filename
|
|
class="directory">/var/</filename> directory hierarchy, and
|
|
<literal>f</literal> for the <filename
|
|
class="directory">/usr/</filename> directory
|
|
hierarchy.</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="install/disk-layout" format="EPS"/>
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced">.-----------------. --.
|
|
| | |
|
|
| DOS / Windows | |
|
|
: : > First slice, ad0s1
|
|
: : |
|
|
| | |
|
|
:=================: ==: --.
|
|
| | | Partition a, mounted as / |
|
|
| | > referred to as ad0s2a |
|
|
| | | |
|
|
:-----------------: ==: |
|
|
| | | Partition b, used as swap |
|
|
| | > referred to as ad0s2b |
|
|
| | | |
|
|
:-----------------: ==: | Partition c, no
|
|
| | | Partition e, used as /var > file system, all
|
|
| | > referred to as ad0s2e | of FreeBSD slice,
|
|
| | | | ad0s2c
|
|
:-----------------: ==: |
|
|
| | | |
|
|
: : | Partition f, used as /usr |
|
|
: : > referred to as ad0s2f |
|
|
: : | |
|
|
| | | |
|
|
| | --' |
|
|
`-----------------' --'</literallayout>
|
|
</textobject>
|
|
</mediaobject>
|
|
</example>
|
|
</sect1>
|
|
|
|
<sect1 id="mount-unmount">
|
|
<title>Mounting and Unmounting File Systems</title>
|
|
|
|
<para>The file system is best visualized as a tree,
|
|
rooted, as it were, at <filename class="directory">/</filename>.
|
|
<filename class="directory">/dev</filename>,
|
|
<filename class="directory">/usr</filename>, and the
|
|
other directories in the root directory are branches, which may
|
|
have their own branches, such as
|
|
<filename class="directory">/usr/local</filename>, and so
|
|
on.</para>
|
|
|
|
<indexterm><primary>root file system</primary></indexterm>
|
|
<para>There are various reasons to house some of these
|
|
directories on separate file systems. <filename
|
|
class="directory">/var</filename> contains the directories
|
|
<filename class="directory">log/</filename>,
|
|
<filename class="directory">spool/</filename>, and various types
|
|
of temporary files, and as such, may get filled up. Filling up
|
|
the root file system is not a good idea, so splitting <filename
|
|
class="directory">/var</filename> from
|
|
<filename class="directory">/</filename> is often
|
|
favorable.</para>
|
|
|
|
<para>Another common reason to contain certain directory trees on
|
|
other file systems is if they are to be housed on separate
|
|
physical disks, or are separate virtual disks, such as
|
|
<link linkend="network-nfs">Network File System</link> mounts,
|
|
or CDROM drives.</para>
|
|
|
|
<sect2 id="disks-fstab">
|
|
<title>The <filename>fstab</filename> File</title>
|
|
|
|
<indexterm>
|
|
<primary>file systems</primary>
|
|
<secondary>mounted with fstab</secondary>
|
|
</indexterm>
|
|
|
|
<para>During the <link linkend="boot">boot process</link>,
|
|
file systems listed in <filename>/etc/fstab</filename> are
|
|
automatically mounted except for the entries containing
|
|
<option>noauto</option>. This file contains entries in the
|
|
following format:</para>
|
|
|
|
<programlisting><replaceable>device</replaceable> <replaceable>/mount-point</replaceable> <replaceable>fstype</replaceable> <replaceable>options</replaceable> <replaceable>dumpfreq</replaceable> <replaceable>passno</replaceable></programlisting>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>device</literal></term>
|
|
<listitem>
|
|
<para>An existing device name as explained in
|
|
<xref linkend="disks-naming"/>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>mount-point</literal></term>
|
|
|
|
<listitem>
|
|
<para>An existing directory on which to mount the file
|
|
system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>fstype</literal></term>
|
|
|
|
<listitem>
|
|
<para>The file system type to pass to &man.mount.8;. The
|
|
default &os; file system is
|
|
<literal>ufs</literal>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>options</literal></term>
|
|
|
|
<listitem>
|
|
<para>Either <option>rw</option> for read-write
|
|
file systems, or <option>ro</option> for read-only file
|
|
systems, followed by any other options that may be
|
|
needed. A common option is <option>noauto</option> for
|
|
file systems not normally mounted during the boot
|
|
sequence. Other options are listed in
|
|
&man.mount.8;.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>dumpfreq</literal></term>
|
|
|
|
<listitem>
|
|
<para>Used by &man.dump.8; to determine which file systems
|
|
require dumping. If the field is missing, a value of
|
|
zero is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>passno</literal></term>
|
|
|
|
<listitem>
|
|
<para>Determines the order in which file systems should be
|
|
checked. File systems that should be skipped should
|
|
have their <literal>passno</literal> set to zero. The
|
|
root file system needs to be checked before everything
|
|
else and should have its <literal>passno</literal> set
|
|
to one. The other file systems should be set to
|
|
values greater than one. If more than one file system
|
|
has the same <literal>passno</literal>, &man.fsck.8;
|
|
will attempt to check file systems in parallel if
|
|
possible.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Refer to &man.fstab.5; for more information on the format
|
|
of <filename>/etc/fstab</filename> and its options.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="disks-mount">
|
|
<title>The <command>mount</command> Command</title>
|
|
|
|
<indexterm>
|
|
<primary>file systems</primary>
|
|
<secondary>mounting</secondary>
|
|
</indexterm>
|
|
|
|
<para>File systems are mounted using &man.mount.8;. The most
|
|
basic syntax is as follows:</para>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.root; <userinput>mount <replaceable>device</replaceable> <replaceable>mountpoint</replaceable></userinput></screen>
|
|
</informalexample>
|
|
|
|
<para>This command provides many options which are described in
|
|
&man.mount.8;, The most commonly used options include:</para>
|
|
|
|
<variablelist>
|
|
<title>Mount Options</title>
|
|
|
|
<varlistentry>
|
|
<term><option>-a</option></term>
|
|
|
|
<listitem>
|
|
<para>Mount all the file systems listed in
|
|
<filename>/etc/fstab</filename>, except those marked as
|
|
<quote>noauto</quote>, excluded by the
|
|
<option>-t</option> flag, or those that are already
|
|
mounted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-d</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>Do everything except for the actual mount system
|
|
call. This option is useful in conjunction with the
|
|
<option>-v</option> flag to determine what &man.mount.8;
|
|
is actually trying to do.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-f</option></term>
|
|
|
|
<listitem>
|
|
<para>Force the mount of an unclean file system
|
|
(dangerous), or the revocation of write access when
|
|
downgrading a file system's mount status from read-write
|
|
to read-only.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-r</option></term>
|
|
|
|
<listitem>
|
|
<para>Mount the file system read-only. This is identical
|
|
to using <option>-o ro</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-t</option>
|
|
<replaceable>fstype</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Mount the specified file system type or mount only
|
|
file systems of the given type, if <option>-a</option>
|
|
is included. <quote>ufs</quote> is the default file
|
|
system type.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-u</option></term>
|
|
|
|
<listitem>
|
|
<para>Update mount options on the file system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-v</option></term>
|
|
|
|
<listitem>
|
|
<para>Be verbose.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-w</option></term>
|
|
|
|
<listitem>
|
|
<para>Mount the file system read-write.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>The following options can be passed to <option>-o</option>
|
|
as a comma-separated list:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>noexec</term>
|
|
|
|
<listitem>
|
|
<para>Do not allow execution of binaries on this file
|
|
system. This is also a useful security option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>nosuid</term>
|
|
|
|
<listitem>
|
|
<para>Do not interpret setuid or setgid flags on the
|
|
file system. This is also a useful security
|
|
option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2 id="disks-umount">
|
|
<title>The <command>umount</command> Command</title>
|
|
|
|
<indexterm>
|
|
<primary>file systems</primary>
|
|
<secondary>unmounting</secondary>
|
|
</indexterm>
|
|
|
|
<para>To unmount a filesystem use &man.umount.8;. This command
|
|
takes one parameter which can be a mountpoint, device name,
|
|
<option>-a</option> or <option>-A</option>.</para>
|
|
|
|
<para>All forms take <option>-f</option> to force unmounting,
|
|
and <option>-v</option> for verbosity. Be warned that
|
|
<option>-f</option> is not generally a good idea as it might
|
|
crash the computer or damage data on the file system.</para>
|
|
|
|
<para>To unmount all mounted file systems, or just the file
|
|
system types listed after <option>-t</option>, use
|
|
<option>-a</option> or <option>-A</option>. Note that
|
|
<option>-A</option> does not attempt to unmount the root file
|
|
system.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="basics-processes">
|
|
<title>Processes</title>
|
|
|
|
<para>&os; is a multi-tasking operating system. Each program
|
|
running at any one time is called a
|
|
<firstterm>process</firstterm>. Every running command starts
|
|
at least one new process and there are a number of system
|
|
processes that are run by &os;.</para>
|
|
|
|
<para>Each process is uniquely identified by a number called a
|
|
<firstterm>process ID</firstterm>
|
|
(<firstterm>PID</firstterm>). Similar to files, each process
|
|
has one owner and group, and the owner and group permissions are
|
|
used to determine which files and devices the process can open.
|
|
Most processes also have a parent process that started them.
|
|
For example, the shell is a process, and any command started in
|
|
the shell is a process which has the shell as its parent
|
|
process. The exception is a special process called
|
|
&man.init.8; which is always the first process to start at boot
|
|
time and which always has a PID of 1.</para>
|
|
|
|
<para>To see the processes on the system, use &man.ps.1; and
|
|
&man.top.1;. To display a static list of the currently running
|
|
processes, their PIDs, how much memory they are using, and the
|
|
command they were started with, use <command>ps</command>. To
|
|
display all the running processes and update the display every
|
|
few seconds so that you can interactively see what the computer
|
|
is doing, use <command>top</command>.</para>
|
|
|
|
<para>By default, <command>ps</command> only shows the commands
|
|
that are running and owned by the user. For example:</para>
|
|
|
|
<screen>&prompt.user; <userinput>ps</userinput>
|
|
PID TT STAT TIME COMMAND
|
|
298 p0 Ss 0:01.10 tcsh
|
|
7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14)
|
|
37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14)
|
|
48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
|
|
72210 p0 R+ 0:00.00 ps
|
|
390 p1 Is 0:01.14 tcsh
|
|
7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y
|
|
6688 p3 IWs 0:00.00 tcsh
|
|
10735 p4 IWs 0:00.00 tcsh
|
|
20256 p5 IWs 0:00.00 tcsh
|
|
262 v0 IWs 0:00.00 -tcsh (tcsh)
|
|
270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16
|
|
280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16
|
|
284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc
|
|
285 v0 S 0:38.45 /usr/X11R6/bin/sawfish</screen>
|
|
|
|
<para>The output from &man.ps.1; is organized into a number of
|
|
columns. The <literal>PID</literal> column displays the process
|
|
ID. PIDs are assigned starting at 1, go up to 99999, then wrap
|
|
around back to the beginning. However, a PID is not reassigned
|
|
if it is already in use. The <literal>TT</literal> column shows
|
|
the tty the program is running on and <literal>STAT</literal>
|
|
shows the program's state. <literal>TIME</literal> is the
|
|
amount of time the program has been running on the CPU. This is
|
|
usually not the elapsed time since the program was started, as
|
|
most programs spend a lot of time waiting for things to happen
|
|
before they need to spend time on the CPU. Finally,
|
|
<literal>COMMAND</literal> is the command that was used to start
|
|
the program.</para>
|
|
|
|
<para>&man.ps.1; supports a number of different options to change
|
|
the information that is displayed. One of the most useful sets
|
|
is <literal>auxww</literal>. <option>a</option> displays
|
|
information about all the running processes of all users.
|
|
<option>u</option> displays the username of the process' owner,
|
|
as well as memory usage. <option>x</option> displays
|
|
information about daemon processes, and <option>ww</option>
|
|
causes &man.ps.1; to display the full command line for each
|
|
process, rather than truncating it once it gets too long to fit
|
|
on the screen.</para>
|
|
|
|
<para>The output from &man.top.1; is similar. A sample session
|
|
looks like this:</para>
|
|
|
|
<screen>&prompt.user; <userinput>top</userinput>
|
|
last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10
|
|
47 processes: 1 running, 46 sleeping
|
|
CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle
|
|
Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free
|
|
Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
|
|
|
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
|
|
72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top
|
|
7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14
|
|
281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA
|
|
296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm
|
|
48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu
|
|
175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd
|
|
7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt
|
|
...</screen>
|
|
|
|
<para>The output is split into two sections. The header (the
|
|
first five lines) shows the PID of the last process to run, the
|
|
system load averages (which are a measure of how busy the system
|
|
is), the system uptime (time since the last reboot) and the
|
|
current time. The other figures in the header relate to how
|
|
many processes are running (47 in this case), how much memory
|
|
and swap space has been used, and how much time the system is
|
|
spending in different CPU states.</para>
|
|
|
|
<para>Below the header is a series of columns containing similar
|
|
information to the output from &man.ps.1;, such as the PID,
|
|
username, amount of CPU time, and the command that started the
|
|
process. By default, &man.top.1; also displays the amount of
|
|
memory space taken by the process. This is split into two
|
|
columns: one for total size and one for resident size. Total
|
|
size is how much memory the application has needed and the
|
|
resident size is how much it is actually using at the moment.
|
|
In this example, <application>&netscape;</application> has
|
|
required almost 30 MB of RAM, but is currently only using
|
|
9 MB.</para>
|
|
|
|
<para>&man.top.1; automatically updates the display every two
|
|
seconds. A different interval can be specified with
|
|
<option>-s</option>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="basics-daemons">
|
|
<title>Daemons, Signals, and Killing Processes</title>
|
|
|
|
<para>When using an editor, it is easy to control the editor and
|
|
load files because the editor provides facilities to do so, and
|
|
because the editor is attached to a
|
|
<firstterm>terminal</firstterm>. Some programs are not designed
|
|
to be run with continuous user input and disconnect from the
|
|
terminal at the first opportunity. For example, a web server
|
|
responds to web requests, rather than user input. Mail servers
|
|
are another example of this type of application.</para>
|
|
|
|
<para>These programs are known as <firstterm>daemons</firstterm>.
|
|
The term daemon comes from Greek mythology and represents an
|
|
entity that is neither good or evil, and which invisibly
|
|
performs useful tasks. This is why the BSD mascot is the
|
|
cheerful-looking daemon with sneakers and a pitchfork.</para>
|
|
|
|
<para>There is a convention to name programs that normally run as
|
|
daemons with a trailing <quote>d</quote>.
|
|
<application>BIND</application> is the Berkeley Internet Name
|
|
Domain, but the actual program that executes is
|
|
<command>named</command>. The <application>Apache</application>
|
|
web server program is <command>httpd</command> and the
|
|
line printer spooling daemon is <command>lpd</command>. This is
|
|
only a naming convention. For example, the main mail daemon for
|
|
the <application>Sendmail</application> application is
|
|
<command>sendmail</command>, and not
|
|
<command>maild</command>.</para>
|
|
|
|
<para>One way to communicate with a daemon, or any running
|
|
process, is to send a <firstterm>signal</firstterm> using
|
|
&man.kill.1;. There are a number of different signals; some
|
|
have a specific meaning while others are described in the
|
|
application's documentation. A user can only send a signal to a
|
|
process they own and sending a signal to someone else's process
|
|
will result in a permission denied error. The exception is the
|
|
<username>root</username> user, who can send signals to anyone's
|
|
processes.</para>
|
|
|
|
<para>&os; can also send a signal to a process. If an application
|
|
is badly written and tries to access memory that it is not
|
|
supposed to, &os; will send the process the
|
|
<firstterm>Segmentation Violation</firstterm> signal
|
|
(<literal>SIGSEGV</literal>). If an application has used the
|
|
&man.alarm.3; system call to be alerted after a period of time
|
|
has elapsed, it will be sent the Alarm signal
|
|
(<literal>SIGALRM</literal>).</para>
|
|
|
|
<para>Two signals can be used to stop a process:
|
|
<literal>SIGTERM</literal> and <literal>SIGKILL</literal>.
|
|
<literal>SIGTERM</literal> is the polite way to kill a process
|
|
as the process can read the signal, close any log files it may
|
|
have open, and attempt to finish what it is doing before
|
|
shutting down. In some cases, a process may ignore
|
|
<literal>SIGTERM</literal> if it is in the middle of some task
|
|
that can not be interrupted.</para>
|
|
|
|
<para><literal>SIGKILL</literal> can not be ignored by a process.
|
|
This is the <quote>I do not care what you are doing, stop right
|
|
now</quote> signal. Sending a <literal>SIGKILL</literal> to a
|
|
process will usually stop that process there and then.<footnote>
|
|
<para>There are a few tasks that can not be interrupted. For
|
|
example, if the process is trying to read from a file that
|
|
is on another computer on the network, and the other
|
|
computer is unavailable, the process is said to be
|
|
<quote>uninterruptible</quote>. Eventually the process will
|
|
time out, typically after two minutes. As soon as this time
|
|
out occurs the process will be killed.</para>
|
|
</footnote>.</para>
|
|
|
|
<para>Other commonly used signals are <literal>SIGHUP</literal>,
|
|
<literal>SIGUSR1</literal>, and <literal>SIGUSR2</literal>.
|
|
These are general purpose signals and different applications
|
|
will respond differently.</para>
|
|
|
|
<para>For example, after changing a web server's configuration
|
|
file, the web server needs to be told to re-read its
|
|
configuration. Restarting <command>httpd</command> would result
|
|
in a brief outage period on the web server. Instead, send the
|
|
daemon the <literal>SIGHUP</literal> signal. Be aware that
|
|
different daemons will have different behavior, so refer to the
|
|
documentation for the daemon to determine if
|
|
<literal>SIGHUP</literal> will achieve the desired
|
|
results.</para>
|
|
|
|
<procedure>
|
|
<title>Sending a Signal to a Process</title>
|
|
|
|
<para>This example shows how to send a signal to &man.inetd.8;.
|
|
The <command>inetd</command> configuration file is
|
|
<filename>/etc/inetd.conf</filename>, and
|
|
<command>inetd</command> will re-read this configuration file
|
|
when it is sent a <literal>SIGHUP</literal>.</para>
|
|
|
|
<step>
|
|
<para>Find the PID of the process you want to send the signal
|
|
to using &man.pgrep.1;. In this example, the PID for
|
|
&man.inetd.8; is 198:</para>
|
|
|
|
<screen>&prompt.user; <userinput>pgrep -l inetd</userinput>
|
|
198 inetd -wW</screen>
|
|
|
|
</step>
|
|
|
|
<step>
|
|
<para>Use &man.kill.1; to send the signal. Because
|
|
&man.inetd.8; is owned by <username>root</username>, use
|
|
&man.su.1; to become <username>root</username> first.</para>
|
|
|
|
<screen>&prompt.user; <userinput>su</userinput>
|
|
<prompt>Password:</prompt>
|
|
&prompt.root; <userinput>/bin/kill -s HUP 198</userinput></screen>
|
|
|
|
<para>Like most &unix; commands, &man.kill.1; will not print
|
|
any output if it is successful. If you send a signal to a
|
|
process that you do not own, you will instead see
|
|
<errorname>kill: <replaceable>PID</replaceable>: Operation
|
|
not permitted</errorname>. Mistyping the PID will either
|
|
send the signal to the wrong process, which could have
|
|
negative results, or will send the signal to a PID that is
|
|
not currently in use, resulting in the error
|
|
<errorname>kill: <replaceable>PID</replaceable>: No such
|
|
process</errorname>.</para>
|
|
|
|
<note>
|
|
<title>Why Use <command>/bin/kill</command>?</title>
|
|
|
|
<para>Many shells provide <command>kill</command> as a built
|
|
in command, meaning that the shell will send the signal
|
|
directly, rather than running
|
|
<filename>/bin/kill</filename>. Be aware that different
|
|
shells have a different syntax for specifying the name of
|
|
the signal to send. Rather than try to learn all of them,
|
|
it can be simpler to use <command>/bin/kill
|
|
<replaceable>...</replaceable></command>
|
|
directly.</para>
|
|
</note>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>When sending other signals, substitute
|
|
<literal>TERM</literal> or <literal>KILL</literal> in the
|
|
command line as necessary.</para>
|
|
|
|
<important>
|
|
<para>Killing a random process on the system can be a bad idea.
|
|
In particular, &man.init.8;, PID 1, is special. Running
|
|
<command>/bin/kill -s KILL 1</command> is a quick, and
|
|
unrecommended, way to shutdown the system.
|
|
<emphasis>Always</emphasis> double check the arguments to
|
|
&man.kill.1; <emphasis>before</emphasis> pressing
|
|
<keycap>Return</keycap>.</para>
|
|
</important>
|
|
</sect1>
|
|
|
|
<sect1 id="shells">
|
|
<title>Shells</title>
|
|
|
|
<indexterm><primary>shells</primary></indexterm>
|
|
<indexterm><primary>command line</primary></indexterm>
|
|
|
|
<para>&os; provides a command line interface called a shell. A
|
|
shell receives commands from the input channel and executes
|
|
them. Many shells provide built in functions to help with
|
|
everyday tasks such as file management, file globbing, command
|
|
line editing, command macros, and environment variables. &os;
|
|
comes with several shells, including <command>sh</command>, the
|
|
Bourne Shell, and <command>tcsh</command>, the improved C-shell.
|
|
Other shells are available from the &os; Ports Collection, such
|
|
as <command>zsh</command> and <command>bash</command>.</para>
|
|
|
|
<para>The shell that is used is really a matter of taste. A C
|
|
programmer might feel more comfortable with a C-like shell such
|
|
as <command>tcsh</command>. A Linux user might prefer
|
|
<command>bash</command>. Each shell has unique properties that
|
|
may or may not work with a user's preferred working environment,
|
|
which is why there is a choice of which shell to use.</para>
|
|
|
|
<para>One common shell feature is filename completion. After a
|
|
user types the first few letters of a command or filename and
|
|
presses <keycap>Tab</keycap>, the shell will automatically
|
|
complete the rest of the command or filename. Consider two
|
|
files called <filename>foobar</filename> and
|
|
<filename>foo.bar</filename>. To delete
|
|
<filename>foo.bar</filename>, type <command>rm
|
|
fo[<keycap>Tab</keycap>].[<keycap>Tab</keycap>]</command>.</para>
|
|
|
|
<para>The shell should print out <command>rm
|
|
foo[BEEP].bar</command>.</para>
|
|
|
|
<para>The [BEEP] is the console bell, which the shell used to
|
|
indicate it was unable to complete the filename because there
|
|
is more than one match. Both <filename>foobar</filename> and
|
|
<filename>foo.bar</filename> start with <literal>fo</literal>.
|
|
By typing <literal>.</literal>, then pressing
|
|
<keycap>Tab</keycap> again, the shell would be able to fill in
|
|
the rest of the filename.</para>
|
|
|
|
<indexterm><primary>environment variables</primary></indexterm>
|
|
|
|
<para>Another feature of the shell is the use of environment
|
|
variables. Environment variables are a variable/key pair stored
|
|
in the shell's environment. This environment can be read by any
|
|
program invoked by the shell, and thus contains a lot of program
|
|
configuration. Here is a list of common environment variables
|
|
and their meanings:</para>
|
|
|
|
<indexterm><primary>environment variables</primary></indexterm>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><envar>USER</envar></entry>
|
|
<entry>Current logged in user's name.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>PATH</envar></entry>
|
|
<entry>Colon-separated list of directories to search for
|
|
binaries.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>DISPLAY</envar></entry>
|
|
<entry>Network name of the <application>Xorg</application>
|
|
display to connect to, if available.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>SHELL</envar></entry>
|
|
<entry>The current shell.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>TERM</envar></entry>
|
|
|
|
<entry>The name of the user's type of terminal. Used to
|
|
determine the capabilities of the terminal.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>TERMCAP</envar></entry>
|
|
|
|
<entry>Database entry of the terminal escape codes to
|
|
perform various terminal functions.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>OSTYPE</envar></entry>
|
|
<entry>Type of operating system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>MACHTYPE</envar></entry>
|
|
<entry>The system's CPU architecture.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>EDITOR</envar></entry>
|
|
<entry>The user's preferred text editor.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>PAGER</envar></entry>
|
|
<entry>The user's preferred text pager.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><envar>MANPATH</envar></entry>
|
|
<entry>Colon-separated list of directories to search for
|
|
manual pages.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<indexterm><primary>Bourne shells</primary></indexterm>
|
|
|
|
<para>How to set an environment variable differs between shells.
|
|
In <command>tcsh</command> and <command>csh</command>, use
|
|
<command>setenv</command> to set environment variables. In
|
|
<command>sh</command> and <command>bash</command>, use
|
|
<command>export</command> to set the current environment
|
|
variables. This example sets the default <envar>EDITOR</envar>
|
|
to <filename>/usr/local/bin/emacs</filename> for the
|
|
<command>tcsh</command> shell:</para>
|
|
|
|
<screen>&prompt.user; <userinput>setenv EDITOR /usr/local/bin/emacs</userinput></screen>
|
|
|
|
<para>The equivalent command for <command>bash</command>
|
|
would be:</para>
|
|
|
|
<screen>&prompt.user; <userinput>export EDITOR="/usr/local/bin/emacs"</userinput></screen>
|
|
|
|
<para>To expand an environment variable in order to see its
|
|
current setting, type a <literal>$</literal> character in front
|
|
of its name on the command line. For example,
|
|
<command>echo $TERM</command> displays the current
|
|
<envar>$TERM</envar> setting.</para>
|
|
|
|
<para>Shells treat special characters, known as meta-characters,
|
|
as special representations of data. The most common
|
|
meta-character is <literal>*</literal>, which
|
|
represents any number of characters in a filename.
|
|
Meta-characters can be used to perform filename globbing. For
|
|
example, <command>echo *</command> is equivalent to
|
|
<command>ls</command> because the shell takes all the files that
|
|
match <literal>*</literal> and <command>echo</command> lists
|
|
them on the command line.</para>
|
|
|
|
<para>To prevent the shell from interpreting a special character,
|
|
escape it from the shell by starting it with a backslash
|
|
(<literal>\</literal>). For example,
|
|
<command>echo $TERM</command> prints the terminal setting
|
|
whereas <command>echo \$TERM</command> literally prints the
|
|
string <literal>$TERM</literal>.</para>
|
|
|
|
<sect2 id="changing-shells">
|
|
<title>Changing Your Shell</title>
|
|
|
|
<para>The easiest way to permanently change the default shell is
|
|
to use <command>chsh</command>. Running this command will
|
|
open the editor that is configured in the
|
|
<envar>EDITOR</envar> environment variable, which by default
|
|
is set to <command>vi</command>. Change
|
|
the <quote>Shell:</quote> line to the full path of the
|
|
new shell.</para>
|
|
|
|
<para>Alternately, use <command>chsh -s</command> which will set
|
|
the specified shell without opening an editor. For example,
|
|
to change the shell to <command>bash</command>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>chsh -s /usr/local/bin/bash</userinput></screen>
|
|
|
|
<note>
|
|
<para>The new shell <emphasis>must</emphasis> be present in
|
|
<filename>/etc/shells</filename>. If the shell was
|
|
installed from the &os; <link linkend="ports">Ports
|
|
Collection</link>, it should be automatically added to
|
|
this file. If it is missing, add it using this
|
|
command, replacing the path with the path of the
|
|
shell:</para>
|
|
|
|
<screen>&prompt.root; <userinput>echo <replaceable>/usr/local/bin/bash</replaceable> >> /etc/shells</userinput></screen>
|
|
|
|
<para>Then rerun <command>chsh</command>.</para>
|
|
</note>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="editors">
|
|
<title>Text Editors</title>
|
|
|
|
<indexterm><primary>text editors</primary></indexterm>
|
|
<indexterm><primary>editors</primary></indexterm>
|
|
|
|
<para>Most &os; configuration is done by editing text files.
|
|
Because of this, it is a good idea to become familiar with a
|
|
text editor. &os; comes with a few as part of the base system,
|
|
and many more are available in the Ports Collection.</para>
|
|
|
|
<indexterm>
|
|
<primary><command>ee</command></primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>editors</primary>
|
|
<secondary><command>ee</command></secondary>
|
|
</indexterm>
|
|
|
|
<para>A simple editor to learn is <application>ee</application>,
|
|
which stands for easy editor. To start this editor, type
|
|
<command>ee <replaceable>filename</replaceable></command> where
|
|
<replaceable>filename</replaceable> is the name of the file to
|
|
be edited. Once inside the editor, all of the commands for
|
|
manipulating the editor's functions are listed at the top of the
|
|
display. The caret <literal>^</literal> represents
|
|
<keycap>Ctrl</keycap>, so <literal>^e</literal> expands to
|
|
<keycombo
|
|
action="simul"><keycap>Ctrl</keycap><keycap>e</keycap></keycombo>.
|
|
To leave <application>ee</application>, press
|
|
<keycap>Esc</keycap>, then choose the <quote>leave
|
|
editor</quote> option from the main menu. The editor will
|
|
prompt you to save any changes if the file has been
|
|
modified.</para>
|
|
|
|
<indexterm>
|
|
<primary><command>vi</command></primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>editors</primary>
|
|
<secondary><command>vi</command></secondary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary><command>emacs</command></primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>editors</primary>
|
|
<secondary><command>emacs</command></secondary>
|
|
</indexterm>
|
|
|
|
<para>&os; also comes with more powerful text editors such as
|
|
<application>vi</application> as part of the base system.
|
|
Other editors, like <filename
|
|
role="package">editors/emacs</filename> and
|
|
<filename role="package">editors/vim</filename>, are part of the
|
|
&os; Ports Collection. These editors offer more functionality
|
|
at the expense of being a more complicated to learn. Learning a
|
|
more powerful editor such as <application>vim</application> or
|
|
<application>Emacs</application> can save more time in the long
|
|
run.</para>
|
|
|
|
<para>Many applications which modify files or require typed input
|
|
will automatically open a text editor. To alter the default
|
|
editor used, set the <envar>EDITOR</envar> environment
|
|
variable as described in the <link
|
|
linkend="shells">shells</link> section.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="basics-devices">
|
|
<title>Devices and Device Nodes</title>
|
|
|
|
<para>A device is a term used mostly for hardware-related
|
|
activities in a system, including disks, printers, graphics
|
|
cards, and keyboards. When &os; boots, the majority of the boot
|
|
messages refer to devices being detected. A copy of the boot
|
|
messages are saved to
|
|
<filename>/var/run/dmesg.boot</filename>.</para>
|
|
|
|
<para>Each device has a device name and number. For example,
|
|
<devicename>acd0</devicename> is the first IDE CD-ROM drive,
|
|
while <devicename>kbd0</devicename> represents the
|
|
keyboard.</para>
|
|
|
|
<para>Most devices in a &os; must be accessed through special
|
|
files called device nodes, which are located in
|
|
<filename>/dev</filename>.</para>
|
|
|
|
<sect2>
|
|
<title>Creating Device Nodes</title>
|
|
|
|
<para>When adding a new device to your system, or compiling
|
|
in support for additional devices, new device nodes must
|
|
be created.</para>
|
|
|
|
<sect3>
|
|
<title><literal>DEVFS</literal> (DEVice File System)</title>
|
|
|
|
<para> The device file system, <literal>DEVFS</literal>,
|
|
provides access to the kernel's device namespace in the
|
|
global file system namespace. Instead of having to
|
|
manually create and modify device nodes,
|
|
<literal>DEVFS</literal> automatically maintains this
|
|
particular file system. Refer to &man.devfs.5; for
|
|
more information.</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="binary-formats">
|
|
<title>Binary Formats</title>
|
|
|
|
<para>To understand why &os; uses the &man.elf.5; format,the three
|
|
currently <quote>dominant</quote> executable formats for &unix;
|
|
must be described:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>&man.a.out.5;</para>
|
|
|
|
<para>The oldest and <quote>classic</quote> &unix; object
|
|
format. It uses a short and compact header with a
|
|
&man.magic.5; number at the beginning that is often used to
|
|
characterize the format. It contains three loaded segments:
|
|
.text, .data, and .bss, plus a symbol table and a string
|
|
table.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><acronym>COFF</acronym></para>
|
|
|
|
<para>The SVR3 object format. The header comprises a section
|
|
table which can contain more than just .text, .data, and
|
|
.bss sections.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>&man.elf.5;</para>
|
|
|
|
<para>The successor to <acronym>COFF</acronym>, featuring
|
|
multiple sections and 32-bit or 64-bit possible values. One
|
|
major drawback is that <acronym>ELF</acronym> was designed
|
|
with the assumption that there would be only one ABI per
|
|
system architecture. That assumption is actually incorrect,
|
|
and not even in the commercial SYSV world (which has at
|
|
least three ABIs: SVR4, Solaris, SCO) does it hold
|
|
true.</para>
|
|
|
|
<para>&os; tries to work around this problem somewhat by
|
|
providing a utility for <emphasis>branding</emphasis> a
|
|
known <acronym>ELF</acronym> executable with information
|
|
about its compliant ABI. Refer to &man.brandelf.1; for more
|
|
information.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>&os; comes from the <quote>classic</quote> camp and used
|
|
the &man.a.out.5; format, a technology tried and proven through
|
|
many generations of BSD releases, until the beginning of the 3.X
|
|
branch. Though it was possible to build and run native
|
|
<acronym>ELF</acronym> binaries and kernels on a &os;
|
|
system for some time before that, &os; initially resisted the
|
|
<quote>push</quote> to switch to <acronym>ELF</acronym> as the
|
|
default format. Why? When Linux made its painful transition to
|
|
<acronym>ELF</acronym>, it was due to their inflexible
|
|
jump-table based shared library mechanism, which made the
|
|
construction of shared libraries difficult for vendors and
|
|
developers. Since <acronym>ELF</acronym> tools offered a
|
|
solution to the shared library problem and were generally seen
|
|
as <quote>the way forward</quote>, the migration cost was
|
|
accepted as necessary and the transition made. &os;'s shared
|
|
library mechanism is based more closely on the &sunos; style
|
|
shared library mechanism and is easy to use.</para>
|
|
|
|
<para>So, why are there so many different formats? Back in the
|
|
PDP-11 days when simple hardware supported a simple, small
|
|
system, <filename>a.out</filename> was adequate for the job of
|
|
representing binaries. As &unix; was ported, the
|
|
<filename>a.out</filename> format was retained because it was
|
|
sufficient for the early ports of &unix; to architectures like
|
|
the Motorola 68k or VAXen.</para>
|
|
|
|
<para>Then some hardware engineer decided that if he could force
|
|
software to do some sleazy tricks, a few gates could be shaved
|
|
off the design and the CPU core could run faster.
|
|
<filename>a.out</filename> was ill-suited for this new kind of
|
|
hardware, known as <acronym>RISC</acronym>. Many formats were
|
|
developed to get better performance from this hardware than the
|
|
limited, simple <filename>a.out</filename> format could offer.
|
|
<acronym>COFF</acronym>, <acronym>ECOFF</acronym>, and a few
|
|
others were invented and their limitations explored before
|
|
settling on <acronym>ELF</acronym>.</para>
|
|
|
|
<para>In addition, program sizes were getting huge while disks
|
|
and physical memory were still relatively small, so the concept
|
|
of a shared library was born. The virtual memory system became
|
|
more sophisticated. While each advancement was done using the
|
|
<filename>a.out</filename> format, its usefulness was stretched
|
|
with each new feature. In addition, people wanted to
|
|
dynamically load things at run time, or to junk parts of their
|
|
program after the init code had run to save in core memory and
|
|
swap space. Languages became more sophisticated and people
|
|
wanted code called before the main() function automatically.
|
|
Lots of hacks were done to the <filename>a.out</filename> format
|
|
to allow all of these things to happen, and they basically
|
|
worked for a time. In time, <filename>a.out</filename> was not
|
|
up to handling all these problems without an ever increasing
|
|
overhead in code and complexity. While <acronym>ELF</acronym>
|
|
solved many of these problems, it would be painful to switch
|
|
from the system that basically worked. So
|
|
<acronym>ELF</acronym> had to wait until it was more painful to
|
|
remain with <filename>a.out</filename> than it was to migrate to
|
|
<acronym>ELF</acronym>.</para>
|
|
|
|
<para>As time passed, the build tools that &os; derived their
|
|
build tools from, especially the assembler and loader, evolved
|
|
in two parallel trees. The &os; tree added shared libraries and
|
|
fixed some bugs. The GNU folks that originally wrote these
|
|
programs rewrote them and added simpler support for building
|
|
cross compilers and plugging in different formats. Those who
|
|
wanted to build cross compilers targeting &os; were out of luck
|
|
since the older sources that &os; had for
|
|
<application>as</application> and <application>ld</application>
|
|
were not up to the task. The new GNU tools chain
|
|
(<application>binutils</application>) supports cross
|
|
compiling, <acronym>ELF</acronym>, shared libraries, and C++
|
|
extensions. In addition, many vendors release
|
|
<acronym>ELF</acronym> binaries, and &os; should be able to run
|
|
them.</para>
|
|
|
|
<para><acronym>ELF</acronym> is more expressive than
|
|
<filename>a.out</filename> and allows more extensibility in the
|
|
base system. The <acronym>ELF</acronym> tools are better
|
|
maintained and offer cross compilation support.
|
|
<acronym>ELF</acronym> may be a little slower than
|
|
<filename>a.out</filename>, but trying to measure it can be
|
|
difficult. There are also numerous details that are different
|
|
between the two such as how they map pages and handle init code.
|
|
In time, support for <filename>a.out</filename> will be moved
|
|
out of the <filename>GENERIC</filename> kernel, and eventually
|
|
removed from the kernel once the need to run legacy
|
|
<filename>a.out</filename> programs is past.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="basics-more-information">
|
|
<title>For More Information</title>
|
|
|
|
<sect2 id="basics-man">
|
|
<title>Manual Pages</title>
|
|
|
|
<indexterm><primary>manual pages</primary></indexterm>
|
|
|
|
<para>The most comprehensive documentation on &os; is in the
|
|
form of manual pages. Nearly every program on the system
|
|
comes with a short reference manual explaining the basic
|
|
operation and available arguments. These manuals can be
|
|
viewed using <command>man</command>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>man <replaceable>command</replaceable></userinput></screen>
|
|
|
|
<para>where <replaceable>command</replaceable> is the name of
|
|
the command you wish to learn about. For example, to learn
|
|
more about <command>ls</command>, type:</para>
|
|
|
|
<screen>&prompt.user; <userinput>man ls</userinput></screen>
|
|
|
|
<para>The online manual is divided into numbered
|
|
sections:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>User commands.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>System calls and error numbers.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Functions in the C libraries.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Device drivers.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>File formats.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Games and other diversions.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Miscellaneous information.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>System maintenance and operation commands.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Kernel developers.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In some cases, the same topic may appear in more than one
|
|
section of the online manual. For example, there is a
|
|
<command>chmod</command> user command and a
|
|
<function>chmod()</function> system call. To tell
|
|
<command>man</command> which section to display, specify the
|
|
section number:</para>
|
|
|
|
<screen>&prompt.user; <userinput>man 1 chmod</userinput></screen>
|
|
|
|
<para>This will display the manual page for the user command
|
|
<command>chmod</command>. References to a particular section
|
|
of the online manual are traditionally placed in parenthesis
|
|
in written documentation, so &man.chmod.1; refers to the
|
|
<command>chmod</command> user command and &man.chmod.2; refers
|
|
to the system call.</para>
|
|
|
|
<para>If you do not know the command name, use <command>man
|
|
-k</command> to search for keywords in the command
|
|
descriptions:</para>
|
|
|
|
<screen>&prompt.user; <userinput>man -k <replaceable>mail</replaceable></userinput></screen>
|
|
|
|
<para>This command displays a list of commands that have the
|
|
keyword <quote>mail</quote> in their descriptions. This is
|
|
equivalent to using &man.apropos.1;.</para>
|
|
|
|
<para>To determine what the commands in
|
|
<filename>/usr/bin</filename> do, type:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd /usr/bin</userinput>
|
|
&prompt.user; <userinput>man -f *</userinput></screen>
|
|
|
|
<para>or</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd /usr/bin</userinput>
|
|
&prompt.user; <userinput>whatis *</userinput></screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="basics-info">
|
|
<title>GNU Info Files</title>
|
|
|
|
<indexterm>
|
|
<primary>Free Software Foundation</primary>
|
|
</indexterm>
|
|
|
|
<para>&os; includes many applications and utilities produced
|
|
by the Free Software Foundation (FSF). In addition to manual
|
|
pages, these programs may include hypertext documents called
|
|
<literal>info</literal> files. These can be viewed using
|
|
<command>info</command> or, if <filename
|
|
role="package">editors/emacs</filename> is installed, the
|
|
info mode of <application>emacs</application>.</para>
|
|
|
|
<para>To use &man.info.1;, type:</para>
|
|
|
|
<screen>&prompt.user; <userinput>info</userinput></screen>
|
|
|
|
<para>For a brief introduction, type <literal>h</literal>. For
|
|
a quick command reference, type <literal>?</literal>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|