Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Application Server 7, Enterprise Edition Installation Guide

Chapter 3
Preparing for HADB Setup

After the high-availability components have been installed on the servers that will be part of an cluster, perform the tasks in this chapter to prepare for setting up high availability. Refer to "Installation Roadmap" to see the full sequence of events for implementing the Sun ONE Application Server 7, Enterprise Edition product.

The following topics are addressed here:

After you have done the tasks here, proceed to the Sun ONE Application Server Administrator’s Guide for comprehensive instructions on configuring and managing the cluster, the load balancer plug-in, and the high-availability database (HADB).

Information on high-availability topologies is available in the Sun ONE Application Server System Deployment Guide.

Configuring Shared Memory and Semaphores

You will need to configure shared memory for the HADB host machines before beginning to work with the HADB.

  1. Log in as root.

    2. Note

    If necessary, make sure permissions are set correctly to administer the HADB as non-root user. See "Setting up RSH for HADB Administration", Step 5.

  2. Add lines similar to the following to the /etc/system file if they do not already exist:

    3. For shared memory:

    set shmsys:shminfo_shmmax=0x80000000
    set shmsys:shminfo_shmseg=20

    This example sets maximum shared memory shmmax to 2GB (hexadecimal 0x80000000) which is sufficient for most configurations.

    The shmsys:shminfo_shmmax setting is calculated as 10,000,0000 per 256 MB and should set to be identical to the memory size for the host. To determine your host’s memory, run this command:

    prtconf | grep Memory

    Then plug the value into the following formula:

    ((<host> MB / 256 MB) * 10,000,000)

    For semaphores:

    Your /etc/system file may already contain semmni, semmns, and semmnu entries. For example:

    set semsys:seminfo_semmni=10
    set semsys:seminfo_semmns=60
    set semsys:seminfo_semmnu=30

    Note

    Your original /etc/system file may or may not contain all of these entries.

    If the entries are present, increment the values by adding 16, 128, and 1000 respectively, as follows:

    set semsys:seminfo_semmni=26
    set semsys:seminfo_semmns=188
    set semsys:seminfo_semmnu=1030

    If your /etc/system file does not contain the above mentioned entries, add the following entries at the end of the file:

    set semsys:seminfo_semmni=16
    set semsys:seminfo_semmns=128
    set semsys:seminfo_semmnu=1000

    This is sufficient to run up to 16 HADB nodes on the computer.

  3. Reboot the machine for changes to take effect.

For an explanation of HADB nodes, see Configuring the High Availability Databasein the Sun ONE Application Server Administrator’s Guide.

Setting Up Host Communication

To implement remote access for HADB administration, all machines that will be used for running HADB servers and the HADB management client must be configured for Remote Shell (RSH) or Secured Shell (OpenSSH/SSH).

RSH is a simple remote shell command and does not have any security features. The SSH communication channel provides a level of security by encrypting the data that passes between the HADB nodes.

Note

For Solaris 9, it is recommended that you use the default installation of SSH. However, you can use RSH if preferred by following the instructions in "Setting up RSH for HADB Administration" and then editing the clresource.conf file to specific RSH as described in "Running the clsetup Command".

On Solaris 8, by default SSH is not installed. Follow the instructions in "Installing SSH for Solaris 8" if SSH is not on your Solaris 8 system.

If you want to use SSH, but it is not configured or not available, you will not be able to use the hadbm command. Refer to "SSH Requirements and Limitations" to verify that SSH is recognized.

This section contains instructions for the following tasks:

Setting up RSH for HADB Administration

If you want to use RSH instead of SSH, you must explicitly specify RSH using the set managementProtocol option. Refer to Table 3-3 for guidelines on setting this parameter in the clresource.conf file.

Note

SSH is the strongly recommended default for the hadbm create command because SSH is more secure than RSH.

To implement RSH, perform these steps:

  1. Log in as root.
  2. Edit the /etc/hosts file to contain entries for all the selected HADB hosts, including the host name of the local host. Use localhost format. For example:

    3. computer1.xbay.company.com
    computer99.zmtn.company.com

  3. Append this file to the /etc/hosts file of all selected installation hosts.
  4. Create a .rhosts file in the $HOME directory of the HADB user, if one does not already exist.

    5. vi .rhosts

  5. Verify that permissions are set to Read Only for group and other. For example:

    6. rw-r--r--

  6. Add the host name of each HADB host, including the name of your local host, followed by the name of your database user. For example, if the database user is Jon:

    7. computer1.xbay.company.com Jon
    computer99.zmtn.company.com Jon
    mine456.red.mycompany.com  Jon

  7. Append this file to the .rhosts file of each HADB host.
  8. Check host communication for each host. For example:

    9. rsh computer99.zmtn.company.com uname -a

    If all is well, the identity will be returned from the other host.

