Unix Tutor

UNIX/INTRODUCTION
This book is a Guide to UNIX and Unix-like operating systems, such as GNU/Linux and *BSD. Other
systems like Mac OS X, Solaris, and OSF/Tru64 also belong in the list.
Because of this book's incomplete state, it might be hard to find the chapter that you want.
Edit this paragraph

Guide to UNIX is incomplete. At Wikibooks, you can edit this book now. (If you are reading a mirror,
then you can go to the editable version of this book.) Here are some suggestions for improvements:
improve modules, add detail

add modules, follow naming policy
enforce neutral point of view, reduce bias
provide graphics, follow image policy
fix bad info, spelling, grammar
put questions and comments on talk pages
Contents [hide]
1 Structure of this book
2 Conventions
2.1 Shell prompt
2.2 Commands and files
2.3 Audience
2.4 Command links
[edit] Structure of this book

After this introduction, there are three main parts of this book.
The Why Unix-like page introduces the Unix system-like platform. The various Platforms such as BSD
then highlight particular Unix-like distributions. This book needs to add more platform pages other
than BSD and Linux.
The Explanations section contains a list of various topics which introduce and explain the use and
administration of Unix-like systems. For example, Explanations/Shell Prompt introduces the shell
prompt, and Explanations/Filesystems and Swap explains the use of storage devices. Many of the
sections are incomplete or missing, but this section is being expanded. The current division into six
parts might need to be changed later.
The Quick References chapters list the Environment Variables, Files, Commands. There actually is not
much here except for the Commands section.
[edit] Conventions
This book uses (or will use) the following conventions.
[edit] Shell prompt

The shell prompt looks like:
$
A root shell prompt (see Explanations/Becoming Root) looks like:
#
When the user types commands or other text, it appears in bold. The following is an example. The user
typed the "cat" command and then several lines which the computer echoed.
$ cat
This is an example.
This is an example.
^D $
Control characters are written like ^D. This means to hold the Control key and press D. Note that some
control characters sometimes do not appear on the screen. For example, the user typed ^D but no "^D"
actually appears on the screen.
[edit] Commands and files

This convention might need improvement. Currently, a good example is Explanations/Shell Prompt.
A command name is introduced in bold, like uname. Later, it is mentioned as "uname". In the future,
the bold version might be a link to the command in Commands.
Filenames usually appear like /dev/null and /etc/ssh/sshd_config. Entire commands look like ls
/dev/null /etc/sshd_config or echo a1 a2 a3. Mentioning again the parts or arguments of these
commands looks like "a1" and "a2". When introducing a new part (like a new option) not mentioned
before, that looks like -r or -o loop. Text from files is also quoted, for example "# comment".
[edit] Audience
This is a proposed convention, because it is mostly unimplemented in this book.
The book targets multiple audiences.
Unix or non-Unix users seeking background

Unix system users (background and user instructions)
Unix system administrators (background and administrator instructions)
To handle this, there might be some templates.
{{Guide to UNIX:u}} begin user instructions

{{Guide to UNIX:eu}} end user instructions
{{Guide to UNIX:i}} begin administrator instructions
{{Guide to UNIX:ei}} end administrator instructions
UNIX/WHY UNIX-LIKE
The operating system installed on many servers and some workstations is Unix-like. But what does it
mean to be like Unix? In this book, a Unix-like system is one that is similar to *BSD, GNU/Linux,
Solaris, and the original Unix. Today, Mac OS X also qualifies as a Unix-like system.
Contents [hide]
1 General Concepts
2 The shell
3 The C language
4 The kernel and userland
5 Neutral point of view
[edit] General Concepts

As opposed to the (point and click) (graphical user interfaces) familiar to the general computer user,
work usually gets done in unix in a text-based way, through what's known as the (command line shell).
As opposed to a (single-user) operating system which permits computer usage only by one person at
one particular time, unix is a multi-user) system, that allows access of multiple users to the computer
simultaneously. Normally this is achieved by having the users access the system (remotely), through
digital networks.
Whether accessing (remotely) or not, users need a (user account) before being granted access to the
system; for the purposes of accounting, security, logging and resource management.
Since each particular user account has varying degrees of control over the system and its resources,
having the ability to verify the true identity of a given user is crucial, so a method exists that verifies
each user account (username) against a corresponding (password); in a process known as (logging in).
All Unix-like systems are similar. As with many operating systems for servers, the Unix-like systems
can host multiple users and programs simultaneously. Some features are specific to Unix-like systems.
The Unix-like systems provide a common command line interface called the shell. They also provide a
common programming interface for the C language. The latter fact allows most Unix-like systems to
run the same application software and desktop environments.
Unix is popular with programmers for a variety of reasons. A primary reason for its popularity is the
building-block approach, where a suite of simple tools can be streamed together to produce very
sophisticated results. Another reason is the philosophy that 'everything is a file', which means that a
standardized set of operations and functionality can be performed on different file types (directories vs.
regular files), hardware devices, and even system processes.
[edit] The shell

Wikipedia has more about this subject:
Unix shellThe shell is a program unique to Unix-like systems. It lets you type commands to launch
other programs.
When you login to the system through a text-only terminal, Unix gives you a login shell. If your system
has a graphical user interface such as GNOME, KDE, or anything that uses X Window System, you
can access the shell through a program called a console emulator or terminal emulator. This emulates
the text-only terminal that the shell requires for running.
Unfortunately, the shell and the commands are hard to learn. Further, many commands require
"arguments" to work. For example, the rm command, which removes files, needs one or more
"arguments" naming the files to delete. This book has a Explanations/Shell Prompt chapter which
introduces the shell and its many features.
One can automate tasks by saving shell commands in a text file called a shell script. For example, shell
scripts are used to boot the system.
The Unix shell is unique to Unix-like systems. Actually, there are multiple shells available for Unix.
These shells extend their features in different ways. For the "Bourne-compatible" shells, there is a book
in Wikibooks,Bourne Shell Scripting, to describe them. Most shell scripts are for Bourne-compatible
shells.
[edit] The C language

