Configure the Liberty server
This chapter will guide you through the server set up which requires the configuration of a WebSphere Liberty server.
The UKO z/OSMF installation workflows provide
- a UKO server example workflow
- a Crypto Connect server example workflow to configure and start the Liberty server. Either specify the variables using a properties file (see examples here) or specify them once you are prompted by the step.
The following directories are required for the Liberty server configuration:
${INSTALL_DIR}: location where UKO or Crypto Connect is installed${JAVA_HOME}: location where Java is installed${WLP_INSTALL_DIR}: location where WebSphere Liberty is installed${WLP_USER_DIR}: the parent directory under which the${SERVER_DIRECTORY}will be created, for example/etc/liberty
Prerequisite tasks
The following tasks need to be completed before you can complete this chapter:
- A Liberty angel process must be running. If this is a named angel, you will need the angel name
${WLP_ANGEL_NAME}. - The required network configuration must be completed.
Directory setup
The following directories need to be created:
${SERVER_DIRECTORY}- the directory where the configuration files of the active Liberty server (server.envandjvm.options) are residing${SERVER_OUTPUT_DIR}- optional output directory for the server logs, otherwise they will be created in the${SERVER_DIRECTORY}
The ${SERVER_DIRECTORY} requires a special format. WebSphere Liberty expects to find the configuration files in a directory with the name of the server under ${WLP_USER_DIR}/servers/. It is recommended to use the name
of the Liberty server started task ${SERVER_STC_NAME} as server name, so that the ${SERVER_DIRECTORY} will be ${WLP_USER_DIR}/servers/{SERVER_STC_NAME}.
The installation workflows can guide you through the creation of the required directories as well as the allocation of ZFS datasets that will be mounted there.
Configure the Liberty server
The configuration of the Liberty server consists of some generic configuration, followed by specific steps depending on what the server is used for.
Generic server configuration
Adjust configuration file server.env
Copy server.env from the ${INSTALL_DIR} to the ${SERVER_DIRECTORY} and adjust it to match your environment (this file is in EBCDIC!).
cd ${WLP_USER_DIR}/servers/${SERVER_STC_NAME}
cp ${INSTALL_DIR}/server.env server.env
This file is self-documenting. The reference section contains a copy of server.env before customization as it is shipped with the latest release.
Adjust java options file jvm.options
Copy jvm.options from the ${INSTALL_DIR} to the ${SERVER_DIRECTORY} and adjust it to match your environment (this file is in EBCDIC!).
cd ${WLP_USER_DIR}/servers/${SERVER_STC_NAME}
cp ${INSTALL_DIR}/jvm.options jvm.options
This file is self-documenting. The reference section contains a copy of java.options before customization as it is shipped with the latest release.
Set up the remaining server directory
Some customizations of the server are done using the configDropins folder, which contains the follwing subfolders:
- configDropins/defaults - for the default configuration
- configDropins/options - for options, like running the UKO server with Db2 type 4 driver instead of type 2 or for deciding which features to start with the Crypto Connect server
The recommended setup for the configDropins is to create the folder, link to the defaults and options folders in the ${INSTALL_DIR} and then create a separate overrides folder, like shown in the following sample command:
cd ${WLP_USER_DIR}/servers/${SERVER_STC_NAME}
mkdir configDropins
mkdir configDropins/overrides
ln -s ${INSTALL_DIR}/configDropins/defaults configDropins/defaults
ln -s ${INSTALL_DIR}/configDropins/options configDropins/options
Finally, create symbolic links to the remaining files and folders in the ${INSTALL_DIR}:
cd ${WLP_USER_DIR}/servers/${SERVER_STC_NAME}
ln -s ${INSTALL_DIR}/EkmfWeb.properties EkmfWeb.properties
ln -s ${INSTALL_DIR}/apps apps
ln -s ${INSTALL_DIR}/resources resources
ln -s ${INSTALL_DIR}/server.xml server.xml
Additional configuration options
You can now configure the server for the following use cases:
- Configure Liberty for UKO, like database connection configuration and Db2 type 4 instead of type 2
- Configure Liberty for Crypto Connect
- Configure Liberty for MSDKE
- Configure Liberty for CAT
Change directory ownership and permissions
After all files and directories are in place, change the ownership of the ${SERVER_OUTPUT_DIR} and the ${SERVER_DIRECTORY} to be owned by the ${SERVER_STC_USER} and set the permission bits to 700 so that
only this technical user has access to the file. The Set directory permissions sub-step will help you with that. If you also specified ${SERVER_STC_GROUP} then the group ownership will be transferred to this
group and the permission bits changed to 770.
Create the server procedure
Create a procedure to start the server and copy it to your ${ZOS_PROCLIB}. If you don't use the workflow, you can use the following sample procedure and replace all ${placeholders} to match your environment:
//${SERVER_STC_NAME} PROC PARMS='${SERVER_STC_NAME}'
// SET WLPHOME='${WLP_INSTALL_DIR}'
//*
//STEP1 EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &WLPHOME./lib/native/zos/s390x/bbgzsrv --clean &PARMS.'
//STEPLIB DD DSN=${DB_HLQ}.SDSNEXIT,DISP=SHR
// DD DSN=${DB_HLQ}.SDSNLOAD,DISP=SHR
// DD DSN=${DB_HLQ}.SDSNLOD2,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
//STDENV DD *
_BPX_SHAREAS=YES
JAVA_HOME=${JAVA_HOME}
WLP_USER_DIR=${WLP_USER_DIR}
#JVM_OPTIONS=<Optional JVM parameters>
//*
// PEND
//
Configure security for the server
Perform the statements in the Security setup for the Liberty server chapter.
Start the server
You are now ready to start the server. Issue the following command:
/START ${SERVER_STC_NAME}
Alternatively, you can use the workflow to start the server. The Validate console API sub-step checks whether the user ID running the step is allowed to issue console commands and whether a task with the ${SERVER_STC_NAME} is already running. Afterwards, in the Start server via console sub-step, it issues the START command to the console.
Note: To use that part of the workflow, your userid needs to be enabled to use the console API. The provided workflow is sending console requests to /zosmf/restconsoles/consoles/defcn. This means that the name of
the console that is used to issue the command is generated by the REST Console API, by adding CN to the logon user ID.
For example, if user UKOSTC plans to accept the default console name, UKOSTCCN, this user can issue this RACF command to set console attributes for the console:
ADDUSER UKOSTCCN OPERPARM(AUTH(MASTER) ROUTCODE(ALL))
If the user ID is longer than 6 characters, the user ID is truncated. For example, if the user ID is UKORACF, the console name is UKORACFN.
Refer to the z/OSMF documentation for more information on issuing commands from a system console.