Setting Up SSH for HADB Administration

SSH is strongly recommended for using the hadbm create command because SSH is more secure than RSH.

Note

From a security perspective, the DSA-based version 2 protocol is recommended instead of the RSA-based version 1 protocol. The version you select depends on the SSH client software in use at your site.

This section contains the following sections:

SSH Requirements and Limitations

Note

Although SSH is installed by default on Solaris 9 systems, on Solaris 8, by default SSH is not installed. Instructions for installing SSH for Solaris 8 are contained in "Installing SSH for Solaris 8".

You may need to take action on any or all of the following requirements during your SSH setup:

Installing SSH for Solaris 8

The ssh and scp binaries are not installed by default on Solaris 8 systems. If the binaries are not on your Solaris 8 system, perform these steps:

  1. Go to the following site:

    2. http://www.sunfreeware.com/openssh8.html

    On this site, you may receive a message similar to the following:

    ===PLEASE NOTE!!!............ make a note of some of the mirror sites so that if the servers are down, you can still download from a mirror site.

    If you receive such a message, try one of the many mirror sites listed in the FTP/Mirror Sites link. For example:

    http://sunfreeware.secsup.org/

  2. On this site, follow the instructions in the Installation Steps to download and install all the necessary OpenSSH packages and patches.
  3. After you have installed OpenSSH, proceed to the next section on Configuring SSH.

Configuring SSH

To set up SSH on a system where the ssh and scp binaries are already installed, perform the steps in one of the following sections:

SSH for Non-Mounted Home Directories

To implement SSH in systems with home directories that are not mounted, perform these steps:

  1. Verify that SSH requirements have been understood and met as specified in "SSH Requirements and Limitations".
  2. Log in to the host as the HADB user.
  3. Generate your keys by running the following:

    4. ssh-keygen -t dsa

    For SSH1 and OpenSSH/1, you normally do not need to give any parameters to the ssh-keygen command.

  4. For the next three prompts, accept the default options by pressing Enter.
  5. Repeat steps 1, 2, and 3 for all machines in your cluster.

A file called identity.pub or id_dsa.pub (depends on whether you are using SSH version 1 or version 2) located in your ~/.ssh directory holds the public key. To connect to a machine without being asked for a password, the content of this file must be appended to a file called authorized_keys on all the machines.

  1. To set up login identity, go to your user directory:

    2. ~/.ssh.

    For SSH1, OpenSSH/1:

    1. Copy the identity.pub file and name it authorized_keys.
    2. For each of the other machines in the cluster, copy the content of the identity.pub file and append it to the local authorized_keys file.

      3. OpenSSH/2:

    3. Copy the id_dsa.pub file and name it authorized_keys2.
    4. For each of the other machines in the cluster, copy the content of the id_dsa.pub file and append it to the local authorized_keys2 file.
  2. Copy the authorized_keys file to the ~/.ssh directory on all the HADB machines.
  3. Verify that the .ssh directory, HADB user’s home directory, and the .ssh/authorized_keys file do not have write permissions for group and other.

    4. If needed, disable these group/other write permissions as follows:

    chmod og-w ~/.ssh
    chmod og-w ~/.ssh/authorized_keys
    chmod og-w $HOME

    Replace $HOME with the home directory of the HADB user. For example:

    chmod og-w ~/johnsmith

    Note

    If the files under the ~/.ssh directory have even read permission given to group/other, you cannot set up an automatic SSH login identity. In this case, if you try ssh machine_name, the system complains about the incorrect permissions and asks for a password. In other words, it is best not to give any permissions at all for group/other if you want to enable automatic login.

  4. To enable login without any user input, at initial SSH usage (after the SSH environment is set up) you need to add the node machine name to the known_hosts file under the /.ssh directory as follows:
    1. Type the following:

      2. ssh machine_name

      You will be prompted with a Yes/No question whether to add machine_name to the known_hosts file.

    2. Answer Yes.

      3. You will now be able to log in without any input.

  5. To verify that SSH is set up correctly, SSH to each host in the cluster before trying to run the management tool for HADB.

    6. You are automatically logged in without a password requirement.