Unix is the origin of the popular C language. Every program on the computer links to the C library
which provides basic system features including access to the kernel. Even if an application is written in
another language, like C++, it still links to the C library. An interpreted language like perl needs a perl
interpreter linked to the C library.
This dependence on C can be a disadvantage. Most Unix-like kernels are written entirely in C; most
common programs use C, C++ or Objective-C. It is difficult to add code to these programs in another
language such as Fortran. In contrast, some non-Unix systems allow different programming languages
to interact more easily.
This book does not describe how to program with C; that is the job of the book Programming:C.
However, planned additions to this book will describe how to build and run Unix programs when you
obtain their C source code.
[edit] The kernel and userland
kernel (computer science)Wikipedia has more about this subject:
userlandEach Unix-like system has a kernel. This program controls the computer hardware.
All other programs on the system are part of userland, which means outside the kernel. The kernel
shares the system between all running userland programs. To use the keyboard, the network
connection, or another part of the hardware, a userland program must contact the kernel using system
calls. The kernel allows multiple programs to share the hardware safely. It also switches programs in
and out of the processors; thus it is a "multitasking" kernel.
For example, a web server like Apache, through the kernel, can simultaneously make multiple network
connections to multiple web browsers. The same computer might also be running other server
programs. As another example, a user on desktop system (with GNOME or KDE, for example) can
simultaneously open multiple windows containing file managers, word processors, and games. While
the file manager copies files and the word processor prints a document, the user can play a Tetris clone
at the same time.
However, though some non-Unix kernels do not provide these features, there are some to do. Both of
the previous examples are possible with Windows in the place of Unix, Apache, GNOME, and KDE.
Today, a very popular kernel is Linux. Linux qualifies as free and open source; even if Linux is running
a server for millions of users, there is no licensing fee. Linux is combined with GNU to form the
UNIX-like operating system, GNU/Linux (Although on very rare occasions it isn't combined with
GNU). Thus, an easy way for a home user to obtain a Unix-like system is to install a GNU/Linux
distribution that includes GNOME (pronounced "guh-nome", not "nome") or KDE (Although very old
machines might not have the resources to run GNOME or KDE).
When we want to configure the network connection, disks, or other parts of the hardware, we must
often use special utility programs that configure the running kernel. Some of those programs are
described in this book.
UNIX/LINUX
Linux® is an open source, Unix®-like kernel and operating system. The author of the kernel itself is
Linus Torvalds, plus a loosely-knit team of programmers who enhance it in a collaborative effort over
the Internet. This page provides a brief overview the main features of the Linux kernel and system,
especially in comparison to other Unix-like systems. There are several other Wikibooks about Linux
with more information.
Contents [hide]
1 General
2 Kernel
3 Userland
4 Links to more information
4.1 Wikibooks for Linux
4.2 External Links
4.3 Distribution Related
[edit] General
After Linus Torvalds suggested a penguin, Larry Ewing (lewing@isc.tamu.edu) used The GIMP to
draw this popular image of Tux, the Linux mascot. Tux is now also the hero of some Linux games. In
Guide to UNIX, "tux" has an account on the example machines.Mascot: The official mascot of Linux is
Tux, the Linux penguin.
Distributions: The Linux system that you actually obtain, install, and run, is one of the many available
Linux distributions. A Linux distribution (or 'distro' for short) is a bundle of the Linux kernel and
applications and a suite of programs for installing and maintaining a Linux system.
There is much variation between distributions concerning the available packages, the installation
procedure, the preferred desktop environment, and even the Linux kernel configuration. Some
distributions have different target audiences: these might be home users, enterprise users, free software
supporters, hobbyists, or users of certain applications.
Typically, distributions are in CD or DVD form. One can download them as a raw disk image in ISO
format and burn it. One can also inexpensively purchase a Linux distro as a retail package. Live CDs or
DVDs allow users to boot from a disk and run Linux using a RAM disk rather than a hard disk.
A Neutral Look at Operating Systems has a comparison of Linux systems.
Wikipedia has a list of Linux distributions.
Packages: A complete GNU/Linux operating system uses many free software (open source) packages
from the BSD, X11, GNU, and other projects. There are also non-free packages without source code, or
requiring one to buy licenses. Each distro decides which packages to provide.
[edit] Kernel
Copyright license: The Linux kernel and its source code are released under the GNU General Public
License. Many of the userland packages also use this license. If you modify Linux or another package
using this license, you can redistribute your modified version, but you must use the same license,
which means you must provide source code. Every Linux vendor provides Linux source code.
Separate development: The Linux kernel is developed and maintained separately from userland.
With most other Unix-like systems, the kernel is maintained at least with the basic set of utilities,
which would include the shell, shell utilities, C compiler, C library, system configuration utilities, and
system boot scripts.
Linus Torvalds and his team can worry about the kernel (and userland programs which query and
configure the kernel) and let other teams develop the userland system separately.
Both kernel and userland maintain extra compatibility so that one can update only the kernel, or only
some userland package like the C library. In general, the Linux distro vendors take care of making
updates install correctly.
Customizable kernel: Linux is probably the most customizable Unix-like kernel. There are even several
ways to edit the kernel configuration before building the kernel.
Most builds of Linux use modules aggressively (though use of modules is optional). Modules allow
pieces of the monolithic kernel, such as device drivers and network protocol implementations, to reside
in separate files, load on demand, and unload when not used.
Many systems have multiple versions of Linux headers installed, in /usr/include/linux-version. Both the
Linux kernel and some userland software, such as the C library, need these. On non-Linux systems,
/usr/include/sys would sometimes have files used shared by the kernel and userland.
Special filesystems: Linux has some special filesystems which are not used for normal files.
/proc holds information about running processes. Other Unix-like systems sometimes provide /proc,
but it is not as important as with Linux. Programs that use /proc often have trouble with ports to non-
Linux systems.
/sys holds other information about the running kernel.
/dev is often a dynamic filesystem where device nodes appear and disappear dynamically, when
modules load or unload or when devices are connected or disconnected. However, you can also just
have /dev contain static device nodes like on other Unix-like systems.
[edit] Userland
GNU project: The GNU (GNU's Not Unix) project created the shell, core commands, C compiler and
build tools for a Unix-like system. However, their kernel, Hurd, never worked well, and thus GNU
encourages users to use Linux kernel.
Nearly every Linux distribution uses these programs, which makes them "GNU slash Linux"
distributions. But with the exception of the GNU C library and core commands, many GNU tools and
applications are also found on other Unix-like systems. In fact, *BSD and Mac OS X, like Linux,
depend on the GNU C compiler, assembler, and linker.
The GNU project always insists on providing their packages as free software, using licenses like the
GNU General Public License.
The GNU project also has a connection to the desktop environment called GNOME (GNU Network
Object Model Environment).
/lib: The directory /lib exists on Linux and holds libraries needed by /bin and /sbin because /usr might
not be mounted.
/usr: Stuff provided by your Linux distro often becomes installed in /usr instead of /usr/local. This frees
/usr/local for packages which your Linux distro does not provide.
Text editors: Most distros provide the traditional Unix editors "vi" and "emacs", but some install
neither by default. Even "ed" could be missing. Traditional Unix skills for text editing are not necessary
when GNU "nano" is the installed non-X11 editor.
Package management: Most distros provide a package management system such as "apt" (Advanced
Package Tool), "rpm" (Red Hat Package Manager), or Portage. These automate the installation and
upgrade of packages. Both application packages and base system packages use this system. The
package manager is often the biggest difference between distros.
Graphical user interface: Many of the popular Linux distros now boot the user straight into a desktop
environment (GNOME or KDE, both based on X11 window system) immediately after installation.
This is in contrast to some Linux distros and most *BSD distros which drop you at a root shell prompt,
and expect you to use the root shell prompt to install X11, GNOME or KDE if you want it.
Source distros: Some Linux distros, such as Gentoo, emphasise building from source. Though every
Linux distro with a compiler gives one the opportunity to rebuild the Linux kernel and other packages
from source, these source distros provide scripts that not only automate the process, but help the system
administrator make customisations and optimisations.
PART 1: COMMAND LINE.
UNIX/EXPLANATIONS/SHELL PROMPT
The shell prompt (or command line) is where one types commands. When accessing the system
through a text-based terminal, the shell is the main way of accessing programs and doing work on the
system. In effect, it is a shell surrounding all other programs being run. When accessing the system
through a graphical environment such as X11, it remains possible to open a terminal emulator and do
useful work with the shell.
This chapter describes how to find a shell prompt and start using it.
TODO
Find places to introduce pagers, pipes, redirects, and some basic file managing commands. These might
be separate chapters under Guide to Unix/Explanations.
Contents [hide]
1 Finding a shell prompt
1.1 Using the TTY device
1.2 Opening a terminal emulator
1.3 Using SSH to access a remote shell
2 Appearance of the prompt
2.1 Root shell prompt
3 The basics of using the shell
3.1 Arguments and Options
3.2 Editing Commands
3.3 The current/working directory
4 Finding help for commands
5 Continue
[edit] Finding a shell prompt

People get shell prompts in different ways, such as:
They use a graphical environment (such as Aqua, GNOME, or KDE) and a terminal emulator.
They do not use GUI, but simply use TTY device; sometimes also use GUI and get to a TTY device
with Ctrl+Alt+F[number] (most GNU/Linux systems allow 1-6 for [NUMBER]). To get back to The X
Window System, use Ctrl+Alt+F[number 1 higher than the number of TTY devices].
[edit] Using the TTY device

Unix systems can use TTY devices for a shell. The first line looks like
login:
Type your username at this prompt, then type your password. This gives a shell.
[edit] Opening a terminal emulator

A terminal emulator (or console emulator) is a program that emulates the terminal hardware that early
users traditionally used to login to Unix. It appears as a window in the graphical environment and
allows access to the shell prompt.
There are several ways to open a terminal emulator:
With The X Window System, try xterm. Most setups either start you with an xterm or two when you
login, or provide a menu from which you can start an xterm.
KDE provides a Terminal Program (Konsole). You can find it in the K Menu > System menu. If you
right click on an empty part of your icon panel, you can Add an Application Button for the terminal.
GNOME provides a terminal emulator somewhere in the Programs menu.
Using Enlightenment 17, right click on the desktop, then go to Enlightenment>Eterm.
On Mac OS X, use /Applications/Utilities/Terminal. That is, go to the Applications folder on your hard
disk, and to the Utilities folder inside it, and double-click the icon for the Terminal program. You may
want to keep the Terminal icon on your Dock.
Most terminal emulators, like other graphical programs, provide a menu bar to configure the terminal.
For example, they allow you to change the font and colors; some people prefer white text on a black
background. xterm is more difficult to configure; its menus can be found by holding the Control key
and clicking with each of the three mouse buttons.
[edit] Using SSH to access a remote shell

The ssh program is a secure way to connect to a shell account on a remote server. The server must be
running the sshd servers software to accept the connection. See the chapter on Connecting to Remote
Unix.
[edit] Appearance of the prompt

The shell prompt normally ends in a $ sign. For simplicity, the examples in this book use a shell prompt
like this:
$
Some older shell prompts end in % instead:
%
The C shell sometimes uses > instead:
>
Several shells have prompts that give more information, such as:
localhost:puffy {1}
You can also customize your shell prompt. For bash, use these special characters in the variables
$PS[1-4]. $PS1 is what you usually see and $PS2 is what you see when you are doing a multi-line
command with a backslash ('\'). For more see the manual.
Never copy/type the shell prompt used in this book. The shell will always give you a prompt if it is
ready to accept commands.
[edit] Root shell prompt

If you become root or login as root, most systems change the shell prompt to end with #. The root
account is allowed to do anything (delete or change any file) so the # is a reminder of the power of the
prompt. Avoid using the # prompt when necessary; see the chapter on Becoming Root. In this book,
root shell prompts look like this:
[edit] The basics of using the shell
[edit] Arguments and Options

When you enter a command, the shell does a few things in this order (if it succeeds, it executes the
found command):
The shell checks if the command is an absolute path (such as /bin/ls) and if that path is an executable
file.
If the command is not an absolute path, the shell:
searches through its builtin commands for the entered command.
Looks in the directories in enviornment variable PATH for the entered command. It starts its search
with the first directory listed in PATH, then the second and so on.
For examples, we'll be using the command ls, which lists files and directories. This command lists the
contents of /var (which may differ on your computer):
$ ls /var
account backups db lib msgs run tmp
audit crash empty log named rwho www
authpf cron games mail quotas spool yp
The first word, "ls", is the name of the program or command built into the shell to run. In this case, the
program /bin/ls is run. The "/var" in this case is an argument; it tells ls what to list. Arguments are
separated by whitespace, usually one space.
There are some special arguments called options. Each command decides what is an option, but for
many commands, options with only one hyphen to start usually are short for a more descriptive option
that starts with two hyphens and some that start with two hyphens don't have shorthands. Here is an
example (read it as "el es dash one slash var"):
$ ls -l /var
drwxr-xr-x 2 root wheel 512 Mar 20 2005 account
drwxrws--- 2 root wheel 512 Mar 20 2005 audit
drwxrwx--- 2 root authpf 512 Mar 20 2005 authpf
...
drwxr-xr-x 2 root wheel 512 Jun 11 02:09 yp
Note that these commands require that options come before other arguments. For example, the
following does not work (unless you have a file or directory called -l):
$ ls /var -l
ls: -l: No such file or directory
/var:
account backups db lib msgs run tmp
audit crash empty log named rwho www
authpf cron games mail quotas spool yp
Exception: on systems with the GNU C library (GNU and GNU/Linux), many programs (not all of
them) will automatically treat the options as if they were in the front, so ls /var -l is the same as ls -l
/var. This is nice for users who forget to type some option.
What if there really is a file called "-l"? Then it must be specified that "-l" is not an option. One does
this using the "--" argument, which means "end of options". This is why it is inconvenient to have
filenames start with hyphens.
$ ls -- -l
-l
[edit] Editing Commands

If the shell has command-line editing, then the arrow, End, and Home keys are useful. The left and
right arrows allow the user to move the text cursor to edit the command and the Home and End keys
allow the user to move the to the beginning or end of the line. For example, we want to list some
specific files, like this:
$ ls -l /etc/passwd /etc/profile
But we typed:
$ ls l- /etc/passwrd /etc/profile
We can press the Home key to move the cursor to the beginning of the line, then use the right arrow to
move the cursor to the right to delete the "-l". After this, we press Return to run the command as
normal. (This will not work in many non-shell programs that lack command line editing!)
Shells with history features allow using the up arrow to recall previous commands to the shell prompt.
These previous lines are not run again unless the user presses Return. The down arrow returns down
the list.
If the arrow keys are broken, or you actually find some keyboard without arrows, then the Control
Emacs navigation keys (Ctrl+B, Ctrl+F, Ctrl+P, Ctrl+N, Ctrl+E and Ctrl+A) also work in most shells.
[edit] The current/working directory

Use cd to change the directory you are "in." The syntax is cd followed by the pathname. cd /bin would
take you to the /bin directory (located in the directory you are currently in), cd .. would take you up one
level. cd ~ would take you to your home directory, and cd ~ followed by a username would take you to
that user's home.
Although many shell prompts have the current directory's name or the end of the current directory's
name right in the prompt (like '[user@localhost ~]$'), you can use the command pwd to Print the
Working Directory.
$ cd /etc
$ pwd
$ ls passwd profile
[edit] Finding help for commands

The first word of the command is the name of the command. For example, in the following command,
"ls" is the command name, and "-l", "/etc/passwd", and "/etc/profile" are the arguments.
$ ls -l /etc/passwd /etc/profile
But how do we know what the "ls" command does? Most Unix-like systems provide online manual
pages for each command. For example,
$ man ls
This opens the manual page in a program called the pager. The most common pagers are less and more.
These let the user type space bar to scroll down and 'q' to quit the pager.
However, the manual pages are often not useful for persons who know almost nothing about the
commands. The chapter on Commands will help. The section Guide to UNIX/Commands/Getting Help
contains strategies for how to use man and the other help tools effectively.
UNIX/EXPLANATIONS/QUOTING AND FILENAME EXPANSION
Contents [hide]
1 Special characters and substitution
2 Quoting
2.1 Backslash
2.2 Paired quoting characters
2.2.1 Single quotes
2.2.2 Double quotes
3 Filename expansion
3.1 * and ?
3.2 When expansion fails
3.3 Curly brackets expansion
[edit] Special characters and substitution

The shell recognizes several special characters. The following are the special characters:
\ (backslash)
" (double quote)
' (single quote)
# {number sign, pound sign, or hash)
$ (dollar sign)
` (tick)
~ (tilde)
{ and } (braces or curly brackets)
( and ) (parentheses)
* (asterisk, star or splat)
? (question mark)
< (less than sign)
> (greater than sign)
& (ampersand)
| (pipe)
; (semicolon)
! (exclamation point or bang)
They are all special characters in the Bourne shell, except for the exclamation point. However, many
Bourne and non-Bourne shells also make special the exclamation point. When the shell sees special
characters, it does something more complex than simply running the command that you typed.
Some special characters trigger substitution, when parts of the command are replaced with other text.
One common form of substitution is filename expansion, which saves you work when typing longer
filenames and lists of filenames.
To test substitution, we need the echo command. This command simply echoes its arguments
(including any changes made to the arguments by the shell). All options except "-n" are ignored.
$ echo -lnQ arg1 arg2 arg3

-lnQ arg1 arg2 arg3
[edit] Quoting
Quoting is used to preserve the literal meaning of special characters.
Here is an example of several types of quoting, which will be refered to in the rest of this section (there
are many unnecessary things in this which you should find after reading this section, but are used for
the sake of example):
$ echo There is \"a small possibility\" that '/etc/*tab' are " not " text and a backslash will not be printed
after this. \\
There is "a small possibility" that /etc/*tab are not text and a backslash will not be printed after this. \
[edit] Backslash
A backslash (\) simply stops the shell from thinking that certain characters are special. In the example
above, it was used to print literally the doublequote character.
To print a backslash, use two backslashes in a row.
Now commands that want special shell characters for input will work.
[edit] Paired quoting characters

Paired characters affect whatever is between them.
[edit] Single quotes

Single quotes perserve the literal meaning of everything except single quotes.
In the example, single quotes were used to prevent the * from expanding.
Note single quotes can't be within single quotes, even with a preceding backslash.
[edit] Double quotes

Double quotes are like single quotes, but don't preserve the literal meaning of $, \ when followed by a
dollar sign, tick, double quote, or backslash, and `.
In the example, double quotes were used to preserve the literal meaning of spaces.
[edit] Filename expansion

The filename expansion is used in avoiding the typing of long lists of files. These characters are used
for filename expansion:
*?{}
[edit] * and ?
The shell globbing characters of * and ? are used to form patterns. The shell searches for existing files
that match the patterns and does a subsitution.
* matches 0 or more characters, except /

? matches any 1 character except /
When more than one file is matched, the files are separated by spaces, as separate arguments.
For example, /etc/ss* means all of the files inside the /etc directory which begin with the letters ss. The
echo command demonstrates the substitution. The results may differ on your system, depending on
what files you have.
$ echo /etc/ss*
/etc/ssh /etc/ssl
The echo command did this because it thinks that you ran echo /etc/ssh /etc/ssl. The shell substituted
those names for /etc/ss*. Though /etc/ssh/ssh_config exists on many systems, it appeared not above,
because * never matches /.
Now here is something more useful. We will use substitution with a command other than "echo". We
will combine filename expansion with the ls command.
$ ls /etc/ss*
/etc/ssh:
ssh_config ssh_host_key ssh_host_rsa_key.pub
ssh_host_dsa_key ssh_host_key.pub sshd_config
ssh_host_dsa_key.pub ssh_host_rsa_key
/etc/ssl:
lib openssl.cnf private x509v3.cnf
Notice how the * saved typing. If we did ls /etc/s*, we would probably save much typing.
Here is an example of the ? character at work:
$ ls /etc/ssh/ssh_host_???_key
/etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_rsa_key
[edit] When expansion fails

Sometimes, when using * or ?, no files are found. In this case, the shell does not give an error; it simply
does no substitution. Suppose that in the machine on the example above, we make a mistake and typed
/etc/sss* which matches nothing. Then the shell would do no substitution:
$ echo /etc/sss*
/etc/sss*
[edit] Curly brackets expansion

The curly brackets help when typing several similar arguments, especially filenames. The filenames do
not need to actually exist. Example:
$ echo /etc/ss{h,l,ssnakes}
/etc/ssh /etc/ssl /etc/ssssnakes
They are very useful for long lists of files in the same directories:
$ echo /bin/{ls,mv,cp} /sbin/{halt,reboot}

/bin/ls /bin/mv /bin/cp /sbin/halt /sbin/reboot
You can also use them to print the alphabet (or numbers):
$ echo {z..a}
zyxwvutsrqponmlkjihgfedcba
Unix/Explanations/Pipes and Job Control
Pipes and Redirects

We can connect standard input, output, and error of commands to other commands or to files.
[edit] Job Control

You can run multiple commands at once, but only one can be in the foreground. The other commands
can be in running at the background or suspended.
Unix/Explanations/Choice of Shell
Contents [hide]
1 Choice of shell
1.1 Bourne-compatible shells
1.2 C shell
1.3 zsh
1.4 Temporarily using a different shell
1.5 Permanently changing the default shell
2 Advanced Bourne shell topics
[edit] Choice of shell
[edit] Bourne-compatible shells

All Unix shells are similar, but they have different features. If you are beginning, and you are not aware
of the differences between shells, then you probably want to start with a Bourne-compatible, POSIX-
compatible shell such as bash or ksh.
These are the Bourne-compatible shells:
sh is the original Bourne shell. On many non-Linux systems, this is an old shell without the POSIX
features. Thus bash and ksh (or even csh and tcsh) are better choices than sh. On some systems though,
sh is really the same as bash or ksh.
bash is the GNU Bourne-again shell. It is Bourne-compatible, mostly POSIX-compatible, and has other
useful extensions. It is the default on most Linux systems. If it is not the default, it is probably installed
on Linux, and can also be installed on non-Linux systems.
ksh is one of the three:
Public domain ksh (pdksh) is Bourne-compatible and mostly POSIX-compatible.
AT&T ksh is a commercial shell. It has all of the features of pdksh, plus the ksh93 version has several
interesting extensions, different from bash. One must pay a license fee to use it; Mac OS X 10.4
includes it.
mksh is the MirBSD enhanced version of the Public Domain Korn shell (pdksh)
dash is a POSIX compliant shell that is much smaller than bash.
[edit] C shell
BSD introduced the C shell, which sometimes resembles slightly the C programming language. This
shell is csh. The shell tcsh is csh with more features. These shells are NOT Bourne-compatible. Many
of the features were later added to the Bourne-compatible shells (except old copies of sh). When these
features work differently in C shell and Bourne-compatible shells, this guide will describe the Bourne-
compatible shells.
If csh or tcsh is your default shell, you might benefit by using bash or ksh to get Bourne-compatibility
and POSIX features. Some users still prefer the C shell.
[edit] zsh
There are alternative shells such as zsh, the Z shell. The Z shell boasts extra and unusual features that
make it the prefered shell of many. (For example, it has a builtin ftp client!) Though the Z shell is
almost Bourne-compatible, it differs in enough ways that its default behaivour is not Bourne-
compatible, though zsh is capable of masquerading as a Bourne shell when so instructed.
[edit] Temporarily using a different shell

If you do not like the shell that you are using, you might want to use a different shell such as ksh or
bash. Shells are normal programs, and can be run easily. The SHELL environment variable will still
contain the default shell. The exit command will return you to the first shell.
tcsh> printenv SHELL

/bin/tcsh
tcsh> bash
bash$ printenv SHELL
/bin/tcsh
bash$ exit
exit
tcsh>
[edit] Permanently changing the default shell

$ chsh
[edit] Advanced Bourne shell topics

There are some important features in the Bourne-compatible shell. This guide does not describe them
because the Wikibook for Bourne Shell Scripting already has several useful chapters:
Bourne Shell Scripting/Redirection describes redirection and piping. With redirection, one can connect
the standard input and output of commands to files. With piping, one can connect commands into
useful chains. This is one of the main strengths of Unix. If you only read one chapter, read this one.
Bourne Shell Scripting/Substitution shows how the special character $ allows one to embed the values
of parameters or the results of commands into the arguments of commands.
Bourne Shell Scripting/Loops has a useful section on "for loops" which allow the same commands to
run repeatedly with different arguments each time.
Retrieved from "http://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Choice_of_Shell"
UNIX/EXPLANATIONS/ENVIRONMENT
[edit] Environment Variables

Every program inherits "environment variables" from the program that started it. This means that each
program has the same environment variables as the program that started it. The environment of a
program can change, in which case other programs later started by that program also have a changed
environment.
The environment variable called SHELL contains the name of the default shell. (You might be running
some other shell, but the default shell is always in "SHELL".) The "SHELL" environment variable is
set during login and inherited by the shell. When we started the "printenv" program, it inherited the
entire environment, including "SHELL", and showed "SHELL" to us.
Using printenv with no arguments gives the entire environment:
$ printenv
...
SHELL=/bin/bash
...
See Environment Variables to learn about specific variables.
[edit] Process limits

Each process has limits on the following.
Limits are inherited from the parent process. The normal way to set limits is to change the limits of
some shell, and then start the program from that shell. Each shell provides a different way to set limits:
Bourne shell uses the ulimit command while C shell uses limit.
The following is the list of available limits, given with their C shell name ("Bourne shell option"). We
need the name ("option") to show or change the limit in the C ("Bourne") shell.
* cputime ("-t SECONDS")

* filesize ("-f BLOCKS")
* datasize ("-n KILOBYTES")
* stacksize ("-s KILOBYTES")
* coredumpsize ("-c BLOCKS") can also accept "unlimited" instead of BLOCKS
* memoryuse ("-m KILOBYTES")
* memorylocked ("-l KILOBYTES")
* maxproc ("-p COUNT")
* openfiles ("-n COUNT")
TODO
Explain how to use "limit" or "ulimit -S" to set limits. Explain the danger of reducing hard limits.
Explain what these limits do or refer to another chapter of this book. For example, core dump size
might be covered in a chapter on crashing.
Scenario: A program crashes with a message about "resource temporarily unavailable" or "too many
open files".
Raise the limits in the shell from which you start the program. For example, to allow 512 open files per
process:
Bourne shell
$ ulimit -Sn 512
C shell
$ limit openfiles 512
UNIX/EXPLANATIONS/CONNECTING TO REMOTE UNIX
If the shell prompt is on a remote server, ssh is the most common way to access it. The server must be
running the sshd server software to accept your connection. The SSH protocol encrypts your
connecting to prevent spying and stealing of passwords. All that is required is that you trust the
computer that you connect from and the server where your account is located.
To connect, open your SSH client, specify the name of the server and your username. Most servers use
the default port 22, so specifying the port is not necessary. (Be careful with ports 1024 and higher
because these are controlled by users, not the system administrator.)
[edit] Using SSH from a Shell Prompt

To connect to one Unix-like system from another, you can the ssh shell command. This command is
often OpenSSH, a popular SSH implementation from OpenBSD. For example, Tux wants to connect to
an account (username tux) on the computer "linux.example.edu":
$ ssh tux@linux.example.edu
tux@linux.example.edu's password:
If Tux has the same username on the local computer, than specifying the username is optional:
$ whoami
tux
$ ssh linux.example.edu
tux@linux.example.edu's password:
[edit] Accepting the Key Fingerprint
The first time you connected, you saw a message similar to the following:
The authenticity of host 'linux.example.edu (1.2.3.4)' can't be established.

RSA key fingerprint is a4:3d:fe:10:7e:45:2b:29:d0:fe:ed:ba:a3:21:66:a1.
Are you sure you want to continue connecting (yes/no)?
If you are reasonably sure that you connected to the correct computer (an attacker on the Internet might
steal your connection to learn passwords) than you can answer 'yes' and add linux.example.edu to the
list of known hosts. Some SSH clients also allow you to say 'yes' to one session only.
When you say 'yes', you get a message such as: Warning: Permanently added
'linux.example.edu,1.2.3.4' (RSA) to the list of known hosts.
This means that your SSH client "knows" linux.example.edu. It will verify that future connections to
"linux.example.edu" reach the same computer (or cluster). You will be alerted if an attacker steals your
connection, but also if linux.example.edu changes its key. Thus, if you know that linux.example.edu
changed its key and you recognize the key, then you can ignore the alert.
Retrieved from
"http://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Connecting_to_Remote_Unix"
PART 2: COMMON PROGRAMS
UNIX/EXPLANATIONS/SCHEDULING JOBS
CRON:
Cron is an automated scheduler in UNIX/Linux Systems, which executes jobs (scripts) which are
scheduled by system, root, or individual users. Information of schedules is contained within crontab file
(which is different and individual for each user).
ps -e |grep cron : Displays status of cron deamon if running.
/usr/sbin/cron & : Starts users cron deamon.
CRON description : When you start cron deamon, it searches for crontab files, which are user named
account names in /var/cron/tabs directory. Cron deamon wakes up every minute and checks for any
jobs scheduled to be executed in crontab files. Every time cron deamon wakes up to check crontab
files, it also checks /etc/crontab file for any modifications in time stamp of the file, which it keeps track
and records. When you simply 'touch' /etc/crontab file, cron deamon will catch it and ultimately stop
executing scheduled jobs in crontabs - this is how to stop cron deamon. In order to have cron deamon
continue running scheduled jobs, you need to restart it (bouce it).
crontab -l : Displays cron schedule of a user running this command from. For root automated schedule
(cron) login as root first, then add jobs to crontab file (crontab is per user specific configuration, which
is executed by cron deamon).
[edit] CRONTAB file (Example):
crontab -l : Enter this command to display user crontab file schedule for a logged in user.
A line in crontab file (below) removes all files in /home/me/tmp directory, each day at 6:30 PM. (Use
of wildcard * allowed)
30 18 * * * rm /home/me/tmp/*</nowiki>
UNIX/EXPLANATIONS/INTRODUCTION TO EDITORS
The Introduction to Editors briefly introduces the reader to the common Unix text editors and provides
links to more information.
Many readers will be familiar with text editors that have graphical user interfaces similar to Notepad
from Windows, TextEdit (in unstyled text mode) from Mac OS X, GEdit from GNOME, or KEdit or
KWrite from KDE. Other readers will only know about word processors, which are like text editors,
but have additional features for applying style and layout to the text. Text editors only deal with
sequences of text characters, all in the same font.
The approach of this chapter is to introduce the earliest Unix text editors and progress to the Notepad-
style editors. The early editors lack many common features of editors.
Contents [hide]
1 The need for a text editor
2 ed
3 vi
4 vim
5 emacs
6 Word wrap
[edit] The need for a text editor

One who uses the command line, but knows not how to use a text editor, can still create text files using
the cat tool and the shell redirection feature.
$ cat > newfile

We the people, promoting the common keyboard
and preserving a more perfect docmument for all,
do ordain and establish three lines of text.
Suppose there is a want to change this file. In this example, "docmument" has an incorrect spelling; it
should be document. Other wants could be revisions to this sentence and the addition of more
sentences.
One can append to the file with cat >> newfile, but that leaves the first lines unmodified. One can
replace it with cat > newfile again, but that requires retyping the entire file. (Users of graphical user
interfaces such as X11 have an advantage: they can use the mouse to copy and paste the text before
"docmument", type the correction, then copy and paste the remainder of the text.)
An interesting possibility is if there is a way to delete the extra "m" from "docmument", and to handle
more complex tasks like inserting words and rearranging text.
[edit] ed
One of the first editors that did this was ed, short for "edit". This has many features of Windows
Notepad, but also lacks many. Observe what happens when one starts "ed". Here, "newfile" is the name
of the text file to edit.
$ ed newfile
139
A number (here "139") appears. Then the program seems to stop, but no shell prompt appears. This is
actually "ed" waiting for commands. On many computers, "ed" actually lacks a prompt.
The "139" indicates that "ed" read in 139 characters that are now ready for editing. We say that the file
is open. To be more correct from the perspective of a C programmer, the file was opened and copied
into a buffer. The buffer, not the file is open. This means that the disk or storage device will not be
bothered until we save the file. Other text editors still follow this behavior, opening files, copying them
into buffers, and requiring the user to save to write the file back to disk.
Notice that unlike many editors, "ed" has not yet shown the text of the file. We type a command ,p to
do this.
$ ed newfile
139
,p
The command, roughly translated, is that for every line in the file (","), "p"rint that line to standard
output.
Now to do some actual editing, we use a command 2s/docmument/document.
$ ed newfile
139
,p
2s/docmument/document
and preserving a more perfect document for all,
For line "2", "s"ubstitute the first instance of "docmument" with "document". Here "ed" prints the
changed line from the buffer.
We run two more commands, "w" to write the buffer back into newfile on disk, and "q" to quit "ed". If
we forget "w", then our edit is lost.
$ ed newfile
139
,p
2s/docmument/document
w
138
q
We made only one minor change, but this already required four commands. Even worse, "ed" error
messages are not useful when we mistype commands. Many Unix users never bother to learn "ed". For
those readers with interest, this book has a chapter ed and sed (when someone writes that chapter).
[edit] vi
At some point, Unix systems introduced video screens that allow Unix to draw anywhere on the screen.
Someone decided that it would be good to create a "visual editor" that allows the user to move the
cursor through the file (as it appears with "cat" or the ed "p" command) and make changes. The name
of this program is vi, which is short for "VIsual editor". Thus, the namers of this program intended one
to call it "vee eye", not "vee" nor "six".
Observe what happens when one starts "vi". First you type the command:
$ vi newfile
Then the screen clears and becomes like this:

~
~
~
~
newfile: unmodified: line 1
The screen might look different if you have a different version of "vi". Your screen also probably has
more than eight lines. However, all versions of "vi" have these two features:
a "~" shows a nonexistant line (though you could type a line with only "~" to be confusing)
there is a status line at the bottom, here it reads "newfile: unmodified: line 1"
On many computers, you can use the arrow keys to move the cursor. If that does not work, you can use
the standard "vi" keys:
[h] moves left, [j] moves down, [k] moves right, [l] moves down
For example, one can press [l] for fifteen times to move the cursor from the "W" in "We" to the "p" in
"promoting". (In fact, as a shortcut, vi lets one press [1] [5] [l] (one, five, ell). This gives the number
"15" to the [l] command, which in this case means to repeat the command fifteen times.) So it is
possible to move the cursor through the file, which was not possible with ed.
But what if we want to type the letter "l" instead of moving the cursor? Press [i], which is a command
to switch the vi editor from command mode to insert mode. Then type something. Here, the user, with
the cursor at "p" in "promoting", typed [i] and then "nominally " (including one space):
We the people, nominally promoting the common keyboard

~
~
~
~
Note that some copies of "vi", such as this one, by default never show at the screen whether the editor
is in command or insert mode.
To exit insert mode, press [ESC] escape. To save and quit the editor, type [:] [w] [q] [RETURN] which
inputs "wq" to the colon prompt.
To learn more about vi, read the Wikibook, Learning the vi editor.
[edit] vim
In new generation of Linux and Unix operating systems, the more improved version of VI editor was
released called vim (version 7 latest). VIM incorporates almost all the features of VI and more,
including color coding screen, highlights, and spell check within the document.
[edit] emacs
[edit] Word wrap
UNIX/EXPLANATIONS/AWK
The name 'awk' is derived from the names of the three people who originally developed it - Aho,
Weinberger and Kernighan. It is a programming language which uses a pattern-action expression that
transforms the input to the output. It processes the input (usually a file of data), searching each line for
the given pattern. Any line that matches the given pattern has the action applied to it and this
constitutes the output. A line that does not match is ignored.
Each input line is divided into fields by a separator character (default is space) and patterns can be
matched to these fields as they are referenced in the usual Unix style - $1 being field 1, $2 being field 2
etc. $0 means the entire input line.
If no pattern is specified then all input lines are selected. If no action is specified, the default action is
to print the entire line. Therefore if you just want to print a subset of the input, you just need to supply
a pattern that will produce the desired results, Awk will print the input as found.
However, you can also specify which fields are to be output in the same way eg print $1.
A simple example:
awk '$1 ~ /A/ { print $2 " " $3 }' /etc/passwd
This will read the file /etc/passwd and check each record field 1 to contain "A", any such records found
will have the second and third fields printed.
The list of commands are generally supplied in a separate file, and this can contain many lines for more
complex problems.
Retrieved from "http://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/awk"
UNIX/EXPLANATIONS/BC
bc is an arbitrary-precision calculator language. The arbitrary-precision means that numbers can

contain unlimited digits (limited by memory); most other languages limit numbers to eight bytes at
most. For addition, subtraction, and multiplication, there is unlimited precision. Division stops after a
certain number of decimal places (usually 0 or 20), so "bc" is often bad with very small numbers (like
10e-44).
"bc" is often called using the "-l" option, which loads the standard library (which mostly contains trig
functions) and sets the number of decimal places for division to 20. (Doing trig with the default
precision of 0 decimal places is not so useful.)
This is an example of a user starting bc, doing two calculations, and exitting with "quit". Note that
pressing ^D (control-D) also exits.
$ bc -l
3+4
7
2/5
.40000000000000000000
quit
$
[edit] Example script

Some versions of "bc" limit function and variable names to one letter. The following example has long
function and variable names and must be changed to work on these copies of "bc".
The following example was tested with OpenBSD bc and probably runs on GNU bc too.

Simpson's ruleThis script implements Simpson's rule for integration. The function "integrate"
approximates the definate integral from "a" to "b" using "n" parabola sections. The formula for
"simpson" is taken from the Wikipedia article. This example integrates the sine function, but different
functions can be used by replacing f.
define f(x) {
return s(x);
}
define simpson(a,b) {
return ( (b-a)/6 ) * ( f(a) + 4*f((a+b)/2) + f(b) );
}
define integrate(a,b,n) {
delta = (b - a) / n;
result = 0;
for(i = a; (n = n - 1) + 1; i = i + delta) {
/*print "calling simpson(", i, ", ", i + delta, ") with n = ", n, "\n";*/
result = result + simpson(i, i + delta);
}
return result;
}
Put this in a file, say "simpson", load it, and integrate f from 0 to pi (pi is "4*a(1)", 4 times arctangent
of 1) with 100 intervals:
$ bc -l simpson
integrate(0, 4*a(1), 100)
2.00000000067647189101
^D
[edit] Explain
Now explain these features so users can understand the script.
variables and statements

"for" loops
functions ("define" and "return")
standard library functions ("s" is sine)
PART 3: ADMINISTRATION
UNIX/EXPLANATIONS/BECOMING ROOT
Most user accounts have only limited access to Unix. For example, it is common that users cannot
delete files of other users or parts of system. Users can typically install new software in their home
directories, but not into system directories like /usr. To install such software, change permissions on
system files, start servers on the reserved ports < 1024, or do any other tasks from which normal users
are banned, one must become the superuser. The superuser has a username of root, user ID of zero, and
is allowed to do anything regardless of system permissions - restrictions on user activity never apply to
root.
NOTE: For Ubuntu and Kubuntu, see this.
Contents [hide]
1 Login as Root
2 Use su
3 Use sudo
3.1 Configuring sudo
3.2 Useful defaults
[edit] Login as Root

