Linux System Administration

This page covers basic Linux system administration functions and utilities.

 Package Management
How to use Red Hat Package Management (RPM) Utility.
 Performance Monitoring
How to monitor system resources, like disk and memory.
 User & Group Administration
How to add, monitor, modify and delete users and groups.
 Performance Tuning
How to tune Linux system resources, like disk and memory.
 Java Administration
How to verify, configure and set-up Java environment.
 File System Backup
How to make and restore backup file systems.
 File System Management
How to verify, create and maintain file systems.
 Troubleshooting
How to troubleshoot installation, file system, networking, boot and other problems.


Java administration in Red Hat Linux is covered in the following three sections.

 Why is Java administration important?
A synopsis of issues requiring action.

 How do you verify Java installation?
A description of how to verify Java packages, versions and default/user access setups.

 How do you configure, replace or upgrade Java?
A step-by-step approach to replacement, upgrade and configuration of Java.


Why is Java administration important?

Red Hat Linux ships with IBM Java, which is configured during installation. IBM Java will run many applications but may encounter problems running Oracle products. Oracle encounters problems with IBM Java because it defaults to native threading and Oracle requires the green thread mode.

The IBM Java may be replaced by the current Sun Microsystems Java Software Development Kit (SDK) and Blackdown Java Runtime Environment (JRE) 1.1.8v3 to support Oracle products. There are several possible approaches but the critical outcome is that Oracle product and user accounts need their path to point to the right java and jre files.

Oracle Applications 11i includes Blackdown JRE 1.1.8v3. After laying down the file system and sourcing the environment file, it is in the $OA_JRE_TOP/bin directory. If installing Oracle Applications, verifying and setting up Blackdown JRE 1.1.8v3 can be skipped unless needed in other environments. The reference file in the context of applications is < $APPL_TOP >/APPSORA.env file.

Java maintenance releases require upgrades. Revision and upgrade of the Java SDK and $JAVA_HOME are covered in the how to replace or upgrade Java section. That section qualifies the file structure used to manage different version of the Sun Microsystems SDK and Blackdown JRE.


How do you verify Java installation?

Verifying Java has three steps as shown below. Find the installed Java packages. Determine the available Java versions. Check the default system and user Java versions.

  1. Find installed Java packages.
If the system is a new Red Hat Linux Advanced Server 2.1 installation, a single argument of IBM may be used to verify the Java packages. The following two values should be returned.

# rpm -qa | grep IBM
 IBMJava2-SDK-1.3.1-3
 IBMJava2-JRE-1.3.1-3

If the Red Hat Linux Advanced Server 2.1 installation status is unknown, the following command will verify the Java packages. While there are many possible value combinations, only three are shown below. The values shown are a new installation, an installation with both IBM and Sun Microsystems installed and an installation with Sun Microsystems installed.

# rpm -qa | grep [jJS][dDR][EkK]
 IBMJava2-JRE-1.3.1-3
 IBMJava2-SDK-1.3.1-3
- OR -
 IBMJava2-JRE-1.3.1-3
 IBMJava2-SDK-1.3.1-3
 jdk-1.3.1_08-fcs
 jre-1.3.1_08-fcs
- OR -
 jdk-1.3.1_08-fcs
 jre-1.3.1_08-fcs

Blackdown JRE is not installed as a Red Hat Linux package and cannot be found with the package management tool. Verification of Blackdown JRE is covered here since it acts like a package in the configuration of the Java home.

There are many ways to find files but the command below run by the root user will find it. The optimal way to find the jre files is to run the command below as root.

# find . -type f -print | grep bin/jre$ | xargs grep -li "Revision: 1.3"
 ./usr/java/jdk118_v3/bin/jre

If nothing is returned when run from the / (root) directory, then Blackdown JRE is probably not installed or installed in a directory with restricted permissions.

  1. Determine the available Java versions.
Since multiple Java versions may be installed on any system, build a list of java versions. This can be done by using the following command.