SSH for Mounted Home Directories

To implement SSH in systems with mounted home directories, perform these steps:

  1. Verify that SSH requirements have been understood and met as specified in "SSH Requirements and Limitations"
  2. Log in to host as the HADB user.
  3. Generate your keys by running the following:

    4. ssh-keygen -t dsa

    For SSH1 and OpenSSH/1, you normally do not need to give any parameters to the ssh-keygen command.

  4. For the next three prompts, accept the default options by pressing Enter.

    5. A file called identity.pub or id_dsa.pub (depends on whether you are using SSH version 1 or version 2) located in your ~/.ssh directory holds the public key. To connect to a machine without being asked for a password, the content of this file must be appended to a file called authorized_keys2 on all the machines. This can be done as follows:

  5. To set up login identity, go to your user directory:

    6. ~/.ssh.

    For SSH1, OpenSSH/1—Copy the identity.pub file and name it authorized_keys.

    For OpenSSH/2—Copy the id_dsa.pub file and name it authorized_keys.

  6. Verify that the .ssh directory and the .ssh/authorized_keys file do not have write permissions for group and other.

    7. If necessary, disable these group/other write permissions as follows:

    chmod og-w ~/.ssh
    chmod og-w ~/.ssh/authorized_keys
    chmod og-w /$HOME

    Replace HOME with the home directory of the HADB user. For example:

    chmod og-w ~/johnsmith.

    Note

    If the files under the ~/.ssh directory have even read permission given to group/other, you cannot set up an automatic SSH login identity. In this case, if you try to run ssh machine_name, the system complains about =incorrect permissions and asks for a password. In other words, it is best not to give any permissions for group/other if you want to enable automatic login.

  7. To enable login without any user input, at initial SSH usage (after the SSH environment is set up) you need to add the node machine name to the known_hosts file under the /.ssh directory
    1. Type the following:

      2. ssh machine_name

      You will be queried about whether or not to add machine_name to the known_hosts file.

    2. Answer Yes.

      3. You will now be able to log in without any input.

  8. To verify that SSH is set up correctly, SSH to each host in the cluster before trying to run the management tool for HADB.

    9. You are automatically logged in without a password requirement.

Setting Up the User Environment

After you have set up host communication, you can run the hadbm command from the install_dir/SUNWhadb/4/bin directory location as follows:

However, it is much more convenient to set up your local environment to use the high-availability management client commands from anywhere. To set this up, perform the following steps.

Note

The examples in this section apply to using csh. If you are using another shell, refer to the man page for your shell for instructions on setting variables.

  1. Set the PATH variable as follows.

    2. setenv PATH ${PATH}:install_dir/bin:install_dir/SUNWhadb/4/bin

  2. Verify that the PATH settings are correct by running the following commands:

    3. which asadmin
    which hadbm

  3. If multiple Java versions are installed on your system, you must ensure that the JAVA_HOME environment variable points to the correct Java version (1.4.1_03 for Enterprise Edition).

    4. setenv JAVA_HOME java_install_dir
    setenv PATH ${PATH}:${JAVA_HOME}/bin

Setting Up Administration for Non-Root

By default, during the initial installation or setup of the Sun ONE Application Server, write permissions of the files and paths created for Sun ONE Application Server are given to root only. For a user other than root to create or manage the Sun ONE Application Server, write permissions on the associated files must be given to that specific user, or to a group to which the user belongs. The files that are affected are the following (with their default locations):

You can create a user group for managing the Sun ONE Application Server as described in the following procedure. (An alternate approach is to set permissions and ownership for the specific user.)

To create a Sun ONE Application Server user group and set permissions on the installation root directory, repeat the following process for each affected file:

  1. Log in as root.
  2. From the command prompt, create the Sun ONE Application Server user group. For example:

    3. # groupadd s1asuser

    You can type groupadd at the command line to see appropriate usage.

  3. Change the group ownership for each affected file to the newly-created group. For example:

    4. chgrp -R s1asuser install_config_dir/cl*.conf

  4. Set the write permission for the newly-created group:

    5. chmod -R g+rw install_config_dir/cl*.conf

  5. Repeat steps 3 and 4 for each affected file.
  6. Make the clsetup and cladmin commands executable by the newly-created group. For example:

    7. chmod -R g+x install_dir/bin/cl*

  7. Delete and recreate the default domain, domain1, using the --sysuser option. The sysuser must also belong to the newly-created group. For example:

    8. asadmin delete-domain domain1

    asadmin create-domain --sysuser bleonard --adminport 4848 --adminuser admin --adminpassword password domain1