The oldest way to access the superuser account is to login as root, using the root password. For security
reasons, and because many crackers on the net seem to know root's username, root logins are normally
only permitted on local consoles. (Some systems allow root to login through ssh because that is the
only way in. A good system administrator would disable root logins when they are no longer necessary,
for example by uncommenting the "PermitRootLogin no" line in /etc/ssh/sshd_config on systems
running OpenSSH.)
In general, it is bad to use root logins. One should require using su or sudo instead, so that a user must
authenticate with a normal user account before becoming root. The only good reason to use a root login
is during the initial setup of a Unix system, before another user account is created and "su" or "sudo"
are tested. After this, root logins should be disabled on local consoles too.
Some installation programs let you create the first user account during installation. You never get a root
password or make a root login, but the first user account can use sudo. Ubuntu Linux and Mac OS X
are both distros which do this.
[edit] Use su
The su command allows anyone who knows the root password to get a root shell, and thus have all of
the powers of root:
$ su
Password:
#
The acronym "su" means switch user. One can a user (su USERNAME) but by default it switches you
to root.
Some systems require that you join the wheel group to have access to su. The requirement is that your
username be listed in /etc/group on the line for group "wheel", group id zero. This requirement does not
exist on some systems.
When one finishes with the root shell created by su, one should exit the root shell, so that it is not
accidentally used later for normal user activity:
# exit
exit
$
[edit] Use sudo

There is a very configurable command called sudo which several Unix-like distros include. This allows
one to run individual commands as root. In most cases, running sudo prompts one for one's own user
account password instead of a root password, so sudo is good for administrators that prefer not to
memorize a separate root password, especially if they rarely use root.
The syntax to run a COMMAND as root is:
$ sudo COMMAND
For example, we try to view the log for email sent through a Unix-like system:
$ less /var/log/maillog
/var/log/maillog: Permission denied
Because the permission was denied, we use sudo to run the command as root:
$ sudo less /var/log/maillog
[edit] Configuring sudo

On some systems, sudo must be configured before you can use it. This is a useful configuration line to
put in /etc/sudoers. It might already be there, but commented out.
%wheel ALL=(ALL) ALL

What does it mean? The first word, "%wheel" is the user allowed to use sudo for something. The
percent sign indicates that all users in group "wheel" can do this. The first "ALL" means this is allowed
on all computers. (That is useful if you copy the same sudoers file to several different Unix-like
systems.) The "(ALL)" is the user for which the commands will have priveleges. We could say "(root)",
but someone who can use root can use all other accounts anyway, so we just say "(ALL)". The last
"ALL" indicates which commands are allowed.
Thus, the line provides that every user in group wheel can run any command as any user, including
root. The only requirement is that the user enter a password: their own password, not root's password.
[edit] Useful defaults

This line in /etc/sudoers disables two options.
Defaults !insults, !lecture

The "insults" feature would give a random insult to any user entering an incorrect password. The
"lecture" gives a message to a user that uses "sudo" for the first time (after each boot of the system). It
is intended for systems where the administrator grants (possibly limited) sudo access to many users; if
only administrators use sudo, then this option is not necessary.
Retrieved from "http://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Becoming_Root"

UNIX/EXPLANATIONS/INSTALLING PACKAGES
The Microsoft Windows and Mac OS X platforms are so widespread that typically a Windows or Mac
software vendor will provide a binary. In contrast, several packages for Unix-like systems are only
available as sources. If they are available as binaries, they are usually only available for a few popular
distros, or statically linked for a few popular kernels, and possibly for a different processor than what
you run.
The best way to get many packages, especially free software packages, is to get them from your Unix-
like system vendor. Vendors port the packages to their distros and build binary packages.
Linux For Newbies has instructions for using apt-get on Debian and rpm on Red Hat.
[edit] Handling packages

rpm
apt-get
pkg_add, pkg_delete, pkg_info
pkgadd,pkginfo,pkgrm for Solaris
[edit] Querying packages

On rpm-based systems, to find out which package owns the command foo (where foo is a standalone
executable), use the command:
$ rpm -q -f foo
To add a package on linux based system use
$ rpm -i foo
To remove package on linux based system user
$ rpm -e foo
rpm command has other options user man pages to find out more.
PART 4: HARDWARE
UNIX/EXPLANATIONS/DETERMINING HARDWARE
Here are some methods of Determining Hardware currently on the system:
run dmesg (works well on *BSD)

use KDE Info Center (K Menu -> System -> Info Center)
TODO
Describe how to determine video hardware while X11 is running (or create a page at Guide to X11 and
link to it).
$_ The Determining Hardware module or this section of Wikibooks Guide to Unix Computing is a
stub.
You can help Wikibooks by expanding it.
[edit] Examples
Run dmesg on a *BSD system to determine the kernel version, amount of memory, and whether this
computer has an audio device.
$ dmesg | less
...
OpenBSD 3.8 (GENERIC) #425: Sat Sep 10 15:49:26 MDT 2005
deraadt@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 268435456 (262144K)
avail mem = 236363776 (230824K)
using 1254 buffers containing 13418496 bytes of memory
mainbus0 (root)
...
mpcpcibr1 at mainbus0: uni-north, Revision 0x5
pci1 at mpcpcibr1 bus 0
...
macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00
...
snapper0 at macobio0: irq 30,1,2
...
audio0 at snapper0
...
This system has an OpenBSD 3.8 kernel, which matches the OpenBSD 3.8 operating system
distribution. (Generally, the kernel on a *BSD matches some version of the system. In contrast, there
are many combinations of Linux kernels and systems.)
The real memory is 262144K, but only 230824K is "avail", which probably means available. Divide by
1024 to convert to megabytes, using bc or some other method:
$ bc
262144 / 1024
256
230824 / 1024
225
quit
This computer has 256 MB of memory, but only 225 MB are "avail". Because we used bc, the answers
are rounded down to integers.
This line from the dmesg output indicates the presence of an audio device:
audio0 at snapper0
We can go up the dmesg, learning that we have audio0 at snapper0 at macobio0 at pci1 at mpcpcibr1 at
mainbus0. However, we are probably only interested in "audio0", which means that we have an audio
device, and "snapper0" if we want to know the type of sound card providing this audio. On this
computer, it should be possible to install programs that play sound and music.
UNIX/EXPLANATIONS/FILESYSTEMS AND SWAP

A common feature in Unix-like filesystems is that all files appear in one file hierarchy. The filesystem
storing the base of the hierarchy is referred to as the root filesystem. /, the directory containing all other
directories, is itself is called the root directory. Other filesystems are mounted on directories under /
which make these filesystems look like directories in the root filesystem. For example, a CD-ROM
containing files might be mounted at /mnt/cdrom. In this example /mnt/cdrom is called a mountpoint.
Access to devices is supplied by another filesystem mounted at /dev. Here files representing physical,
and virtual devices can be accessed. Filesystems themselves are represented as files in /dev such as
/dev/cdrom and can be mounted to directories in the root filesystem such as /mnt/cdrom. Each disk or
storage medium may contain one or more filesystems, each of which contains files which can contain
data. Some disks are also used for swap, which supplies a temporary storage space for data in memory,
when memory is full. Though "swap" resides on a disk, it is not actually a filesystem.
TODO
Explain the /etc/fstab file. Provide a scenario where we add an external disk drive to the file. Explain
better how to use the mount and umount commands.
TODO
Add description of LUKS for Linux -- this is the standard way to encrypt disks under Linux now. The
Gentoo and Ubuntu wikis have good instructions for those specific distros.
Contents [hide]
1 List of Filesystem Types
1.1 Filesystems with full Unix support
1.2 Foreign Filesystems
2 Disk Partitioning
3 Mounting Filesystems and Activating Swap
3.1 Simple mounting
3.2 Mounting with fstab
3.3 Unmounting
3.4 Mounts by Users
3.5 Union Mounts
4 Disk Images
4.1 Mounting Disk Images on NetBSD and OpenBSD
4.2 Mounting Disk Images on FreeBSD 5
4.3 Mounting Disk Images on Linux
4.4 Creating Disk Images
5 Encrypted Filesystems
5.1 Encrypted Filesystems on OpenBSD
5.2 Encrypted Filesystems on Linux
6 References
[edit] List of Filesystem Types

The choice of Unix-like system influences the choice of filesystem. There are two kinds of filesystems:
Filesystems with full Unix support can hold all types of Unix files, including normal files, directories,
named pipes, symbolic links, and device nodes. They also support the entire Unix user and group
permission model. This makes these filesystems good for mounting on /, and also /home, /tmp, /usr,
/var, and other such filesystems if those are separate partitions.
Non-Unix filesystems were intended for non-Unix operating systems or to exchange files between
different filesystems. Sometimes, the permission on every file on the filesystems must be the same, and
only normal files and directories are allowed.
[edit] Filesystems with full Unix support

Unix File System (ufs/ffs) is the filesystem of *BSD and several commercial Unix variants. UFS is the
on-disk layout, while FFS is some kernel optimizations for UFS in *BSD. There are several
incompatible extensions to UFS, including the UFS2 of FreeBSD, NetBSD, and Mac OS X. Therefore,
UFS is good for the root filesystem, but not good for trading files between different Unix-like operating
systems that implement UFS incompatibly.
Linux Second Extended Filesystem (ext2 or ext3) was inspired by ufs/ffs, and is similar. ext2 is the
main filesystem implementation for Linux, and can be used as the root filesystem. Unlike ufs/ffs, ext2
always has the same on-disk layout, and can be shared between different Linux systems, and other
systems that understand ext2. Note that ext3 is really the same as ext2, but with journaling enabled.
Linux also provides other filesystems that you might use instead of ext2.
reiserfs is an alternative to ext2 on Linux. Reiserfs is a fast journaled filesystem written by Hans Reiser.
jfs is a high performance journaled filesystem written by IBM originally for IBM AIX, and then ported
to Linux by the same.
xfs is a high performance journaled filesystem written by SGI. Originally writen for SGI's Irix
operating system this fs has been ported to Linux using a shim layer converting Linux VFS and locking
semantics to Irix semantics.
HFS+ (hfsplus) is the main filesystem implementation for Mac OS X, and can be used as the root
filesystem. Like ext2, HFS+ always has the same on-disk layout, and can be shared between different
Mac systems. HFS+ supports both Unix and Mac file attributes. HFS+ has binary trees, which make it
faster than ffs and ext2 sometimes.
[edit] Foreign Filesystems

iso9660 is a common filesystem for CD-ROMs. Most Unix-like systems can read it.
UDF is a common filesystem for DVDs. Some newer Unix-like systems can read and write it.
msdos (FAT) is the filesystem from MS-DOS, FreeDOS, ReactOS, and Microsoft Windows. Normally
you can have normal files and directories, but not special files, symbolic links, nor Unix file
permissions. Because nearly every Unix-like system (including Linux, *BSD, and Mac OS X) and
DOS/Windows understand it, the msdos filesystem is often used to trade files between computers or on
computers which boot multiple operating systems.
ntfs is a newer filesystem from Microsoft Windows NT. Some Linux kernels can read them.
[edit] Disk Partitioning

If the disk is not partitioned, it can be used for one filesystem, or entirely as swap space.
On Linux, IDE/ATA disks are called /dev/hda, /dev/hdb, /dev/hdc...

On Linux, SCSI disks are called /dev/sda, /dev/sdb, /dev/sdc...
On *BSD, IDE/ATA disks are called /dev/wd0c, /dev/wd1c, /dev/wd2c...
On FreeBSD, IDE/ATA disks are called /dev/ad0c, /dev/ad1c, /dev/ad2c...
On *BSD, SCSI disks are called /dev/sd0c, /dev/sd1c, /dev/sd2c...
On *BSD, compact disks (CDs) are called /dev/cd0c, /dev/cd1c...
On Mac OS X, disks are called /dev/disk0, /dev/disk1, /dev/disk2...
NetBSD/OpenBSD disk images are /dev/svnd0c, /dev/svnd1c, /dev/svnd2c...
Partioning the disk allows for multiple filesystems and swap spaces.
On Linux, hda is partitioned into /dev/hda1, /dev/hda2, /dev/hda3, /dev/hda4...

On *BSD, wd0 is partitioned into /dev/wd0a, /dev/wd0b, /dev/wd0c, /dev/wd0d...
On Mac OS X, disk0 is partitioned into /dev/disk0s1, /dev/disk0s2, /dev/disk0s3...
In addition, *BSD has some extra rules:
Partition 'c' (/dev/wd0c) must be the entire disk.

If a *BSD operating system boots on the disk, then partition 'a' must be root (/) and 'b' must be swap. (If
there is no OS on the disk, then 'a' can be used for any filesystem).
The chapter Partitioning Disks describes the formats in more detail and how to edit the partition maps.
[edit] Mounting Filesystems and Activating Swap

The commands one uses are:
mount to mount filesystems

umount to unmount filesystems
swapctl, swapon, swapoff
[edit] Simple mounting

Suppose /dev/hdb is a device (for example, a CD drive) and /mnt/cdrom is the place to mount. Then the
mount command is:
mount /dev/hdb /mnt/cdrom

There are more mount options so look for mount somewhere in Guide to UNIX/Commands.
[edit] Mounting with fstab

The /etc/fstab file helps you mount.
Create an /etc/fstab entry for /dev/hdb.

Run this command
mount /dev/hdb
[edit] Unmounting
It is called umount, not unmount...
umount /dev/hdb
[edit] Mounts by Users

The user mounts are mounting and unmounting of filesystems by users other than the superuser.
Unfortunately, the different Unix variants have different approaches to this task. (An alternative is to
configure "sudo" to allow users to become root when mounting and unmounting.) Here are some ways
that root can permit user mounts:
Linux allows the user to perform mounts permitted through the /etc/fstab file. Each line with the mount
option "user" describes a permitted mount. For example, mount /dev/cdrom by a non-root user will
mount /dev/cdrom using the mount point and options shows in /etc/fstab, but only if "user" is listed as a
mount option.
Many popular BSD-family operating systems allow the user to mount any device which the user can
already read and write. The user can pick any mount point which the user owns. A sysctl value must be
changed by the root user in order to do this on most of them.
In OpenBSD, kern.usermount must be set to 1.
In NetBSD, vfs.generic.usermount must be set to 1.
In FreeBSD, PcBSD, and DragonflyBSD, vfs.usermount must be set to 1.
[edit] Union Mounts

Normally, filesystems are mounted on empty directories. If the directory was not empty, its files are
hidden until the filesystem is unmounted. The union mount allows these files to show through. Each
existing file from the directory only shows if there is no file in the same place on the mounted
filesystem. All new files are made on the mounted filesystem. Note that union mounts are strange and
might not work well on your system.
Some operating systems provide a mount(8) option -o union for this. In this example, a non-partitioned
SCSI disk sd0 will be mounted on /etc (which is not normally a mount point). Any existing /etc files
that we have that are not also on sd0 will still be available.
# mount -o union /dev/sd0c /etc
[edit] Disk Images

A filesystem can be stored on a file on another filesystem. Such files are called disk images and they
have several applications:
Use dd to copy data from a device node to a normal file to preserve the content of a small disk, for
example a floppy disk.
Some programs let you make iso9660 disk images before burning them to CD. One might want to
mount your disk image read-only to examine it before the burn. One can also move such images to a
computer with a CD burner, or offer the image for download so others may burn it.
If you have no free space for new partitions on your disk, but some partition has free space, then you
can create a disk image if you need a new filesystem. Sometimes this helps in the creation of encrypted
filesystems.
This guide only describes raw disk images, which contain only the filesystem. There are other formats
(such as the Mac OS X NDIF format) but these must be converted or handled specially.
[edit] Mounting Disk Images on NetBSD and OpenBSD

Normally, NetBSD and OpenBSD only allow mounting of filesystems stored on devices. Thus five
steps are involved:
Associate the disk image with a svnd device.

Mount the svnd device.
Use the disk image.
Unmount the svnd device.
Disassociate the disk image from the device.
Association and dissociation are handled by the vnconfig(8) command. In this example,
/the/disk/image will be associated with /dev/svnd0c. This particular disk image has a disklabel with a
filesystem on partition 'a', which we mount on /mnt. If there was no disklabel, we would instead mount
partition 'c'.
# vnconfig -c /dev/svnd0c /the/disk/image

# mount /dev/svnd0a /mnt
...
# umount /dev/svnd0a
# vnconfig -u /dev/svnd0c
[edit] Mounting Disk Images on FreeBSD 5

In FreeBSD 5, one uses mdconfig(8) with a vnode backed storage.
[edit] Mounting Disk Images on Linux

The mount(8) option -o loop can be used to mount disk images instead of devices.
# mount -o loop /the/disk/image /mnt

...
# umount /mnt
Some Linux kernels can mount a cloop (compressed loop), which is a compressed disk image. Such an
image must be mounted read-only. One first prepares the image and then compresses it how? Then one
mounts it how? The Knoppix livecd uses a cloop to fit more programs to the CD.
[edit] Creating Disk Images

Creating a new, empty disk image involves two steps before you mount it and start using it:
Use dd(1) to make a new file of zeros with the correct size.
Format the disk image with partitions and filesystems.
Here is an example. We use dd and an unlimited supply of zeros, /dev/zero, to create a 1440 kilobyte
disk image (1440 blocks of 1024 bytes). Then we use mkfs.ext3(8) to create an unpartitioned ext3
filesystem. Note that mkfs.ext3 does no mounting, so it cares not if it formats a device or a disk image.
(FIXME is this correct?)
$ dd bs=1024 count=1440 if=/dev/zero of=example

$ mkfs.ext3 example
The *BSD newfs(8) and newfs_msdos(8) utilities insist on formatting devices only. This is solved with
vnconfig(8). If we wanted to partition the disk image, we would also have made a disklabel. One can
ignore the imaginary disk geometry.

$ sudo vnconfig -c /dev/svnd0c example
$ sudo newfs /dev/rsvnd0c
...
$ sudo vnconfig -u /dev/svnd0c
In fact, on *BSD it is a good idea to always have a disklabel, especially if when creating an ffs
filesystem, so that the filesystem will be correctly listed in the label, and the letter will be different
from 'c'.

$ sudo vnconfig -c /dev/svnd0c example
$ sudo disklabel -E svnd0
Initial label editor (enter '?' for help at any prompt)

>a
partition: [a]
offset: [0]
size: [2880]
FS type: [4.2BSD]
>p
device: /dev/rsvnd0c
type: SCSI
disk: vnd device
label: fictitious
bytes/sector: 512
sectors/track: 100
tracks/cylinder: 1
sectors/cylinder: 100
cylinders: 28
total sectors: 2880
free sectors: 0
rpm: 3600
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2880 0 4.2BSD 2048 16384 32 # Cyl 0 - 28*
c: 2880 0 unused 0 0 # Cyl 0 - 28*
>q
Write new label?: [y]
$ sudo newfs /dev/rsvnd0a
...
[edit] Encrypted Filesystems
[edit] Encrypted Filesystems on OpenBSD

Because OpenBSD has integrated crypto, one would expect that there is a way to have an encrypted
filesystem. OpenBSD only provides Blowfish encryption for disk images. This is possible with the -k
flag to vnconfig(8), used with -c.
In this example, we will mount the encrypted disk image called /secrets, which contains a single
partion letter 'a':
# vnconfig -ck /dev/svnd0c /secrets

Encryption key:
# mount /dev/svnd0a
...
# umount /dev/svnd0a
# vnconfig -u /dev/svnd0c
Note that if you entered the wrong encryption key, vnconfig will still succeed. The mount will fail
because the disklabel and filesystem header are not readable. In this case, you must vnconfig -u and
then vnconfig -ck with the correct key. Make sure to use the correct key when initially formatting a
new disk image.
To have an entire encrypted disk partition, create a normal unencrypted disk image, mount it, then fill
the partition with one large file to serve as the disk image.
[edit] Encrypted Filesystems on Linux

Some Linux kernel configurations let you use losetup to encrypt disk images. Think of lo(opback)
setup, not of lose tup.
UNIX/EXPLANATIONS/PARTITIONING DISKS
This chapter describes different types of partitioning maps and the programs used to adjust partitioning
maps.
A partition map divides the disk into partitions. Each partition can be formatted separately. Partitions
are normally used for filesystems, which hold computer files, or swap, which is used as additional (but
slower) memory by operating systems. The chapter for Filesystems and Swap described how Unix-like
systems use partitions.
The Unix-like system is often installed on the same disk as some other operating system. In that case,
both the Unix-like kernel and the other system must understand the same kind of partioning map.
On i386 hardware, fdisk partitioning is common. It is used by DOS, Windows, and Linux. The BIOS
which boots the computer starts the Master Boot Record (MBR) on the disk. The MBR understands the
fdisk format.
On Macintoshes, the Apple partition map allows the disk to contain one or more Macintosh (HFS+ or
the older HFS) partitions. The BIOS (Open Firmware) can boot the Macintosh without an MBR,
because the BIOS can find bootloader files on HFS+ and HFS partitions.
The *BSD systems can use an MBR with a *BSD partition map, but most configurations use a non-
BSD partition map with a "slice" that contains a *BSD partition map and partitions.
Contents [hide]
1 fdisk partition maps
2 Apple partition maps
2.1 Partition Types
2.2 Example
3 BSD slices and partitions
3.1 Is there room for the disklabel?
3.2 How does BSD read a non-BSD partition map?
[edit] fdisk partition maps

This section might need corrections.
The fdisk partitioning is used by DOS and Windows. It is also used by Linux systems, especially
because Linux is often installed on the same disks as DOS and Windows. With fdisk:
The master boot record (MBR) is not part of any partition.

You are limited to four primary partititions. If you want more partitions, you must divide primary
partion 4 into secondary partitions. For example, Windows might be installed on primary partitions 1
(drive C:) and 2 (drive D:). Linux might be using 3 partitions (root /, swap, and home /home). Root is
on primary partion 3. Primary partition 4 contains the swap and home partitions, and possibly extra
space for future partitions.
A primary partition might also be a *BSD slice. That means that it contains a *BSD disklabel and
several *BSD partitions.
One primary partition might be marked active. The default MBR (the one from MS-DOS and
FreeDOS) boots the active primary partition. However, some MBRs like GRUB might give you a
menu instead of booting the active partition.
You can declare the type of each partition. Some systems use the type to find their filesystems. BSD
uses the type to find its slice, but Linux ignores the types completely. Linux instead goes by its
/etc/fstab file.
To manipulate fdisk partitions, look for a program called FDISK.EXE on DOS or fdisk on Linux.
[edit] Apple partition maps

Mac OS hard disks normally contain Apple partioning maps. These maps are created when Apple's
Drive Setup program was used to format the disk. With these partition maps:
Partition 1 contains the partition map.

For some reason, Drive Setup insists on creating 128 MB of unused Apple_Free space as partition 2.
Some older disks with Mac OS 9 drivers installed have several tiny partitions, starting at 2, which are
only used by Mac OS 9 and older.
You can create at least 17 partitions, and probably more.
There is no Master Boot Record (MBR).
To manipulate Apple partitions, go to a shell prompt on Mac OS X or *BSD and use pdisk or diskutil.
Most GNU/Linux systems now call that same program mac-fdisk for some reason.
[edit] Partition Types

