LPI Linux Certification in a Nutshell Part 24

Objective Weight Description 1 2 Install and Configure X11 2 2 Set Up a Display Manager 3 1 Accessibility

Table12-3.Administrative Tasks (Topic 107)

Objective Weight Description 1 5 Manage User and Group Accounts and Related System Files 2 4 Automate System Administration Tasks by Scheduling Jobs 3 3 Localization and Internationalization

Table12-4.Essential System Services (Topic 108)

Objective Weight Description 1 3 Maintain System Time 2 2 System Logging 3 3 Mail Transfer Agent (MTA) Basics 4 2 Manage Printers and Printing

Table12-5.Networking Fundamentals (Topic 109)

Objective Weight Description 1 4 Fundamentals of Internet Protocols 2 4 Basic Network Configuration 3 4 Basic Network Troubleshooting 4 2 Configuring Client Side DNS

Table12-6.Security (Topic 110)

Objective Weight Description 1 3 Perform Security Administration Tasks 2 3 Set Up Host Security 3 3 Securing Data with Encryption

Chapter13.Sh.e.l.ls, Scripting, and Data Management (Topic 105)

Depending upon the computing environments you're used to, the concepts of sh.e.l.ls and sh.e.l.l programs (usually called scripts scripts) may be a little foreign. On Linux systems, the sh.e.l.l is a full programming environment that can be scripted or used interactively.

This chapter covers Topic 105 and its three Objectives: Objective 1: Customize and Use the Sh.e.l.l Environment This Objective covers your sh.e.l.l and basic scripting concepts, including environment variables, functions, and script files that control the login environment. Weight: 4.

Objective 2: Customize or Write Simple Scripts Customization of the many scripts found on a Linux system is important for its management and automation. Topics for this Objective include sh.e.l.l syntax, checking the status of executed programs, and issues surrounding the properties of script files. Weight: 4.

Objective 3: SQL Data Management This objective covers the basic use of SQL databases to store and query data. Topics for this Objective include communicating with a SQL database, basic queries, basic database concepts, and the relationship between data and tables. Weight: 2.

It is important for Linux administrators to become comfortable with at least one sh.e.l.l and its programming language. This can be an area of some concern to those used to graphics-only environments, where the use of a command interpreter is not a daily activity. As you'll see, becoming adept at working with your favorite sh.e.l.l will allow you to customize many trivial tasks and become a more efficient system administrator.

Objective 1: Customize and Use the Sh.e.l.l Environment This Objective could be considered a brief "getting started with sh.e.l.ls" overview because it details many of the basic concepts necessary to utilize the sh.e.l.l environment on Linux. These concepts are fundamental and very important for system administrators working on Linux systems. If you're new to sh.e.l.ls and sh.e.l.l scripting, take heart. You can think of it as a combination of computer interaction (conversation) and computer programming (automation). It is nothing more than that, but the result is far more than this simplicity implies. If you're an old hand with sh.e.l.l programming, you may want to skip ahead to brush up on some of the particulars necessary for Exam 102.

If you've never taken a computer programming course before, don't be too discouraged. Sh.e.l.l programming is mostly automating repet.i.tive tasks. Your sh.e.l.l scripts can conceivably become relatively complicated programs in their own right, but sh.e.l.l scripting does not have the learning curve of a "conventional" programming language such as C or C++.

An Overview of Sh.e.l.ls A sh.e.l.l is a fundamental and important part of your Linux computing environment. Sh.e.l.ls are user programs not unlike other text-based programs and utilities. They offer a rich, customizable interface to your system. Some of the main items provided by your sh.e.l.l are: An interactive textual user interface to the operating system In this role, the sh.e.l.l is a command interpreter and display portal to the system. It offers you a communications channel to the kernel and is often thought of as the "sh.e.l.l around the kernel." That's where the name sh.e.l.l sh.e.l.l originates and is a good metaphor for conceptualizing how sh.e.l.ls fit into the overall Linux picture. originates and is a good metaphor for conceptualizing how sh.e.l.ls fit into the overall Linux picture.

