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

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 Wikipedia has more about this subject: 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.

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 nonLinux 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.


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.




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, POSIXcompatible 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 Bournecompatible 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 Bournecompatible, 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"

[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




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 (' 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,' (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"

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>




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 Notepadstyle 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 We the people, promoting the common keyboard and preserving a more perfect docmument for all, do ordain and establish three lines of text. 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 We the people, promoting the common keyboard and preserving a more perfect docmument for all, do ordain and establish three lines of text. 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

We the people, promoting the common keyboard and preserving a more perfect docmument for all, do ordain and establish three lines of text. 2s/docmument/document and preserving a more perfect document for all, 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: We the people, promoting the common keyboard and preserving a more perfect document for all, do ordain and establish three lines of text. ~ ~ ~ ~ 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 and preserving a more perfect document for all, do ordain and establish three lines of text. ~ ~ ~ ~ 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

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"

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. Wikipedia has more about this subject: 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)

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"

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 Unixlike 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.

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.




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. $ dd bs=1024 count=1440 if=/dev/zero of=example $ 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'. $ dd bs=1024 count=1440 if=/dev/zero of=example $ 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 c: 2880 0 unused 0 0 # Cyl 0 - 28* >q Write new label?: [y] $ sudo newfs /dev/rsvnd0a ... $ sudo vnconfig -u /dev/svnd0c [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.

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 nonBSD 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 Wikipedia has more about this subject: 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.


[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 $ sudo vnconfig -u /dev/svnd0c 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

[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.

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 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 The IPv4 address of your computer is "". This is in addition to any address that it has on an actual network. In fact, every computer calls itself "", so it is impossible to use this address to communicate between computers. (Some jokes involve a person who is given "" 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 PING ( 56 data bytes 64 bytes from icmp_seq=0 ttl=255 time=0.206 ms 64 bytes from icmp_seq=1 ttl=255 time=0.094 ms 64 bytes from icmp_seq=2 ttl=255 time=0.096 ms --- 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 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.118 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.116 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 twoclause 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 This is a shell variable, not normally exported as an environment variable. 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 This is a shell variable, not normally exported as an environment variable. 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.

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 LABEL=/ none none none mount point fs-type options dump-freq pass-num / ext3 defaults 11 /dev/pts devpts gid=5,mode=620 0 0 /proc proc defaults 00 /dev/shm tmpfs defaults 00 udf,iso9660 noauto,owner,kudzu,ro 0 0 auto noauto,owner,kudzu 0 0 ntfs swap ro,defaults defaults 00 00 00

# my removable media /dev/cdrom /mnt/cdrom /dev/fd0 /mnt/floppy # my NTFS Windows XP partition /dev/hda1 /mnt/WinXP /dev/hda6 swap

# my files partition shared by windows and linux /dev/hda7 /mnt/shared vfat umask=000 ( 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.

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


[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 standardconforming 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.

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.

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 muchneeded 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"

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

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


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 colonseparated 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"

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"

-------------------------------------------------------------------------------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 email 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.

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"

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 poweron password or a specialized program, such as the Linux sulogin command which requires a password before granting access in Single-user mode.

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

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