Actually, partition types on Apple partition maps can be arbitrary strings, for example "OpenBSD".
Some operating systems are still stuck with "Apple_UNIX_SVR2" though.
Apple_partition_map This partition contains the partition map. It exists so that no other partition
overlaps the partition map.
Mac OS classic drivers These tiny partitions would be after the partition map, but most disks now lack
them. Mac OS 9 and earlier would load a device driver for the disk from these partitions. All other
systems, including Mac OS X, do not use them.
Apple_HFS This is an HFS+ or HFS partition. Mac OS mounts all partitions of this type (unless the
HFS do-not-mount flag is set). This might also be an MS-DOS format partition; Mac OS can also
mount those.
Apple_UFS This is a UFS partition mounted by Mac OS X.
It has its own Apple-format disklabel and separate boot partition (Apple_Boot? not Apple_Bootstrap)
in case someone copies a bootable copy of Mac OS X to the partition.
Especially with newer versions of Mac OS X, there is almost never a reason to use Apple_UFS. Use
HFS+ instead. Trying to use Apple_UFS partitions with OpenBSD can corrupt data.
OpenBSD This is the OpenBSD slice. A disk must have zero or one of these.
Apple_Bootstrap The BIOS (Open Firmware) can boot from this partition, but Mac OS will not mount
it. This partition type is used by "ybin" to contain "yaboot", the Linux bootloader. It can also contain an
OS-menu with Mac OS 9, Mac OS X, and GNU/Linux as possible entries.
Apple_UNIX_SVR2 Nominally, it is an A/UX partition for Apple's port of SVR2 to the 68k Mac.
However, Apple borrowed this partition type for their dualithic Linux for PowerPC Mac. Both Apple
systems are obsolete, but now both Linux and NetBSD are using this partition type.
Using NetBSD's pdisk, you can flag two Apple_UNIX_SVR2 partitions as root and swap partitions.
These become "a" and "b" when you boot NetBSD.
It is confusing if you have Linux and NetBSD on the same disk.
Apple_Free Map editors like pdisk create this "partition" whenever partitions are deleted. An
"Apple_Free" partition is just unused space. There is usually one big "Apple_Free" partition.
Drive Setup on Mac OS X also insists on wasting 128 MB on an Apple_Free partition between the
Apple_partion_map and the first Apple_HFS. If careful, one can use the 128 MB as swap for
OpenBSD.
[edit] Example
On the example system, we use "pdisk" on OpenBSD to see the partition map. We run the "pdisk
/dev/rwd0c" command on OpenBSD. On Mac OS X the command would be "pdisk /dev/disk0". Most
Linux distros now give the name "mac-fdisk" to "pdisk", so the command would be "mac-fdisk
/dev/hda". We use the pdisk command "p" to print the partition map and then "q" to quit.
# pdisk /dev/rwd0c
Edit /dev/rwd0c -
Command (? for help): p
Partition map (with 512 byte blocks) on '/dev/rwd0c'

#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_Bootstrap untitled 1954 @ 50331712
3: Apple_HFS Apple_HFS_Untitled_1 24903680 @ 262208 ( 11.9G)
4: OpenBSD OpenBSD 25165824 @ 25165888 ( 12.0G)
5: Apple_UNIX_SVR2 untitled 24064454 @ 50333666 ( 11.5G)
6: Apple_Free Extra 262144 @ 64 (128.0M)
7: Apple_UNIX_SVR2 swap 1099416 @ 74398120 (536.8M)
8: Apple_Free Extra 41712704 @ 75497536 ( 19.9G)
Device block size=512, Number of Blocks=117210240 (55.9G)

DeviceType=0x0, DeviceId=0x0
Command (? for help): q

#
[edit] BSD slices and partitions

BSD disklabelThis section might need corrections.
The terms "slice" and "partition" are often defined as follows:
A partition is an entry (filesystem or swap) in the BSD disklabel.

A slice is the partition of the non-BSD partition map (like fdisk or Apple) which contains the BSD
disklabel and partitions.
The BSD partition map is called a disklabel. In the following discussion, "partition map" refers to a
non-BSD partition map which is not a disklabel.
BSD partitioning is special because on a disk with *BSD installed, 'a' must be root and 'b' if it exists
must be swap. The disklabel indicates the locations, types, and letters of all partitions. Because of these
special traits, BSD disklabels are confined to slices on any disks that are also used by non-BSD
operating systems. This leads to three situations when a disk is used with BSD:
The disk has a partition map and a disklabel. The partition map is at the beginning of the disk (possibly
after the MBR). One of the partitions is a BSD slice. The disklabel is at the beginning of the BSD slice.
The *BSD system will use the disklabel while other systems use the partition map. A disk with
OpenBSD/macppc installed uses this configuration.
The disk has a partition map but no disklabel. If the disk is used with *BSD, the BSD kernel generates
a partition map, assigning letters to all recognized types of partitions. With Apple partition maps,
OpenBSD/macppc only recognizes Apple_HFS partitions. NetBSD/macppc recognizes both
Apple_HFS and NetBSD (Apple_UNIX_SVR2) partitions, so NetBSD/macppc installations do not
need a disklabel.
The disk has only a disklabel. The disklabel is at the beginning of the disk, possibly after the MBR, and
the entire disk is reserved to *BSD. Only *BSD can use this disk.
[edit] Is there room for the disklabel?

To make room for a disklabel, all UFS/FFS partitions leave the first bytes unused. Thus you can put a
root UFS/FFS partition directly at the beginning of the disk (except the MBR) and still have room for a
disklabel.
All UFS/FFS partitions must be listed in a disklabel to be useful. Mac OS X will put an Apple-specific
disklabel on all Apple_UFS partitions because those are not listed in a BSD disklabel.
[edit] How does BSD read a non-BSD partition map?

The *BSD distros have different approaches for using non-BSD partitions, or having *BSD and a non-
*BSD operating system on the same disk.
If NetBSD sees an Apple partitioning map, it will assign letters to all of the HFS+ partitions and
NetBSD partitions.
If OpenBSD sees an Apple partitioning map, it will search for a partition of type "OpenBSD", and use
the disklabel on that partition. If no disklabel exists, OpenBSD assigns letters to all "Apple_HFS"
(HFS+) partitions, starting with letter 'i'. When creating a disklabel, one starts with the HFS+ partitions
already in the disklabel. Then one adds OpenBSD partitions by dividing the "OpenBSD" Apple
partition into several disklabel partitions, which is a form of secondary partitioning. Use disklabel -E to
edit the disklabel.
UNIX/EXPLANATIONS/COMPACT DISCS
Contents
[hide]
• 1 Ripping CD audio
• 1.1 Granting permission to the user
• 1.2 Ripping tracks
• 2 Eject a disc
• 3 Burn a disk
[edit] Ripping CD audio

This copies the audio from a CD track to a file. With some drives (one without analog connections to
the sound card) this is the only way to correctly play a file.
[edit] Granting permission to the user

First you should have read-and-write permission to the CD device. (You could become root to rip the
CD, but then you would have to "chown" the file back to you.)
First look at your CD devices nodes. On *BSD, they are at /dev/cd* and /dev/rcd*. If they look
like this:
$ ls -l /dev/cd*
brw-r--'--- 1 root operator 3, 0 Nov 1 16:26 /dev/cd0a
brw-r--'--- 1 root operator 3, 2 Nov 1 16:26 /dev/cd0c
brw-r--'--- 1 root operator 3, 16 Nov 1 16:26 /dev/cd1a
brw-r--'--- 1 root operator 3, 18 Nov 1 16:26 /dev/cd1c
Here, root needs to grant read and write permission to the user. We decide to add the users to group
"wheel". Once they are in, we change the group of the devices and grant read and write permission to
the group:
$ sudo chgrp wheel /dev/cd* /dev/rcd*
$ sudo chmod g+gw /dev/cd* /dev/rcd*
$ ls -l /dev/cd*
brw-rw--'-- 1 root wheel 3, 0 Nov 1 16:26 /dev/cd0a
brw-rw--'-- 1 root wheel 3, 2 Nov 1 16:26 /dev/cd0c
brw-rw--'-- 1 root wheel 3, 16 Nov 1 16:26 /dev/cd1a
brw-rw--'-- 1 root wheel 3, 18 Nov 1 16:26 /dev/cd1c
[edit] Ripping tracks

We must insert a CD before ripping the track.
Here, for example, we rip track 2 and store it in song.wav. Our ".wav" suffix is because that is the
default format of cdparanoia. With a CD in:
$ cdparanoia 2 song37.wav
[edit] Eject a disc

Many systems provide an eject command.
$ eject cd0
[edit] Burn a disk

Scenario: put the contents of a directory called backup to CD.
Here we do the actual burn (and eject) as root. The user needs to have "sudo" access, but not any
special access to the CD device node.
Create a disk image of the CD. We will call it burn.iso.
• -R is ISO6990 Rock Ridge support
• -r is Rock Ridge but with all files to root (usable on computers with different users)
• -hfs indicates a hybrid ISO9660/HFS disk
$ mkisofs -o burn.iso -r -hfs backup
$ chmod a-w burn.iso
Mount it to check for validity. (NetBSD/OpenBSD)
$ sudo vnconfig /dev/svnd0c burn.iso
$ sudo mount -r -t cd9660 /dev/svnd0a /mnt
$ diff /mnt backup
$ echo $?
0
$ sudo umount /mnt
The filesystem is good though file is misleading:
$ file burn.iso
burn.iso: x86 boot sector, extended partition table
Insert a blank disk.
This is a test burn to demonstrate cdrecord -v.
$ sudo cdrecord -v -dummy dev=/dev/cd0c burn.iso
cdrecord: No write mode specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive
dependent defaults.
cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01 (--) Copyright (C) 1995-2004 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '/dev/cd0c'
devname: '/dev/cd0c'
scsibus: -2 target: -2 lun: -2
Using libscg version 'schily-0.8'.
SCSI buffer size: 61440
atapi: 0
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identifikation : 'CD-RW CW-8123 '
Revision : 'CA0T'
Device seems to be: Generic mmc2 DVD-ROM.
Current: 0x0009
Profile: 0x0010
Profile: 0x0008
Profile: 0x0009 (current)
Profile: 0x000A
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-2 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P
RAW/R96R
Drive buf size : 1731072 = 1690 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 114 MB
Total size: 130 MB (12:58.58) = 58394 sectors
Lout start: 131 MB (13:00/44) = 58394 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in: -11834 (97:24/16)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 24
Manufacturer: SONY Corporation
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 301455
Starting to write CD/DVD at speed 24 in dummy TAO mode for single
session.
Last chance to quit, starting dummy write 0 seconds. Operation
starts.
Waiting for reader process to fill input buffer ... input buffer
ready.
BURN-Free is ON.
Turning BURN-Free off
Starting new track at sector: 0
Track 01: 114 of 114 MB written (fifo 100%) [buf 98%] 8.2x.
Track 01: Total bytes read/written: 119586816/119586816 (58392
sectors).
Writing time: 102.275s
Average write speed 7.6x.
Min drive buffer fill was 98%
Fixating...
WARNING: Some drives don't like fixation in dummy mode.
Fixating time: 34.457s
cdrecord: fifo had 1947 puts and 1947 gets.
cdrecord: fifo was 0 times empty and 1860 times full, min fill was
80%.
$ echo $?
0
An actual burn:
$ sudo cdrecord dev=/dev/cd0c burn.iso
Password:
cdrecord: No write mode specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive
dependent defaults.
cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01 (--) Copyright (C) 1995-2004 Jörg Schilling
scsidev: '/dev/cd0c'
devname: '/dev/cd0c'
scsibus: -2 target: -2 lun: -2
Using libscg version 'schily-0.8'.
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identifikation : 'CD-RW CW-8123 '
Revision : 'CA0T'
Device seems to be: Generic mmc2 DVD-ROM.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-2 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P
RAW/R96R
Starting to write CD/DVD at speed 24 in real TAO mode for single
session.
Last chance to quit, starting real write 0 seconds. Operation
starts.
Track 01: Total bytes read/written: 119586816/119586816 (58392
sectors).
$ echo $?
0
We should eject the finished disk now. The OS or drive might not know that the disk now has a
filesystem on it.
$ sudo eject cd0
If we reinsert the disk then we can mount/unmount it:
$ sudo mount /dev/cd0a /mnt
$ sudo umount /mnt
PART 5: NETWORKING
UNIX/EXPLANATIONS/INTERPROCESS COMMUNICATION
[edit] PIPEs
One of the beauties of UNIX/Linux are pipes. Pipes are used for redirecting STDOUT (standard out) to
STDIN (standard in).
$ command1 | command2
command1 standard output is redirected as standard input to command2.
Unix/Explanations/Real Networking Interfaces

Real Networking Interfaces are the actual physical network connections on a computer. For example,
an Ethernet wire or wireless card is a real networking interface.
If an interface is only a tunnel through another interface, then it is a Guide to Unix/Explanations/Fake

Networking Interface.
Normally, there is somewhere in the Boot Process that configures network connections. Use the
ifconfig command as root, though some Unix variants have a different command. A common
configuration is to do DHCP with dhclient or pump command.
It is also possible to route packets between interfaces. This requires configuring the interfaces correctly
and making a routing table. A firewall is a good idea.
UNIX/EXPLANATIONS/FAKE NETWORKING INTERFACES
Loopback
The system uses the loopback interface "lo0" to talk to itself. Most systems automatically configure it
at boot. Talking-to-oneself is useful for testing servers, and also for any situation where the server and
client are on the same computer. (For example, some computer games have a one-player mode where
server and client are on the same computer. These games use the "network", but because there is only
one computer, they use the loopback interface.)
Use the ifconfig command to check the status of the interface. It probably looks something like:
$ ifconfig lo
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
The IPv4 address of your computer is "127.0.0.1". This is in addition to any address that it has on an
actual network. In fact, every computer calls itself "127.0.0.1", so it is impossible to use this address to
communicate between computers. (Some jokes involve a person who is given "127.0.0.1" as an attack
target and proceeds to destroy their own computer.)
If your system is running an IPv6 stack, then your IPv6 loopback address is "::1". The computer should
be able to use IPv6 to communicate with itself, even if it has no connection to an actual IPv6 network.
You probably have no problem pinging the interface with ping or ping6. We use "ping -c3" and "ping6
-c3" to ping 3 times; otherwise it would ping every second until you interrupted with ^C (CTRL+C).
$ ping -c3 127.0.0.1

PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.206 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.094/0.132/0.206/0.052 ms
$ ping6 -c3 ::1
PING6(56=40+8+8 bytes) ::1 --> ::1
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.284 ms
--- ::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.116/0.173/0.284/0.079 ms
[edit] Create interfaces