An operating environment Sh.e.l.ls set up an environment environment for the execution of other programs, which affects the way some of them behave. This environment consists of any number of for the execution of other programs, which affects the way some of them behave. This environment consists of any number of environment variables environment variables, each of which describes one particular environment property by defining a name=value name=value pair. Other features such as pair. Other features such as aliases aliases enhance your operating environment by offering shorthand notations for commonly used commands. enhance your operating environment by offering shorthand notations for commonly used commands.

A facility for launching and managing commands and programs Sh.e.l.ls are used not only by users but also by the system to launch programs and support those programs with an operating environment.

A programming language Sh.e.l.ls offer their own programming languages. At its simplest, this feature allows user commands to be a.s.sembled into useful sequences. At the other end of the spectrum, complete programs can be written in sh.e.l.l languages, with loop control, variables, and all of the capabilities of Linux's rich set of operating system commands.

All of the sh.e.l.ls share some common concepts: They are all distinct from the kernel and run as user programs.

Each sh.e.l.l can be customized by tuning the sh.e.l.l's operating environment.

Sh.e.l.ls are run for both interactive use by end users and noninteractive use by the system.

A sh.e.l.l can be run from within another sh.e.l.l, enabling you to try a sh.e.l.l other than your default sh.e.l.l. To do this, you simply start the other sh.e.l.l from the command line of your current sh.e.l.l. In fact, this happens constantly on your system as scripts are executed and programs are launched. The new sh.e.l.l does not replace the sh.e.l.l that launched it; instead, the new sh.e.l.l is a process running with the original sh.e.l.l as a parent process. When you terminate the child sh.e.l.l, you go back to the original one.

Sh.e.l.ls use a series of configuration files configuration files in order to establish their operating environment. in order to establish their operating environment.

Sh.e.l.ls pa.s.s on environment variables to child processes.

