You must set one or more WebSphere variables before you can use the job manager to
remotely install and manage Liberty 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 resources and specify search paths for finding
resources that are not yet registered with the job manager.
Before you begin
Liberty resources include projects, software
development kits (Java runtime environments), Liberty
runtimes, servers, and applications. For more information, see Liberty resources.
If you are using an administrative console, wsadmin, or the registerHost
command to set values for Liberty 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 servers that are installed to a working location. For
example, you can configure working
Liberty servers to use
one or more of the following types of shared resources:
- Liberty 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 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 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 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 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
-
When you use the job manager to remotely install and manage Liberty servers, you can set the
following built-in variables to customize installation locations and Liberty 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 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 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 resources on the target
hosts.
- HOSTNAME
- Contains the configured host name of the target host where an Install Liberty
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 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 resources (deprecated) for information on how to properly package files
for the Install Liberty resources job. If you use IBM Installation Manager to install Liberty,
create a subdirectory under the location of
WLP_WORKING_DIR
. This directory will be
used to identify this instance of the Liberty 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.
What to do next
You can now submit a job that installs resources from a Liberty resources compressed file, as well as an inventory
job that searches for previously existing Liberty 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
.