You must set one or more WebSphere variables before you
can use the job manager to remotely install and manage Liberty profile servers. You can
set the variables in an administrative console, a wsadmin script,
or the registerHost command. The variables specify
the root directories to which to install Liberty profile resources and specify
search paths for finding resources that are not yet registered with
the job manager.
Before you begin
Liberty profile resources
include projects, software development kits (Java runtime environments), Liberty profile runtimes, servers,
and applications. For more information, see Liberty profile resources.
If
you are using an administrative console, wsadmin, or the registerHost command
to set values for Liberty profile server
variables, start the job manager or the deployment manager.
About this task
You can specify values for WebSphere variables and built-in
variables.
- WebSphere variables
Before you can install Liberty resources using the job manager,
you must set one or more WebSphere variables. The amount of configuration
depends on the topology being deployed. You can set values for variables
using the job manager console, deployment manager console, wsadmin,
or registerHost command.
You can install
Liberty resources to a working, non-shared location or to a shared
location. Do not share resources that are installed to the working
location.
Resources installed to a shared location
can be used by
Liberty profile servers
that are installed to a working location. For example, you can configure
working
Liberty profile servers
to use one or more of the following types of shared resources:
- Liberty profile runtime
- Software development kit
- Application
Install resources in shared locations as read-only. You can share
resources within a host or across hosts using disk sharing approaches
such as Network File System (NFS).
During resource installation,
unless there is a name conflict, the resources in the Liberty profile compressed file
are extracted to the working root directory specified by WLP_WORKING_DIR
or to the shared directory specified by WLP_SHARED_DIR.
Table 1. Liberty profile default variables. Specify a directory path for the nonshared working directory,
at minimum.Default variables |
Description |
WLP_WORKING_DIR |
Specifies the installation or inventory search
path for nonshared working Liberty profile resources. If a
job submission does not specify that the installation or search directory
be shared, then the job uses this variable. By default, Liberty resources
are installed to the nonshared working directory that this variable
defines. Specify an absolute path for this variable. Do not specify
a relative path.
|
WLP_SHARED_DIR |
Specifies the installation or inventory search
path for shared Liberty profile resources.
If a job submission specifies that the installation or search directory
be shared, then the job uses this variable. Specify an absolute
path for this variable. Do not specify a relative path.
|
WLP_ADDITIONAL_DIRS |
(optional) Specifies additional paths to search
for Liberty resources beyond the paths included in the WLP_SHARED_DIR
and WLP_WORKING_DIR variables. You must configure the additional
search paths for Liberty resources to: - Search for previously installed software development kits that
are managed separately from the job manager.
- Search for any server resources that are not installed in the
default working and shared directories. For example, you might define
different installation locations relative to the home directories
of several different users. For more information, see the descriptions
of the HOME and USER variables.
Specify an absolute path for this variable. Do not specify
a relative path.
|
- Built-in variables
You can use the following built-in variables
to customize installation locations and Liberty profile configuration files
based on operating system home directory, operating system user, host
name, and project membership:
- HOME
- Contains the home directory of the operating system user name
that is used to submit an Install Liberty profile resources job.
You can use the HOME variable to set up a working directory that is
relative to the home directory of the submitting user; for example:
WLP_WORKING_DIR=${HOME}/working
- USER
- Contains the name of the operating system user that is used to
submit an Install Liberty profile resources job.
You can use the USER variable to set up a working directory for each
user, relative to a global directory; for example:
WLP_WORKING_DIR=/working/${USER}
When
using the HOME variable or the USER variable to customize the installation
location, you must configure the WLP_ADDITIONAL_DIRS variable with
the specific directories for each user; for example:
WLP_ADDITIONAL_DIRS=/usr/home/user1;/usr/home/user2
If you do not include the directories in the WLP_ADDITIONAL_DIRS
variable, inventory jobs do not locate the associated Liberty profile resources on the
target hosts.
- HOSTNAME
- Contains the configured host name of the target host where an Install
Liberty profile resources job is run. You can use the
HOSTNAME variable in the server bootstrap.properties file;
for example:
hostname=${HOSTNAME}
You can then use the hostname variable in the server
configuration file,
server.xml; for example:
<httpEndpoint host="${hostname}" httpPort="9081" httpsPort="9444" id="defaultHttpEndpoint"/>
- CURRENT_PROJECT
- Contains the name of the project that is included in the Liberty profile resources compressed
file.
Procedure
You can set WebSphere variables for all target hosts
at a specified scope or set WebSphere variables at a target host level.
- Set WebSphere variables for all target hosts at a specified
scope.
You can use any of the following methods to set
WebSphere variables for all target hosts at a specified scope:
- Set WebSphere variables at the target host level.
You
can use the following methods to set WebSphere variables at the target
host level, thereby overriding the same variables set at a higher
level scope, if they exist:
- Set variables in the host properties when registering a host with
the registerHost command.
- Open a command prompt at the bin directory
of the job manager profile or the deployment manager profile.
- Start the wsadmin tool and use the Jython scripting language.
wsadmin -lang jython
- Run an AdminTask registerHost command that
specifies the variable name and value.
For example, set the WLP_WORKING_DIR
variable to use the
C:/liberty directory:
AdminTask.registerHost('-host host_name
-hostProps [[username admin][password password]
[saveSecurity true][WLP_WORKING_DIR C:/liberty]]')
For
more information on registerHost, see Registering
host computers with job managers.
- Save the changes.
- To later change a variable, you can use the AdminTask modifyManagedNodeProperties command.
For
example, set the WLP_WORKING_DIR variable to use the
C:/liberty2 directory:
AdminTask.modifyManagedNodeProperties('-managedNodeName host_name
-managedNodeProps "[WLP_WORKING_DIR C:/liberty2]"')
Results
After you save the changes, the changes are viewable in
the list of variables on a console WebSphere variables page.
Avoid trouble: After you have defined the variables,
see
Packaging Liberty profile resources for
information on how to properly package files for the Install Liberty
profile resources job. If you use IBM Installation Manager to install
a Liberty profile, create a subdirectory under the location of
WLP_WORKING_DIR.
This directory will be used to identify this instance of the Liberty
profile runtime. Use this directory as the installation directory
during installation with IBM Installation Manager. If
WLP_WORKING_DIR is
set to
/liberty/working, for example, create
a
runtime_1 subdirectory; then, use
/liberty/working/runtime_1 as
the installation directory during installation using IBM Installation
Manager.
gotcha
What to do next
You can now submit a job that installs resources from
a Liberty profile resources
compressed file, as well as an inventory job that searches for previously
existing Liberty profile resources.
You can later set variables
that override the values of variables for different target hosts or
substitute user-defined variables:
- You can choose to override the values of Liberty variables on
individual hosts by changing the target properties for each host.
First, define the appropriate default WebSphere variables at a higher-level
scope, for example:
WLP_SHARED_DIR=/shared
WLP_WORKING_DIR=/working
WLP_ADDITIONAL_DIRS=...
Then, override the values of
these variables for each target that differs from the default value.
For example, if most of your hosts are on AIX, HP-UX, Linux or Solaris
operating systems, with some Windows hosts in your environment, after
registering each Windows host, you can add the following host properties:
WLP_SHARED_DIR=c:/shared
WLP_WORKING_DIR=c:/working
- You can edit target host specific properties to substitute a user-defined
variable for individual targets. Substituting a user-defined variable
is useful when you have multiple network interfaces on each target,
and you want to specify which one to use for each target. You can
define this variable in a server bootstrap.properties file;
for example:
hostname=${hostname.interface1}
For
each target, you must define the actual value of the user-defined
variable in the target host specific properties of that host. For
example, for host1, define the value of the
interface as hostname.interface1=host1.xyz.com and
define host2 as hostname.interface1=host2.xyz.com.