The Bash Sh.e.l.l bash is the GNU Project implementation of the standard Unix sh.e.l.l is the GNU Project implementation of the standard Unix sh.e.l.l sh sh. Since the original sh sh was the "Bourne sh.e.l.l," was the "Bourne sh.e.l.l," bash bash is the "Bourne again sh.e.l.l". As the is the "Bourne again sh.e.l.l". As the bash home page says: says: Bash is an sh sh-compatible sh.e.l.l that incorporates useful features from the Korn sh.e.l.l (ksh) and C sh.e.l.l (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Sh.e.l.l and Tools standard. It offers functional improvements over sh sh for both programming and interactive use. for both programming and interactive use.

While there are a number of sh.e.l.ls available to choose from on a Linux system, bash bash is very popular and powerful, and it is the default sh.e.l.l for new accounts. Bash has become popular enough that it is available on many other Unix flavors as well, including Sun's Solaris and Hewlett-Packard's HP/UX. Exam 102 concentrates on its use and configuration. The next few sections deal with common sh.e.l.l concepts, but the examples are specific to is very popular and powerful, and it is the default sh.e.l.l for new accounts. Bash has become popular enough that it is available on many other Unix flavors as well, including Sun's Solaris and Hewlett-Packard's HP/UX. Exam 102 concentrates on its use and configuration. The next few sections deal with common sh.e.l.l concepts, but the examples are specific to bash bash.

Sh.e.l.ls and environment variables Many programs running under Linux require information about you and your personal preferences to operate sensibly. Although you could manually provide this information to each program you run, much of the information you'd convey would be redundant because you'd be telling every command you enter the same ancillary information at each invocation. For example, you'd need to tell your paging program about the size and nature of your terminal or terminal window each time you use it. You would also need to give fully qualified directory names for the programs you run.

Rather than force users to include so much detail to issue commands, the sh.e.l.l handles much of this information for you automatically. You've already seen that the sh.e.l.l creates an operating environment for you. That environment is made up of a series of variables variables, each of which has a value that is used by programs and other sh.e.l.ls. The two types of variables used by most sh.e.l.ls are: Environment variables These variables can be thought of as global variables global variables because they are pa.s.sed on to all processes started by the sh.e.l.l, including other sh.e.l.ls. This means that child processes inherit the environment. By convention, environment variables are given uppercase names. because they are pa.s.sed on to all processes started by the sh.e.l.l, including other sh.e.l.ls. This means that child processes inherit the environment. By convention, environment variables are given uppercase names. bash bash doesn't require the case convention; it is just intended for clarity to humans. However, variable names are case-sensitive. Your sh.e.l.l maintains many environment variables, including the following examples: doesn't require the case convention; it is just intended for clarity to humans. However, variable names are case-sensitive. Your sh.e.l.l maintains many environment variables, including the following examples:PATHA colon-delimited list of directories through which the sh.e.l.l looks for executable programs as you enter them on the command line. All of the directories that contain programs that you'll want to execute are stored together in the PATH PATH environment variable. Your sh.e.l.l looks through this list in sequence, from left to right, searching for each command you enter. Your environment variable. Your sh.e.l.l looks through this list in sequence, from left to right, searching for each command you enter. Your PATH PATH may differ from the may differ from the PATH PATHs of other users on your system because you may use programs found in different locations or you may have a local directory with your own custom programs that need to be available. The PATH PATH variable can become quite long as more and more directories are added. variable can become quite long as more and more directories are added.HOMEYour home directory, such as /home/adamh /home/adamh.USERNAMEYour username.TERMThe type of terminal or terminal window you are running. This variable is likely to have a value such as xterm xterm or or xterm-color xterm-color. If you are running on a physical VT100 (or compatible) terminal, TERM TERM is set to is set to vt100 vt100.

Sh.e.l.l variables These variables can be thought of as local local because they are specific only to the current sh.e.l.l. Child processes do not inherit them. Some sh.e.l.l variables are automatically set by the sh.e.l.l and are available for use in sh.e.l.l scripts. By convention, sh.e.l.l variables are given lowercase names. because they are specific only to the current sh.e.l.l. Child processes do not inherit them. Some sh.e.l.l variables are automatically set by the sh.e.l.l and are available for use in sh.e.l.l scripts. By convention, sh.e.l.l variables are given lowercase names.

To create a new bash bash sh.e.l.l variable, simply enter a sh.e.l.l variable, simply enter a name=value name=value pair on the command line: pair on the command line: #pi=3.14159 To see that this value is now a.s.signed to the local variable pi pi, use the echo echo command to display its contents: command to display its contents: #echo$pi 3.14159 The dollar sign preceding the variable name indicates that the name will be replaced with the variable's value. Without the dollar sign, echo echo would just return the text that was typed, which in this case is the variable name would just return the text that was typed, which in this case is the variable name pi pi. At this point, pi pi is a local variable and is not available to child sh.e.l.ls or programs. To make it available to other sh.e.l.ls or programs, the variable must be exported to the environment: is a local variable and is not available to child sh.e.l.ls or programs. To make it available to other sh.e.l.ls or programs, the variable must be exported to the environment: #exportpi Aliases Among the features missing from sh sh was the ability to easily make new commands or modify existing commands. was the ability to easily make new commands or modify existing commands. bash bash has the ability to set an alias for commonly used commands or sequences of commands. For example, if you habitually call for the older pager has the ability to set an alias for commonly used commands or sequences of commands. For example, if you habitually call for the older pager more more but actually prefer but actually prefer less less, an alias can be handy to get the desired behavior, regardless of the command you use: $aliasmore='less'

This has the effect of intercepting any command entries for more more, subst.i.tuting less less. The revised command is pa.s.sed along to the sh.e.l.l's command interpreter.

Another common use for an alias is to modify a command slightly so that its default behavior is more to your liking. Many people, particularly when operating with superuser privileges, will use this alias: $aliascp='cp-i'

With this alias in effect, the use of the cp cp (copy) command becomes safer, because with the (copy) command becomes safer, because with the -i -i option always enforced by the alias, option always enforced by the alias, cp cp prompts you for approval before overwriting a file of the same name. Additional options you enter on the command line are appended to the end of the new command, such that prompts you for approval before overwriting a file of the same name. Additional options you enter on the command line are appended to the end of the new command, such that cp -p cp -p becomes becomes cp -i -p cp -i -p, and so on.

If the righthand side of the aliased command is bigger than a single word or if it contains multiple commands (separated by semicolons, bash bash's command terminator), you probably need to enclose it in single quotation marks to get your point across. For example, suppose you wished to use a single alias to pair two simple commands: $aliaslsps=ls-l;ps Your current bash bash process will interpret this command not as a single alias but as two separate commands. First the alias process will interpret this command not as a single alias but as two separate commands. First the alias lsps lsps will be created for will be created for ls -l ls -l, and then a ps ps command will be added for immediate execution. What you really want is: command will be added for immediate execution. What you really want is: $aliaslsps='ls-l;ps'

Now, entering the command lsps lsps will be aliased to will be aliased to ls -l; ps ls -l; ps, and will correctly generate ls ls output immediately followed by output immediately followed by ps ps output, as this example shows: output, as this example shows: $lsps total1253 drwx------5rootroot1024May2717:15dir1 drwxr-xr-x3rootroot1024May2722:41dir2 -rw-r--r--1rootroot23344May2722:44file1 drwxr-xr-x2rootroot12288May2516:13dir3 PIDTTYTIMECMD 892ttyp000:00:00bash 1388ttyp000:00:00ps Admittedly, this isn't a very useful command, but it is built upon in the next section.

After adding aliases, it may become easy to confuse which commands are aliases or native. To list the aliases defined for your current sh.e.l.l, simply enter the alias alias command by itself. This results in a listing of all the aliases currently in place: command by itself. This results in a listing of all the aliases currently in place: $alias aliascp='cp-i'

aliaslsps='ls-l;ps'

aliasmv='mv-i'

aliasrm='rm-i'

Note that aliases are local to your sh.e.l.l and are not pa.s.sed down to programs or to other sh.e.l.ls. You'll see how to ensure that your aliases are always available in the section Configuration files Configuration files.

Aliases are mainly used for simple command replacement. The sh.e.l.l inserts your aliased text in place of your alias name before interpreting the command. Aliases don't offer logical constructs and are limited to a few simple variable replacements. Aliases can also get messy when the use of complicated quoting is necessary, usually to prevent the sh.e.l.l from interpreting characters in your alias.

Functions In addition to aliases, bash bash also offers also offers functions functions. They work in much the same way as aliases, in that some function name of your choosing is a.s.signed to a more complex construction. However, in this case that construction is a small program rather than a simple command subst.i.tution. Functions have a simple syntax: [function]name(){command-list;} This declaration defines a function called name name. function function is optional, and the parentheses after is optional, and the parentheses after name name are required if are required if function function is omitted. The body of the function is the is omitted. The body of the function is the command-list command-list between the curly brackets ( between the curly brackets ({ and and } }). This list is a series of commands, separated by semicolons or by newlines. The series of commands is executed whenever name name is specified as a command. The simple is specified as a command. The simple lsps lsps alias shown earlier could be implemented as a function like this: alias shown earlier could be implemented as a function like this: $lsps(){ls-l;ps;} Using this new function as a command yields exactly the same result the alias did. However, if you implement this command as a function, parameters can be added to the command. Here is a new version of the same function, this time entered on multiple lines (which eliminates the need for semicolons within the function): $lsps(){ >ls-l$1 >psaux|grep'/bin/basename$1'

>} The > > characters come from characters come from bash bash during interactive entry, indicating that during interactive entry, indicating that bash bash is awaiting additional function commands or the is awaiting additional function commands or the } } character, which terminates the function definition (this is called the secondary sh.e.l.l prompt). This new function allows us to enter a single character, which terminates the function definition (this is called the secondary sh.e.l.l prompt). This new function allows us to enter a single argument argument to the function, which is inserted everywhere to the function, which is inserted everywhere $1 $1 is found in the function. These arguments are called is found in the function. These arguments are called positional parameters positional parameters because each one's number denotes its position in the argument list. This example uses only one positional parameter, but there can be many, and the number of parameters is stored for your use in a special variable because each one's number denotes its position in the argument list. This example uses only one positional parameter, but there can be many, and the number of parameters is stored for your use in a special variable $# $#.