# find . -type l -print | grep bin/java$ | grep -v jre
 ./usr/java/jdk1.3.1_02/bin/java
 ./usr/java/jdk1.3.1_08/bin/java
 ./usr/java/jdk118_v3/bin/java

  1. Check the default system and user Java versions.
The default Java version may be found by using the which utility. All Java versions in the default $PATH may be found by using the following command.

# which -a java
 /usr/local/java/bin/java
 /usr/local/java/jre/bin/java

Based on the Java versions in the default $PATH above, the Java versions may be found by using the following command.

# /usr/local/java/bin/java -version
 java version "1.3.1_08"
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_08-b03)
 Java HotSpot(TM) Client VM (build 1.3.1_08-b03, mixed mode)

# /usr/local/java/jre/bin/java -version
 java version "1.1.8"


How do you replace or upgrade Java?

  1. Uninstall IBM JRE and SDK.
Uninstall the IBM Java Runtime Environment (JRE) and Java Software Development Kit (SDK) using the Linux rpm utility.
# rpm -ev IBMJava2-JRE IBMJava2-SDK-1.3.1-3
  1. Download Sun Microsystems Java SDK.
Download the most recent Java 1.3.1 SDK from Sun Microsystems. If installing Oracle9i, 9.2.0.3, download the most recent Java 1.4 SDK from Sun Microsystem. A recommended approach for managing downloads is to pick a mount point and build a directory structure for patches.

A directory structure may start with a patches directory. Within the patches directory, create component directories and within the component directories version subdirectories. Sometimes, components may have subcomponents. If components are broken into subcomponents, then the subcomponents will have the version subdirectories. Both approaches are shown below.

Typical Patches Directory Layout
/u02/patches
            /java
                 /jre1.1.8
                 /sdk_1.3.1_02
                 /sdk_1.3.1_08
            /oracle
                   /9.2.0.2
                   /9.2.0.3
            /AS_2.1
                   /binutils
                   /ftp
                   /glibc
                         /2.2.4-29.1
                         /2.2.4-31.7
                         /2.2.4-32.3
                   /kernel
                          /2.4.9-e.12
                          /2.4.9-e.16
                          /2.4.9-e.24
                   /useradd

  1. Download Blackdown Java JRE 1.1.8v3.
As noted above, it is recommended the Blackdown Java JRE be stored with the Java patches, in a <mount_point>/patches/java/jre1.1.8 directory.

  1. Stage Sun Microsystems Java SDK.
Stage the most recent Java 1.3.1 SDK from Sun Microsystems. As the root user, unzip the file in the directory where it was downloaded. When the file is unzipped, it will produce a warning. The warning may be ignored because it is referring to the software license in the file. After unzipping the file, delete the compressed file. Repeat the process for Java 1.4 SDK from Sun Microsystems.

#  unzip j2sdk-1_3_1_08-linux-i586.rpm.bin
Archive: j2sdk-1_3_1_08-linux-i586.rpm.bin
warning [j2sdk-1_3_1_08-linux-i586.rpm.bin]: 58868 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  inflating: jdk-1.3.1_08.i586.rpm
  1. Install Sun Microsystems Java SDK.
The Java SDK installation will build files in a version subdirectory of the /usr/java directory. If the /usr/java directory does not exist, the first installation of Sun Microsystems Java SDK will create it. Subdirectories use a convention of jdk, release number and maintenance release number. For example, the Java SDK 1.3.1 maintenance release 8 will be in a directory path of /usr/java/jdk1.3.1_08. Repeat the process for Java 1.4 SDK from Sun Microsystems.

The strategy of using version subdirectories enables multiple versions of the Java SDK to co-exist. This enables testing a new Java SDK while maintaining a stable environment on the prior version. Enabling dual environments is covered below.

# rpm -ivh jdk-1.3.1_08.i586.rpm
  1. Install Blackdown JRE 1.1.8v3.