If you want to use a fake network interface, you often must create it with "ifconfig create".
Some interfaces that you might be able to create: bridge, carp, gif, gre, lo, ppp, pppoe, sl, trunk, tun,
vlan.
Unix/BSD/Introduction
This page summarizes the main features of the *BSD kernel and system, especially in comparison to
other Unix-like systems. Currently, this page covers the free variants of *BSD, especially DragonFly
BSD, FreeBSD, NetBSD, and OpenBSD. There are also nonfree variants.
The Wikibook, A Neutral Look at Operating Systems, gives an overview of BSD in its Berkeley
Software Distribution chapter.
Contents [hide]
1 General
2 Kernel
3 Userland
4 Ports
[edit] General
The *BSD systems are descendants of AT&T Unix (though non-free Unix code was removed) so they
feel more like Unix than their rival system GNU/Linux. AT&T had cheaply licensed the code to
universities including Berkeley where major enhancements such as TCP/IP was then developed. The
last BSD release from Berkeley had non-free code removed so more persons could use it. Today, the
*BSD projects honor their ancestry putting BSD at the end of their names.
The four big *BSD systems are free software and open source. While *BSD does use some copylefted
GNU programs, most of *BSD is not copyleft, which leaves everyone free to make non-free versions
of *BSD and distribute binaries without source code. However, some parts of *BSD have extra terms
in the license that annoy some people, and which are not found in the GNU licenses. In particular, there
was enough dislike for the "advertising clause" (which requires marks on certain ads) that the Regents
of the University of California removed it from their license; some other *BSD copyright holders still
use the clause.
The core system, including kernel and userland, is maintained in one CVS tree. This is similar to
OpenSolaris and OpenDarwin, but GNU/Linux programs and kernels are in separate trees, and the
development trees of non-free Unix-like systems are normally not public. Compare:
DragonFly BSD http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/
FreeBSD http://www.freebsd.org/cgi/cvsweb.cgi/
NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/
OpenBSD http://www.openbsd.org/cgi-bin/cvsweb/
OpenSolaris http://cvs.opensolaris.org/source/
OpenDarwin http://cvs.opendarwin.org/index.cgi/
The *BSD sources are stored in /usr/src/ and the kernel in /usr/src/sys/. The *BSD kernel and system
programs are heavily integrated, and so must be upgraded together.
[edit] Kernel
Recall that a kernel is the interface between programs and hardware. Unix-like kernels provide device
drivers and networking support and allow multiple users and programs to share the system.
The *BSD kernel (often installed at "/bsd/") is monolothic, which means that it is one program in one
memory-addressing space. Thus the kernel avoids forming and sending messages between parts of
itself.
DragonFly BSD is changing some of this.
The original AT&T Unix and Linux are also monolithic, while mkLinux and the kernel of Mac OS X
are modular.
The kernel is actually the original AT&T Unix with all of its files replaced. The BSD university project
had added or replaced so much stuff (the VAX port, the networking features, the fast file system, ...)
that *BSD projects could take the free parts and produce completely free kernels without needing a
Unix license. A consequence of this is that the BSD kernel has a similar structure to commercial Unix
kernels also descended from AT&T Unix.
The kernel contains a "securelevel" feature which attempts to permanently restrict what all users
(including root, the superuser) can do after a certain point in the boot process.
The kernel boot messages (also visible with dmesg, on all Unix systems) are organized and shows
where each device was detected.
In contrast, the Linux drivers seem to give any boot messages that they feel like. The mounting and
examining of "/proc" and "/sys", or the use of tools like "lspci", is a better strategy on Linux.
[edit] Userland
Recall that userland consists of all the software above the kernel. This section describes the userland
included with the base system.
The programs in /bin/ and /sbin/ are statically linked.
This is because /usr/ might not be mounted, so the shared library /usr/lib/libc.so cannot be used.
Static linking is when the each program is in one file, without the need for other files (shared libraries)
containing code shared by programs. The library code is copied into the programs.
The main text editor in the base system is "vi". This is nvi included with BSD, and ultimately the
original vi, and is not some other vi implementation such as vim. Actually, nvi is a clone of the original
vi. The clone was necessary to remove some non-free Unix code.
OpenBSD also includes "mg", an editor resembling Emacs 17 but without any free but copylefted
GNU code. FreeBSD includes "ee", the "easy editor" with some similarities to nano and pico (both of
which are in the ports tree, although nano is free software and pico isn't).
[edit] Ports
There is a ports tree or packages tree originally from FreeBSD. This consists of Makefiles that
automate the downloading, extracting, patching, and building of software for *BSD. This is the main
way of installing stuff that is not part of the base system.
On NetBSD this is called pkgsrc. A unique feature of the pkgsrc tree is that it also works on other
operating systems. DragonFly BSD also uses pkgsrc.
Thus installing a program is often two easy steps. First, type a "cd" command to the directory
containing the port (for example, /usr/ports/games/nethack/). Then, type a "make install" command and
wait for everything to finish.
Building software takes a long time, so many prefer to use a binary package instead of a "make install".
The system compiler is the GNU Compiler Collection (GCC) with C, C++, Objective C, and Fortran
77.
By default, gcc does not look in /usr/local/ for header files and libraries; it only looks at the base
system.
The base system can rebuild itself with gcc.
Retrieved from "http://en.wikibooks.org/wiki/Guide_to_Unix/BSD/Introduction"
Unix/BSD/FreeBSD
FreeBSD is a Unix-like free operating system descended from AT&T UNIX via the Berkeley Software
Distribution (BSD) branch through the 386BSD and 4.4BSD operating systems. It runs on processors
compatible with the Intel x86 family, as well as on the DEC Alpha, the UltraSPARC processors by Sun
Microsystems, the Itanium (IA-64), AMD64 and PowerPC processors. It also runs on the PC-98
architecture. Support for the ARM and MIPS architectures is currently in development.
FreeBSD is developed as a complete operating system. The kernel, device drivers and all of the
userland utilities, such as the shell, are held in the same source code revision tracking tree (CVS). This
is in contrast to Linux, a similar but better-known operating system, in which the kernel is developed
by one set of developers; userland utilities and applications by others, such as the GNU project; and all
are packaged together by other groups and published as Linux distributions.
As an operating system, FreeBSD is generally regarded as quite reliable and robust, and of the
operating systems that accurately report uptime remotely [1], FreeBSD is the most common free
operating system listed in Netcraft's list [2] of the 50 web servers with the longest uptime (uptime on
some operating systems such as some versions of Linux can't be calculated). A long uptime also
indicates that no kernel updates have been deemed necessary, as installing a new kernel requires a
reboot and resets the uptime counter of the system.
History and development Initial development of FreeBSD started in 1993, taking its sources from
386BSD. However, due to concerns about the legality of all the sources used in 386BSD and a
consequent lawsuit between Novell (then owner of the UNIX trademark) and Berkeley, FreeBSD
ended up re-engineering much of the system with the FreeBSD 2.0 release in January of 1995 using the
4.4BSD-Lite release from the University of California, Berkeley. The FreeBSD Handbook includes
more historical information about the genesis of FreeBSD.
Perhaps FreeBSD 2.0's most notable advance was the revamp of the original CMU's Mach Virtual
Memory system, which was optimized for performance under high loads, and the creation of the ports
system that made downloading, building and installing third party software very easy. FreeBSD
powered extremely successful sites like cdrom.com (a huge repository of software that broke several
throughput records on the net), Hotmail, and Yahoo!.
FreeBSD 3.0 brought many changes: it switched to the ELF binary format, initial support for SMP
systems and also added support for a new 64 bit platform: the Alpha. At its time the 3.X branch was
severely critized as many changes were not evidently beneficial and affected performance, but it was a
necessary step to develop what would become the very successful 4.X branch.
Initially, FreeBSD employed the BSD Daemon as its logo, but in 2005 a competition for a new logo
was arranged. On October 8, 2005, the competition finished and the design by Anton K. Gural was
chosen as the new FreeBSD logo. The BSD Daemon will remain as the FreeBSD Project mascot. [edit]
FreeBSD 5 development and changes
The latest and final FreeBSD release from the 5-STABLE branch is 5.5, and was released in May 2006.
FreeBSD developers maintain (at least) two branches of simultaneous development. A -STABLE
branch of FreeBSD is created for each major version number, from which releases are cut about once
every 4-6 months. The latest 4-STABLE release of FreeBSD is 4.11, which is the last of the 4-STABLE
branch releases. The first 5-STABLE release was 5.3 (5.0 through 5.2.1 were cut from -CURRENT).
The first 6-STABLE release was 6.0. The development branch, -CURRENT, is now 7.0-CURRENT,
which contains aggressive new kernel and userspace features. If a feature is sufficiently stable and
mature, it is eventually backported ("MFC" - Merge from CURRENT in the FreeBSD developer slang)
to the -STABLE branch. FreeBSD's development model is described in an in-depth article by Niklas
Saers [3].
The big difference in FreeBSD 5 was a major change in the low-level kernel locking mechanisms to
enable better symmetric multiprocessor (SMP) support, releasing much of the kernel from the MP lock,
sometimes referred to as the Big Giant Lock. It is now possible for more than one process to execute in
kernel mode at the same time.
Other major changes include an m:n threading solution called KSE which is now the default threading
(pthreads) library, starting with 5.3 (the creation of the 5-STABLE branch). The terminology m:n,
where m and n are small positive integers, implies that m userland threads correspond to n kernel
threads. Many other new features are security related. The TrustedBSD project was formed by Robert
Watson for the express purpose of adding trusted operating system functionality to the FreeBSD
operating system. An extensible mandatory access control framework (the TrustedBSD MAC
Framework), filesystem Access Control Lists (ACLs), and the new UFS2 filesystem all came from
TrustedBSD. Some of the TrustedBSD functionality has been integrated into the NetBSD and
OpenBSD operating systems as well.
FreeBSD 5 has also significantly changed the block I/O layer with the introduction of the GEOM
modular disk I/O request transformation framework, contributed by Poul-Henning Kamp. GEOM
enables the simple creation of many kinds of functionality, such as mirroring (gmirror) and encryption
(gbde). The recent release of FreeBSD 5.4 has confirmed the FreeBSD 5.x branch as a highly stable
and well-performing release, albeit one with a long gestation period due to the large feature set.
FreeBSD 6 and 7
FreeBSD 6.1 was released on May 8, 2006, and 7.0-CURRENT is under active development. These
versions continue the work on SMP and threading optimization, as well as additional work in the area
of advanced 802.11 functionality, and TrustedBSD security event auditing. The primary release
accomplishments of this release include the removal of the Giant lock from VFS, replacement of the
libthr library with a better performing implementation of 1:1 threading, and the addition of a BSM
audit implementation, called OpenBSM, created by the TrustedBSD Project which is heavily based
upon the BSM implementation found in Apple's Open Source Darwin which has been released under a
BSD-style license.
Linux compatibility
FreeBSD provides binary compatibility with several other Unix-like operating systems, including
Linux. The reasoning behind this is generally attributed to being able to run applications developed for
Linux, often commercial, that are only distributed in binary form and thus cannot be ported to FreeBSD
without the will of those who control the source code.
In a nutshell, it allows FreeBSD users to run a majority of the applications that are only distributed as
Linux binaries. When compared to the vast number of native applications available for FreeBSD using
the Ports Collection, these applications are in the minority. Applications used under the Linux
compatibility layer include StarOffice, the Linux version of Netscape, Adobe Acrobat, RealPlayer,
VMware, Oracle, WordPerfect, Skype, Doom 3, Quake 4, the Unreal Tournament series, SeaMonkey,
and so on. Generally, there seems to be no noticeable performance penalty when running Linux
binaries as opposed to native FreeBSD ones.
Though there are many applications that run flawlessly under the compatibility layer, it should be noted
that the layer is not complete, thus rendering some Linux binaries unusable on FreeBSD or limiting
their functionality, possibly because this compatibility layer only supports the system calls of Linux
Kernel 2.4.2, a historic release. One example of this is Cedega, TransGaming's product to run
Microsoft Windows games on Linux. Its usage is largely crippled at this time due to an incomplete
compatibility layer. There has, however, been limited success in using it to run games on FreeBSD [4].
A 2006 Summer of Code project to update the compatibility layer and implement missing system calls
has been accepted [5].
For most scientific applications, the Linux compatibility layer performs correctly; applications such as
nmrpipe, ccp, Mathematica and Matlab perform as expected.
License
As with its sister operating systems, the code in FreeBSD is released under the terms of a variety of
licenses. All of the kernel code and most newly created code is released under the terms of the two-
clause BSD license, which allows everyone to use and redistribute FreeBSD as they wish. There are
also parts under the GPL, LGPL, ISC, three-clause BSD license, and four-clause BSD license.
Also available are binary blobs for particular functionality, such as the Atheros HAL for wireless
functionality and a binary only tool for Adaptec's AAC RAID.
Derivatives
A range of products are directly or indirectly based on FreeBSD. These range from embedded devices,
such as Juniper routers and Nokia's firewall operating system, to portions of other operating systems
including Linux and the RTOS VxWorks. Darwin, the core of Apple's Mac OS X, borrows heavily
from FreeBSD, including its virtual file system, network stack and components of its userspace. Apple
continues to integrate new code from and contribute changes back to FreeBSD. The open source
OpenDarwin, originally derived from Apple's codebase but now a separate entity, also includes
substantial FreeBSD code. In addition, there are a number of operating systems originally forked from
or based on FreeBSD including PC-BSD and DesktopBSD, which include enhancements aimed at
home users and workstations; the FreeSBIE and Frenzy live CD distributions; the m0n0wall and
pfSense embedded firewalls; and DragonFly BSD, a notable fork from FreeBSD 4.8 aiming for a
different multiprocessor synchronization strategy than that chosen for FreeBSD 5 and development of
some microkernel features.
Retrieved from "http://en.wikibooks.org/wiki/Guide_to_Unix/BSD/FreeBSD"
Unix/Environment Variables
An environment variable is a setting normally inherited or declared when a shell is started. You can use
shells to set variables; the syntax varies but Bourne shells use:
$ VARNAME=new value
$ export VARNAME
or
$ export VARNAME=new value
Each program started from that shell will have VARNAME set to new value. The names of
environment variables are case-sensitive; by convention they are uppercase.
A shell variable is like an environment variable, except that it is not exported to new programs started
from that shell. (You could export it, but normally you just write a shell initialisation script to set it in
each shell.)
[edit] EDITOR
The editor program called by sudoedit, vipw, and other such programs when you tell them to edit a file.
Examples:
EDITOR=vi
EDITOR=emacs
[edit] HOME
The home directory of the user. Most programs use this shell variable to find your home, thus you can
set this variable to override the setting in /etc/passwd for your home directory. This way, you can start
programs that put dotfiles or other files in a different directory than your usual home directory.
In most shells, ~ refers to your home directory. In Bourne shell, ~tux always refers to the home
directory of user tux as specified in /etc/passwd, while ~ (without a username after it) always refers to
the value of HOME, even if it differs from your home directory in /etc/passwd.
[edit] LOGNAME
The name of the user. This is an easy way for a user to get own username. However, programs must not
trust this variable because it can be set to an arbitrary value.
Both LOGNAME and USER should be set to the username.

Examples:
LOGNAME=tux
LOGNAME=puffy
[edit] MAIL
The location of incoming local email. When mail or another local email reader inherits this
environment variable, it uses this variable to find the inbox.
Some users do not have email at their local Unix box, but instead use the Internet to access their mail
server, in which case the MAIL environment variable is irrelevant.
Many users do not have MAIL set, in which case the email reader uses the default setting. The default
value for user "tux" would be /var/mail/tux, which is where many systems deliver mail.
[edit] MAILCHECK
This is a shell variable, not normally exported as an environment variable.
The frequency for which "bash" checks and alerts you for new local email.
[edit] PAGER
The pager called by man and other such programs when you tell them to view a file.
Examples:
PAGER=less
PAGER=more
[edit] PATH
A space or colon separated list of directories in which the shell searches for executables when a
command is run without an absolute path. For example ls doesn't have an absolute path, but /bin/ls
does).
Some systems set PATH using the system shell initialistation files, such as /etc/profile for Bourne
shells. Some systems set PATH before this as part of the login procedure, for example in /etc/login.conf
for OpenBSD systems. For example, a Linux box could set the PATH at login, then add /usr/X11R6/bin
to the path using /etc/profile, then add /home/ambler/bin to the path using ~/.bash_profile.
The system boot scripts also set PATH. On some Linux boxes, the first command to set the path would
seem to be in /etc/rc.d/rc.sysinit, which is one of the shell scripts invoked by the init process (inittab).
Examples:
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/home/puffy/bin
If this PATH is set and you type the shell command
$ uname -r
then the shell searches for the "uname" executable program. First it searches in /bin, then /sbin, then
/usr/bin. If /bin/uname is an executable (which it should be), then the shell stops searching and runs it.
If /home/puffy/bin/uname also is executable, it is not run, because the search never reached that
directory.
[edit] PS1
The bash and public domain ksh shells use this as the prompt string.
Things that can be put in the prompt string include \h (hostname), \u (username), \w (absolute
pathname of working directory), \W (name of working directory w/o path), \d (date), \t (time).
On some Red Hat boxes, the primary prompt string is set in the /etc/bashrc file. The prompt is also set
in /etc/profile, but the setting in bashrc seems to take precedence. A ~/.bashrc file runs /etc/bashrc,
which sets the prompt. Because every instance of "bash" runs ~/.bashrc, the prompt also appears in X
sessions started from a display manager such as "xdm".
On some Slackware boxes, the command line prompt is set in /etc/profile. The xterm and rxvt prompts
are different. The prompt is not set for X sessions, but it would be if you write a ~/.bashrc to do that.
Prompts are shell variables set from shell initialisation scripts. They are not xterm settings set by X
resources such as /usr/X11R6/lib/X11/app-defaults/XTerm.
A Practical Guide to Linux, by Mark G. Sobell and published by Addison-Wesley (1998), has more
information on prompt strings at page 331.
[edit] PS2
The bash and public domain ksh shells use this as a secondary prompt string.
[edit] USER
This variable should have the same setting and purpose as LOGNAME.
UNIX/FILES
Contents [hide]
1 /etc/
1.1 /etc/fstab
1.2 /etc/group
1.3 /etc/passwd
1.4 /etc/profile
1.5 /etc/shadow
1.6 /etc/sysctl.conf
1.7 Files to be merged in to the list
2 /proc/
3 /var/
4 /boot/
5 /dev/
5.1 /dev/cdrom
5.2 /dev/fd*
5.3 /dev/hd*
5.4 /dev/null
6 Dot files
7 Directories
[edit] /etc/
[edit] /etc/fstab
The fstab (for file systems table) file is commonly found on Unix and Unix-like systems and is part of
the system configuration. The fstab file typically lists all used disks and disk partitions, and indicates
how they are to be used or otherwise integrated into the overall system's file system.
Traditionally, the fstab was only read by programs, and not written to. However, more modern system
administration tools can automatically build and edit fstab, or act as graphical editors for it. It is the
duty of the system administrator to properly create and maintain this file.
The file may have other names on a given Unix variant; for example, it is /etc/vfstab on Solaris.
Example
The following is an example of a fstab file on a Red Hat Linux system:
# device name mount point fs-type options dump-freq pass-num

LABEL=/ / ext3 defaults 11
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 00
none /dev/shm tmpfs defaults 00
# my removable media
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
# my NTFS Windows XP partition

/dev/hda1 /mnt/WinXP ntfs ro,defaults 00
/dev/hda6 swap swap defaults 00
# my files partition shared by windows and linux

/dev/hda7 /mnt/shared vfat umask=000 00
( kudzu is an option specific to Red Hat and Fedora Core )
The first column indicates the device name or other means of locating the partition or data source. The
second column indicates where the data is to be attached to the filesystem. The third column indicates
the filesystem type, or algorithm to use to interpret the filesystem. The fourth column gives options,
including if the filesystem should be mounted at boot. The fifth column adjusts the archiving schedule
for the partition (used by dump). The sixth column indicates the order in which the fsck utility will scan
the partitions for errors when the computer powers on. A value of zero in either of the last 2 columns
disables the corresponding feature (http://www.humbug.org.au/talks/fstab/fstab_structure.html).
To get more information about the fstab file you can read the man page about it.
The Kfstab graphical configuration utility is available for KDE for editing fstab.
See also
mtab
[edit] /etc/group
/etc/group stores the definitive list of the users groups and their members.
A typical entry is:
root::0:root,alice
It has four sections which going from left to right are,
(root) The group name.

() The group password in a hashed form. Normally not used.
(0) The unique id assigned to the group. Group ids below 10 are reserved for system use. Some unixs
such as HP-UX reserve other groups numbers as well.
(root,alice) The list of users who are members of that group.
[edit] /etc/passwd
/etc/passwd is the user authentication database, it contains a list of users and their associated internal
user id numbers. Historically it also included passwords, however as this file needs to world readable
(so all programs can use it to convert between username and user id) it is no longer considered secure
to keep passwords in this file.
An entry in this file is of the form:
alice:*:134:20:Alice Monkey:/home/alice/:/bin/bash
It has seven sections which going from left to right are,
(alice) The username.

(*) The password in a hashed form. In modern systems a star indicates shadowing is in use and hence
the password can be found in /etc/shadow/.
(134) The unique id assigned to the user. Some unique ids have special purposes. For example the user
id 0 is used for the root user.
(20) The group that the user is assigned to upon login.
(Alice Monkey) The GCOS field, can be used for anything or left blank. Normally used for personal
information abou the user such as full name.
(/home/alice/) The home directory of the user.
(/bin/bash) The users default shell.
[edit] /etc/profile
/etc/profile contains the system default settings for users who login using the Bourne shell, "/bin/sh".
When these users login, the Bourne shell runs the commands in this file before giving the shell prompt
to the user. Most of these commands are variable assignments which configure the behavior of the
shell.
Some Bourne-compatible shells also use this file, but other shells, such as the C shell, do not.
[edit] /etc/shadow
/etc/shadow contains the passwords for users in systems which use shadowing.
alice:43SrweDe3F:621:5:30:10:100:900:
The sections are:
(alice) The username.

(43SrweDe3F) The password in hashed form.
(621) date of last password change.
(5) the mimimum number of days before the password may be changed.
(30) the maximum number of days before the user is forced to change their password.
(10) the number of days after which a user is advised to change their password.
(100) the maximum number of days an account can be inactive for before it is suspeneded.
(900) the date the account will expire, if left blank the account will remain indefinitely. Most often used
for the purpose of temporary accounts.
[edit] /etc/sysctl.conf
/etc/sysctl.conf configures the behavior of the running Unix kernel. During system boot, the scripts
read this file and use "sysctl" to set the parameters shown in the file. Changing the file has no effect
before the next reboot.
[edit] Files to be merged in to the list

/etc/aliases - file containing aliases used by sendmail and other MTAs (mail transport agents). After
updating this file, it is necessary to run the newaliases utility for the changes to be passed to sendmail.
/etc/bashrc - system-wide default functions and aliases for the bash shell
/etc/conf.modules - aliases and options for configurable modules
/etc/crontab - shell script to run different commands periodically (hourly, daily, weekly, monthly, etc.)
/etc/DIR_COLORS - used to store colors for different file types when using ls command. The dircolors
command uses this file when there is not a .dir_colors file in the user's home directory. Used in
conjunction with the eval command (see below).
/etc/exports - specifies hosts to which file systems can be exported using NFS. Man exports contains
information on how to set up this file for remote users.
/etc/fstab - contains information on partitions and filesystems used by system to mount different
partitions and devices on the directory tree
/etc/HOSTNAME - stores the name of the host computer
/etc/hosts - contains a list of host names and absolute IP addresses.
/etc/hosts.allow - hosts allowed (by the tcpd daemon) to access Internet services
/etc/hosts.deny - hosts forbidden (by the tcpd daemon) to access Internet services
/etc/group - similar to /etc/passwd but for groups
/etc/inetd.conf - configures the inetd daemon to tell it what TCP/IP services to provide (which daemons
to load at boot time). A good start to securing a Linux box is to turn off these services unless they are
necessary.
/etc/inittab - runs different programs and processes on startup. This is typically the program which is
responsible for, among other things, setting the default runlevel, running the rc.sysinit script contained
in /etc/rc.d, setting up virtual login terminals, bringing down the system in an orderly fashion in
response to [Ctrl][Alt][Del], running the rc script in /etc/rc.d, and running xdm for a graphical login
prompt (only if the default runlevel is set for a graphical login).
/etc/issue - pre-login message. This is often overwitten by the /etc/rc.d/rc.S script (in Slackware) or by
the /etc/rc.d/rc.local script (in Mandrake and Red Hat, and perhaps other rpm-based distributions). The
relevant lines should be commented out (or changed) in these scripts if a custom pre-login message is
desired.
/etc/lilo.conf - configuration file for lilo boot loader
/etc/motd - message of the day file, printed immediately after login. This is often overwritten by
/etc/rc.d/rc.S (Slackware) or /etc/rc.d/rc.local (Mandrake/Red Hat) on startup. See the remarks in
connection with /etc/issue.
/etc/mtab - shows currently mounted devices and partitions and their status
/etc/passwd - contains passwords and other information concerning users who are registered to use the
system. For obvious security reasons, this is readable only by root. It can be modified by root directly,
but it is preferable to use a configuration utility such as passwd to make the changes. A corrupt
/etc/passwd file can easily render a Linux box unusable.
/etc/printcap - shows the setup of printers
/etc/profile - sets system-wide defaults for bash shell. It is this file in Slackware that sets up the
DIR_COLORS environment variable for the color ls command. Also sets up other system-wide
environment variables.
/etc/resolv.conf - contains a list of domain name servers used by the local machine
/etc/securetty - contains a list of terminals on which root can login. For security reasons, this should not
include dialup terminals.
/etc/termcap - ASCII database defining the capabilities and characteristics of different consoles,
terminals, and printers
/etc/X11/XF86Config - X configuration file. The location in Slackware is /etc/XF86Config.
[edit] /proc/
/proc/cpuinfo - cpu information
/proc/filesystems - prints filesystems currently in use
/proc/interrupts - prints interrupts currently in use
/proc/ioports - contains a list of the i/o addresses used by various devices connected to the computer
/proc/kcore - The command ls -l /proc/kcore will give the amount of RAM on the computer. It's also
possible to use the free command to get the same information (and more).
/proc/version - prints Linux version and other info
[edit] /var/
/var/log/messages - used by syslog daemon to store kernel boot-time messages
/var/log/lastlog - used by system to store information about last boot
/var/log/wtmp - contains binary data indicating login times and duration for each user on system
[edit] /boot/
/boot/vmlinuz - the typical location and name of the Linux kernel. In the Slackware distribution, the
kernel is located at /vmlinuz.
[edit] /dev/
[edit] /dev/cdrom
/dev/cdrom is not an actual device, but on many systems it is a symbolic link to the actual CD device.
For example, a Linux system with /dev/hdb for its floppy drive is likely to have a link /dev/cdrom
which redirects to /dev/hdb.
[edit] /dev/fd*
At Linux, /dev/fd0 is the first floppy disk drive at the system. Use /dev/fd0H1440 to operate the first
floppy drive in high density mode. Generally, this is invoked when formatting a floppy drive for a
particular density. Slackware comes with drivers that allow for formatting a 3.5" diskette with up to
1.7MB of space. Red Hat and Mandrake do not contain these device driver files by default.
Likewise, /dev/fd1 is the second floppy disk drive.
[edit] /dev/hd*
At Linux, /dev/hda is the first IDE hard drive. The second drive is either /dev/hdb or /dev/hdc,
depending on the hardware configuration. Some IDE hardware allows up to four drives, including
/dev/hdd.
Many machines have one hard drive (hda) and one cdrom drive (hdc on many machines, but hdb on
some). Often, /dev/cdrom is a symbolic link to the cdrom drive.
Partitions are numbered from 1, like /dev/hda1, /dev/hda2, ...
[edit] /dev/null
/dev/null is a do-nothing device to use when one wants to ignore or delete program output. This file is
useful when a program expects to save to a file, but you want not to save anything. This file can also be
used as input to a program to represent an empty file.
There is no actual hardware associated with the /dev/null device.
Examples:
Deleting file called "x" (command rm x) sometimes causes an error, for example if the file does not
exist:
$ rm x
rm: x: No such file or directory
One can hide the error by redirecting it to a file. By using /dev/null as the file, the error never saves to
an actual file.
Bourne shell:
$ rm x > /dev/null 2>&1
In the Bourne shell, the "2>&1" redirects the standard error of "rm" (where the error appears) to
standard output, then the ">" redirects the standard output to /dev/null.
One way to make an empty file called "y" is:
$ cat /dev/null > y

The "cat" command copies the file "/dev/null" to standard output, and the shell operator ">" redirects
this output to "y". The "/dev/null" file seems empty when read, so the file "y" appears, but is also
empty. (Note that in this case, simply "> y" will do the same thing.)
[edit] Dot files
TODO
Move files for X11 from here to Guide to X11. The source of this information is Transwiki:Useful unix
command, not this book. --Kernigh 00:29, 22 December 2005 (UTC)
There is some redundancy across these programs. For example, the look and behavior of emacs can be
customized by usinng the .emacs file, but also by adding the appropriate modifications to the
.Xdefaults file. Default versions of these files are often installed in users' home directories when the
software packages that use them are installed. If a program doesn't find its configuration file in the
user's home directory, it will often fall back on a sytem-wide default configuration file installed in one
of the subdirectories that the package lives in.
.bash_logout - file executed by bash shell on logout

.bash_profile - initialization of bash shell run only on login. Bash looks first for a .bash_profile file
when started as a login shell or with the -login option. If it does not find .bash_profile, it looks for
.bash_login. If it doesn't find that, it looks for .profile. System-wide functions and aliases go in
/etc/bashrc and default environment variables go in /etc/profile.
.bashrc - initialization command run when bash shell starts up as a non-login shell
.cshrc - initialization commands that are run automatically (like autoexec.bat) when C shell is initiated
.emacs - configuration file for emacs editor
.fvwmrc - configuration file for fvwm window manager
.fvwm2rc - configuration file for fvwm2 window manager
.jedrc - configuration file for the jed text editor
.lessrc - typically contains key bindings for cursor movement with the less command
.login - initialization file when user logs in
.logout - commands run when user logs out
.wm_style - gives choice of default window manager if one is not specified in startx
.Xdefaults - sets up X resources for individual user. The behavior of many different application
programs can be changed by modifying this file.
.xinitrc - initialization file when running startx. Can be used to activate applications, run a given
window manager, and modify the appearance of the root window.
.xsession - configuration file for xdm
[edit] Directories
Different distributions have different directory structures, despite attempts at standardization such as
the the Linux Filesystem Hierarchy Standard (FHS) organization.
/bin - essential UNIX commands such as ls, etc. Should contain all binaries needed to boot the system
or run it in single-user mode
/boot - files used during booting and possibly the kernel itself are stored here
/dev - contains device files for various devices on system
/etc - files used by subsystems such as networking, NFS, and mail. Includes tables of disks to mount,
processes to run on startup, etc.
/etc/profile.d - contains scripts that are run by /etc/profile upon login.
/etc/rc.d - contains a number of shell scripts that are run on bootup at different run levels. There is also
typically an rc.inet1 script to set up networking (in Slackwar), an rc.modules script to load modular
device drivers, and an rc.local script that can be edited to run commands desired by the administrator,
along the lines of autoexec.bat in DOS.
/etc/rc.d/init.d - contains most of the initialization scripts themselves on an rpm-based system.
/etc/rc.d/rc*.d - where ``*'' is a number corresponding to the default run level. Contains files for
services to be started and stopped at that run level. On rpm-based systems, these files are symbolic
links to the initialization scripts themselves, which are in /etc/rc.d/init.d.
/etc/skel - directory containing several example or skeleton initialization shells. Often contains
subdirectories and files used to populate a new user's home directory.
/etc/X11 - configuration files for the X Window system
/home - home directories of individual users
/lib - standard shared library files
/lib/modules - modular device driver files, most with .o extensions
/mnt - typical mount point for many user-mountable devices such as floppy drives, cd-rom readers, etc.
Each device is mounted on a subdirectory of /mnt.
/proc - virtual file system that provides a number of system statistics
/root - home directory for root
/sbin - location of binaries used for system administration, configuration, and monitoring
/tmp - directory specifically designed for programs and users to store temporary files.
/usr - directory containing a number of subdirectory with programs, libraries, documentation, etc.
/usr/bin - contains most user commands. Should not contain binaries necessary for booting the system,
which go in /bin. The /bin directory is generally located on the same disk partition as /, which is
mounted in read-only mode during the boot process. Other filesystems are only mounted at a later stage
during startup, so putting binaries essential for boot here is not a good idea.
/usr/bin/X11 - most often a symbolic link to /usr/X11R6/bin, which contains executable binaries related
to the X Window system
/usr/doc - location of miscellaneous documentation, and the main location of program documentation
files under Slackware
/usr/include - standard location of include files used in C programs such as stdio.h
/usr/info - primary location of the GNU info system files
/usr/lib - standard library files such as libc.a. Searched by the linker when programs are compiled.
/usr/lib/X11 - X Window system distribution
/usr/local/bin - yet another place to look for comon executables
/usr/man - location of manual page files
/usr/sbin - other commands used by superuser for system administration
/usr/share - contains subdirectories where many installed programs have configuration, setup and
auxiliary files
/usr/share/doc - location of program documentation files under Mandrake and Red Hat
/usr/src - location of source programs used to build system. Source code for programs of all types are
often unpacked in this directory.
/usr/src/linux - often a symbolic link to a subdirectory whose name corresponds to the exact version of
the Linux kernel that is running. Contains the kernel sources.
/var - administrative files such as log files, used by various utilities
/var/log/packages - contains files, each of which has detailed information on an installed package in
Slackware. The same file can also be found at /var/adm/packages, since the adm subdirectory is a
symbolic link to log. Each package file contains a short description plus a list of all installed files.
/var/log/scripts - package installation scripts in Slackware are stored here. You can inspect these scripts
to see what special features are included in individual packages.
/var/spool - temporary storage for files being printed, mail that has not yet been picked up, etc.
UNIX/GNU FREE DOCUMENTATION LICENSE
Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.

51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Contents [hide]
1 0. PREAMBLE
2 1. APPLICABILITY AND DEFINITIONS
3 2. VERBATIM COPYING
4 3. COPYING IN QUANTITY
5 4. MODIFICATIONS
6 5. COMBINING DOCUMENTS
7 6. COLLECTIONS OF DOCUMENTS
8 7. AGGREGATION WITH INDEPENDENT WORKS
9 8. TRANSLATION
10 9. TERMINATION
11 10. FUTURE REVISIONS OF THIS LICENSE
[edit] 0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document
"free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with
or without modifying it, either commercially or noncommercially. Secondarily, this License preserves
for the author and publisher a way to get credit for their work, while not being considered responsible
for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must
themselves be free in the same sense. It complements the GNU General Public License, which is a
copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms that
the software does. But this License is not limited to software manuals; it can be used for any textual
work, regardless of subject matter or whether it is published as a printed book. We recommend this
License principally for works whose purpose is instruction or reference.
[edit] 1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the
copyright holder saying it can be distributed under the terms of this License. Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated
herein. The "Document", below, refers to any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in
a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it,
either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals
exclusively with the relationship of the publishers or authors of the Document to the Document's
overall subject (or to related matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of historical connection with the subject
or with related matters, or of legal, commercial, philosophical, ethical or political position regarding
them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under this License. If a section
does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The
Document may contain zero Invariant Sections. If the Document does not identify any Invariant
Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may
be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose
specification is available to the general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of pixels) generic paint programs
or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters
or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in
an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent. An image format is not
Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called
"Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo
input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-
conforming simple HTML, PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats
that can be read and edited only by proprietary word processors, SGML or XML for which the DTD
and/or processing tools are not generally available, and the machine-generated HTML, PostScript or
PDF produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are
needed to hold, legibly, the material this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means the text near the most prominent
appearance of the work's title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ
or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ
stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications",
"Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the
Document means that it remains a section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License
applies to the Document. These Warranty Disclaimers are considered to be included by reference in this
License, but only as regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.
[edit] 2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially,
provided that this License, the copyright notices, and the license notice saying this License applies to
the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of
this License. You may not use technical measures to obstruct or control the reading or further copying
of the copies you make or distribute. However, you may accept compensation in exchange for copies.
If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display
copies.
[edit] 3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document,
numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front
cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you
as the publisher of these copies. The front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the covers in addition. Copying with
changes limited to the covers, as long as they preserve the title of the Document and satisfy these
conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones
listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
include a machine-readable Transparent copy along with each Opaque copy, or state in or with each
Opaque copy a computer-network location from which the general network-using public has access to
download using public-standard network protocols a complete Transparent copy of the Document, free
of added material. If you use the latter option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least one year after the last time you distribute an Opaque copy
(directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing
any large number of copies, to give them a chance to provide you with an updated version of the
Document.
[edit] 4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2
and 3 above, provided that you release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must do these things in the
Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from
those of previous versions (which should, if there were any, be listed in the History section of the
Document). You may use the same title as a previous version if the original publisher of that version
gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the
modifications in the Modified Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five), unless they release you from this
requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use
the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in
the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no
section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of
the Document as given on its Title Page, then add an item describing the Modified Version as stated in
the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy
of the Document, and likewise the network locations given in the Document for previous versions it
was based on. These may be placed in the "History" section. You may omit a network location for a
work that was published at least four years before the Document itself, or if the original publisher of
the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section,
and preserve in the section all the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section
numbers or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified
Version.
N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any
Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some or
all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your
Modified Version by various parties--for example, statements of peer review or that the text has been
approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a
Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by)
any one entity. If the Document already includes a cover text for the same cover, previously added by
you or by arrangement made by the same entity you are acting on behalf of, you may not add another;
but you may replace the old one, on explicit permission from the previous publisher that added the old
one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version.
[edit] 5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms
defined in section 4 above for modified versions, provided that you include in the combination all of
the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve all their Warranty
Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant
Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same
name but different contents, make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if known, or else a unique
number. Make the same adjustment to the section titles in the list of Invariant Sections in the license
notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original
documents, forming one section Entitled "History"; likewise combine any sections Entitled
"Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled
"Endorsements."
[edit] 6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this
License, and replace the individual copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the rules of this License for verbatim
copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this
License, provided you insert a copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that document.
[edit] 7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or
works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights of the compilation's users beyond
what the individual works permit. When the Document is included in an aggregate, this License does
not apply to the other works in the aggregate which are not themselves derivative works of the
Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the
Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the
Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole
aggregate.
[edit] 8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document
under the terms of section 4. Replacing Invariant Sections with translations requires special permission
from their copyright holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include a translation of this
License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you
also include the original English version of this License and the original versions of those notices and
disclaimers. In case of a disagreement between the translation and the original version of this License
or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the

requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
[edit] 9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for
under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void,
and will automatically terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses terminated so long as such
parties remain in full compliance.
[edit] 10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation
License from time to time. Such new versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a
particular numbered version of this License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not as a draft) by the Free
Software Foundation.
UNIX COMPUTING SECURITY

The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground
in a secret location... and I'm not even too sure about that one.
—Dennis Hughes, FBI
UNIX is a computer operating system that was first developed during the 1960s and 1970s at AT&T
Bell Labs. It was originally conceived as an academic operating system, particularly at the university
level, and hence security was not a top priority of the design. Since then, however, UNIX computing
systems have been made more widely available and have become an essential part of networking and
internet infrastructure. The increased level of access and the need for data security have driven
improvements to UNIX security features. The evolution of UNIX security features continues to this
day, with an increasingly urgent need for preventing inappropriate access to systems and their data.
This book is intended for an audience that has at least a basic familiarity with the UNIX operating
system, including common shell commands, the directory structure, and file manipulation. The primary
focus will be for the System Administrator of a UNIX system. That is the operator who is responsible
for configuring and maintaining a functioning system, as well as troubleshooting system failures,
controlling user access to the system, and so forth.
As there are multiple variations of the UNIX operating system made available by various computing
vendors, not to mention related operating systems such as Linux, this book will cover topics common
to most of the UNIX releases. Features specific to a particular vendor's release will be noted
accordingly.
UNIX COMPUTING
SECURITY/PRINCIPLES AND POLICIES
Computing security as it applies to UNIX is usually taken to mean protection of a UNIX-based

computing system against unauthorized access to information or services on that system, including
viewing, copying, modifying or destroying data.
But security can also apply to unauthorized attempts to deny appropriate individuals access to the
stored information through loss of availability. Security is also used to manage privacy on a system,
whether by confirming the identity of a person who performed an action, and by allowing individuals
to maintain control of private information.
Providing security to a system is not a goal so much as it is an ongoing process. At least at present, a
UNIX computing system can never be made fully secure. However by continually applying a series of
security measures to the systems, the net risk to the system can be brought to a minimum.
Contents [hide]
1 Legal issues
1.1 Sarbanes-Oxley
2 System management
3 User education
[edit] Legal issues

A necessary element of system security is the legal system. The threat of prosecution is an important
element in deterring an unlawful intrusion or activity, particularly in the circumstance where the system
is serving as a component of a company business or when the loss of important information can have
significant consequences. It is not even necessary for a system to be compromised in order to have
business consequences. A business service can be rendered inoperative for a period of time, costing a
firm a significant source of income.
To allow successful prosecution of unlawful activities against a computer system, forensic evidence
must be available to demonstrate that a crime occured. This necessitates the use of logging to track
activities and events on the system, and the protection of these logs against tampering. This also
includes the need to make periodic backup copies of files on the system on secure media, as frequently
as once per day if feasible. In the event of a direct compromise through the hardware, unmodified
physical evidence may also be needed, including camera records, witnesses, and so forth.
It can be important during the prosecution to demonstrate that you were performing on-going active
measures to prevent inappropriate access, rather than just initiating monitoring in the particular
circumstance. So logging and auditing need to be part of the standard security measures. In addition, a
carefully-worded legal warning notice needs to be presented prior to login so that the potential intruder
can not claim ignorance. Even a greeting message presented prior to login can be used as a legal
defense. Finally, due diligence in securing your system can help demonstrate that an inappropriate
intrusion was willful and dedicated, rather than as a result of curiosity.
[edit] Sarbanes-Oxley
The Sarbanes-Oxley Act of 2002 was a significant piece of legislation designed to help prevent
corporate financial fraud. Although computing security was not a factor in the events that resulted in
this act, the legislation has had an indirect impact on security requirements. The law imposes
accounting requirements and control practices on U.S. companies, or at least those that are publically
owned. Requirements for accurate financial records have been strengthened, resulting in the need for
control of all aspects of how financial information is processed.
Computing security became relevant due to a provision in Sarbanes-Oxley requiring disclosure of

potential liabilities that might impact the bottom line. Events that resulted in the compromise of key
computing systems can have a significant impact on the company business. Three of the most relevant
sections of Sarbanes-Oxley for computing security are:
Section 302 — Certification of the completeness and accuracy of financial reports by the CEO and
CFO.
Section 404 — Management assessment of internal controls, which must be reported to the SEC each
year.
Section 409 — Real time disclosure of information.
Due to these requirements, attention to computing security has became an important factor. The act
requires companies to disclose when their financial information has been tampered with, describe the
measures used to protect the data, and safeguard the information used to track the information security.
Companies that are required to disclose that they have poor security practices could prove an uninviting
investment, which can affect their stock value. This has brought an increased, and in some cases much-
needed attention to computing security in many commercial companies.
[edit] System management

Applying security measures is a constant trade-off between maintaining the usefulness of a system and
keeping it secure. Each new security measure will further restrict activities on a system, and is likely to
be met with resistance by the users. So the system operators must weigh the risks of data loss versus
less utility, and decide whether the extra measures are worth the trade-off.
The Administrator of a UNIX system has a significant ability to reduce security risks by properly
configuring the operating system to enable security features. In many instances the operating system as
shipped by a vendor is applied with a weak security configuration. It requires careful examination of
the system to control or eliminate these weaknesses, and neglecting to apply an appropriate restriction
can leave a system vulnerable to exploitation.
Once a system has been properly secured, it will still require steady maintenance and monitoring to
keep it that way. New exploitations are constantly being discovered, and the administrator will need to
stay on top of remedies for newly discovered vulnerabilities. Doing so may require periodic application
of new patches, additional changes to the system configuration, or simply an assessment of the risk and
determining a means to manage it.
[edit] User education

Unfortunately, individual actions by users on a UNIX system can result in a net increase in the security
risk. So, in addition to monitoring potentially harmful actions by users, some education of the users is
needed. This education includes raising security awareness, training users against certain types of
harmful actions, and demonstrating useful tools that can enhance the security of their data.
Determining whether an individual is authorized to have access to the information is an essential

component of UNIX system security, and requires access control policies, secure methods of verifying
identity, and methods of storing and transmitting credentials. The identity of the individual is used to
determine the information they can access, and their ability to modify information on the system.
Retrieved from "http://en.wikibooks.org/wiki/UNIX_Computing_Security/Principles_and_policies"

UNIX COMPUTINGSECURITY/ACCESS
AUTHORIZATION
Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six
months.
—Clifford Stoll
In order to connect to a UNIX-based system and perform activities, a user must have an account. This
account must have a unique numerical identifier, which is associated with the account name, or
username. The account also has a password, which is string known to the user by which the account
access is authenticated when accessing the system. The username and password are normally sufficient
to connect a user to the system.
Users can have multiple accounts on the same system, or accounts on different systems. Each account
can use a different name, if they are on the same system, or share a common name across multiple
systems. Depending on the person or institution operating the systems, the individual users may be able
to choose their account names, or they may be assigned a name. Typically an assigned name will be
based on the person's actual name, and will be a unique identifier on the system.
Contents [hide]
1 Login
1.1 /etc/passwd
1.2 Selecting a password
1.3 Unauthorized login attempts
2 Groups
2.1 /etc/group
3 Identifiers
3.1 Default accounts
4 Shadow password file
5 Account management
[edit] Login
The username is also the login name, which means that it is the name that the user types on the
keyboard when prompted for a login. On UNIX systems it is a requirement that the first character of
the username be an alphabetical character. The case of the character matters: "Joe1234" is a different
login name than "joe1234". In most cases the account begins with a lower case character by
convention. The remainder of the login name can consist of numbers, alphabetical characters, or an
underscore. Thus an asterisk or colon character is invalid for a login name. Accounts with these special
characters can cause problems with certain system functions, such as delivering electronic mail. So
these characters are usually prohibited on many UNIX systems.
UNIX systems are typically delivered with a set of system accounts for performing special operations.
These may include such accounts as root, bin, sys, lp, or uucp. The root account has special capabilities
that grant the user enhanced privileges, and so precautions are usually enforced to prevent its
acquisition by unauthorized individuals. More on this later.
[edit] /etc/passwd
The information for UNIX accounts is stored in a text file located at /etc/passwd. This file contains
information for one account per line, and each line is subdivided into fields that are separated by
colons. The meaning of the fields is as follows:
login name Text name of the account

password The one-way hash encrypted password
user ID A unique numerical identifier for the account
group ID The default group identifier for the account
GECOS ID A comma-separated list of user information
home directory The users' initial working directory
shell The program to use for a shell interface
When a user gains an account, they are provided with a default password so that they can login. When
they connect to the system they will be prompted for the login name, followed by a prompt for the
password. If the system is configured correctly, the user can then enter their provided password and it
will not appear on the display when it is typed. (Some systems will print an asterisk for each password
character, while others will not show anything.) If the password is valid, the user will be allowed access
to the system. (They may be prompted to immediately change their password to something only they
know.)
The system stores the password in the /etc/passwd file in an encrypted form. UNIX uses an encryption
technique called a one-way hash. This means that the password is encrypted using a technique that that
does not have a known decryption method. That is, there is no efficient means to determine the
password based on the encryption string.
Each time the user logs on, their input password is encrypted and compared to the encryption in the
/etc/passwd file. If the two match then the user is allowed access. If the two do not match then access is
refuse and the user is prompted again to login. (Each connection allows multiple attempts in case the
user accidently types the login name or password incorrectly.) Note that the password is also case
sensitive, so accidently forgetting to turn off the caps-lock key may result in access denial.
If there is a format error in the /etc/passwd file, the system commands are unable to read entries further
down in the file. If a user is unable to log on to a system, this could be the reason why. (This is why it
is important for the root account to always be the first entry, so that the System Administrator can log
in and correct issues with the passwd file.) UNIX systems can include a command called pwck that can
be run to check for format problems with the passwd file. It is a good idea to run this from time to time
to make sure potential problems haven't been introduced.
When editing the /etc/passwd file, the vipw command uses a locking mechanism to prevent another
administrator from editing the same file at the same time. (Simultaneous edits can result in changes
from one operator overwriting changes from another operator, an unfortunate situation where file
locking is not available on multi-user systems.) It is a good habit for all System Administrators to use
the vipw command, assuming they are versed in the use of vi.
[edit] Selecting a password