The command implemented in the previous example function now prints to STDOUT STDOUT a directory listing and process status for any program given as an argument. For example, if the Apache web server is running, the command: a directory listing and process status for any program given as an argument. For example, if the Apache web server is running, the command: $lsps/usr/sbin/httpd yields a directory listing for /usr/sbin/httpd /usr/sbin/httpd and also displays all currently running processes that match and also displays all currently running processes that match httpd httpd: -rwxr-xr-x1rootroot3170722010-01-2214:31/usr/sbin/httpd root18820.01.5226648088?SsAug100:14/usr/sbin/httpd apache208690.00.6226643560?S04:270:00/usr/sbin/httpd apache208700.00.6226643560?S04:270:00/usr/sbin/httpd apache208720.00.6226643560?S04:270:00/usr/sbin/httpd apache208740.00.6226643560?S04:270:00/usr/sbin/httpd apache208750.00.6226643560?S04:270:00/usr/sbin/httpd apache208760.00.6226643560?S04:270:00/usr/sbin/httpd apache208770.00.6226643560?S04:270:00/usr/sbin/httpd apache208780.00.6226643560?S04:270:00/usr/sbin/httpd Configuration files It's a good a.s.sumption that every Linux user will want to define a few aliases, functions, and environment variables to suit his or her needs. However, it's undesirable to manually enter them upon each login or for each new invocation of bash bash. To set up these things automatically, bash bash uses a number of configuration files to set its operating environment when it starts. Some of these files are used only upon initial login, whereas others are executed for each instance of uses a number of configuration files to set its operating environment when it starts. Some of these files are used only upon initial login, whereas others are executed for each instance of bash bash you start, including at login time. Some of these configuration files are system-wide files for all users to use, whereas others reside in your home directory for your use alone. you start, including at login time. Some of these configuration files are system-wide files for all users to use, whereas others reside in your home directory for your use alone.

