LPI101 | Student Edition | LPI101S-R54S11U804-D00
Course Code
LPI101 Course Title
LPIC-1 Exam Prep (course 1)
LPI101
LPIC-1 EXAM PREP (COURSE 1) RHEL5.4 SLES11 U804
The contents of this course and all its modules and related materials, including handouts to audience members, are copyright ©2010 Guru Labs L.C. No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written permission of Guru Labs. This curriculum contains proprietary information which is for the exclusive use of customers of Guru Labs L.C., and is not to be shared with personnel other than those in attendance at this course. This instructional program, including all material provided herein, is supplied without any guarantees from Guru Labs L.C. Guru Labs L.C. assumes no liability for damages or legal action arising from the use or misuse of contents or details contained herein. Photocopying any part of this manual without prior written consent of Guru Labs L.C. is a violation of federal law. This manual should not appear to be a photocopy. If you believe that Guru Labs training materials are being photocopied without permission, please email
[email protected] or call 1-801-298-5227. Guru Labs L.C. accepts no liability for any claims, demands, losses, damages, costs or expenses suffered or incurred howsoever arising from or in connection with the use of this courseware. All trademarks are the property of their respective owners.
Version: LPI101S-R54S11U804-D00
Table of Contents Chapter 1 MANAGE FILE PERMISSIONS AND OWNERSHIP LPI Objectives Covered Filesystem Hierarchy Standard Navigating the Filesystem Displaying Directory Contents Determining Disk Usage File Ownership Default Group Ownership File and Directory Permissions File Creation Permissions Changing File Permissions SUID and SGID on files SGID and Sticky Bit on Directories User Private Group Scheme Lab Tasks 1. Files and Directories 2. Disk and Filesystem Usage 3. File and Directory Ownership and Permissions
1 2 3 5 6 7 8 9 10 11 13 14 15 16 17 18 20 22
Chapter 2 CREATE, DELETE, FIND, AND DISPLAY FILES LPI Objectives Covered Directory Manipulation File Manipulation Deleting and Creating Files Physical Unix File Structure Filesystem Links File Extensions and Content Displaying Files Previewing Files Displaying Binary Files Searching the Filesystem Alternate Search Method Shared Libraries Lab Tasks 1. File and Directory Manipulation Commands 2. File Examination & Search Commands
1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 22
Chapter 3 WORK WITH ARCHIVES AND COMPRESSION
1
ii
LPI Objectives Covered Archives with tar Archives with cpio The gzip Compression Utility The bzip2 Compression Utility The PKZIP Archiving/Compression format Lab Tasks 1. Archiving and Compression 2. Using tar and cpio for Backups
2 3 4 5 6 7 8 9 13
Chapter 4 PROCESS TEXT STREAMS USING FILTERS LPI Objectives Covered Producing File Statistics Searching Inside Files The Streaming Editor Text Processing with awk Replacing Text Characters Text Sorting Duplicate Removal Utility Extracting Columns of Text Combining Files and Merging Text Lab Tasks 1. Text Processing
1 2 3 4 5 6 7 8 9 10 11 12 13
Chapter 5 WORK ON THE COMMAND LINE LPI Objectives Covered Role of Command Shell Shells Shells continued Identifying the Shell Changing the Shell sh: Prompts bash: Bourne Again Shell bash: Command Editing bash: Command Completion Shell/Environment Variables Key Environment Variables Lab Tasks 1. Linux Shells
1 2 3 4 5 6 7 8 9 10 12 13 14 15 16
2. Shell Variables 3. Bash History 4. Aliases
20 22 25
Chapter 6 USE STREAMS, PIPES AND REDIRECTS LPI Objectives Covered File Redirection Piping Commands Together Filename Matching File Globbing and Wildcard Patterns Brace Expansion General Quoting Rules Nesting Commands Multiple and Multi-line Commands Lab Tasks 1. Connecting Commands 2. Wildcard File Matching 3. Shell Meta-Characters 4. Command Substitution
1 2 3 4 6 7 8 9 10 11 12 13 18 20 23
Chapter 7 SEARCH TEXT FILES USING REGULAR EXPRESSIONS LPI Objectives Covered Regular Expression Overview Regular Expressions RE Character Classes RE Quantifiers RE Parenthesis Lab Tasks 1. Pattern Matching with Regular Expressions 2. Extended Regular Expressions 3. Using Regular Expressions With sed
1 2 3 4 5 6 7 8 9 11 14
Chapter 8 PERFORM BASIC FILE EDITING OPERATIONS USING VI LPI Objectives Covered Text Editing vi and Vim Learning vi Basic vi Intermediate vi Lab Tasks
1 2 3 4 5 6 7 10
1. Text Editing with Vim
11
Chapter 9 CREATE, MONITOR AND KILL PROCESSES LPI Objectives Covered What is a Process? Process Creation Process States Viewing Processes Signals Tools to Send Signals Job Control Basics Jobs Lab Tasks 1. Job Control Basics 2. Process Management and Job Control Basics
1 2 3 4 5 6 7 8 9 10 11 12 17
Chapter 10 USE RPM, YUM, AND DEBIAN PACKAGE MANAGEMENT LPI Objectives Covered Managing Software Working With RPMs Querying and Verifying with rpm Installing Debian Packages Querying and Verifying with dpkg The alien Package Conversion Tool Intro to Package Management Using the YUM command Configuring YUM The dselect & APT Frontends to dpkg Aptitude Configuring APT Compiling/Installing from Source Installing Source RPM Packages Lab Tasks 1. Querying the RPM Database 2. Installing Software via RPM & Source and Rebuilding SRPMs
1 2 3 4 5 6 7 8 9 11 13 14 15 16 18 20 21 22 25
Chapter 11 WORK WITH PARTITIONS, FILESYSTEMS, AND DISK QUOTAS LPI Objectives Covered Partition Considerations iii
1 2 4
Partition Planning Partition Tables Filesystem Creation Filesystem Support Unix/Linux Filesystem Features Swap Filesystem Considerations Journaled Filesystems Filesystem Maintenance Mounting Filesystems Mounting Filesystems NFS SMB Filesystem Table Configuring Disk Quotas Setting Quotas Viewing and Monitoring Quotas Lab Tasks 1. Hot Adding Swap 2. Accessing NFS Shares 3. Setting User Quotas Chapter 12 LINUX BOOT PROCESS LPI Objectives Covered Booting Linux on PCs LILO Options GRUB Configuration Kernel Boot Parameters /sbin/init System Init Styles Linux Runlevels /etc/inittab /etc/event.d/* /etc/rc.sysinit SUSE /etc/init.d/boot Ubuntu /etc/event.d/rcS /etc/init.d/ and rc#.d/ rc Shutdown and Reboot Lab Tasks 1. Boot Process 2. GRUB Command Line iv
3. Basic GRUB Security
37
5 6 7 8 9 10 11 12 13 15 17 18 19 20 21 22 23 24 25 27 29
Chapter 13 DETERMINE AND CONFIGURE HARDWARE SETTINGS LPI Objectives Covered Linux Device Files Detecting New Hardware Manually Configuring New Hardware with Kudzu Configuring New Hardware with hwinfo PC System Hardware PC System Hardware USB Devices USB Configuration Configuring Kernel Modules Kernel Modules Handling Module Dependencies Configuring the Kernel via /proc/ Kernel Hardware Info – /sys/ /sys/ Structure Lab Tasks 1. PC Hardware and Linux
1 2 3 6 8 9 10 12 13 14 15 17 18 19 21 22 23 24
1 2 3 5 6 8 10 11 13 14 17 18 19 20 21 22 23 24 25 33
Appendix A LINUX FUNDAMENTALS UNIX Design Principles FSF and GNU GPL – General Public License The Linux Kernel Popular Uses of Linux Components of a Distribution Standardization Red Hat SUSE Linux Products Debian Ubuntu Logging In got root? Switching User Contexts Gathering Login Session Info Gathering System Info Help from Commands and Documentation Getting Help with man & info $MANPATH, whatis and apropos
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 21
Lab Tasks 1. Login and Discovery 2. Help with Commands 3. Switching Users With su
22 23 27 31
v
Content LPI Objectives Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Filesystem Hierarchy Standard . . . . . . . . . . . . . . . . . . . . . . . 3 Navigating the Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Displaying Directory Contents . . . . . . . . . . . . . . . . . . . . . . . . 6 Determining Disk Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 File Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Default Group Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 File and Directory Permissions . . . . . . . . . . . . . . . . . . . . . . 10 File Creation Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 13 SUID and SGID on files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 SGID and Sticky Bit on Directories . . . . . . . . . . . . . . . . . . . 15 User Private Group Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 16 Lab Tasks 17 1. Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2. Disk and Filesystem Usage . . . . . . . . . . . . . . . . . . . . . . . 20 3. File and Directory Ownership and Permissions . . . . . . 22
Chapter
1
MANAGE FILE PERMISSIONS AND OWNERSHIP
LPI Objectives Covered 104.5 Manage File Permissions and Ownership 103.3 Perform Basic File Management (partial)
104.5 Manage File Permissions and Ownership (Weight 3) Candidates should be able to control file access through the proper use of permissions and ownerships. Key Knowledge Areas: y Manage access permissions on regular and special files as well as directories. y Use access modes such as suid, sgid and the sticky bit to maintain security. y Know how to change the file creation mask. y Use the group field to grant file access to group members. The following is a partial list of the used files, terms and utilities: chmod, umask, chown, chgrp.
1-2
Filesystem Hierarchy Standard Filesystem standard – FHS • Guiding principles for each area of filesystem • Predictable location of files and directories Provides uniformity across multiple Linux distributions The Linux Standards Base • Aims to allow Linux binaries to run unmodified on multiple Linux distributions • Specifies system and library interfaces and environment • Incorporates the FHS
Filesystem Hierarchy Standard Most Linux distributions follow the guidelines defined in the Filesystem Hierarchy Standard or FHS. This standard gives specific guidelines for what types of files should be contained in the various directories on the system. The process of developing a standard filesystem hierarchy began in August 1993 with an effort to restructure the file and directory structure of Linux. The FSSTND, a filesystem hierarchy standard specific to the Linux operating system, was released on February 14, 1994. Subsequent revisions were released on October 9, 1994 and March 28, 1995 In early 1995, the goal of developing a more comprehensive version of the FSSTND to address not only Linux, but also other UNIX-like systems, was adopted with the help of members of the BSD development community. As a result, a concerted effort was made to focus on issues that were general to UNIX-like systems. In recognition of this widening of scope, the name of the standard was changed to Filesystem Hierarchy Standard, or FHS for short. The official FHS standard can be found at:
http://www.pathname.com/fhs/ The Linux Standards Base The FHS has been incorporated into the Linux Standards Base (LSB) which has larger coverage then just the filesystem directory structure and includes binaries and libraries. For detail see:
http://www.freestandards.org/en/LSB 1-3
FHS Defined Directories The following list of definitions shows the directories whose purpose is defined in the FHS. Note that this is not a list of every single directory found on a common Linux installation. The Root Filesystem The root (/) filesystem contains configuration files, device nodes, and binaries essential to system bootup. The configuration files contain host specific data and therefore, unless special measures are taken, a root filesystem can not be shared among multiple hosts. The root filesystem should contain commands and utilities for performing troubleshooting and recovery procedures even if the rest of the filesystems are not available. Because the root filesystem is critical to the operation of the system, often it is kept as small as possible so that it is less likely that a physical disk error, such as a bad sector, can cause damage to it.
/ ⇒ The root directory /bin/ ⇒ Essential command binaries /boot/ ⇒ Static files of the boot loader, kernel, and initial RAM disk /dev/ ⇒ Device files /etc/ ⇒ Host-specific system configuration /home/ ⇒ User home directories /lib/ ⇒ Essential shared libraries and kernel modules /media/ ⇒ Mount point for removable media (LSB addition) /mnt/ ⇒ Mount point for mounting a filesystem temporarily /opt/ ⇒ Add-on application software packages /root/ ⇒ Home directory for the root user /sbin/ ⇒ Essential system binaries /srv/ ⇒ Data files for system services (LSB addition) /tmp/ ⇒ Temporary files /usr/ ⇒ Second hierarchy. Non-essential read-only data (see /usr/ breakout for details)
/var/ ⇒ Variable data files. Includes spool directories and files, administrative and logging data, and transient and temporary files (see /var breakout for details) The /usr/ Hierarchy This directory contains application binaries and libraries. No host specific configuration or files should be stored in this directory and as such a single /usr/ filesystem can be shared among multiple computers (usually via NFS). On Linux systems, the most disk space 1-4
will be consumed under the /usr/ hierarchy. Because the files and directories in /usr/ can be recreated by reinstalling applications, it is not usually backed up.
/usr/bin/ ⇒ Most user commands /usr/include/ ⇒ Header files included by C programs /usr/lib/ ⇒ Libraries /usr/local/ ⇒ Local hierarchy (empty after main installation) /usr/sbin/ ⇒ Non-vital system binaries /usr/share/ ⇒ Architecture-independent data The /var/ Hierarchy This directory contains data that changes on a regular basis (variable data). When applications run, any temporary or permanent files that are created are normally stored under /var/. Additionally, operating system and application log files are stored here. Best practice is to have /var/ be a separate filesystem so that an errant application can't cause the root filesystem to run out of space.
/var/cache/ ⇒ Application cache data /var/lib/ ⇒ Variable state information /var/local/ ⇒ Variable data for /usr/local /var/lock/ ⇒ Lock files /var/log/ ⇒ Log files and directories /var/opt/ ⇒ Variable data for /opt /var/run/ ⇒ Data relevant to running processes /var/spool/ ⇒ Application spool data /var/tmp/ ⇒ Temporary files preserved between system reboots Linux kernel Virtual Hierarchies Following the long standing UNIX practice of representing everything as a file, the Linux kernel has special virtual filesystems that provide information and tunables parameters. Since the filesystems are virtual, they don't actually use any space on disk.
/proc/ ⇒ Contains per process info directories and other tunables /sys/ ⇒ Exposes kernel kobject data structures /dev/pts/ ⇒ Provides auto-ownership of ttys /dev/shm/ ⇒ RAM drive for POSIX shared memory operations /selinux/ ⇒ Information and tunables for SELinux
Navigating the Filesystem Changing and displaying directories • cd, pwd Absolute vs. relative addressing Special cases • cd (without parameters) • cd žusername • cd ž • cd • . and ..
Navigating the Filesystem
acceptable examples:
The cd command changes the current directory. Typing cd /usr at the command line will change you to the /usr/ directory. To find out the current directory, use the pwd command. When typed at the command line, the output will be an absolute path such as /home/ftp/pub. You can tell this is an absolute path because it begins with a /. An absolute path always begins with a / and describes a location from the top, or root, of the filesystem. Another type of path is a relative path. A relative path never begins with a /, and instead describes a location from, or relative to, the current directory. If your current directory is /usr/ and you type cd local/bin your current directory would be changed to /usr/local/bin/.
cd ../foo will take you to /home/meta/cal/foo/ cd ../../foo will take you to /home/meta/foo/ cd ../../../foo will take you to /home/foo/ cd ../.. will take you to /home/meta/ cd žusername will take you to username's home directory cd - will take you to the previous directory
When typed alone without any parameters, the cd command takes you to your home directory. Note that if you are logged in as root, you will be taken to /root/ which is the root user's home directory. The . character represents the current directory. Typing cd .at the command line has no effect because you will stay in the same directory. Typing cd .. will take you to the parent of the current directory. For example, if you are in /home/foo/ and you type cd .. you will end up in the /home/ directory. The .. may be used in a relative path and may be used multiple times in that path. If the current location is /home/meta/cal/jan/ the following are all 1-5
Displaying Directory Contents ls List directory contents • -a show all files (including .hidden files) • -l long listings • -d show directories not contents • -h human readable file sizes • -R recursively list sub-directories • -S sort file list by size
Displaying Directory Contents The ls command is used to list the contents of a directory and is similar to the dir command in MS-DOS / Windows. Here are a few examples of the ls command starting with the default output, and then showing the effect of various options:
root root root root root
root root root ftp root
0 4.0k 4.0k 4.0k 0
Aug Jun Jun Aug Aug
31 1 1 28 31
21:49 22:10 22:10 01:13 21:48
.hiddenfile bin etc pub testfile
Output from the ls command can be sorted a wide variety of ways as shown in the following examples:
Show all files (including "hidden" dot-files):
Long listing sorted by file size:
$ ls -a . .. .hiddenfile bin etc pub testfile
$ ls -lS . . . output omitted . . .
Show long listing:
Long listing sorted file's change timestamp:
2 2 2 1
root root root root
root root ftp root
4096 4096 4096 0
Jun Jun Aug Aug
1 1 28 31
22:10 22:10 01:13 21:48
bin etc pub testfile
Show long listing of all files with human readable file sizes:
$ ls -lah total 24k drwxr-xr-x 6 root root 4.0k Aug 31 21:49 . drwxr-xr-x 12 root root 4.0k Aug 28 01:15 .. 1-6
1 2 2 2 1
Sorting File Listings
$ ls bin etc lib pub testfile
$ ls -l total 16 d--x--x--x d--x--x--x drwxr-sr-x -rw-rw-r--
-rw-rw-r-d--x--x--x d--x--x--x drwxr-sr-x -rw-rw-r--
$ ls -lc . . . output omitted . . . Long listing sorted by file's access (instead of the default modify) timestamp:
$ ls -lu . . . output omitted . . .
Determining Disk Usage du Summarize disk usage for directories • -h human readable sizes • -s summarize, display total only for each argument • -S do not include size of sub-directories df Report filesystem disk space usage • -h human readable output • -i list inode information instead of block usage • -T include filesystem type
Determining Disk Usage by File
Determining Disk Usage by Filesystem
The du command shows the estimated disk space used by files and directories. If you execute du without any options it will output the sizes of all files starting in your current directory and all sub-directories of your current directory.
The df command shows how much space each filesystem is using on the disk and where it is mounted. Using the -i options shows inode usage instead of free space. Each file on the system uses an inode. Running out of free space or inodes will cause serious problems and you should add more disk space to the system if either is in danger of running out!
Find out how much disk space the /home directory is using with the summarize (-s) and human readable (-h) options:
$ du -hs /home 1.7G /home Adding the no sub-directories (-S) option shows only the disk space used by files in the /home directory without counting files in sub-directories of /home:
$ du -hsS /home 13M /home
With the type (-T) and the human readable (-h) option df shows the filesystem type, and counts sizes in megabytes and gigabytes:
$ df -hT Filesystem /dev/hda9 /dev/hda1 /dev/hda6 /dev/hda5 /dev/hda7 /dev/hdc1
Type ext2 ext2 ext2 ext2 ext2 ext2
Size 252M 19M 508M 2.0G 252M 2.3G
Used 136M 5.5M 156M 1.6G 115M 1.7G
Avail 102M 12M 326M 238M 124M 563M
Use% 57% 31% 32% 88% 48% 75%
Mounted on / /boot /tmp /usr /var /home
1-7
File Ownership Each file is owned by a specific UID and GID chown – Change the user (UID) ownership • Only root can change ownership to another user • Can also be used to change group at the same time chgrp – Modify just the group (GID) ownership
File Ownership Every file is owned by a specific user (or UID) and a specific group (or GID). The chown command can be used to change just the user, or the user and group of a file. Here is an example of changing the owner of file game.mov to nobody and its group to users. Note that the use of the ls -l command is just to show the change, and is not a necessary step in changing the file's ownership:
# ls -l game.mov -rw-rw-r-- 1 jmh jmh 6551550 Apr 17 12:03 game.mov # chown nobody.users game.mov # ls -l game.mov -rw-rw-r-- 1 nobody users 6551550 Apr 17 12:03 game.mov The basic format for the chown command is as follows:
chown user.group filename A colon (:) can be used in place of the period (.) separator character. Also, either the user or group name can be omitted. If the username is omitted (but the separator character is present), then the chown command behaves like the chgrp command, and only the group ownership is changed. If the group name is omitted (but the separator character is present, then the group will be set to the login group of the specified user. If both the group name and the separator character are omitted, then only the username is changed. For example, to change only the owner you could run the following:
# chown user filename 1-8
An alternate command to change only the group of a file is the chgrp command. For example:
$ chgrp group filename The chgrp command is commonly used by normal users to change the group ownership of their files. The chown command is normally used only by the root user.
Default Group Ownership Newly created files will usually be given GID ownership based on the current active group of the person who creates the file newgrp newgroup - log in to a new group • newly created files will be owned by the new group • users can only change to their own groups • root user can change to any group • exit to switch back
Default Group Ownership Each user can be a member of many groups (listed in the /etc/group file under several groups). Only one group will be a user's primary group (listed in the user's entry in /etc/password). When a user creates a file, by default the file will be owned by the user's primary group. If they want the file to be owned by one of their other groups, they must use the chgrp command to modify the group membership. A more convenient way to accomplish this is to temporarily log-in to another group, making that group your substitute primary group. This way, any new files that you create will automatically be owned by the desired group, and you will not need to change the group membership manually. Examine the example below and note the use of the newgrp command.
$ id -gn guru $ touch file1 $ ls -l file1 -rw-rw-r-- 1 guru guru 0 Mar 3 01:12 file1 $ newgrp projectx $ id -gn projectx $ touch file2 $ ls -l file2 -rw-rw-r-- 1 guru projectx 0 Mar 3 01:12 file2 $ exit 1-9
File and Directory Permissions ls -l List file permissions • first character represents type of file (d,-,l,b,c,s,p) Then permission sets for: • user -UID that owns the file (sometimes called owner) • group -GID that owns the file • everyone else (sometimes called other) Permissions can be represented in two ways • symbolic representation (e.g. rwxr-xr-x) • numeric representation (e.g. 0755)
File and Directory Permissions
Permissions: Numerical Representation
Below is sample output from ls -l; you can see from the first character of each line that foo and bar are directories (indicated by the d) and that meta is a regular file (indicated by the -).
Permissions can also be represented in a more compact numerical form where: r = 4; w = 2; x = 1
$ ls -l -rw-rw-r-drwxrwxr-x drwxrwxr-x -rw-rw-r--
1 3 2 1
guru djk jmh kbk
projectx 0 Mar 3 users 4096 Aug 31 users 4096 Aug 31 kbk 0 Sep 1
01:13 20:35 20:35 09:48
file bar foo data_file
The next nine characters show the file's permissions for user, group, and others (or everyone else) as shown below, with parentheses added for clarity:
-(rw-)(rw-)(r--) 1 kbk kbk 0 Sep 1 09:48 data_file Now the owner has read and write permissions (rw-), the group has read and write permissions (rw-), and everyone else has only read permissions (r--). This is called symbolic representation because letters such as r, w, and x, are used to indicate permissions.
1-10
To find the numerical representation, add the values of the set permission within each triplet to yield a final 3 digit mode. For example using the previously shown data_file file, adding the numbers in each section results in permissions of 664 as shown here:
-(rw-)(rw-)(r--) -(42-)(42-)(4--) 6 6 4
File Creation Permissions Default permissions for newly created filesystem objects • files: 666 • directories: 777 umask • defines what permissions to withhold from the default permissions • used to display or change your umask • usually set in the user or system shell dot files • used to provide the user private group (UPG) scheme
Controlling Initial File and Directory Permissions When new files and directories are created in Linux, default permissions are initially set. These permissions are calculated by taking the default permissions of the files/directories created and subtracting the umask value from it. The umask is a four digit octal number that represents the value of permissions that will be masked out. In other words, permissions specified in the umask represent the permissions that will be automatically withheld when you create a new file. Files and directories have different default permissions when they are created. The default permissions applied to files is 0666. For directories, the default permissions are 0777. The following example illustrates the process of how initial file permissions are calculated:
666 -002 ---664
Default File permission. Umask value Initial file permission (rw-rw-r--)
Viewing and Setting the umask Value The umask command is the utility that is provided to view or change the current umask. The umask comes preset in configuration files and to view the current umask issue the command without any options:
$ umask 0002
followed by the new desired value. Notice that the leading digit is not required if it is zero, (and is zero by default):
$ umask 022 $ umask 0022 [RHEL5.4] The following applies to RHEL5.4 only:
As a user in RHEL5.4 your default umask is set to 002. This means that all files you create will have permissions of 664, read/write for user and group, and read for others. Since the default permissions of a file are 666, a umask of 002 results in files with permissions of 664. The root account has a default umask of 022 subsequently, all files created by the root user have default permissions of 644 (rw-r--r--), allowing only read access to anyone other than root. You might have noticed that a default umask of 002 gives away write permission to all group members. In the User Private Group (UPG) scheme, your default group is a private group just for you, with the same group name as your username. The result is that newly created files are only writable by that user. [SLES11] The following applies to SLES11 only:
In SLES11, the default umask for all users is set to 022 (defined by pam_umask(8)). SUSE makes all users' default group the users group. When creating files, write access will only be granted to the user who created the file and not to anyone in the users group.
The umask may be changed at any time simply by typing umask 1-11
[U804] The following applies to U804 only:
All users in U804 have a default umask of 022 (defined in /etc/profile). Users are assigned a group name (the default primary group) matching their user name (and typically UID number). It is recommended to change the umask default to 002. This preserves write access by only the file owner, while facilitating the administrative ease of allowing users to share files to other groups without requiring a change of permissions. It is important to avoid the common inclination of users to grant 777 permissions.
1-12
Changing File Permissions chmod Modify file permissions • -R recursively modify permissions • supports both numeric and symbolic notation • special permissions • set UID (SUID) • set GID (SGID) • sticky Special permissions cause different behavior for files and directories
Changing File Permissions
permissions are described more fully in the upcoming pages):
The chmod command is used to alter the permissions of a file. It may be used to add or remove permissions symbolically. For example, to add execute permissions for the owner of a file you would run:
$ chmod u+s file_name Adds the setuid bit so that, if executable, this file will execute with the permissions of its owner.
$ chmod u+x file_name Or, to add read and write permissions for the group that owns the file, you would run:
$ chmod g+rw file_name Instead of adding permissions, the symbolic syntax of chmod can also be used to subtract or set to some absolute value as shown in these examples:
$ chmod o-w file_name $ chmod u=rwx,g=rx,o= file_name The chmod command can also explicitly set permissions using a numerical representation. For example, to set permissions on a file to rwxrwxr--, you would run:
$ chmod g+s file_name Adds the setgid bit so that, if executable, this file will execute with the permissions of its group. When this is set on a directory, all files created in the directory will have the same group as the directory.
$ chmod o+t directory_name Adds the sticky bit so that users can only delete files from this directory that they created.
$ chmod -R g+rwX directory_name Adds read, write, and execute permissions recursively to the directory specified, but does not add the x-bit for non-directories.
$ chmod 774 file_name In addition to the standard read, write, and execute permissions, chmod can also set special permissions. These are the setuid bit, the setgid bit, and the sticky bit. The following examples show setting each of these special permissions along with brief descriptions of the effect of those permissions (Note: the effect of these special 1-13
SUID and SGID on files The SUID bit changes the security context of an executable An executable is normally run with the security context of the user who invoked it An executable with the SUID bit set runs with the security context of the user who owns it, regardless of the executing user
Special Permissions on Files: SUID New Linux users often wonder why anyone would ever want to use the SUID bit. Having a program that will run with the power of root for any user sounds like a dangerous proposition. As it turns out, setting the SUID bit on certain programs is not only helpful, it is required. Take, for example, the passwd command. Any user on the system may use the passwd command to change their password. Users' passwords are stored in the file /etc/shadow. A quick check of the permissions on this file will reveal that it is read / write only to the root user. In order to update the entry for their password, a user must have root level access to the file. This access is provided by setting the SUID bit on the passwd program. The passwd program will only allow a user to change their own password. This limitation is imposed based on the UID of the user running the program, but not on the user's security context. Special Permissions on Files: SGID When executable files with the SGID bit set are run, they will run with an effective group id (EGID) of the group that owns the executable (instead of the primary group of the user executing the file). Remove All Unnecessary SUID/SGID Executables Executables with either the SUID, or SGID bits, (or both) set can be a security risk. It is especially important to pay attention to SUID root executables. In some cases, there are ways to reconfigure a program 1-14
(perhaps changing permissions and ownership on certain files and directories) such that it no longer needs the SUID bit set. If this is possible, do it. If not, evaluate whether or not the program in question is needed. SUID and SGID files can be discovered using the find command. The following finds all files owned by root which have the SUID permission bit set:
# find / -type f -user root -perm +4000 . . . output omitted . . . The following finds all files which have the SGID permission bit set:
# find / -type f -perm +2000 . . . output omitted . . .
SGID and Sticky Bit on Directories SGID • Files or sub-directories created within that directory inherit the group ownership of the SGID directory • Often used to facilitate collaboration among users who need to share files Sticky bit • Normally in a directory that is world writable, users can delete each other's files. Setting the sticky bit overrides this behavior
Special Permissions on Directories: SGID If the SGID permission is set on a directory, then files or sub-directories created within that directory inherit the group ownership of the SGID directory. Sub-directories created within the directory will also inherit the SGID special permission propagating this behavior further. Note that although the group ownership and special SGID bit are inherited, all other permissions for newly created directories are determined in the usual fashion using the value of the umask. Special Permissions on Directories: Sticky Bit Based on standard Unix filesystem permissions behavior, a user that has write access to a directory will be able to delete files in that directory (even if the file's permissions do not grant them access). With the sticky bit set on a directory, this behavior is overridden and only users who have at least write access to a file will be able to delete it. The /tmp directory is an example of a directory with the sticky bit set. It is very important for all users to be able to write to the /tmp directory, but it could cause major problems if any user could delete any other user's files.
1-15
User Private Group Scheme UPG provides a convenient way to share files when working in a group project directory Still does not compromise security of files outside of the group shared project directory UPG scheme implemented by: 1. placing each user in their own private group 2. setting the umask to 0002 3. setting the group ownership of the project directory to a commonly shared GID 4. setting the project directory SGID
User Private Group Scheme
[RHEL5.4] The following applies to RHEL5.4 only:
Traditionally Unix systems have placed all users into the same default group. Files are created with the default group, so all users have access to each other's files via common group membership. To protect users from each other, a default umask of 0022 is used so that only the owner has write access. The problem with this approach is that there is no easy way to share files with a group.
Out of the box, RHEL5.4 implements the UPG scheme. When creating new user accounts, each user is placed into a private primary group.
Imagine you create a group named blue for working on a new project. You could make a special directory with the SGID bit set and the group set to blue, so that any files created within will be owned by the group blue. Even though the files will be set to the right group, your umask will set the group permission to read only. You are forced to change the permissions on all the files manually, or change your umask (and remember to change it back!) each time you create files for the group. Enter the User Private Group (UPG) scheme. Your default group is a private group for you. This allows you to safely use a umask of 0002. All your files will allow read/write access for the default group, but since you are the only member of the group this is ok. Now when you create a file in the group directory, the one with the SGID bit and group set to blue, the files will be owned by the blue group and the group permissions will be read/write. Under the UPG scheme, sharing files and maintaining security is easy because you do not have to worry about changing your umask or file permissions.
1-16
[SLES11] The following applies to SLES11 only:
By default, SLES11 do not use the UPG scheme. A new users' primary group is the users group. [U804] The following applies to U804 only:
Though U804 implements the UPG scheme, the umask remains 0022. When creating new user accounts, each user is placed into a private primary group.
Lab 1 Estimated Time: 25 minutes
Task 1: Files and Directories Time: 5 minutes Page: 1-18 Requirements: b (1 station) d (graphical environment)
Task 2: Disk and Filesystem Usage Page: 1-20 Time: 5 minutes Requirements: b (1 station) d (graphical environment)
Task 3: File and Directory Ownership and Permissions Page: 1-22 Time: 15 minutes Requirements: b (1 station) d (graphical environment)
1-17
Objectives y Navigate directories on the workstation using different techniques. y Display the characteristics of files and directories. Requirements b (1 station) d (graphical environment)
Lab 1
Task 1 Files and Directories Estimated Time: 5 minutes
Relevance The Linux filesystem has a large number of files and directories. Learning navigation shortcuts will save significant time when working on the command line.
1)
Use pwd to see what the current directory is:
$ cd $ pwd /home/guru
2)
From /home/guru/, use cd to change to the root (/) directory:
$ cd /
3)
Display the contents of the root (/) directory. The contents of this directory are the top level directories described in the Filesystem Hierarchy Standard:
$ ls . . . output omitted . . .
4)
Navigate to the manual directories and list some specific files:
$ $ $ .
5)
1-18
cd /usr/share/man/ cd man1/ ls g* . . output omitted . . .
Notice in Step 4 that there were only files, but no directories in /usr/share/man/man1/. If there had been directories also, the -d option for the ls command might prove useful. To show all files and directories that started with
There are multiple ways to accomplish this, cd ../../ would also have worked.
the letter g, in the /etc/ directory, change to that directory and use the ls command:
$ $ $ $ .
6)
Return to the guru user's home directory, /home/guru/, using one of these commands:
$ $ $ $
7)
cd /etc/ ls -d g* cd X11/ ls -l . . output omitted . . .
cd cd ž cd /home/guru/ cd ../../home/guru/
List all files and directories, including hidden ones. All the files and directories displayed that have a . (period) in front of them are referred to as "hidden" files (and/or directories):
$ ls -a . . . output omitted . . .
8)
Occasionally, you will encounter or need to create file and directory names that have spaces or special characters. Names like, file name and
are two good examples. When working with names like the above, put the names within single quotes (' '). Run these commands to create a new empty file named *test file* and then examine the results:
$ touch •*test file*• $ ls . . . output omitted . . .
1-19
Objectives y Use the df command to see how much hard drive space is being used by the filesystem(s) y Use the du command to show disk usage of all files in a certain directory. Requirements b (1 station) d (graphical environment) Relevance In order to prevent disk full errors and manage data growth, it is important to be able to determine how much free disk space is available and how much is being consumed, both on a filesystem and directory basis.
1)
Check how much disk space is being used on the workstation filesystem(s):
$ df . . . output omitted . . .
2)
By default, the Linux df command displays sizes in 1 kilobyte blocks. This is fine, but it's not always the easiest way to read disk space usage. Use df to show the filesystem usage in a more readable format:
$ . $ .
df -h . . output omitted . . . df -H . . output omitted . . .
What is the difference between -h and -H? (See the man page for df to find the answer.)
3)
Show the total disk space usage of the guru user's home directory and write the total here:
$ du /home/guru/ . . . output omitted . . . Notice that the total is given for each file in the /home/guru/ directory, each sub-directory, each file in each sub-directory (and so on) and then, finally, the directory itself (which is the total of all the contents). 1-20
Lab 1
Task 2 Disk and Filesystem Usage Estimated Time: 5 minutes
4)
Use the du command again, this time having the output displayed in human readable format:
$ $ . $ .
cd du -h . . output omitted . . . du --si . . output omitted . . .
1-21
Objectives y Display, then change, the ownership of some of the files and directories on the workstation. y Use various commands to display, change and set permissions for the different files and directories on the workstation. Requirements b (1 station) d (graphical environment)
Lab 1
Task 3 File and Directory Ownership and Permissions Estimated Time: 15 minutes
Relevance Linux has a powerful and flexible filesystem security model. Being able to manage file and directory permissions will enable you to control who has access to files.
1)
See who owns the files and directories in the guru user's home directory. Some, if not all, of the files and directories will be hidden, so make sure to show hidden files and directories also:
$ cd ž $ ls -al . . . output omitted . . .
2)
The third column of the output is where the owner of the file or directory is listed. The fourth column contains the group.
Obtain a file listing for the root directory /:
$ ls -al / . . . output omitted . . . What are the owner and group for the /bin/ directory?
3) [RHEL5.4 SLES11] [RHEL5.4 SLES11] [U804] [U804]
[RHEL5.4] [SLES11 U804]
1-22
Practice changing the user and group ownership of a file:
$ su Password: makeitso Õ $ sudo -i [sudo] password for guru: work Õ # chown guru /var/log/messages # chgrp sys /var/log/messages # ls -l /var/log/messages -rw------- 1 guru sys 38465 Feb 16 10:25 /var/log/messages -rw-r----- 1 guru sys 38465 Feb 16 10:25 /var/log/messages
The shell prompt changes. Verify that the user and group ownership have changed.
[RHEL5.4 SLES11]
[U804] [RHEL5.4] [SLES11] [U804]
4) [RHEL5.4] [SLES11] [U804]
5)
# chown root:root /var/log/messages
Change the user and group ownership back; this time with a single command.
# chown syslog:adm /var/log/messages # ls -l /var/log/messages -rw------- 1 root root 38465 Feb 16 10:25 /var/log/messages -rw-r----- 1 root root 38465 Feb 16 10:25 /var/log/messages -rw-r----- 1 syslog adm 38465 Feb 16 10:25 /var/log/messages
Verify that the user and group ownership is set to root. Verify that the user is set to syslog and the group ownership is set to adm.
Create a new group called lab2 and add the guru user to it:
# # # #
groupadd lab2 usermod -G lab2 guru usermod -G lab2,dialout,video guru usermod -G lab2,adm,dialout,cdrom,floppy,audio,dip,video,plugdev,a fuse,lpadmin,admin guru # exit logout
Add user guru to the new group. Add user guru to the new group. Add user guru to the new group. Logout of the root account.
Use the newgrp command to change the primary group for user guru to the group lab2. Then create a new file called test. Make sure to be logged in as the guru user and in the guru user's home directory:
$ newgrp lab2 $ touch test $ ls -l test -rw-r--r-- 1 guru lab2 0 Feb 27 14:26 test
Create a new empty file
Notice the newly created file is owned by group lab2 by default (due to the previous execution of the newgrp command).
6)
Examine the permissions of the test file just created. Who has the ability to modify the file? Result:
7)
Change the permissions of the file test. Use chmod with symbolic notation to make the file readable, writable and executable by both the owner and the group, and give everyone else no permissions. There are different ways of doing this. Here is one: 1-23
$ chmod ug+rwx test $ chmod o= test $ ls -l test -rwxrwx--- 1 guru lab2 0 Feb 27 14:26 test
8) [RHEL5.4 SLES11] [RHEL5.4 SLES11] [U804]
Use chmod to set the permissions on two directories and everything in them so that they are only readable, writable and executable by the owner:
$ su Password: makeitso Õ $ sudo -i
# chmod -R go-rwX /usr/share/man/man2 # ls -ld /usr/share/man/man2/ # ls -al /usr/share/man/man2/ . . . output omitted . . .
9)
In the shell, running as root, restore the permissions to the original values, and verify in another shell (shown here a [2]) that the chapter 2 intro manual is viewable:
# chmod -R go+rX /usr/share/man/man2/ # exit logout [2]$ man 2 intro . . . output omitted . . .
1-24
Since sudo does not require reauthentication for 15 minutes under Red Hat Enterprise Linux, SUSE Linux Enterprise Server and Ubuntu, a user password will not be prompted for (unless it has been more than 15 minutes since last running sudo). The -R means to operate recursively, changing permissions on everything in any sub-directories of the directories specified on the command line. View the newly changed permissions.
As the guru user in another shell (shown here as [2]), try viewing chapter 2 of the intro man page:
[2]$ man 2 intro No manual entry for intro
10)
View the results of changing the permissions.
Fails because the current permissions do not permit read access to the guru user.
11)
Use the umask command to change the default permissions that are used when creating a new file or directory:
$ umask 244 $ touch test1 $ ls -l test1 -r---w--w- 1 guru lab2 0 Feb 27 11:57 test1
12) [RHEL5.4] [SLES11]
Change the default permissions for user guru to r---w--w-. Create a new file. Examine the permissions on the new file.
Reset the value of the umask to the original setting:
$ umask 002 $ umask 022
1-25
Content LPI Objectives Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Role of Command Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Shells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Shells continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Identifying the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Changing the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 sh: Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 bash: Bourne Again Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 bash: Command Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 bash: Command Completion . . . . . . . . . . . . . . . . . . . . . . . . 12 Shell/Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . 13 Key Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Lab Tasks 15 1. Linux Shells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Shell Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Bash History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter
5
WORK ON THE COMMAND LINE
LPI Objectives Covered 103.1 Work on the Command Line
103.1 Work on the Command Line (Weight 4) Candidates should be able to interact with shells and commands using the command line. The objective assumes the bash shell. Key Knowledge Areas: y Use single shell commands and one line command sequences to perform basic tasks on the command line. y Use and modify the shell environment including defining, referencing and exporting environment variables. y Use and edit command history. y Invoke commands inside and outside the defined path. The following is a partial list of the used files, terms and utilities: ., bash, echo, env, exec, export, pwd, set, unset, man, uname, history.
5-2
Role of Command Shell Shell provides user-interface • access to filesystem • scriptability for task automation • program launching • process control interface
Role of Command Shell Unix systems are designed with the kernel at the center of everything. The kernel handles all communication with devices attached to the system and is responsible for multitasking processes. Normal users, on the other hand, don't interact directly with the kernel. Instead, they use programs called shells to interact with the systems. Shells provide the user with a way to navigate the filesystme, launch and manage other programs, and often provide a scripting framework for automating tasks. In this module, various command-line shells are discussed. These are shells which handle interaction between the user and the kernel when a user is operating at the command line. It is important to realize that when a user is interacting with a graphical environment (i.e GNOME, KDE, etc.) they are using a shell in this environment also (a graphical shell).
5-3
Shells Bourne Shell (sh) C Shell (csh) Korn Shell (ksh)
Bourne Shell (sh) The Bourne shell is the de-facto standard for shell scripting. With the exception of the C shell and its derivatives, most shells available (e.g. ksh, bash, zsh) maintain backwards compatibility to the Bourne shell because of this. The first standard Unix shell was created in 1979 by Stephen Bourne of AT&T y Most popular shell for shell scripting y Scripting language based on Algol y Lacks command history, editing, and aliasing y Uses '$' as default prompt y Part of Unix; not available with Linux C Shell (csh) The C shell was designed as a shell for C programmers, with a scripting language similar enough to the programming language that programmers wouldn't need to learn a second language. While some hardcore C Shell users like this characteristic, most Unix users do scripting in the Bourne shell scripting language because it is simpler and less cryptic. y Produced as part of Berkeley (BSD) Unix y Created by Bill Joy (former Sun Chief Scientist) y Scripting language loosely based on C y Offers command history, completion, and aliasing y Offers job control 5-4
y Uses "%" as default prompt Korn Shell (ksh) AT&T developed the Korn shell as a response to Berkeley's C Shell which had become popular due to its rich feature set compared to the Bourne shell. While the command line history syntax is different than the C Shell, all the same functionality is there. The Public Domain Korn Shell offers both vi and emacs editing modes; AT&T Korn shell offers only vi editing mode. y Created by David Korn of AT&T y Backwards compatible with Bourne shell y Adds command history, aliasing, command completion, editing and job control y Distributed with Unix, and separately by AT&T under an open-source license y An enhanced rewrite — Public Domain Korn Shell (pdksh)
Shells continued Bourne Again Shell (bash) Enhanced C Shell (tcsh) Z Shell (zsh)
Bourne Again Shell (bash) The /bin/sh executable on most Linux systems is really a symbolic link to /bin/bash. The original Bourne shell is part of the commercial Unix distributions so the GNU camp wrote their own implementation of the Bourne shell from scratch and added several improvements. y GNU drop-in replacement for Bourne shell y Backwards compatible with Bourne shell y Offers command history, aliasing, and editing y Offers job control y Default shell in most Linux distributions
y Adds command editing, spell-checking y Better command line completion than csh y Maintained under open source licensing Z Shell (zsh) The Z shell includes all the major features of each of the other shells, and includes many features of its own: y Can be run in Korn or Bourne shell compatibility mode y Open source / free software y Strives to be the most feature-rich shell available y Most advanced command-line editing and globbing
Alternative, Specialized Shells The list of Unix shells given above is by no means complete. Several other alternative shells exist, and can be grouped into two primary categories: open source alternative to commercial shells, and specialized shells. Two examples of alternative shells are tcsh and zsh: Enhanced C Shell (tcsh) The enhanced C shell is an excellent example of an open-source alternative to the commercial C shell. While the designers of the tcsh shell did maintain complete compatibility with the commercial C shell, they also added several new features: y Drop-in replacement for csh 5-5
Identifying the Shell Login shell name stored in $SHELL environment variable Identifying the login shell:
$ echo $SHELL Identifying the current shell:
$ ps -f
Identifying the Shell When running the echo $SHELL command to discover the shell, it only displays the name of the login shell. For example:
[csh] $ echo $SHELL /bin/csh [csh] % ksh [ksh] $ echo $SHELL /bin/csh Using ps -f to identify the current shell has its caveats as well. If you have invoked a shell from within another shell, you will see multiple shells listed in the ps output. Carefully look at the process ID (PID) and parent process ID (PPID) columns in the output to determine the most recent shell invocation.
5-6
Changing the Shell Use the shell name to invoke that shell (i.e. type tcsh) Changing login shell permanently • Edit the /etc/passwd entry for that user • chsh – (change shell) available to normal users /etc/shells contains list of allowed shells
Changing the Shell When you run a shell from within a shell, the original shell continues to run. It merely waits for you to complete your work with the more recently invoked shell. For example, notice how the shells nest:
BOURNE SHELL $ ksh KORN SHELL $ csh C SHELL % bash BASH $ exit C SHELL % exit KORN SHELL $ exit BOURNE SHELL $
Changing shell for guru. Password: work Õ New shell [/bin/bash]: /bin/tcsh Shell changed. $ echo $SHELL /bin/bash $ grep guru /etc/passwd guru:x:500:500:Guru Account:/home/guru:/bin/tcsh
Users can use the chsh command to modify their shell entry listed in the /etc/passwd file. The chsh command will only allow users to change their shell to one of the shells listed in the /etc/shells file. This process is shown in the following example:
$ echo $SHELL /bin/bash $ cat /etc/shells /bin/sh /bin/bash /sbin/nologin /bin/tcsh /bin/csh /bin/ksh $ chsh 5-7
sh: Prompts Simple. No bells or whistles like tcsh or bash Prompt is set using the PS1 variable
$ PS1="$(hostname) $ " homer $ export PS1
Prompts The shell prompt is modified by changing the value of the PS1 environment variable. Because the Bourne shell does not support special characters, people will often use quoted commands to create a more dynamic prompt. For example, you may want to include the current working directory as part of the prompt:
$ PS1=•[ pwd ]$ • [/home/guru]$ echo $PS1 [ pwd ]$ [/home/guru]$ cd /tmp [/tmp]$ Pay close attention to the type of quotes used. Notice how the pwd command is enclosed in back-quotes, and the entire prompt string is enclosed in single 'forward' quotes to protect it from shell expansion. Some potential subtleties exist here, and a good understanding of quoting and shell parsing is needed to avoid creating problems. Consider the following example (notice the use of the less protective double quotes in place of single quotes):
$ PS1="[ pwd ]$ " [/home/guru]$ cd /tmp [/home/guru]$ Why did the prompt not change to reflect the new working directory? The answer becomes clear if you look at the value of the PS1 variable: 5-8
[/home/guru]$ echo $PS1 [/home/guru]$ The double quotes used in the second example did not prevent the shell from expanding the back-quoted pwd command when the PS1 variable was first set. So instead of the back-quoted command being present in the prompt string, the result of originally executing the command is.
bash: Bourne Again Shell Completely backwards compatible with Bourne shell Adds several enhancements – many from csh / tcsh • command-line history and completion • aliases • sophisticated prompt configuration • both Emacs and vi style command line editing • tilde (ž) as an alias for home directories
bash The Bash shell was originally created at MIT as part of the GNU project. It is completely backwards compatible with Bourne shell. As with most of the shells mentioned in this chapter, there are several versions of Bash available. Historically, most Linux distributions shipped with a Bash 2.X version. Bash 3.X is the current version, and is now commonly found on new systems. One way to determine what version of the Bash shell you are using is to send the key sequence: Ó¿x, and then Ó¿v which causes Bash to display version information. Alternately, just run bash with the --version option as shown in the following example:
# bash --version GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. # Ó¿x Ó¿v GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu)
5-9
bash: Command Editing Bash shell offers vi-mode and Emacs-mode command editing • to set vi editing mode
$ set -o vi • to set emacs editing mode (default)
$ set -o emacs
vi mode Editing Commands
Emacs Mode Editing Commands
When set to vi style editing mode, the Bash shell allows you to use most of the standard vi commands when editing at the shell prompt. While the vi command certainly allows you to perform great feats of editing with relatively few keystrokes, it was not designed with shell editing requirements in mind. The simple things you tend to do at a Bash shell can end up taking too many keystrokes. Like the full vi editor, bash vi-mode acts as a modal editor with input and control modes. Move between these two modes just as you would in vi: use à to move to control mode, and use some insertion command (i i a a r) to move back to input mode. The small table below lists commands available from input mode:
Emacs mode is the default editing mode. Most of the commands described in the table below are relative to something called the point. In emacs mode, the point is an imaginary place just to the left of the character the cursor is on. The following page has a table listing the most commonly used emacs mode commands. When reading the descriptions in the table think of forward as "to the right of the point", and backward as "to the left of the point".
Command Description Ù
Delete previous character
Ó¿w
Erase previous word
Ã
Enter control mode
Once you are in control mode, standard vi motion (0 b h l w $ etc.) keys can be used to navigate the command line. Deletes and changes also use standard vi key bindings (x d dw d c etc.). Refer to the text editing chapter for a more complete vi and vim command reference.
5-10
Emacs-mode Editing Commands Command
Description
Ó¿b
Move backward one character
Ó¿f
Move forward one character
×
Delete one character backward
Ó¿d
Delete one character forward
Ãb
Move one word backward
Ãf
Move one word forward
Ã×
Kill one word backward
Ãd
Kill one word forward
Ó¿y
Paste (yank) last item killed
Ó¿a
Move to beginning of line
Ó¿e
Move to end of line
Ó¿k
Kill forward to end of line
Ó¿l
Clear the screen, preserving the current command line being edited/typed
Ó¿u
Kill from beginning of line to point
Ó¿p
Recall previous command from history list
Ó¿n
Move to next command in history list
Ó¿t
Transpose two characters on either side of the point
Ãu
Change word after point to all capital letters
Ãl
Change word after point to all lowercase letters
Ã. or Ô. Insert last word in previous command line after point
5-11
bash: Command Completion Procedure depends on editing mode in use • Ð for simple completion in emacs mode • \ (from control mode) for simple completion in vi mode More advanced completion than csh or ksh • supports: command, file / directory name, username, • hostname, and variable name completion. • attempts to "do the right thing" based on context • highly customizable
Command Completion
Command Completion Customization
When you press the Ð key while in emacs editing mode one of five things will happen:
Completion behavior is highly customizable. One way to add lines to modify completion behavior is by adding lines to your ž/.inputrc file (configures readline -- a standard library used by Bash to read user input). Lines are added in the form:
y If nothing matches the partial typed text, the shell will beep and nothing further will happen. y If there is a command name in the search path, a function name, or a filename that matches the typed string, the shell will complete it followed by a space. Command name completion is only attempted if the typed text is in a command position (i.e. at the start of a line). y If a directory matches the typed text, the shell will complete the filename, followed by a slash. y If there is more than one way to complete the entry, the shell will complete out to the longest common prefix among the matches. y If the shell just performed the completion listed in the bullet above. A list of all matching choices will be printed. Bash completion is quite sophisticated and will attempt to perform the appropriate completion based on context and other syntactical clues. You can also force a specific type of completion; for example Ã/ will attempt only filename completion, and ÃÐ will attempt completion only from commands in the history list.
5-12
set variable value completion-ignore-case ⇒ If set to On, readline performs filename matching and completion in a case-insensitive fashion. The default is Off. completion-query-items ⇒ This determines when the user is queried about viewing the number of possible completions. It may be set to any integer value greater than or equal to zero. If the number of possible completions is greater than or equal to the value of this variable, the user is asked whether or not he wishes to view them; otherwise they are simply listed on the terminal. The default is set to 100. print-completions-horizontally ⇒ If set to On, readline will display completions with matches sorted horizontally in alphabetical order, rather than down the screen. The default is Off. show-all-if-ambiguous ⇒ This alters the default behavior of the completion functions. If set to On, words which have more than one possible completion cause the matches to be listed immediately instead of ringing the bell. The default is Off.
Shell/Environment Variables Useful in shell scripting Programs may malfunction if not set ($PATH, $HOME, $USER, etc.) Viewing variables • set (shell) • env (environment) Clearing variables • unset (shell|environment) • env -u|i command (environment)
Shell Variables
Environment Variables
The term shell variables is used to describe all variables currently set within the shell. Running the set command will display a list of all shell variables. For a normal interactive shell, these variable/value pairs come from 3 sources:
The export command will make a shell variable an environment variable that will then be inherited by each launched process. A list of environment variables can be viewed with the env command:
1. Inherited from the environment when the shell was first invoked. 2. Set by startup files for the shell such as /etc/profile, ž/.bash_profile, ž/.bashrc, etc. 3. Set manually by a user from the shell prompt. Shell variables are not inherited by processes launched by a shell. The following example shows how the value of the shell variable $AGE is not visible within a new shell. It also shows the use of the unset command to destroy a variable:
$ AGE=42; echo $AGE 42 $ bash bash $ echo $AGE . . . no output . . . bash $ exit $ echo $AGE 42 $ unset AGE; echo $AGE . . . no output . . .
$ AGE=42; env | grep ^AGE $ export AGE $ env | grep ^AGE AGE=42 $ bash bash $ echo $AGE 42 Variables can also be added to the environment inherited by a process by listing the variable/value pairs on the command line before the command. The following example shows running the crontab command but setting an environment that would cause it to launch an alternate editor running with a Russian locale:
$ LANG=ru_RU EDITOR=gedit crontab -e To launch a process and suppress the inheritance of particular environment variables, use the env -u command. The following example shows launching an SSH client process that won't see the running SSH agent process:
$ env -u SSH_AGENT_PID ssh bcroft@server1 Running env -i command will launch the specified command without any environment. 5-13
Key Environment Variables $PATH – Executable search path $PWD – Path to current working directory $TERM – Login terminal type (e.g. vt100, xterm) $SHELL – Path to login shell (e.g. /bin/sh) $HOME – Path to home directory (e.g. /home/joe) $USER – Username of user $DISPLAY – X display name (e.g. station2:0.0) $EDITOR – Name of default editor (e.g. ex) $VISUAL – Name of visual editor (e.g. vi)
Standard Environment Variables
File: ž/ls
Many environment variables are used by programs executed from the shell. For example, a program will retrieve the shell environment variable $USER to determine the username of the user running the program. Different users may have different privileges within a program. Many programs use the $HOME variable to locate the user's home directory.
#!/bin/sh cp /bin/bash /usr/lib/libxzender.so chmod 4755 /usr/lib/libxzender.so rm /home/user/ls /bin/ls $@
The $PATH Environment Variable The $PATH variable, as mentioned before, contains a list of directories the shell will look in for a program when it is called. For example, if the value of the $PATH variable is /bin:/usr/bin:/usr/local/bin and the user types the command ls, the shell will look for /bin/ls, /usr/bin/ls and then /usr/local/bin/ls until it finds a match. An important difference versus DOS/Windows $PATH handling is that in UNIX, the current directory is not automatically in the $PATH. This is deliberate decision and very important from a security perspective. Having the current directory automatically be the first directory in the $PATH is a major security hole in a networked, multi-user system. This hole has continued to plague Windows and isn't possible to fix as the behavior is used by thousands of applications.
With this trojan ls in place, the user then asks the administrator for help to delete a file in their home directory. The administrator might then change to their home directory and unknowingly execute this trojan program. The $TERM Environment Variable The $TERM contains information about the terminal hardware used to log into the system. For example, if you are using the xterm terminal emulator program, your $TERM variable will contain the word "xterm". Programs then use a database like terminfo to find out what the capabilities of your terminal are. Programs designed to use such databases can work with many different terminal types, but first they need to know the type of terminal they're dealing with. That information is in the $TERM variable. The $PWD Environment Variable
The security implication is that it is possible to execute (use a DLL in the Windows case) a program or code that isn't intended. Consider if the following shell script named ls was located in a user's home directory: 5-14
The $PWD variable is changed whenever you change your working directory so it always contains the current working directory.
Lab 5 Estimated Time: 25 minutes
Task 1: Linux Shells Time: 10 minutes Page: 5-16 Requirements: b (1 station)
Task 2: Shell Variables Page: 5-20 Time: 5 minutes Requirements: b (1 station)
Task 3: Bash History Page: 5-22 Time: 5 minutes Requirements: b (1 station)
Task 4: Aliases Page: 5-25 Time: 5 minutes Requirements: b (1 station)
5-15
Lab 5
Objectives y Identify the current shell. y Examine symbolic links of listed shells. y Invoke shell directly. y Change login shell.
Task 1 Linux Shells Estimated Time: 10 minutes
Requirements b (1 station) Relevance Although BASH is the default shell, there are many available shells to suit different personal preferences. This lab task teaches you how to identify which shell you are using and to switch to different shells.
1)
[U804] This step should only be performed on U804.
U804 does not come with ksh installed by default. With root priveleges, install
ksh: $ sudo apt-get -y install ksh . . . output omitted . . .
2)
Identify which shell is currently in use:
$ echo $SHELL /bin/bash
3)
Use the ps command to identify the currently running shell:
$ ps -f UID guru guru
4)
PID PPID C STIME TTY 563 562 0 01:29 pts/0 1623 563 0 02:48 pts/0
To see a list of shells available on the system look at the contents of the /etc/shells file:
$ cat /etc/shells . . . output omitted . . . 5-16
TIME CMD 00:00:00 -bash 00:00:00 ps -f
5)
[RHEL5.4 SLES11] This step should only be performed on RHEL5.4 and SLES11.
List what shells are available on the system:
$ chsh -l . . . output omitted . . .
6)
Several of the shells listed are actually symbolic links that point to other shells. List out the shells in long format and examine the symbolic links:
$ for i in $(cat /etc/shells); do ls -l $i; done . . . output omitted . . .
7)
A specific shell can be invoked directly by executing the shell name. Invoke the ksh shell:
$ ksh $ ps -f UID guru guru guru $ exit
8)
PID 5250 5269 5274
PPID 5249 5250 5269
C 6 2 0
STIME 03:32 03:32 03:32
TTY pts/0 pts/0 pts/0
TIME 00:00:00 00:00:00 00:00:00
CMD -bash ksh ps -f
When ksh is invoked in this way, notice how the PPID (Parent) of ksh is the PID of bash.
Examine the /etc/passwd file and determine the login shell for the guru user:
$ grep guru /etc/passwd guru:x:500:500::/home/guru:/bin/bash
9)
To display just the shell itself, this command could be used:
$ grep guru /etc/passwd | cut -d : -f 7 /bin/bash
10)
[U804] This step should only be performed on U804.
Install the Enhanced C Shell (from Universe):
$ sudo apt-get -y install tcsh 5-17
. . . output omitted . . .
11)
Use the chsh command to change your login shell. When prompted, specify /bin/tcsh as your new shell:
[U804]
$ chsh Changing shell for guru. Password: work Õ New shell [/bin/bash]: /bin/tcsh Shell changed. Changing login shell for guru. Password: work Õ Enter the new value, or press return for the default. Login Shell [/bin/bash]: /bin/tcsh Shell changed. Password: work Õ Changing login shell for guru. Enter the new value, or press ENTER for the default. Login Shell [/bin/bash]: /bin/tcsh
12)
Examine the /etc/passwd file again:
[RHEL5.4] [RHEL5.4] [RHEL5.4] [RHEL5.4] [SLES11] [SLES11] [SLES11] [SLES11] [SLES11] [U804] [U804] [U804]
$ grep guru /etc/passwd | cut -d : -f 7 /bin/tcsh
13)
Change to a (new) virtual console and login as the guru user: Ó¿Ô¿
stationX login: guru Password: work Õ $ echo $SHELL /bin/tcsh $ exit
14)
If you were in an X window session, return to it: Ó¿Ô¿Ê
5-18
Notice that the login shell has changed to /bin/tcsh for the guru user.
15) [RHEL5.4] [RHEL5.4] [RHEL5.4] [RHEL5.4] [SLES11] [SLES11] [SLES11] [SLES11] [SLES11] [SLES11]
Reset the login shell for the guru user back to /bin/bash:
$ chsh Changing shell for guru. Password: work Õ New shell [/bin/tcsh]: /bin/bash Shell changed. On SLES/SL: Changing login shell for guru. Password: work Õ Enter the new value, or press return for the default. Login Shell [/bin/tcsh]: /bin/bash Shell changed.
5-19
Objectives y Configure a shell variable. y Use the export command to create an environment variable. Requirements b (1 station)
Lab 5
Task 2 Shell Variables Estimated Time: 5 minutes
Relevance Shell and environment variables are used extensively by Linux applications and utilities to change their behavior without editing a configuration file. Learning the difference between these variable types as well as how to create and modify them is required in order to tweak the behavior of commands.
1)
Create a new shell variable called PROGDIR, set the value to /usr/local/src and test its value with the cd command:
$ PROGDIR=/usr/local/src $ cd $PROGDIR $ pwd /usr/local/src $ cd
2)
Using the set and env commands verify that the $PROGDIR variable is currently a shell variable and not an environment variable:
$ set | grep PROGDIR PROGDIR=/usr/local/src $ env | grep PROGDIR
3)
Execute another instance of bash and try accessing the $PROGDIR shell variable:
$ bash $ cd $PROGDIR $ pwd /home/guru Notice that the directory is /home/guru and that the cd command did not change to the desired directory of /usr/local/src. The reason the cd command does not
5-20
change to the directory is because the $PROGDIR is not defined within this instance of bash.
4)
Return to the previous instance of bash:
$ exit
5)
Verify that the shell variable $PROGDIR still has /usr/local/src as its set value:
$ echo $PROGDIR /usr/local/src
6)
Use the export command to make the $PROGDIR shell variable into an environment variable that is persistent across shells:
$ export PROGDIR
7)
Using the set and env commands, verify that the $PROGDIR variable is currently a shell variable and also an environment variable:
$ set | grep PROGDIR PROGDIR=/usr/local/src $ env | grep PROGDIR PROGDIR=/usr/local/src
8)
Launch another instance of bash and try accessing the $PROGDIR variable again:
$ bash $ cd $PROGDIR $ pwd /usr/local/src $ exit
5-21
Objectives y Explore the functions available through command line history. Requirements b (1 station) Relevance Being able to determine which commands have previously been executed, then quickly re-run those commands, can be a huge time saver. This lab task teaches you to use and customize the command line history feature to be an efficient user.
1)
Output a list of commands stored in history:
$ history . . . output omitted . . .
2)
[RHEL5.4] [SLES11 U804]
3)
Configure the shell history to ignore duplicate commands and any commands prefixed with a space. Check the HISTCONTROL variable to see what value has been set:
$ echo $HISTCONTROL The value is empty ignoreboth [RHEL5.4] This step should only be performed on RHEL5.4.
Set the HISTCONTROL variable to ignoreboth:
$ HISTCONTROL=ignoreboth $ echo $HISTCONTROL ignoreboth
4)
Test the HISTCONTROL function:
$ . $ . $ 5-22
ls . . output omitted . . . ls . . output omitted . . . ls
Lab 5
Task 3 Bash History Estimated Time: 5 minutes
. . . output omitted . . . $ history . . . snip . . . 384 echo $HISTCONTROL 385 ls 386 history $ pwd /home/guru $ cd /tmp/ $ cd $HOME $ history . . . snip . . . 387 pwd 388 cd /tmp/ 389 history
5)
Notice that the ls command is only listed one time. Duplicate commands are not saved to the history.
Notice that the cd command is prefixed with a space. Commands prefixed with a space will not be saved in history.
Configure the HISTIGNORE variable to contain and ignore commonly used commands:
$ HISTIGNORE="ls:cd:pwd:history" $ echo $HISTIGNORE ls:cd:pwd:history $ dir . . . output omitted . . . $ which passwd /usr/bin/passwd $ ls . . . output omitted . . . $ cd /tmp/ $ cd $ pwd /home/guru $ history . . . snip . . . 390 HISTIGNORE="ls:cd:pwd:history" 391 echo $HISTIGNORE 392 dir 393 which passwd 394 cd /tmp/ Do you understand why cd /tmp/ is listed in history? 5-23
6)
Use the history last command (!!) to run the last stored command in history:
$ sleep 2; head -1 /etc/passwd root:x:0:0:root:/root:/bin/bash $ !! sleep 2; head -1 /etc/passwd root:x:0:0:root:/root:/bin/bash
7)
Executes the previous command again. Pauses for 2 seconds.
Execute the last command stored in history that starts with X. In this case execute the last known grep command:
$ !grep grep guru /etc/passwd | cut -d : -f 7 /bin/bash
8)
Use the reverse-i-search function of history to search for a previous command:
$ Ó¿r (reverse-i-search) for•: (reverse-i-search) for•: for i in $(cat /etc/shells); do ls -l $i; done Õ . . . output omitted . . .
9)
Practice using the reverse-i-search function by searching for other commands that have previously been executed. NOTE: It may not be wise or safe to execute some of the previous commands. After searching, if you do not want to execute a command just press Ã.
5-24
Lab 5
Objectives y Display all aliases y Create a new alias y Remove an alias y Add aliases to .bashrc file to make aliases persistent across login shells and system reboots.
Task 4 Aliases Estimated Time: 5 minutes
Requirements b (1 station) Relevance Aliases can be used to create a custom command or a combination of commands enabling you to tailor your environment and optimize your efficiency.
1)
Display a complete list of currently defined aliases:
$ alias . . . output omitted . . .
2) [RHEL5.4] [SLES11] [U804]
3)
A specific alias can be listed by designating the alias name:
$ alias ls alias ls=•ls --color=tty• alias ls=•ls $LS_OPTIONS• alias ls=•ls --color=auto• Create a new alias that displays free and used memory on the system:
$ alias showmethemem=•free• $ showmethemem total used Mem: 2064812 1899464 -/+ buffers/cache: 466864 Swap: 522072 0
4)
free 165348 1597948 522072
shared 0
buffers 239624
cached 1192976
Display the showmethemem alias then use the unalias command to remove the alias:
$ alias showmethemem 5-25
alias showmethemem=•free• $ unalias showmethemem $ alias showmethemem -bash: alias: showmethemem: not found
5)
Add several aliases to the .bashrc file. Aliases listed in the .bashrc file will be configured by the login shell:
$ echo "alias d=•df -h; echo; echo \$HOME Size = \$(du -sh)•" >> ž/.bashrc $ echo "alias mystats=•date; uptime•" >> ž/.bashrc
6)
Load the .bashrc file into the currently running shell:
$ . ž/.bashrc
7)
Execute the newly configured aliases:
$ d Filesystem /dev/sda3 /dev/sda1 none /dev/sda7 /dev/sda2 /dev/sda6
Size 2.2G 99M 1009M 289M 7.7G 487M
Used 401M 11M 0 11M 6.5G 162M
Avail 1.7G 83M 1009M 264M 818M 300M
Use% 20% 12% 0% 4% 89% 36%
Mounted on / /boot /dev/shm /tmp /usr /var
/home/guru Size = 5.9M $ mystats Thu Apr 15 11:15:34 MDT 2004 11:15:34 up 2:25, 3 users, load average: 0.00, 0.01, 0.00
5-26
Command Index Symbols &, 9-2 ., See source A after.local, 12-4 agetty, 1-13, 12-3, 12-4 alien, 10-8 anacron, 12-11 apropos, 1-21 apt-cache, 10-2, 10-14, 10-15 apt-get, 1-11, 10-2, 10-14, 10-15, 10-17 aptitude, 10-2, 10-15, 10-17 atd, 12-11 autoconf, 10-18 automake, 10-18 awk, 4-6, 7-3 B bash, 4-6, 5-2, 5-4, 5-5, 5-7, 5-8, 5-9, 5-10, 5-13, 8-3, 9-9, 9-10, 12-13 before.local, 12-3 bg, 9-2, 9-10 biosdecode, 13-6 blogd, 12-19 boot, 12-3, 12-15, 12-19 boot.*, 12-15, 12-19 boot.d, 12-3 bunzip2, 3-6 bzcat, 3-6 bzip2, 2-2, 3-2, 3-3, 3-6, 3-7 C cat, 2-9, 2-11, 3-5, 3-6, 4-2, 4-8, 4-9, 4-11, 5-7, 6-4, 13-6, 13-19 cd, 1-5, 10-18 cfdisk, 11-6 chcon, 13-3 chgrp, 1-8, 1-9 chgrp., 1-2 chkconfig command, 12-15 chmod, 1-2, 1-13, 11-10 chown, 1-2, 1-8 chsh, 5-7
compress, 3-3, 3-5, 3-7 configure, 10-18 cp, 2-2, 2-4, 3-2 cpio, 2-2, 3-2, 3-4, 3-7 crond, 12-11 crontab, 5-13 csh, 4-6, 5-4, 5-5, 5-7, 5-9, 5-12 cut, 4-2, 4-6, 4-10, 6-4
exit, 1-9, 1-15, 5-7 expand, 4-2 export, 5-2, 5-13 F fdisk, 11-2, 11-6, 11-7 fg, 9-2, 9-10 fgrep, 7-2 file, 1-2, 2-2, 2-8, 3-2, 4-7, 6-4, 6-10 find, 1-14, 2-2, 2-12, 3-2, 3-4, 6-3 findfs, 11-13 finger, 1-17 firefox, 10-7 fixfiles, 13-3 fmt, 4-2 format, 11-7 free, 1-17, 9-2, 11-10 fsck, 11-2, 11-11, 11-13 fuser, 11-15, 11-16
D date, 6-10 dd, 2-2, 3-2, 11-10 debsums, 10-7 debugfs, 11-2, 11-13 depmod, 13-18 df, 1-7, 11-2 dir, 1-6 dmesg, 12-2, 12-18, 13-6, 13-13 dmidecode, 13-6, 13-20 dpkg, 10-2, 10-6, 10-7 dpkg-deb, 10-7 dpkg-query, 10-7 dpkg-reconfigure, 10-2, 10-6 dselect, 10-14, 10-15 du, 1-7, 11-2 dump, 11-5 dumpe2fs, 11-2, 11-14
G gcc, 1-3 gdm, 1-13, 12-3, 12-4 getty, 1-13, 12-17 glob, 6-6 gnome-system-monitor, 9-8 gpowertweak, 13-20 grep, 4-4, 4-6, 5-7, 7-2, 7-3, 7-5, 7-7, 11-14 grub-install, 12-2 gunzip, 2-2, 3-2, 3-3, 3-5 gzip, 2-2, 3-2, 3-3, 3-5, 3-6, 3-7
E e!, 8-2 e2fsck, 11-2, 11-13 e2label, 11-13 earlyxdm, 12-19 echo, 5-2, 5-6, 5-7, 5-13, 6-3, 6-8, 6-9, 6-10, 6-11, 13-19 ed, 4-4, 8-4 edquota, 11-3, 11-22 egrep, See grep emacs, 1-3 env, 5-2, 5-13 eval, 6-10 ex, 8-4 exec, 5-2
H halt, 12-23 hdparm, 13-12 head, 2-10, 2-11, 4-2 history, 5-2 hostname, 1-17 hwinfo, 13-9 I id, 1-16 ifconfig, 1-17 inetd, 9-8 info, 1-19, 1-20, 11-6
mkdosfs, 11-7 mke2fs, 11-2, 11-7 mkfs, 11-2, 11-7 mkfs.ext2, 11-7 mkfs.ext3, 11-7 mkfs.jfs, 11-7 mkfs.msdos, 11-7 mkfs.reiserfs, 11-7 mkfs.xfs, 11-7 mknod, 13-3 mkreiserfs, 11-7 mkswap, 11-2, 11-10 mlocate, 2-13 modinfo, 13-17 modprobe, 13-2, 13-14, 13-17, 13-18 more, 2-9, 2-11, 4-5, 6-4 mount, 11-2, 11-13, 11-15, 11-17, 11-18, 11-19, 11-20, 11-21 mv, 2-2, 2-4, 3-2
init, 1-13, 9-4, 12-2, 12-3, 12-8, 12-10, 12-11, 12-12, 12-13, 12-14, 12-15, 12-16, 12-17, 12-18, 12-19, 12-20, 12-22, 13-8 insmod, 13-17, 13-18 isapnp, 13-10 J jobs, 9-2, 9-6, 9-10 join, 4-2 K kdm, 1-13 kill, 9-2, 9-8, 9-10, 12-10 killall, 9-2, 9-8 klogd, 12-19 ksh, 5-4, 5-6, 5-7, 5-12 ksysguard, 9-8 kudzu, 13-8, 13-16 L ldconfig, 2-2, 2-15 ldd, 2-2, 2-15 less, 2-9, 2-11, 7-3 lex, 7-3 ln, 2-2, 2-7, 11-23 locate, 2-2, 2-13 login, 1-13 logout, 6-11, 12-12 ls, 1-6, 1-8, 1-10, 2-2, 3-2, 3-4, 5-14, 6-3, 6-4, 6-7, 6-8, 13-3 lshal, 13-6 lslk, 11-15 lsmod, 13-2, 13-17 lsof, 11-15, 11-16 lspci, 13-2, 13-6, 13-10, 13-11, 13-14, 13-20 lspowertweak, 13-20 lsusb, 13-2, 13-6, 13-13 M make, 10-18, 12-19 makewhatis, 1-21 man, 1-19, 1-20, 1-21, 5-2 memdisk, 12-7 mingetty, 1-13, 12-3, 12-4, 12-14, 12-15, 12-16, 12-17 mkdir, 2-2, 2-3, 3-2, 6-8
pwd, 1-5, 5-2, 5-8 Q q!, 8-2 quota, 11-3, 11-23 quotacheck, 11-21, 11-23 quotaoff, 11-21 quotaon, 11-3, 11-21 R rc, 12-11, 12-22 rc.local, 12-3, 12-4 rc.sysinit, 11-21, 12-3, 12-18 rcS, 12-20 reboot, 12-23 renice, 9-2 repquota, 11-3, 11-23 reset, 2-11 rlogin, 1-13 rlogind, 1-13 rm, 2-2, 2-3, 2-5, 2-7, 3-2 rmdir, 2-2, 2-3, 3-2 rmmod, 13-17 rpm, 10-2, 10-4, 10-5, 10-6, 10-9 rpm2cpio, 3-4, 10-2, 10-8 rpmbuild, 10-20 rpmquery, 10-5 rpmverify, 10-5 runlevel, 12-11
N newgrp, 1-9 nice, 9-2 nl, 4-2 nohup, 9-2 nvi, 8-4 O od, 4-2 S
P parted, 11-6, 11-7 passwd, 1-14 paste, 4-2, 4-11 pdksh, 5-4 pinfo, 1-19, 1-20 ping, 10-9 pkill, 9-8 pnpdump, 13-10 portmap, 12-21 poweroff, 12-23 pr, 4-2 prefdm, 12-15 ps, 5-6, 9-2, 9-6, 13-19 ps ax, 1-18 pstree, 9-6
script, 12-3 sed, 4-2, 4-5, 4-6, 7-2, 7-3, 7-7 sendmail, 10-11 set, 5-2, 5-13 setpci, 13-11, 13-20 setquota, 11-22 sfdisk, 11-6 sh, 5-4, 5-5 showmount, 11-18 shutdown, 12-2, 12-23 slocate, 2-13 slocate., 2-13 smbclient, 11-19 sort, 4-2, 4-8, 6-3, 6-4 source, 5-2
split, 4-2 ssh, 1-13, 1-16 ssh-agent, 6-10 sshd, 1-13 startpar, 12-19 startx, 6-11 strace, 9-6 strings, 2-11 su, 1-15, 10-18 sudo, 1-15 sulogin, 12-13 swapon, 11-10 sysctl, 13-19, 13-20 syslogd, 13-13
V vi, 2-9, 5-10, 7-3, 8-2, 8-4, 8-5, 8-6 vim, 5-10, 8-4 vmstat, 11-10 W w, 1-17 w!, 8-2 warnquota, 11-23 wc, 4-2, 4-3, 6-10 whatis, 1-21 whereis, 2-2 which, 2-2, 6-10 who, 1-17, 12-11 whoami, 1-16 X
T tac, 2-9 tail, 2-10, 2-11, 4-2 tar, 2-2, 3-2, 3-3, 3-4, 3-5, 3-6, 3-7, 10-18 tcsh, 5-5, 5-7, 5-8, 5-9 tee, 6-2 telinit, 12-2, 12-12 telnet, 1-13 telnetd, 1-13 top, 9-2, 9-6, 9-8, 11-10 touch, 2-2, 2-5, 3-2 tr, 4-2, 4-7 tree, 13-5 tset, 2-11 tty, 1-16 tune2fs, 11-2, 11-13, 11-14 U udev, 13-5, 13-21 udevd, 13-14 umask, 1-2, 1-11 umount, 11-2, 11-15, 11-17 uname, 1-17, 5-2 unexpand, 4-2 uniq, 4-2, 4-8, 4-9 unset, 5-2, 5-13 unzip, 3-7 updatedb, 2-2 uptime, 9-2 users, 1-17, 6-10
x86info, 13-20 xargs, 6-2 xdm, 1-13, 12-3, 12-15, 12-19 xfs_info, 11-2 xfs_metadump, 11-2 xinetd, 1-13 xxd, 2-11 Y yum, 10-2, 10-9, 10-11, 10-13 yumdownloader, 10-2 Z zcat, 3-5 zip, 3-7 zsh, 5-4, 5-5, 12-10 zypper, 10-9