The Blackdown JRE 1.1.8v3 does not exist in a Linux RPM format. The following command unzips and positions the tape archived files in a sibling directory to Sun Microsystems Java SDK installations.

# bunzip2 -dc jdk118_v3-glibc-2.1.3.tar.bz2 | tar -xf - -C /usr/java
  1. Configure a $JAVA_HOME.
Java executables depend on file system hierarchies to access components. Java homes are built when a Java JRE or SDK are installed. This describes how to build a default $JAVA_HOME that combines Java 1.1 and Java 1.3. Combining the two is necessary because JRE functionality was deprecated with Java 2 or Java 1.2.

While some dependencies are easy to see, others are not. For example, the SDK java executable is a symbolic link pointing to the $JAVA_HOME/.java_wrapper script. The .java_wrapper script determines which java executable in the Java SDK file hierarchy should be called. The default selection is the green threads java but if the java command is provided an option of "-native", it will run the native threads java.

Likewise, the jre executable is a shell script mirroring the functionality of the .java_wrapper file. Green threads jre is also the default for the jre script.

  1. Create a directory.

The convention on Linux for the $JAVA_HOME is to place it in /usr/local/java.

# mkdir /usr/local/java
  1. Create symbolic links from the Java SDK to the $JAVA_HOME.

There may be multiple Java SDK versions installed on a machine. The example assumes that Java SDK 1.3.1 maintenance release 8 is selected. If this is not the case, please modify the commands accordingly. If existing links are present, they should be removed first.

While it is not necessary to reference all the files, it makes the $JAVA_HOME appear complete to users who might poke around in the system. So, both required and optional links are noted below.

# ln -s /usr/java/jdk1.3.1_08/bin /usr/local/java/bin
# ln -s /usr/java/jdk1.3.1_08/include /usr/local/java/include
# ln -s /usr/java/jdk1.3.1_08/lib /usr/local/java/lib
# ln -s /usr/java/jdk1.3.1_08/man /usr/local/java/man
# ln -s /usr/java/jdk1.3.1_08/COPYRIGHT /usr/local/java/COPYRIGHT
# ln -s /usr/java/jdk1.3.1_08/LICENSE /usr/local/java/LICENSE
# ln -s /usr/java/jdk1.3.1_08/README /usr/local/java/README
# ln -s /usr/java/jdk1.3.1_08/README.html /usr/local/java/README/html
# ln -s /usr/java/jdk1.3.1_08/README.html /usr/local/java/README.html
# ln -s /usr/java/jdk1.3.1_08/src.jar /usr/local/java/src.jar
  1. Create symbolic link from the Backdown JRE to the $JAVA_HOME.

A single symbolic link is required to tie in Blackdown JRE 1.1.8v3 into the $JAVA_HOME.

# ln -s /usr/java/jdk118_v3 /usr/local/java/jre
NOTE:
If installing Oracle9i, 9.2.0.3, DO NOT configure a separate $JAVA_HOME for Java 1.4 SDK from Sun Microsystem. Configure the path of the user installing Oracle9i to point to java executable as the second in sequence.

Sequencing of same name executables is best illustrated by the "which -a" command.

  1. Configure default Java environment files.
Location of these files is based on the above instructions for Red Hat Linux AS 2.1. If other directories have been chosen or another release installed, they may not exist. If the example files exist, they should be modified to match any changes. Alternatively, the following templates may be used in Red Hat Linux AS 3.0.

When users log into the Red Hat Linux operating system, several scripts are used to configure user accounts. Java is configured automatically for all users based on their default shell by the files noted below. Installing the Sun Microsystems Java SDK or Blackdown JRE does not automatically create these but fortunately when you removed the IBM Java packages, examples shell scripts were left on the file system.

The example shell scripts will be found in the /etc/profile.d directory for an installation of Red Hat Linux AS 2.1. They have the extension of .rpmsave. Copy the files without the second .rpmsave extension and edit them as noted below. The java_jre.sh or java_jre.csh is executed before the java_sdk.sh or java_sdk.csh file. This ensures correct sequencing to the $PATH environment variable.

