Configuring the User Environment

An organization typically has two types of servers. One type has relatively static content, such as a DHCP or DNS server. The second type of server contains user files. In both cases, providing a consistent work environment for the end user is a must.

Uniformity of behavior over the server environment permits tool sets and scripts to be used cross-platform. Additionally, users do not have to remember multiple command syntaxes to achieve the same goal. In the following sections, we look at how this can be achieved in SLES first by defining a consistent command interpreter and then by selecting a standard set of variables the user can use.

Default Shell

Previously, we detailed the structure of the /etc/passwd file and identified that the last field on each record identifies the default, or login, shell. A login shell is a fancy name for a command interpreter and its associated environment.

Simply put, a shell is a program. A shell can be run interactively, spawned off as a child process, or run in the background through cron. As with any other program, a shell expects a predetermined syntax for commands and parameters. Within the lifetime of the shell process, the program allows for interaction with the operating system, other processes, and the file system.

Unlike some operating systems, Linux offers a variety of different shells such as ksh, zsh, bash, and others. Each shell supported by SLES incorporates its own syntax and command set. By specifying an initial shell for each user, you can define the type of environment a user experiences when interacting with the system.

A standard should be set for each organization to identify the default shell for all accounts. Each shell type uses a different set of configuration files. To facilitate system management, restricting changes to a single set of configuration files reduces the chances of errors. Choosing a standard shell allows scripting efforts by one individual to be shared with other users.

Selecting which shell to standardize on will invoke various arguments from the different camps as to which is best. For the purpose of this book, we restrict ourselves to describing the bash shell.

BUT I DON'T WANT BASH!

bash is not the only game in town. SLES comes bundled with a variety of other shells. In some cases, required third-party utilities use the scripting capabilities of other shells. In other cases, users with experience on other systems have tool sets of scripts.

In Linux, the first line of a shell script determines the interpreter for the script. If you look around your server at scripts in /etc/init.d, you will find the first line of many scripts showing

 #!/usr/bin/sh 

Similarly, scripts written in the programming language Perl start with a comment line like

 #!/usr/bin/perl 

The active shell under which the script is initiated interprets this first line of the script and passes the content of the script off to the identified interpreter. Hence, users who need to run specific shells for their scripts need only point their tools to the appropriate interpreter.

bash is a hybrid shell that is compatible with the original Unix sh shell but contains some features originally present only in the Korn and C shells. The following is a quick summary of what bash makes available:

• Standard command set bash invokes the standard Linux commands such as ps, df, mount, man, and so on.

• Script language bash is actually a fully scriptable language including variable, complex looping structures and if-then constructs.

• Command-line completion You can use the Tab key to trigger bash to examine the current command line and expand the provided input to an appropriate value.

  AUTOCOMPLETION

  Completely typing long names or commands is often unnecessary. bash is aware of what you are typing and can autocomplete filenames for you. As an example, type the following at a command prompt:

   Hermes> cat /etc/serv[TAB] 

  
  

  bash autocompletes the filename, and the command line becomes

   Hermes> cat /etc/services 

  
  

  You can also traverse complex directory trees by using the Tab key. Each time the Tab key is pressed, the bash shell interprets what it has found and autocompletes the command for the first target matching the current pattern of text. If the shell detects multiple targets, the cursor will not autocomplete. Pressing Tab again lists the available targets. Typing in enough text to allow bash to uniquely identify a path permits the Tab key to continue traversing the various targets.

  
  

• Command history Previously used commands can be recalled and edited using the arrow keys.

  COMMAND HISTORY

  bash allows for command-line recall and command editing using the cursor keys because bash keeps a history of past commands. Pressing the up- or down-arrow keys allows you to scroll through past commands. Pressing the left- or right-arrow keys allows you to edit the command currently present at the prompt.

  Commands can also be retrieved through a search function. If you type the first few letters of a command and press Ctrl+S, bash will retrieve the first previously used command that matches the pattern. In some ssh clients, control characters are handled differently and not passed along to the server side. In such instances, the Ctrl+S sequence may not be accessible.

  
  

• Redirection of input and output The input for commands can be redirected from a file by using the less-than sign. Also, the output from commands can be redirected to a file by using the greater-than sign.

  REDIRECTION

  Redirection at the command-line level allows the user to redefine the source of STDIN, STDOUT, and STDERR. For input redirection, the single less-than symbol followed by a filename tells the command interpreter to read keystrokes from the identified file rather than from the console keyboard.

  In the case of output, two channels exist. STDOUT is the default and can be represented by using 1> followed by a filename or, as a short form, by using a single greater-than sign because the numeric 1 is optional. When this is done, all nonerror message output written to the console STDOUT is placed in the identified file. Double greater-than signs cause the output to be appended to the target file.

  Error messages, STDERR, are written through the second channel and can be redirected by using 2> followed by a target file for error messages.

  You can also combine the standard redirect to a file (for example, > out.txt), with the 2>&1 suffix. This forces STDOUT and STDERR to the same filename. This command would look like this:

   Command > alloutput.txt 2>&1 

  
  
  
  