Once a user is logged on to a system, they can change their password by means of the passwd
command. The user will then be prompted for their current password, then they will be prompted twice
for the new password selection. (The redundant prompt is to make sure that the user didn't accidently
mistype the new password the first time.) After the new password is accepted, the encrypted password
field will be updated in the user's account entry in the /etc/passwd file.
The password is a key element of the system's security that is used to verify a user's identity. For this
reason it is vital that the password be selected so that it is difficult to guess. Simple, easily-guessable
passwords have frequently been the cause of unauthorized access, and there exist programs that can
attempt to gain access to a system through trial and error of commonly selected passwords.
Here are some exmples of typical passwords that can make it relatively easy to guess:
The person's name
The name of their child
A birthday
Simple words such as "guess" or "password"
A place name
The person's phone number
Common keyboard patterns such as "qwerty"
The name of the computer
A word spelled backwards
The same as one of the above followed by a single digit
Modern UNIX systems have security configurations that provide some measure of strength checking
when a password is set or changed. For example, a password may be required to be at least eight
characters in length, and include one or more upper-case and lower-case letters, a number, and a special
character (such as *, $, #, %, &c.) These measures can make a password much more difficult to
determine. Wherever possible it is advisable to implement such features to ensure the selection of
strong passwords.
When a user has an account on multiple systems, they may choose to use the same password on each of
the systems in order to make it easier to remember. Unfortunately this means that if the password on
one system is determined by another person, they may be able to gain unauthorized access to the other
systems as well. This possibility is difficult for the System Administrator to guard against, except by
educating the user and discouraging the use of passwords on multiple systems.
[edit] Unauthorized login attempts

Unfortunately there are individuals who may attempt to gain unauthorized access to a system by trying
to use another individual's account. They may resort to surreptitious means to obtain the proper login
from a user, such as observing them at the keyboard during login, using social engineering to trick an
operator or user into giving them access, or by setting up a spoofing program that mimics normal login.
Another method used to obtain unauthorized access is to attempt to guess the login and password.
Normally the login is printed on the screen during access, so the individual may already know the
account name. However the password should be kept concealed on the screen. If a weak password has
been selected by the user, however, it may still be possible to guess the password.
To make the task of guessing a password difficult, most UNIX systems have limits built into the login
system. The first limit puts a time delay in between each failed login attempt, so that it takes much
longer to attempt each guess. Another limit is to restrict the number of login attempts before
disconnecting the session. In addition, the failed login attempts can be recorded in log files, such as
btmp. The log files can be periodically checked by the System Administrator to check for unusual
failed login activities (such as hundreds of attempts in a day).
[edit] Groups
In addition to the account identifiers, UNIX can qualify access to system resources on the basis of
group membership. Each group can contain multiple accounts, and an account can belong to one or
more groups. An account will have a default group to which they belong, such as users, and this
information is stored in the /etc/passwd file.
The newgrp command is used to switch your group without changing your account. As long as the
group exists and your account belongs to the group, you will be changed to the selected group name.
You would now have access privileges appropriate for that group.
The group is used to manage information or resources that are shared by multiple people. It is normally
used to obviate the need for shared accounts, which is considered bad security practice. Wherever
possible the System Administrator should require the use of a group for providing access to shared
resources, and avoid the use of a shared account. There are two reasons for this. The first is that it is
nearly impossible to track or audit the activities of an individual who is a member of a shared account.
The second is that it is much more difficult to terminate access by a specific individual to a shared
account.
[edit] /etc/group
The information for UNIX groups is stored in a text file located at /etc/group. This file contains
information for one group per line, and each line is subdivided into fields that are separated by colons.
The meaning of the fields is as follows:
group name Text name of the group

password The one-way hash encrypted password
group ID The default group identifier for the account
members A comma-separated list of group names
To belong to additional groups beyond the default, an account must be added to the appropriate
members list. Here is a brief example of an /etc/group file:
root::0:root
other::1:root
bin::2:bin
users::20:
secrets::30:billy_bob,sally_sue,frederick
Each line in the file describes a group. In this example, the accounts billy_bob, sally_sue, and frederick
are all members of the group secrets, even though their default group is users. Note that if a group has a
password, a user can use the password to change to that group even if he or she is not a member.
As with the pwck command for the /etc/passwd file, there is usually a grpck command available that
can be used to check the format of the /etc/group file. It is good practice to use this command to check
that format errors have not been introduced.
[edit] Identifiers
UNIX uses integer values to track and store access information. The user identifier, or uid, is an
identifier that corresponds to a user's account on a UNIX system. This identifier is used internally by
the system to determine ownership of potentially sensitive data and processes. When the system needs
to list the owner of a data file or process, it normally maps the identifier back to the account name in
the /etc/passwd file before presenting the information.
The value of the uid can typically range from 0 up to one less than the maximum integer supported on
the system. (Negative identifiers, particularly -2, are for special purpose use only.)
User identifiers are usually assigned beginning with 100, and each new account is added by assigning a
previously unused identifier. When an account is deleted for some reason, the account entry is removed
from the /etc/passwd file. However this may result in files created by that account having an
unassigned uid. A new account created subsequently may be assigned the previous uid, making that
new user the owner of the files created by the previous account. In order to prevent this eventuality, the
System Administrator needs to perform periodic maintenance to locate files that lack a valid account.
[edit] Default accounts

During the initial installation of a system, the vendor media can load selected default accounts. These
accounts are generally used for system administration and maintenance. By convention the user
identifiers 0 through 99 are nearly always reserved for these accounts, such as root, daemon, bin, sys,
and so forth. In many instances, most of these accounts have their passwords disabled, and the uid is
used for system files or processes.
The root account in particular, which has a uid of zero (0), is a special account that has higher
privileges than any user. It is often referred to as the superuser account. Special precautions need to be
taken to prevent inappropriate individuals from gaining access to this account, and much of the
security-related configuration of a UNIX system is intended to prevent this eventuality.
In certain environments it may be necessary for certain administrative capabilities to be shared among
more than one operator. The drawback to this, of course, is that becomes more difficult to maintain a
secure system when multiple people have superuser access. It can also make it more difficult to
perform a root-cause analysis when something on a system breaks.
There are several methods to help reduce the risk of a shared superuser access, although it can never be
reduced to zero. The first is to configure a system so that the root account can not be accessed directly.
Instead the operator must log on using their user account, then su (switch-user) to the superuser
account. This can provide an audit trail of when the superuser account was accessed and by whom. It
also helps to insulate the system from attempts to break into the superuser account directly. Instead a
user account must first be compromised, and then the superuser account.
A more sophisticated approach to limiting the superuser account access requirement is through the use
of role-based access control. This allows designated user accounts to perform a limited set of actions
that are normally restricted to the root account. (An example of this would be a trusted user account
that is allowed to make revisions to a server's printer configuration.) There are a number of tools
available, both in open source and from vendors, that can be used to provide role-based access control
capabilities. This topic will be covered in more detail in later chapters.
[edit] Shadow password file

While a user's password is stored as an encrypted string on UNIX systems, anybody who can read the
encrypted value may be able to use a program to test various commonly-used passwords and see if they
match. That is, the program can try a series of guesses and encrypt them to see if they match the value
in the user's password field. The program can also use a dictionary of words and encrypt each one and
compare them in turn to each encrypted password on a system.
To make this task somewhat more difficult for a password guessing program, the encrypted password
includes a random, two-character "salt". This random salt value will most likely result in a different
encryption string value even when the passwords for two accounts match. As a result the program must
recompute the encryption string for each guess and for every account. Nonetheless a modern UNIX
system can still crunch through a large number of guesses in a relatively short amount of time, making
a brute-force attack quite feasible on a system where a password consists of a simple word.
When the password is formed using a rule, such as two words separated by a number, the task becomes
slightly more difficult. However a wily individual may have considerable computing resources at his or
her disposal, so guessing a weak password may just be a matter of time. (An example of such a
program is called crack, which can be used by the System Administrator to periodically check their
user's passwords for guessable values.)
In order to forestall this technique, the encrypted passwords can be stored in a separate file, commonly
known as the shadow password file. The contents of the shadow password file can only be read by the
root account, and the password field of the /etc/passwd file is replaced by an asterisk. The
implementation of this feature will vary depending on the UNIX vendor. The shadow password is
located at /etc/shadow on Sun systems and under /tcb on HP-UX systems. With the encrypted password
"shadowed" in this manner, the task of guessing a password is rendered much more difficult.
[edit] Account management

Under construction...
Paperwork & records

Modifying passwords
Password aging
Disabling accounts
UNIX COMPUTING SECURITY/UNIX FILESYSTEM
Most of the data used by a computer is stored on disk drives. These are physical devices with a relative
high access latency, compared to, say, physical memory, but large storage capacity. On a server system
a disk drive can be located inside the same cabinet as the CPU, an adjacent expansion cabinet, attached
to the network as an appliance, or attached as part of a Storage Area Network. Some sites may also
employ removeable disk media that can be loaded by an operator or a robotic device.
Contents [hide]
1 Filesystem and files
2 File permissions
2.1 Set ID on execute
2.2 Directory permissions
2.3 Setting file permissions
2.4 Searching for file permissions
2.5 umask
[edit] Filesystem and files

The filesystem is the method by which data on a device, such as a disk drive, is laid out. It includes
information that the operating system can use to find specific data content and who is allowed to access
that data. All of this data is organized into a series of files, which are an essential means of managing
information on a computer system. The data in a file is organized in a format that applications can
understand. The location of a file on a directory tree is called its path.
In UNIX, as on many other modern operating systems, files are stored in a tree structure with the
branch nodes being called directories. A directory is a special type of file that can reference zero or
more other files and directories, allowing the data to be organized and access managed. Directory trees
are contained in one or more filesystems.
In UNIX the filesystem contains the following information available for each file:
Unique inode number

The length of the file in bytes
The identifier of the device that contains the file
File type
A set of permissions bits, or mode
Identifier of the file's owner, or uid
Identifier of the file's group, or gid
File creation date and time
File last access date and time
File last modification date and time
The total number of hard links to the inode
The typical UNIX file types are as follows:
Block file
Raw file
Regular file
Directory
Named pipe
Symbolic link
Socket
A hard link is a type of file that references another file on the same device and file system by means of
its inode number. A symbolic link is a type of file that contains the path information to another file.
[edit] File permissions

Information about a file's statistics can be viewed by means of the ls command in combination with the
-l "long listing" option. Here is an example:
$ ls -l /usr/bin/vi
-r-xr-xr-t 6 bin bin 604880 Sep 3 2003 /usr/bin/vi
The left-most field of the ls output displays the mode of a file. This is an integer field that is normally 2
bytes (16 bits) in length. Each bit within the mode is a binary flag that represents a type of security
access setting.
The number to the right of the mode shows the total number of hard links to the file, including the
original file. So this case the command has five other hard links. Next are the names of the file owner
and group, followed by the file size in bytes, the date or time of the last modification, and the file name
or path.
The ls displays the mode information as a field of ten characters. The first (left-most) character shows
the type of the file. The common types are as follows:
- — Ordinary file
b — Block special file
c — Character special file
d — Directory
D — Door (Solaris)
l — Symbolic link
n — Network special file (HP-UX)
p — Named pipe
s — Socket
The remaining nine characters consist of three groups of three characters each. Each of these groups
describe a set of file permissions that determine whether a file can be read, write, and executed as a
program. (They can also cover certain special execution modes. More on that in a moment.)
These permissions are indicated by an r, w and x, respectively. Thus an rwx in the group set indicates
that any member of the file group can read, modify, or run the file as a program (or script). The r-x
above is missing the write flag, so members of the group would not necessarily be able to modify the
file.
From left to right, the first set of three characters indicates the permission settings for the owner of the
file. The middle set are the permission settings for the file group, and the last set to the right are the
permissions for every body else (usually referred to as "world".)
[edit] Set ID on execute

The mode can also contain special flags that set the permissions of a file when it is executed. That is, if
a file is a program or a script, the set permissions bits will determine the owner or group under which it
will run. Normally when a job is run, it uses the user and group of the account that executes the file.
This controls the type of access that the job gains.
For example, suppose a command myjob has permissions r-xr-x--- and is run by the file owner, user
bill in group research. The process that executes the myjob command is given the owner bill and group
research. The job can access any file that can also be accessed from the account bill.
Now suppose the myjob file is given owner root, and the set permissions bit for the user are activated
by the System Administrator. The resulting file has permission bits r-sr-x---, where the s indicates that
the set user ID on execution flag has been set. Because the file still belongs to group research, the user
bill is able to run it. When the job is run now, however, it has access to any file that can be accessed by
root (which is usually any file on the system.)
A similar effect occurs when the set group ID on execution flag has been set. The resulting file
permission bits may now appear as r-xr-s---. When this file is executed, the job runs as though the user
belonged to the same group as the file's group identifier. That is, if the group identifier were set to sys,
when the file was executed it would have access to any file that can be accessed by the group sys.
It is important to point out at this point that the set ID feature can potentially compromise the security
of a system. A file that is owned by root that has the set user ID flag has the same access privileges as
the System Administrator. If this file can also be modified by any user, say, then it can be exploited to
elevate that user's privileges, or perform other unauthorized activities. Even if the file can not be
modified by a user, it may still contain vulnerabilities that can be exploited to gain unauthorized
privileges.
For this reason the existance of files with set user ID or set group ID permissions should be carefully
monitored by the System Administrator. Selected system commands require these mode settings in
order to function properly. However any other files with these settings, particularly when they can be
modified by a user, can represent an unacceptible level of risk to a system. Batch jobs can be run at
regular intervals to search for the existence of these files and to bring them to the attention of the
System Administrator.
Note: On Linux, when a shell script is executed, all setuid and setgid permissions are ignored
intentionally by system.
[edit] Directory permissions

The permissions on a directory have a somewhat different meaning than they do for files. The read
permissions on a directory allow the ls command, with no arguments to list the contents of that
directory. However the read mode only allows the file name to be read, not the file permissions, owner,
or size. You also can not change directory with the cd command to a directory where you only have
read permissions, nor read the content of files in that directory.
If a directory allows you x, or execute permissions, you can cd to that directory and read the contents
of any files in that directory for which you have read privileges. You can also do a "long list" of the
directory using the ls -l command. If a directory allows you execute but not read permissions, you get
an error if you tried to use ls to list the directory. However, if you knew that a particular file existed in
that directory and if that file allowed you read privileges, you could do a "long list" of that file.
As a simple example:
$ id
uid=234(myacct) gid=100(mygrp)
$ mkdir test
$ touch test/test.txt
$ chmod 100 test
$ chmod 640 test/test.txt
$ cd test
$ ls
. unreadable
total 0
$ ls -l test.txt
-rw-r----- 1 myacct mygrp 0 Dec 9 12:00 test.txt
See the appropriate manual pages for further information on these commands.
set user ID or set group ID permissions

sticky bit.
under construction...
[edit] Setting file permissions

The permissions for a file can be set using the chown, chgrp, and chmod commands. The chown is
given a valid account name or numerical identifier, and is used to set the owner of a file or set of files.
Likewise chgrp can be used to set the group for a file. (On some operating systems, the chown can be
used to set both the owner and group of a file. Finally chmod can set the file mode.
Here is an example of a combined chown command that sets the file owner to root and the group to
sys:
$ chown root:sys /usr/local/bin/bigjob

Permission Value
Execute (x) 1
Write (w) 2
Read (r) 4
The original format for the chmod command allows the entire mode to be set for a file or set of files.
This is done by passing the command a three or four digit number that defines the mode settings. Each
of the last three digits in the number represents one of the sets of permission flags, as discussed above.
A one (1) enables the execute mode, a two (2) sets the write mode, and a four (4) sets the read mode.
Any combination of these modes can be set by adding up the appropriate values.
For example:
$ chmod 550 /usr/local/bin/bigjob

has a 5 for the user permissions, a 5 for the group permissions, and a 0 for the world permissions. A 5 is
equal to a 1 plus 4, so this is enabling the read (4) and execute (1) flags for both the user and group.
The world gets no privileges for this file.
More recently the chmod command has been enhanced to allow a comma-separated list of symbolic
operations. This allows a more refined approach to modifying the mode of a file. A symbolic operation
determines who it affects, the type of operation, and the affected permissions. For example:
$ chmod u+x,g-w,o=r /usr/local/bin/bigjob

Here the u, g, and o represent the user, group, and other (world) permissions, respectively. The +, -, and
= modify the permissions by adding, deleting, or setting the bits specified by the r (red), w (write), or x
(execute) mode bits. This example gives the user execute permissions, removed write permissions for
the file's group, and limits other (world) to read operations only.
The chown, chgrp and chmod commands normally have a recursive option that acts upon a directory
and all files under that directory tree. This option is typically activated with the -R, but see the manual
pages for your particular operating system. When combined with the symbolic operations of the chmod
command, this can provide a powerful tool for managing permissions on a directory. For example:
$ chmod -R o-w /usr/bin

will recursively remove any world permission bits on the /usr/bin directory, or any files or directories
under that directory tree.
[edit] Searching for file permissions

The find can be a powerful tool for searching the file systems for files or directories with particular
permission settings, as well as certain file owners and groups. In the example below (which was written
for HP-UX) the find command is being used to search the /usr/bin directory tree for any files that allow
world write permissions.
$ /usr/bin/find /usr/bin -type f -perm -002 -exec ls -l {} \;

The parameters passed to the find command form an expression that determines what the command is
seeking in the directory tree /usr/bin. The arguements -type f restricts the search to files, instead of, say,
directories, symbolic links, device files, and so forth. The -perm -002 sets the type of permissions to
find; the minus before the number means to only match on the values that are set in the number. In this
case the two in the third digit matches the world write bit. Finally the fancy -exec ls -al {} \; causes the
command ls -l to be executed on any file that met the prior conditions. (The odd \; clause at the end is a
terminator of the command.) Some variant of find has the -ls option which can replace -exec ls -al {} \;.
The example below shows a search of the /home directory tree for any files with an owner that is not in
the password database.
$ /usr/bin/find /home -nouser -exec ls -l {} \;
If any accounts have been removed from the password database, a command such as this can be used to
search for orphaned files.
Note that whenever the System Administrator is performing a lengthy search of the file system, it can
be considerate of the users to run the find at a lower priority using the nice command. Otherwise the
job may impact disc access performance. Also some care needs to be exercised to avoid searches of
network-mounted directory trees as this can significantly slow the search time; this can be achieved
with the help of -xdev option which limits find to search local file system only.
[edit] umask
Each UNIX session has a file mode creation mask that defines the initial value of the permission bits
when a new file is created. This mask consists of a series of bit flags that determine whether a
particular permissions setting will be turned on or off. This value is similar to the number that is passed
to the chmod command, except that the values are used in the negative sense. That is, when a value is
set in the mask the corresponding permission bit will be turned off when a file is created.
The command umask can be used to display the mask for the current session.
$ umask
027
$ touch testfile.txt
$ ls -al testfile.txt
-rw-r----- 1 bilbo users 0 Jan 18 07:41 testfile.txt
In this example, the first zero affects the owner's permissions on the file. A zero means that all of the
permission bits will be set, so the file owner can have read, write, and execute permissions on that file.
(Note that in the example above, the system creates a file with the execute permissions turned off,
regardless of the setting of the umask.) The middle number two affects the permissions for the file
group. A '2' will turn off the write permission bit, so members of the group will only be able to read or
execute the file. Finally the seven in the last digit will turn off all permissions for world.
To change the mask for the session, the umask command can be executed with the new mask passed as
a parameter.
$ umask 077
$ umask
077
$ touch testfile2.txt
$ ls -al testfile2.txt
-rw------- 1 bilbo users 0 Jan 18 07:47 testfile.txt
A umask setting of 077 is recommended for optimal security. The user will then need to manually
modify the permissions on a file or directory in order to make it available to others. Conversely, a
umask setting of 000 results in the weakest security setting, as anybody on the system can have access
to the file unless the user remembers to restrict the permissions. In order to apply a base umask setting,
the System Administrator can include a umask command in the shell startup files such as /etc/profile.
Retrieved from "http://en.wikibooks.org/wiki/UNIX_Computing_Security/UNIX_filesystem"

Category: UNIX
UNIX COMPUTING SECURITY/SECURING

ACCOUNTS
The users of a Unix system are most likely not nearly as knowledgeable about the security aspects of
their system as are the System Administrators. So it is important to use the configuration capabilities of
the system to configure these accounts so that they are reasonably secure. Such configuration can be
applied to the default user security settings, the environments in which programs will be run, and so
forth. There may also be special restrictions needed for certain accounts depending on access and data
security requirements on the server.
Once an account is in use, the System Administrator will still need to employ a certain level of
vigilence to make certain the access is not abused, or even coopted by an inappropriate person.
Passwords need to be checked for strength and periodically updated. Unused or unneeded accounts
need to be disabled so that they are not employed for inappropriate purposes.
Contents [hide]
1 Home directory
1.1 Missing home directories
2 Shell environment
2.1 Session timeout
2.2 PATH
3 Dot files
3.1 .forward
3.1.1 ForwardPath
3.2 .netrc
3.3 .rhosts
[edit] Home directory

When an account is first created, it is normally given a separate home directory. This is a directory,
usually under the /home or possibly the /user directory tree where the user can store their data files and
where custom startup and configuration files are located. (These can include .profile, .login, .cshrc, and
so forth.)
The home directory should be protected in such a manner that the user owns it and the group identifier
of the directory matches the account's default group. In addition the home directory is normally given
permissions that restrict access by other users. Permission modes of 750 or 700 are common.
Many System Administrators provide a default set of startup, or "dot" files that are copied into the new
home directory. These can provide, for example, useful aliases and site-specific operations. However
these default files need to be properly secured or else they may be tampered with and any new accounts
quickly compromised.
[edit] Missing home directories

In cases where the home directory does not exist for a particular user account, the default action on
many Unix systems is to start the login session at the top-level, or slash (/) directory. This is also the
default directory for the root (super-user) account. So this can potentially lead to permissions problems
with the startup configuration files, and other unexpected behavior.
As a remedy for this case, the home directory for the root account can be located under its own
directory tree. (For example, /root). Normally this directory should be placed on the same file system
as slash so that the directory is always present when the system is booted. Having a private directory
for root also provides a somewhat more secure location for any tools and scripts the System
Administrator might want to run.
Once a private root home directory is implemented, the System Administrator can then modify the
"dot" files under the slash directory and use them to provide a default set of startup files for their users.
Note that having a user log in using a home directory of slash is generally not a good idea, and it is
often indicative of a problem with the system. Some versions of Unix provide a means of disabling
user logins whenever their home directory is not found.
[edit] Shell environment
Many of the shells available for use on Unix systems allow environmental variables to be configured.
Some of these variables can have security implications, and a few can be configured to enhance the
system security.
[edit] Session timeout

When a Unix session is left unattended for a period of time, it only takes a few moments for an
unscrupulous individual to take advantage of the situation to increase their own access privileges. For
example, suppose that a System Administrator has walked away from their desk for a minute and a
person types in a few commands at the shell prompt:
root$ touch /tmp/rubbish

root$ chmod 4777 /tmp/rubbish
root$ exit
This creates a world-editable file that can be modified to run commands that can grant root privileges
to anybody executing it. That individual now owns the system. It is for situations like this that it is
important for unattended sessions to either be locked down or disconnected.
Certain shell types, including the Korn Shell, Bash, and some vendor versions of the Bourne Shell, will
support a time out variable, either TMOUT or TIMEOUT. When this variable is set it gives the number
of seconds of no activity before the shell expires. (A value of zero means no timeout.) This variable can
be used to expire shells when a user or system administrator is drawn away from active login session
for a period of time. Typically this variable would be set to some value, such as 300 (or 5 minutes), that
will limit the period of vulnerability. It is normally set in a global shell startup file such as /etc/profile
or /etc/csh.login.
[edit] PATH
Unix shell sessions use an environment variable called PATH to determine the location of commands
and other programs that can be executed from the shell command line. This variable is set to a colon-
separated list of valid directories on the system. When a command is typed at the shell prompt, the
system searches through each of the directories in the PATH looking for a program with a matching
name. When a match is found the search ceases and the program is executed. (For reasons of efficiency,
the directory path to recently executed commands can get stored in a cache.)
$ echo $PATH
/usr/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:.
In Unix a single period within the path name (.) or an empty entry (::) is used to represent the current
working directory. Suppose an account contains just such a period in its PATH variable, and the user
decides to execute a command. If the command was not located in one of the directories listed prior to
the period, the system will then check the user's current working directory for a matching file. If it is
found, the system will then attempt to execute the file. As the user's current working directory may be
anywhere on the system where the account has access permissions, it is easy to see why this may pose
a security problem.
This potential vulnerability is particularly true for the root account. Suppose root has a period at the
start of their PATH variable, then a user calls up to report a problem in their home directory. It would
be normal for the System Administrator to change directory to the user's home location and perform a
directory listing using the ls command. However if the user has placed a file called ls in their home
directory, the system will then try to execute it. This file could easily be a shell script that exploits the
permissions of the root account to grant the user enhanced permissions, then simply replicates the
actions of the ls call. The System Administrator might never even be aware of the inappropriate
activity.
For this reason it is important that the root account in particular never have a period in its PATH
variable. Note that if the value of the PATH variable begins or ends with a period, the system will treat
this just like a period. So, in addition, the root PATH variable should never begin or end with a colon,
or have two colons next to each other with no directory in between. In any event it is often preferable
for the System Administrator to type in the full command path rather than relying on the system.
If it is necessary for a user's PATH variable to include a period, it should be placed at the very end of
the PATH. This will cause the system to check all of the standard directories containing executables
before trying the current working directory. Setting the PATH in the shell startup script, such as
/etc/profile, or in the /etc/PATH file on some vendor releases, can help the System Administrator
manage the use of the PATH variable for most user accounts.
Another concern with the PATH variable is whether any of the directories in the PATH allow user's to
modify the contents. The permissions on the directories in the PATH should all restrict write
permissions, and all files within those directories should not allow write permissions. Otherwise an
unscrupulous user can modify one or more of the commands, and expect other users and even root to
execute their modified file. Periodic checks of the permissions on these directories and files is
necessary to help maintain a secure system.
[edit] Dot files

These files are normally located in the home directory of an account and contain various startup and
configuration settings and procedures. These are of interest to the System Administrator because in
certain cases they can introduce weaknesses into the security of a Unix system.
An alert System Administrator will regularly search their system for the presence of these files, then
check the permissions and contents for potential security issues. In addition to improper settings added
by users, the files may be modified by an intruder so that they can regain access at some future date.
[edit] .forward
The sendmail program includes support for this file that is intended to forward e-mail messages to a
new address (after a user has relocated their account, for example). The contents of this file can contain
a comma-separated list of addresses. The problem with regard to security, however, is that an address
can also be a system command. For example:
sample_address@no.such.com, "|/var/tmp/give_me_access"
When an e-mail message arrives, it is forwarded to the addresses in the .forward file. It is also passed
as standard input to the program listed in strings. This could, for example, be a script written by the
user to execute commands contained within the mail message.
It may be common practice to initially disable a user account by disabling the password. However if
the user has configured their .forward file to execute a command, they can still perform actions on the
system. An unscrupulous individual may exploit this access for inappropriate activities.
[edit] ForwardPath
Beginning with version 8 of the sendmail program, the ForwardPath option can be used to define
alternate locations for the .forward file. The ForwardPath option is set in the sendmail configuration by
means of the OJ line (or "O ForwardPath="). For example:
OJ/var/forward/$u.forward:$z/.forward
This will cause sendmail to first check for a file under a /var/forward directory with the name of the
user's account followed by a .forward. (Thus bob.forward would be interpreted as the .forward file for
the user account named bob.) If the file is not found, then sendmail will check for a .forward file in the
user's home directory.
Whenever a new user account is created, the System Administrator can then create a account.forward
file in the controlled directory. (This can be automated as part of the account creation tools.) After the
user has established that they are sufficiently well-trained with UNIX to properly configure their own
.forward file, the account.forward file can be removed.
[edit] .netrc
Users may want to use the ftp command for, say, batch downloads of files from a remote site. In order
to automate this process, they can configure a .netrc file to provide access without the need to input a
password. Once this is done, a script can be run to transfer files using, say, a scheduled batch task.
Unfortunately the format of the .netrc file stores the password in plain text. Anybody who has read
access to the .netrc file can also obtain the user's login password.
The ftp process has a built-in restriction that partially alleviates this problem. If the user's .netrc can be
read by anybody except the owner, the automatic login process will fail. This serves to force the owner
to restrict the permissions on this file. However this is only a partial solution. A preferable approach for
most purposes would be to use the host authentication method of the sftp command instead.
[edit] .rhosts
The .rhosts file can provide an autologin capability for a user when running the remote login command
(usually rlogin.) This bypasses the normal login process and immediately connects the user with the
system. As you'd expect, this capability can introduce a number of potential vulnerabilities to a system.
Suppose that three systems are set up so that A has a trust relationship with B, but A does not
necessarily trust C. The establishment of .rhosts for an account to connect between A—B and B—C,
can provide a back door for an individual to get from C to A. That is, somebody who manages to obtain
inappropriate access to C can use the .rhosts file to obtain access to A, even though C is not trusted by
A (and may even have network access blocked).
Another issue with the .rhosts file is the method used to enter the allowed account access. The file can
be set up to allow access from any host. For example:
+ joebob
will allow the account joebob to connect from any host without entering a password. Unfortunately, the
account may belong to an entirely different person on another system, or it could be deliberately
established on a compromised system to allow inappropriate access.
Due to the security dangers inherant in its use, it is usually better to disable the .rhosts capability where
possible.
Retrieved from "http://en.wikibooks.org/wiki/UNIX_Computing_Security/Securing_accounts"
UNIX COMPUTING SECURITY/SYSTEM

PROCESSES
System processes of UNIX consist of those processes that are not user services or user processes. One
of the most known is init.
[edit] Init
The parent of all processes. init will take ownership of orphaned processes. Process ID is almost
always 1.
[edit] Viewing processes

For example, a user may list the status of his or her processes using the ps command, thus:
$ ps -f
UID PID PPID C STIME TTY TIME CMD
john_doe 15265 15254 0 11:18:13 pts/5 00:00 -sh
john_doe 11407 15265 1 13:52:09 pts/5 00:00 ps -f
The user with the account name john_doe is the owner of the two processes with process identifiers
15265 and 11407. That user can send signals to those two processes using the kill command. However
the system can prevent that user from using the kill command on processes he does not own.
Retrieved from "http://en.wikibooks.org/wiki/UNIX_Computing_Security/System_processes"
UNIX COMPUTING SECURITY/REMOTE ACCESS

--------------------------------------------------------------------------------
Contents [hide]
1 Telnet
1.1 /etc/securetty
2 ftp
3 Sendmail
[edit] Telnet
This command is used to establish a connection with another host that can be accessed via the network,
and communicate with it using the TELNET protocol. Typically telnet is used to connect to a user login
via the standard TELNET port. For the default configuration, the login password is sent across the
network in clear-text form. That is to say, if the network packets between the two hosts are being read
by some intermediary, then the password string will appear in the packets in a readable form. Likewise
any data sent through during the session will also appear in readable form, including any other secure
information sent to the remote hosts.
Normally, if you want to maintain the security of your communications, the default configuration of
telnet should only be employed on network segments that you are highly confident are secure.
Establishing such a network is becoming increasingly difficult, however, unless of course it is kept
physically isolated. (Even then it is never possible to be 100% certain.)
A method of securing the password using telnet is to configure it to run as a Kerberos client, when this
functionality is available. The Kerberos client will support secure authentication, and help maintain the
secrecy of the password string. However this will not provide an encrypted session, so data
transmission subsequent to the login will remain vulnerable to interception.
Something that can be said in favor of telnet, from a security perspective, is that it typically lacks the
means to bypass the login sequence that is available to the Berkeley remote login commands, such as
rlogin. This reduces the risk of back-door access methods of the later commands.
The telnet service can normally be configured to display a text banner prior to the presentation of the
login prompt. This banner can be useful for presenting a carefully-worded warning to anybody
accessing the system. So in this sense it is like a "Do Not Trespass" sign on a piece of property. If
somebody is presented this warning prior to login, then they can not claim ignorance of what they were
trying to access. The presence and consistent use of a login banner can be useful in the event that a
prosecution of an individual for unauthorized access becomes necessary.
[edit] /etc/securetty
The /etc/securetty file is used to enable login security. When the file exists, the root account is only
allowed to login via the listed devices in the file, one per line. To prevent direct remote connection via
the root account, a recommended practice is to only include the single entry console within this file.
Note that this does not prevent a System Administrator from connecting to the system via their user
account and then executing an su - to become root. In fact this is a recommended method as it allows
usage of the root account to be logged.
When the /etc/securetty file is created it should be properly restricted to prevent modification from any
accounts except root. Thus an owner and group of root:sys and a file mode of 640 would effectively
secure this file.
[edit] ftp
The File Transfer Protocol is intended to allow the reliable transmission of files between two systems
on the network. It has two network ports, usually 20 and 21, and uses tcp for reliable packet transfer.
(Port 20 is employed for data transfer, while port 21 is used for session control.)
Connecting to a remote system via ftp requires a login at the destination. However unless a secure
authentication system such as kerberos has been enabled, the password will be transmitted across the
network in the clear. That is, anybody using a packet sniffer to intercept the session packets will be able
to read the password. In addition, any data files are also sent in unencrypted form. This uprotected
version of ftp should only be used across a secure network, or in cases where security is not an issue.
(See anonymous ftp below.) For encrypted login and file transmission, the Secure Shell software can be
used. However, at least at present, the sftp command equivalent does not have as rich a set of supported
commands as does the standard version of ftp.
There are several other features of ftp that can present a security issue for the System Administrator.
The first of these is the use of the .netrc file in a user's home directory. This file can be configured to
allow automatic connection to a remote site without the need to provide an account name or password.
However, any passwords stored in .netrc are in an unencrypted form. So if an unauthorized person is
able to gain read access to the .netrc file (such as by compromising the system) they may also be able
to gain access to other remote systems. To prevent this situation, many System Administrators will
regularly search their systems for .netrc files and then either remove them or check their contents.
The ftp daemon can be configured to allow a form of access that is known as "anonymous ftp". This
allows any individual from a remote site to connect by typing "anonymous" at the login prompt, then
entering any string as a password. (By convention the password is usually entered in the form of an e-
mail address, but this is a courtesy only.) An improperly configured anonymous ftp capability can
present a host of weaknesses that can be exploited by an intruder.
The instructions for how to properly configure an anonymous ftp account are usually given in the
manual pages for the ftp daemon. If this service is required, great care should be taken to follow the
documented instructions. In particular, the ~ftp/etc/passwd file should not include encrypted password
information, and only the ls command should be in the ~ftp/usr/bin/ directory and have 111
permissions.
More here...
Many vendors have adopted the wu-ftpd flavor of the File Transfer Protocol. This incorporates
additional features in the ftp configuration, many of which can be used to enhance the security of a
system.
More to come...
[edit] Sendmail
The sendmail program is used to send, relay, and receive electronic mail using SMTP (Simple Mail
Transfer Protocol). Unfortunately it has had a spotted history with respect to security vulnerabilities
and exploits. For this reason it is important to take advantage of any security features that have been
added to sendmail, and to apply the latest security patches to this product as they become available.
On each system where it is loaded, sendmail reads a file that is used to store a list of mail aliases. These
aliases are e-mail addresses that the sendmail program translates into another form, such as a
distribution list of e-mail addresses. One of the built-in features of the alias list is the ability to execute
a shell command using a prog mailer.
Here is an example of just such an entry:
save_debug_message : "|/usr/local/bin/record_bug.sh",debug_log
When an e-mail message is sent to the save_debug_message address on this server, its sendmail
daemon executes the /usr/local/bin/record_bug.sh command and passes the mail message to the script
as standard input.
As you might expect, this capability can readily introduce security vulnerabilities into the system.
Messages with arbitrary content can be sent to this address, and if it does not securely process the data
a suitably-formatted e-mail could potentially be used to compromise the system. Likewise if the script
is not securely protected, users on the system can modify it for their own purposes. A user with a
terminated account might even be able to regain access by this means.
A capability that was introduced to try and limit the amount of damage that an aliased command could
introduced was the use of the smrsh shell. When the sendmail process is configured to use smrsh as the
prog mailer, it limits the capabilities of the script being executed. The System Administrator can restrict
the commands that can be run in the script to a small set of "safe" commands. The prog mailer is
configured in the sendmail.cf configuration file using the Mprog option.
UNIX COMPUTING SECURITY/LOG FILES AND

AUDITING
Log files are generated by system processes to record activities for subsequent analysis. They can be
useful tools for troubleshooting system problems and also to check for inappropriate activity. The
UNIX releases are preconfigured to record certain information in log files, but configuration settings
are available to increase the amount of information recorded.
Log files can be very useful resources for security incident investigations. They can also be essential
for prosecution of criminal activity. For these reasons log files should be periodically backed up to
separate media, and precautions need to be taken to prevent tampering with the log files. It is expeced
that an unauthorized intruder into a computing system will attempt to remove any trace of their
activities from the system log files.
For log files that tend to grow significantly in size over the course of time, it can be good practice to
periodically rotate the logs. That is to say, rename the current log file to a name in a sequence, and start
a new log. Here is an example of rotating a log file called mylog:
$ cd /var/adm
$ test -f mylog.2 && mv -f mylog.2 mylog.3
$ test -f mylog.1 && mv -f mylog.1 mylog.2
$ test -f mylog.log && cp -p mylog mylog.1
$ :>mylog
The effect of this is to rotate the log through three copies before it is finally overwritten. A script can be
used to run this periodically, thus keeping the log file trimmed. (The log files should be backed up to
media at some point.) Rotating the log files helps minimizes the disk space usage, thus avoiding a
denial of service event due to a full file system.
[edit] Syslog
The system log is a log file that is maintained by the syslogd daemon. This log file can collect a variety
of useful information, including panic conditions, data corruption, hardware errors, as well as warnings
and tracking information. This log file can be written to from a shell or script by means of the logger
command. Messages are sent to the syslogd daemon, which processes them according to a
configuration defined by a special file (such as /etc/syslog.conf).
Events passed to the syslog are defined by a set of facilities and log levels. Combinations of facilities
and log levels can be processed in different manners, or ignored altogether. For example, all error
messages can be copied to the syslog.log file and e-mailed to the System Administrator, alerts can be
printed to the console, mail debug messages can be added to a mail.log file, and so forth.
Certain services or daemons can be configured to log information to the syslogd file. These can include
the inetd file, which on some systems can be configured to provide additional logging information.
Among the types of information that can be logged is remote user login attempts and successes,
including the client host from where the user is connecting. In some circumstances this can be useful
for helping tracing the origin of an inappropriate or erroneous connection.
Some versions of syslogd can be configured to read log messages broadcast over the network. However
it is possible to flood this socket with invalid messages, thus leading to a rapid growth of the log file
and a potential denial of service. For this reason it is often a good idea to disable this network logging
capability in the syslogd startup.
There are several options for maintaining a system log that is difficult if not impossible for an intruder
to clean up. These can be configured by means of the /etc/syslog.conf file.
A printer can be dedicated to recording log messages on hard copy. The old line printers were
especially useful for this purpose as the messages could be viewed immediately, rather than waiting for
a page to fill.
The daemon can forward messages to a secure system on the network. If the server is compromised, the
messages will still be stored safely on the remote host.
The log messages can be copied to a device that is configured for write-once, read-many operations.
This could be a CD-ROM recording or a specially-configured tape drive.
The System Administrator should also be wary of misleading log messages. Users can add log entries
using the logger command, and this can be employed as a prank or nuisance factor.
[edit] Other logs

There are other log files that can sometimes be useful in tracking accesses and activities.
The line printer daemon (lpd) is normally used to dispatch an output job to a printer. This can either
print to a locally attached device, or forward the print jobs to a remote printer on a different server. The
print jobs are recorded in a log file, usually giving the printer name, the account running the print job,
and the date and time. This could potentially be useful in tracking access attempts.
The sendmail daemon can be used to send and receive electronic mail between UNIX systems using
SMTP (Simple Mail Transfer Protocol). The daemon can be configured to log information about e-mail
messages sent, received, and relayed. It can be used to troubleshoot e-mail issues as well as to look for
unusual mail activity. The log messages are sent to the system via the syslogd, which is often
configured to save mail-related messages to a dedicated log file.
[edit] Auditing
Auditing is normally a built-in capability that can be activated on a UNIX system. It is a requirement
for C-2 trusted system security.
The audit system must be activated in order to begin collecting data. This data acquisition does come at
a cost, as it can consume as much as 10% of the system CPU time. The data is stored in a file, which
can then be analyzed using the available audit system commands.
The audit subsystem can collect data on events, system calls, and user activities. Auditing can collect a
significant amount of data, which can then be examined for information about the system calls being
run, the users calling the system commands, and the modifications made.
The particulars of the auditing configuration can vary depending on the particular flavor of the UNIX
OS, so it is best for the System Administrator to review the manual pages on the subject. Usually there
is an audit man page, which is a good place to start.
As the audit file can potentially grow without bounds, management of the file is necessary, usually on a
daily basis. This can be done by rotating the log files and backing up the logs to separate media. The
audit capability typically has a threshold setting that will cause the auditing to switch to an alternate log
file under certain conditions. This audit file is often placed on a different file system in case the
threshold switch is triggered by the original file system reaching a disk usage limit.
The audit logs should be regularly monitored to check for activity that needs to be tracked. Usually this
can be achieved by means of a cron job that summarizes the log entries and looks for inappropriate
events. In addition, regularly storing the audit event logs on separate media can be useful for the
purposes of investigation of unauthorized access, &c.
Retrieved from "http://en.wikibooks.org/wiki/UNIX_Computing_Security/Log_files_and_auditing"
UNIX COMPUTING SECURITY/PHYSICAL

SECURITY
Suggested topics: server room, media storage and network connections.
The physical security of your computing infrastructure is at least as important as the measures that are
applied at the software level. Unauthorized individuals gaining access to a server room can intercept
network transmissions, cause servers to reboot from inserted media, or perform malicious destruction
of your systems and data.
Companies that value their server computing resources will typically place the systems in isolated
rooms with carefully managed environments and protections against power outages. Access to server
rooms is limited by means of locks that can require combination codes, special digital cards, or
biometric devices. The interior can be monitored using surveillance systems, such as ceiling-mounted
camera domes. Perimeter defense is provided by building access mechanisms and security personnel.
However not all the computing infrastructure can be protected to this degree. Access to the network and
internal servers can be acquired by accessing an office terminal or workstation. Data can be removed or
stolen by the theft of a laptop or disk drive. It is also a simple matter to obtain valuable data, then to
copy it onto media for easy removal.
[edit] Reboot
When an intruder has physical access to a server, they may be able to reboot the system from alternate
media. With the system up, they may be able to mount up the file systems on the server and make
whatever changes they would like. When the system is rebooted normally, they may have inserted
changes that allow unauthorized privileges. Removalable media devices, such as CD-ROM, floppy
disk, magnetic tape or USB disks (including USB pen drives) should be removed from the list of
bootable devices, or placed after the primary boot device.
If a removable media device is not present, the system can still be booted into single-user mode. If this
level has not been protected by a login prompt, the system can be modified with privileges equivalent
to root. Vendors will typically implement a Boot Authentication feature only allows authorized users to
boot a system to Single-user mode. Boot authentication can take the form of a BIOS supported power-
on password or a specialized program, such as the Linux sulogin command which requires a password
before granting access in Single-user mode.
UNIX COMPUTING SECURITY/DATA SECURITY

Suggested topics: backups to media, recovery, encryption and disaster recovery.
Backup is very essential in an environment where your data is precious, and that to a subset of data for
almost any computer user, when planning for a backup system, there are some questions you need to
answer:
What do i want to backup?

How often do i want to backup?
Where to save the backup?
How long do i need the backup?
How long does it take to get the backup replace a damaged system after a desaster?
Whats the format i want to my backup to be in?
How to backup ?
How to minimize backup time when doing frequent backups?
if you are desinging your system in a way to make it easy to backup, you could take in consideration
selecting a filing system that supports usefull features, such as snapshots, XFS supports it, and ufs2 for
(free?)bsd supports it.
Contents [hide]
1 backup tools
1.1 remote backup
2 backup systems
2.1 disaster recovery tool
3 external links
[edit] backup tools

backup tools can be devided according to what they backup, file/directory backup tools, disk backup
tools and data backup tools (database dumps for example)
UNIX systems provide many tools that help in backing up files, most commonly known is the tar
command which allows creating archives and preserver ownership/time-date/permessions on the files
being archived. those tar archives can also easily be compressed, using gzip for example.
another tool to backup is "dump" and "restore", which dumps entire filing systems and treats it as a
collection of disk blocks, can be configured in /etc/fstab
cpio
tar:
tar puts multiple files and directories in one archive, note that tar actually stands for Tape Archive, so it
inherents a lot from the ar command (archive), tar can compress archives too, some of the options that
can be passed to tar are:
c : create archive
x : extract archive
t : list
z : work with gz compression to create compressed archives or extract compressed archives or list the
content.
v : operate verbosily (print out what files were progressed)
f file: to specify the file name you are dealing with.
[edit] remote backup

rsync
tar to remote machine:
tar czf uwe@remotehost:/path/remote localpath
tar over ssh tunneling
example
tar czf - someDir | ssh user@domain tar -C somDirToExtractTo xzf -
[edit] backup systems

amanda
[edit] disaster recovery tool

mondo
UNIX COMPUTING SECURITY/USEFUL TOOLS

Suggested topics: COPS, TIGER, sudo, md5, nfsbug, tripwire, OpenSSH, Linux Virtualization,
SNORT, IDS/IPS, IPTables.
--------------------------------------------------------------------------------
There are a number of commercial and free software tools available that are designed to help the
System Administrator strengthen the security of their system. Depending on the security requirements,
a number of these utilities can be employed on a regular basis to strength-check their system security,
look for indications of an attack or a compromised system, and implement more secure procedures.
[edit] COPS
This venerable package consists of a series of scripts and binaries that can be used to check some basic
security configurations on a UNIX system. The last update to this package was version 1.04, released
in 1991. hence this tool is starting to show its age, and may require some fine tuning to operate on a
modern version of UNIX. The output will vary according to the UNIX vendor and OS version. (There
is also a perl version included in the package, but was based on a much older version of perl and is
known to have some bugs.)
The following groups of checks are performed by the COPS utility:
Check selected system directories for world-write permissions.

Check specific system files for world-write permissions.
Check all files on the system for setuid status and note changes.
Check for insecure entries in the /etc/passwd file.
Check the format of the /etc/group file.
Check the root account PATH, umask, and for a root entry in the /etc/ftpuser.
Check for world-writeable files in /etc/rc*.
Check for world-writeable files in /usr/lib/crontab.
Check specific startup and configuration files in the user home directories.
Use the U-Kuang rules-based expert system to check for potential security exploits.
[edit] Check sum utilities

There are UNIX utilities such as cksum and md5 that can be used to read the contents of a file and
produce a one-way hashed values, or check sums, as an output. The value of the resulting string will
change whenever the contents of a file is changed, so this utility can be used to check whether a
downloaded file has been tampered with inappropriately. The string can also be used to check whether
a file was corrupted during the download process.
For example,
$ mdf important_data.pdf
MD5 (important_data.pdf) = 46df33cb1473394c32a8910d162eb913
Whenever a System Administrator downloads a program or patch that will be executed on a UNIX
system, it is important that the check sum of the file be compared with the value at a secure source.
This will help to protect the system from illicit tampering. Many vendors will provide check sum
values for the downloadable files that they make available. When possible, a stronger utility such as
md5 should be used instead of cksum, as this will make it vastly more difficult for an attacker to
produce a tampered file that has the same check sum.
Check sums can also be used to validate the binary commands on a system. Some integrity-checking
utilities such as tripwire use multiple check sum programs to search for file modifications.
[edit] OpenSSH

Unix Tutor

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unix Tutor

Загружено:

Авторское право:

Доступные форматы

UNIX/INTRODUCTION

Edit this paragraph

improve modules, add detail

[edit] Structure of this book

[edit] Shell prompt

[edit] Commands and files

Unix or non-Unix users seeking background

{{Guide to UNIX:u}} begin user instructions

[edit] General Concepts

[edit] The shell

[edit] The C language

PART 1: COMMAND LINE.

[edit] Finding a shell prompt

[edit] Using the TTY device

[edit] Opening a terminal emulator

There are several ways to open a terminal emulator:

[edit] Using SSH to access a remote shell

[edit] Appearance of the prompt

[edit] Root shell prompt

[edit] The basics of using the shell

[edit] Arguments and Options

[edit] Editing Commands

[edit] The current/working directory

[edit] Finding help for commands

UNIX/EXPLANATIONS/QUOTING AND FILENAME EXPANSION

[edit] Special characters and substitution

$ echo -lnQ arg1 arg2 arg3

To print a backslash, use two backslashes in a row.

[edit] Paired quoting characters

[edit] Single quotes

[edit] Double quotes

[edit] Filename expansion

* matches 0 or more characters, except /

Here is an example of the ? character at work:

[edit] When expansion fails

[edit] Curly brackets expansion

$ echo /bin/{ls,mv,cp} /sbin/{halt,reboot}

Unix/Explanations/Pipes and Job Control

Pipes and Redirects

[edit] Job Control

[edit] Choice of shell

[edit] Bourne-compatible shells

These are the Bourne-compatible shells:

[edit] Temporarily using a different shell

tcsh> printenv SHELL

[edit] Permanently changing the default shell

[edit] Advanced Bourne shell topics

[edit] Environment Variables

Using printenv with no arguments gives the entire environment:

[edit] Process limits

* cputime ("-t SECONDS")

UNIX/EXPLANATIONS/CONNECTING TO REMOTE UNIX

[edit] Using SSH from a Shell Prompt

The authenticity of host 'linux.example.edu (1.2.3.4)' can't be established.

PART 2: COMMON PROGRAMS

ps -e |grep cron : Displays status of cron deamon if running.

/usr/sbin/cron & : Starts users cron deamon.

[edit] The need for a text editor

$ cat > newfile

Now to do some actual editing, we use a command 2s/docmument/document.

We the people, promoting the common keyboard

We the people, nominally promoting the common keyboard

[edit] Word wrap

awk '$1 ~ /A/ { print $2 " " $3 }' /etc/passwd