UNIX
Shell
Java Default Environment Files
Java SDK Java JRE
Bash
Bourne
Korn
File Name: java_sdk.sh

root=/usr/local/java

if ! echo ${PATH} | grep -q "${root}/bin" ; then
  PATH=${root}/bin:${PATH}
fi

File Name: java_jre.sh

root=/usr/local/java/jre

if ! echo ${PATH} | grep -q "${root}/bin" ; then
  PATH=${root}/bin:${PATH}
fi

csh
tcsh
File Name: java_sdk.csh

root = /usr/local/java

if ( $root/bin !~ "${path}" ) then
  set path = ( $root/bin $path )
endif

File Name: java_jre.csh

root = /usr/local/java

if ( $root/jre/bin !~ "${path}" ) then
  set path = ( $root/jre/bin $path )
endfi

  1. Configure override $JAVA_HOME.
Alternates to the default $JAVA_HOME may be built. The above instructions can be used by changing the target directly location of /usr/local/java. Overriding which $JAVA_HOME a user accesses may be done in three steps.

  1. Copy the java source files from the /etc/profile.d directory to a home directory of a user. Rename the files by prepending a dot to each file so they appear as configuration files.

  2. Source the java_jre.sh and java_sdk.sh or java_jre.csh and java_sdk.csh in the appropriate shell environment file shown in the matrix below.

  3. Add a $JAVA_HOME environment variable to the appropriate shell environment file shown in the matrix below.

Source
File
Shell Environment Files
Bourne Bash csh/tcsh Korn
java_jre.sh .profile .bash_profile or
.bashrc
  .profile or
.kshrc
java_sdk.sh .profile .bash_profile or
.bashrc
  .profile or
.kshrc
java_jre.csh     .login or
.cshrc
 
java_sdk.csh     .login or
.cshrc
 
  1. Configure slots to support Java.
Alternates to a default $JAVA_HOME environment variable may be desired in environments that support multiple user slots for testing. Each slot may require a different version of the Java SDK. In some environments, the Java SDK may be NFS mounted.

The following assumes Java SDKs have been NFS mounted.

  1. As the superuser, create symbolic links to the NFS mounted Java SDKs using this syntax.
# ln -s <NFS location>/jdk1.3.1_08 /usr/java/jdk1.3.1_08
  1. Make a local directory in each slot's home directory as the superuser.
# mkdir <User_Home_Directory>/local
  1. As the superuser, change ownership of the local directory to the user. This assumes that each user is not built with their own group and is assigned the users group as their primary group.
# chmod <User_Name>:users <User_Home_Directory>/local
  1. Create symbolic links to the local symbolic link that points to the most commonly used NFS mounted Java SDKs using this syntax as the superuser.
# ln -s /usr/java/jdk1.3.1_08 <User_Home_Directory>/local/java
  1. As the superuser, change ownership of the java symbolic link to the user. This assumes that each user is not built with their own group and is assigned the users group as their primary group.
# chmod <User_Name>:users <User_Home_Directory>/local/java
  1. Create the following files in the /etc/profile.d directory, which is read by each user's login.

UNIX
Shell
Java Default Environment Files
Java SDK Java JRE
Bash
Bourne
Korn
File Name: java_sdk.sh

root=${HOME}/local/java

if ! echo ${PATH} | grep -q "${root}/bin" ; then
  PATH=${root}/bin:${PATH}
fi

File Name: java_jre.sh

root=${HOME}/local/java/jre

if ! echo ${PATH} | grep -q "${root}/bin" ; then
  PATH=${root}/bin:${PATH}
fi

csh
tcsh
File Name: java_sdk.csh

root = ${home}/local/java

if ( $root/bin !~ "${path}" ) then
  set path = ( $root/bin $path )
endif

File Name: java_jre.csh

root = ${home}/local/java

if ( $root/jre/bin !~ "${path}" ) then
  set path = ( $root/jre/bin $path )
endfi