Using the clsetup Command

The purpose of the clsetup command is to automate the process of setting up a basic cluster in a typical configuration. The clsetup command is located in install_dir/bin, where install_dir is the directory where the Sun ONE Application Server software is installed.

The clsetup command is bundled with the Sun ONE Application Server software along with the cladmin command.

Note

The cladmin command is used to streamline the process of configuring and administering the cluster after all installation and configuration tasks are complete, and is not documented here.

When you have completed the tasks in this Installation Guide, refer to the Sun ONE Application Server Administrator’s Guide for instructions on creating the HADB and on using on the cladmin command.

The following topics are addressed in this section:

How the clsetup Command Works

The clsetup command is a set of Sun ONE Application Server commands that are gathered together in a script that allows a cluster to be configured automatically, based on prepopulated input files. As part of cluster setup, an HADB is created, but you will still need to set up your working cluster using the hadbm commands as described in the Sun ONE Application Server Administrator’s Guide.

Note

The clsetup command interface is unstable. An unstable interface may be experimental or transitional, and may therefore change incompatibly, be removed, or be replaced by a more stable interface in the next release.

The following topics are addressed in this section:

How the Input Files Work

Three input files are used by the clsetup command to configure the cluster:

You can use the clsetup configuration parameters as they are preconfigured to set up a typical cluster configuration. To support a different configuration, you can make edits to any or all of the configuration files.

What the clsetup Command Accomplishes

Using the pre-populated values in the clsetup input files, the clsetup command accomplishes the following:

Commands Used by the clsetup Command

The clsetup command uses a number of hadbm and asadmin commands to perform the steps for setting up the cluster. In Table 3-1, the clsetup task is described in the left column and the command used to accomplish the task is listed in the right column.

Table 3-1  hadbm and asadmin Commands Used by the clsetup Command 

Task Performed by clsetup

Command

Checks to see if database exists.

hadbm status

Creates and starts the HADB.

hadbm create

Gets the JDBC URL.

hadbm get jdbcURL

Creates the session store.

asadmin create-session-store

Checks the instance status.

asadmin show-instance-status

Creates the instance.

asadmin create-instance

Creates the JDBC connection pool.

asadmin create-jdbc-connection-pool

Registers the data source.

asadmin create-jdbc-resource

Configures the persistence type

asadmin configure-session-persistence

Reconfigures the instance.

asadmin reconfig -u admin

clsetup Requirements and Limitations

The following requirements and limitations apply to the clsetup command:

Editing the clsetup Input Files

The input files that are needed for the clsetup command are installed under the configuration installation directory, default /etc/opt/SUNWappserver7, as part of the installation procedure. The installation program pre-populates these files with the values to set up a typical configuration, but you can edit any or all of them as needed using a text editor.

This section addresses the following topics:

The clinstance.conf File

For the clsetup command to work properly, all application server instances that are part of a cluster must be defined in the clinstance.conf file. During installation, the installation program creates a clinstance.conf file with entries for two instances. If you add more instances to the cluster, you must add information about these additional instances.

The format of the clinstance.conf file is as follows:

One set of entries is required for each instance that is part of the cluster. Any line that starts with a hash mark (#) is treated as a comment.

Note

The order in which these entries appear in the clinstance.conf file is important and must not be changed from the order specified here.

If you add information about more application server instances, entries for these instances must appear in this order.

Comments can be added anywhere in the file.

Table 3-2 provides information about the entries in the clinstance.conf file. The left column contains the parameter name, the middle column defines the parameter, and the right column contains the default value specified by the installation program.

Table 3-2  Entries in the clinstance.conf File 

Parameter

Definition

Default Value

instancename

Application Server instance name

server1, server2

user

Admin Server user name

admin

host

Host name

localhost

port

Admin Server port number

4848

domain

Administrative domain name

domain1

instanceport

Application Server instance port

80, 81

Example clinstance.conf File

This clinstance.conf file contains information about two instances.

#Instance 1

instancename server1
user admin
host localhost
port 4848
domain domain1
instanceport 80

#Instance 2

instancename server2
user admin
host localhost
port 4848
domain domain1
instanceport 81

The clpassword.conf File

When the clsetup command is run, the asadmin command needs the Admin Server password, which is specified in the clpassword.conf file during installation.

The format of the clpassword.conf file is as follows:

where password is the Admin Server password.

Permissions 0600 are preset on the clpassword.conf file, which can only be accessed by the root user.

The clresource.conf File

During installation, the installation program creates the clresource.conf file to set up a typical configuration. The clresource.conf file contains information about the following resources that are part of the cluster:

Permissions 0600 are preset on the clresource.conf file, which can only be accessed by the root user.

Note

Before running the clsetup command, the values specified in the clresource.conf file can be modified for optimization, or for setting up a different configuration. If you edit the values, make sure that the order and format of the file is not changed.

Any line that begins with a hash mark (#) is treated as a comment.

The parameters of the clresource.conf file are described in the following tables. The left column contains the parameter name, the middle column defines the parameter, and the right column contains the default value specified by the installation program.

Table 3-3 describes the HADB parameters in the clresource.conf file.

Table 3-3  HADB Parameters in the clresource.conf File 

Parameter

Definition

Default Value

historypath

Path for the history files.

/var/tmp

devicepath

Path for the data and log devices.

/opt/SUNWappserver7/SUNWhadb/4

datadevices

Number of data devices on each node.

1

portbase

Port base number used for node 0. Other nodes are then assigned port number bases in increments of 20 from the number specified here (a random number in the range 10000 - 63000).

15200

spares

Number of spare nodes.

0

set

Comma-separated list of database configuration attributes.

For explanations of valid database configuration attributes, see Sun ONE Application Server Administrator’s Guide.

For example, to specify the use of RSH instead of SSH (the default), uncomment the following line:

#set managementProtocol=rsh

inetd

Indicates if HADB runs with the inet daemon.

false

inetdsetupdir

Directory where theinet daemon setup files will be put.

/tmp

devicesize

Size of device in MB. This size is applicable to all devices.

512

dbpassword

Password for the HADB user.

password

hosts

All hosts used for all data nodes.

Values are populated automatically based on the hosts specified during installation.

Note

The database name is specified at the end of the [HADBINFO] section in the clresource.conf file.

Table 3-4 describes the session store parameters in the clresource.conf file.

Table 3-4  Session Store Parameters in the clresource.conf File 

Parameter

Definition

Default Value

storeurl

URL of the HADB store

REPLACEURL

NOTE: Value is replaced by actual URL at runtime.

storeuser

User who has access to the session store

appservusr

NOTE: Must match the username property in Table 3-5.

storepassword

Password for the storeuser

password

NOTE: Must match the password property in Table 3-5.

dbsystempassword

Password for the HADB system user

password

Table 3-5 describes the JDBC connection pool parameters in the clresource.conf file.

Table 3-5  JDBC Connection Pool Parameters in the clresource.conf File 

Parameter

Definition

Default Value

steadypoolsize

Minimum and initial number of connections maintained in the pool.

8

maxpoolsize

Maximum number of connections that can be created.

32

datasourceclassname

Name of the vendor-supplied JDBC datasource.

Name of the vendor-supplied JDBC datasources capable datasource class will implement javax.sql.XADatasource interface.

Non-XA or Local transactions only datasources will implement javax.sql.Datasource interface.

com.sun.hadb.jdbc.ds.HadbDataSource

isolationlevel

Specifies the transaction isolation level on the pooled database connections.

repeatable-read

validationmethod

Specifies the type of validation method.

meta-data

property

Property used to specify username, password, and resource configuration.

username=appservusr:password=password:cacheDataBaseMetaData=false:eliminateRedundantEndTransaction=true:serverList=REPLACEURL

NOTE: Make sure that the username and password properties use the same values as shown in the Session Store Parameters table. REPLACEURL is replaced by the actual URL at runtime.)

Note

The connection pool name is specified at the end of the [JDBC_CONNECTION_POOL] section in the clresource.conf file.

Table 3-6 describes the JDBC resource parameters in the clresource.conf file.

Table 3-6  JDBC Resource Parameters in the clresource.conf File 

Parameter

Definition

Default Value

connectionpoolid

Name of the connection pool

appservCPL

NOTE: Connection pool name is specified in Table 3-5.

Note

The JDBC resource name is defined at the end of the [JDBC_RESOURCE] section in the clresource.conf file.

Table 3-7 describes the session persistence parameters in the clresource.conf file.

Table 3-7  Session Persistence Parameters in the clresource.conf File 

Parameter

Definition

Default Value

type

Session persistence type

ha

frequency

Session frequency

web-method

scope

Session scope

session

store

Session store

jdbc/hastore

NOTE: Store name is defined at end of the [JDBC_RESOURCE] section.

Example clresource.conf File

[HADBINFO]
historypath /var/tmp
devicepath /opt/SUNWappserver7/SUNWhadb/4
datadevices 1
portbase 15200
spares 0
#set    managementProtocol=rsh
inetd false
inetdsetupdir /tmp
devicesize 512
dbpassword password
hosts machine1,machine1
hadb

[SESSION_STORE]
storeurl                 REPLACEURL
storeuser              appservusr
storepassword             password
dbsystempassword        password

[JDBC_CONNECTION_POOL]
steadypoolsize         8
maxpoolsize         32
datasourceclassname     com.sun.hadb.jdbc.ds.HadbDataSource
isolationlevel          repeatable-read
validationmethod        meta-data
property username=appservusr:password=password:cacheDataBaseMetaData=false:e liminateRedundantEndTransaction=true:serverList=REPLACEURL

appservCPL

[JDBC_RESOURCE]
connectionpoolid      appservCPL
jdbc/hastore

[SESSION_PERSISTENCE]
type            ha
frequency        web-method
scope            session
store              jdbc/hastore

Running the clsetup Command

The syntax for running the clsetup command is as follows:

If no arguments are specified, the clsetup command assumes the following defaults:

You can override these arguments by providing custom input file locations. For example:

To run the clsetup command, perform the following steps:

  1. Verify that the requirements have been met as described in "clsetup Requirements and Limitations".

    2. Note

    If you want to run the clsetup command as a user other than root, follow the instructions in "Setting Up Administration for Non-Root" to set this up.

  2. Verify that the input files have the information that is required to set up the cluster. If necessary, edit the input files following the guidelines in "Editing the clsetup Input Files".
  3. If you are using RSH, edit the clresource.conf file to uncomment the following line (remove the # sign):

    4. #set managementProtocol

  4. Go to the Sun ONE Application Server installation /bin directory:

    5. cd install_dir/bin

  5. Invoke the clsetup command using the appropriate syntax. For example, to run the command using the defaults:

    6. ./clsetup

    The clsetup command displays the welcome message, the prerequisites for configuring the cluster, and the following message:

    Do you want to start configuring your cluster? [Yes/No]

  6. To start configuring, type Yes and press Enter.

    7. The clsetup command runs in verbose mode. The various commands are displayed on the screen as they run, and the output is redirected to the log file, /var/tmp/clsetup.log.

    If a vital error occurs (for example, failure to create a non-existing HADB), the configuration stops and the error is recorded in the log file. If the log file already exists, the output is appended to the existing log file.

    Note

    If the entities to be handled (HADB nodes and Application Server instances) already exist, the clsetup command does not delete or reconfigure them, and the respective configuration steps are skipped. This type of event is recorded in the log file.

  7. When the clsetup command completes the configuration, you are advised about the location of the log file. It’s a good idea to scan the log file after each run.
  8. Upon completion, the clsetup command returns the exit codes as described in Table 3-8:

    9. Table 3-8  Exit Codes for the clsetup Command 

    Exit Code

    Description

    0

    Successful exit

    2

    Usage error

    3

    Instance file not found

    4

    Instance file cannot be read

    5

    Resource file not found

    6

    Resource file cannot be read

    7

    Password file not found

    8

    Password file cannot be read

    10

    Script cannot find asadmin

    11

    Script cannot find hadbm

    12

    Cannot create temporary file

    13

    Session store configuration failed

    14

    Create HADB failed

    15

    HADB get jdbcURL failed

    16

    User exits in welcome message

You can obtain a list of the exit codes by running the following command from the command line immediately after running the clsetup command:

Cleanup Procedures for the clsetup Command

After running the clsetup command, errors that have occurred are logged in the log file /var/tmp/clsetup.log. Examine the log file after every run of the clsetup command and correct any significant errors that are reported (for example, failure to create a non-existing instance).

You can undo all or part of the configuration as follows:

After you have completed the tasks in this chapter (and the post-installation tasks in the following chapter, if needed), proceed to the Sun ONE Application Server Administrator’s Guide for instructions on configuring the HADB and managing the cluster, the load balancer plug-in, and the HADB.



Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.