bash configuration files important to Exam 102 are listed in configuration files important to Exam 102 are listed in Table13-1 Table13-1.

Table13-1.bash configuration files

File Description /etc/profile This is the system-wide initialization file executed during login. It usually contains environment variables, including an initial PATH, and startup programs.

/etc/bashrc This is another system-wide initialization file that may be executed by a user's .bashrc for each for each bash bash sh.e.l.l launched. It usually contains functions and aliases. sh.e.l.l launched. It usually contains functions and aliases.

~/.bash_profile If this file exists, it is executed automatically after /etc/profile during login. during login.

~/.bash_login If .bash_profile doesn't exist, this file is executed automatically during login. doesn't exist, this file is executed automatically during login.

~/.profile If neither .bash_profile nor nor .bash_login .bash_login exists, this file is executed automatically during login. Note that this is the original Bourne sh.e.l.l configuration file. exists, this file is executed automatically during login. Note that this is the original Bourne sh.e.l.l configuration file.

~/.bashrc This file is executed automatically when bash starts. This includes login, as well as subsequent interactive and noninteractive invocations of starts. This includes login, as well as subsequent interactive and noninteractive invocations of bash bash.

~/.bash_logout This file is executed automatically during logout.

~/.inputrc This file contains optional key bindings and variables that affect how bash responds to keystrokes. By default, responds to keystrokes. By default, bash bash is configured to respond like the Emacs editor. is configured to respond like the Emacs editor.