• Command-line pipelines Using the pipe (|) symbol, you can pass the STDOUT from one command directly to the STDIN of a second command without having to worry about temporary files to host the content.

• Environment variables bash maintains a list of predefined variables that can be used at the command line or in scripts. This list includes parameters passed between shells, local host information, the path searched when commands are invoked, as well as the prompt presented during interactive sessions. You can also define your own variables in your scripts.

Using a standard shell across the enterprise is important. It provides consistency of interface and allows for the porting of scripts from server to server. In the following section, we examine another benefit of a consistent default shell: controlling login-generated information.

Login Scripts and Environment Variables

In the preceding section, you saw that a shell is simply an instance of a program or command interpreter. This is true whether it is controlling an interactive session or running a script. A login shell is a special case of such an instance, and it triggers a number of additional events.

A login shell executes a number of additional scripts when it is invoked. These additional scripts are used to tailor the environment the user will experience. You, as the system administrator, can customize these scripts to your advantage. These login scripts can modify search paths pointing to customized resources or set up environment variables specific to third-party software. The names of the logon scripts depend on the flavor of the default login shell. If all the users on a system share the same default login shell, maintenance of login scripts will be greatly simplified.

In the case of the bash shell, the system-wide login script executed at login is stored as /etc/profile. SUSE LINUX suggests that you maintain a customized version of your login script in /etc/profile.local instead. This is done to prevent the overwriting of any customizations at upgrade time. At login, the /etc/profile script will be run followed by /etc/profile.local. One of the benefits of using a managed login script is allowing control over the setting of environment variables that can be used in other scripts or applications. Typical examples would be setting an environment variable ORACLE_HOME to point to the base directory for your Oracle install or a BACKUP_DIR variable to specify a target location for your backups.

Within the /etc/profile script, you will also find numerous calls to other scripts. One such script, /etc/bash.bashrc, creates a number of aliases that can be used as shortcuts for other commands. Listing 5.2 shows a few of the aliases provided. If you want to add a number of system-wide aliases, SLES recommends that you place them in the local version, bash.bashrc.local. This script will be run following bash.bashrc.

Listing 5.2. Some of the Aliases Generated in /etc/bash.bashrc

 alias +='pushd .' alias -='popd' alias ..='cd ..' alias ...='cd ../..' alias dir='ls -l' alias la='ls -la' alias ll='ls -l' 

The default aliases created in bash.bashrc allow users to type plus (+) to save their current working directory and minus (-) to return to that directory without the need for typing pushd and popd. Setting system-wide environment variables and aliases can make the system more comfortable for the users. A case in point would be the dir alias in Listing 5.2 that allows for DOS-type commands to appear to work in Linux.

To allow user-based customizations, bash also interprets scripts in the user's directory. At login, bash runs the first of the following files it finds in the user's directory: .bash_profile, .bash_login, or .profile. These local scripts can be used to set or override variables to better suit the end user's requirements. A typical snippet of a .bash_profile would look like Listing 5.3. In this snippet, you can see that two environment variables, BACKUP_DIR and WEB, are created, as well as an alias. The alias st, short for status, yields information on the current logged-on process, disk quota usage, as well as a summary of disk space in the user's home directory. When the user is logged in, the variables have the username of the current session in the proper locations, as shown in Listing 5.4. It is important to note that an alias is not evaluated at login; it is evaluated when invoked.

Listing 5.3. Content of a Typical ./bash_profile

 BACKUP_DIR=/backup/$USER ; export BACKUP_DIR WEB="/home/$USER/public_html" ; export WEB alias st='finger $USER ; quota $USER ; du --si -s $HOME' 

Listing 5.4. Verification of Environment Variables After Login

 eric@Athena:~> env | grep -e BACKUP BACKUP_DIR=/backup/eric eric@Athena:~> env | grep -e WEB WEB=/home/eric/public_html eric@Athena:~> alias -p | grep -e st= alias st='finger $USER ; quota $USER ; du --si -s $HOME' eric@Athena:~> 

When the $USER symbol is placed in the definitions in Listings 5.3 and 5.4, the .bash_profile script is more portable from machine to machine and user to user. A user with a privileged account on one machine, such as WEBMASTER, should have a regular account, such as eric on other servers. By using standard variables provided by bash, the login script becomes user-independent.

Upon logout, the bash shell calls one final script: .bash_logout. If this file exists at logout time, it will be executed. Users can set up routines to back up files or force a cleanup of temporary files. Here is the content of a sample .bash_logout:

 eric@Athena:~> cat ./.bash_logout mv Documents.tar.gz old_Documents.tar.gz tar -zcvf Documents.tar.gz ./Documents eric@Athena:~> 

This script makes a copy of the current archive and then creates a backup of the content of the Documents subfolder in the account's root directory. If required during an interactive session, this routine can be invoked as ./.bash_logout.

A number of automated script processes take place on login and logout. By defining environment variables and aliases, the system administrator can provide the user with a more consistent environment from server to server.