NoteThe syntax ~ ~ (the tilde) refers to the current user's "home directory" (usually (the tilde) refers to the current user's "home directory" (usually /home/username /home/username). Although this shortcut may not represent much of a savings in typing, some Linux configurations may place users' directories in various and sometimes non.o.bvious places in the filesystem. Using the tilde syntax reduces the need for you to know exactly where a user's home directory is located.

In practice, users will generally (and often unknowingly) use the system-wide /etc/profile /etc/profile configuration file to start. In addition, they'll often have three personal files in their home directory: configuration file to start. In addition, they'll often have three personal files in their home directory: ~/.bash_profile ~/.bash_profile, ~/.bashrc ~/.bashrc, and ~/.bash_logout ~/.bash_logout. The local files are optional, and bash bash does not mind if one or all of them are not available in your directory. does not mind if one or all of them are not available in your directory.

Each of these configuration files consists entirely of plain text. They are typically simple, often containing just a few commands to be executed in sequence to prepare the sh.e.l.l environment for the user. Since they are evaluated by bash bash as lines of program code, they are said to be as lines of program code, they are said to be sourced sourced, or interpreted, when bash bash executes them. executes them.

Like most programming languages, sh.e.l.l programs allow the use of comments. Most sh.e.l.ls, including bash bash, consider everything immediately following the hash mark (#) on a single line to be a comment. An important exception is the $# $# variable variable, which has nothing to do with comments but contains the number of positional parameters pa.s.sed to a function. Comments can span an entire line or share a line by following program code. All of your sh.e.l.l scripts and configuration files should use comments liberally.

Files sourced at login time are created mainly to establish default settings. These settings include such things as where to search for programs requested by the user (the PATH PATH) and creation of shortcut names for commonly used tasks (aliases and functions). After login, files sourced by each subsequent sh.e.l.l invocation won't explicitly need to do these things again, because they inherit inherit the environment established by the login sh.e.l.l. Regardless, it isn't unusual to see a user's the environment established by the login sh.e.l.l. Regardless, it isn't unusual to see a user's .bashrc .bashrc file filled with all of their personal customizations. It also doesn't hurt anything, provided the file filled with all of their personal customizations. It also doesn't hurt anything, provided the .bashrc .bashrc file is small and quick to execute. file is small and quick to execute.

Although it is not necessary to have detailed knowledge of every item in your sh.e.l.l configuration files, Exam 102 requires that you understand them and that you can edit them to modify their behavior and your resulting operating environment. The following examples are typical of those found on Linux systems and are annotated with comments. Example13-1 Example13-1 shows a typical Linux systemwide shows a typical Linux systemwide profile profile. This file is executed by every user's bash bash process at login time. A few environment variables and other parameters are set in it. process at login time. A few environment variables and other parameters are set in it.

Example13-1.An example system-wide bash profile #!/bin/bash #/etc/profile

pathmunge() { if!echo$PATH|/bin/egrep-q"(^|:)$1($|:)";then if["$2"="after"];then PATH=$PATH:$1 else PATH=$1:$PATH fi fi }

#kshworkaround if[-z"$EUID"-a-x/usr/bin/id];then EUID='id-u'

UID='id-ru'

fi

#Pathmanipulation if["$EUID"="0"];then pathmunge/sbin pathmunge/usr/sbin pathmunge/usr/local/sbin fi

#Nocorefilesbydefault ulimit-S-c0>/dev/null2>&1

if[-x/usr/bin/id];then USER="'id-un'"

LOGNAME=$USER MAIL="/var/spool/mail/$USER"

fi