Continuing on our DPK series, this week we’ll explore how to do advanced web server domain configuration. The psft_configuration.yaml file gives you many of the configuration options for your web domain. While these settings will help you configure your web domain, there are more changes to WebLogic most administrators make. One of those changes is configuring SSL/Certificates and Logging.
DPK and WSLT
Before the DPK, you could script configuration changes to WebLogic using the WebLogic Scripting language WSLT. WSLT is a great interface to WebLogic, and you can do quite a bit with it.
We use the psft_customizations.yaml file to document the WLST commands in a section called config_settings:. This section is not included in psft_configuration.yaml for the PIA, so it will be a new section for your files. The config_settings: section is included for app server and process scheduler sections. If you look at the file puppet\etc\modules\pt_config\tests\test_pia_create.pp you can see the PeopleTools team is using the config_settings section when creating a test domain.
In the psft_customizations.yaml file, the config_settings: section will go below the webserver_settings: section and above the site_settings: section. Everything under config_settings: is broken down into WSLT commands. To make a change to WebLogic, use the tree structure from your web domains’ config.xml file to identify a section to change. E.g, Servers/PIA/WebServer/PIA/WebServerLog/PIA will be the HTTP access log settings for the PIA server.
Under each WSLT header, you can include a key: value for any configurable option in WebLogic. For our Servers/PIA/WebServer/PIA/WebServerLog/PIA above, we’ll enable the access log:
config_settings:
Servers/PIA/WebServer/PIA/WebServerLog/PIA:
LoggingEnabled: true
When we run puppet apply, the Puppet code take this configuration and executes the WLST to make the change to WebLogic. After the puppet apply run, you can check the config.xml file to verify the updated configuration.
Using WSLT to Identify Config Values
If you don’t know what the path or values you want to change, you can spin up a WLST session and browse your web domain. To start WLST, run setWLSEnv.cmd script under your WL_HOME\server\bin folder. That will set up the environment variables so Java can find the WLST package.
Next, start up a WLST session with java weblogic.WLST. Your web server needs to be running to connect, and you’ll need the console username and password.
connect('system', 'Passw0rd', 't3://localhost:8000')
Once you connect to your domain, you can use cd() and ls() commands to navigate around the configuration tree. For example, this command will take us to the Access Log settings for the PIA.
cd('Servers/PIA/WebServer/PIA/WebServerLog/PIA')
ls()
You can do much more with WLST, but we’ll save that for another time.
SSL and Certificate Configuration
Now that we can configure a web domain via WLST commands, let’s set up SSL and a certificate for a domain. The DPK will do all the configuration, but it won’t update the pskey file. A good idea would be to prebuild your pskey file (using KeyStore Explorer) and be ready to copy into your domains piaconfig folder after the DPK runs.
This is what the config_settings section of the psft_customizations.yaml looks like to configure SSL:
config_settings:
Servers/PIA:
CustomIdentityKeyStorePassPhrase: Passw0rd
CustomTrustKeyStorePassPhrase: Passw0rd
KeyStores: CustomIdentityAndCustomTrust
Servers/PIA/SSL/PIA:
ServerPrivateKeyAlias: psadminio-2016
ServerPrivateKeyPassPhrase: Passw0rd
Servers/PIA/WebServer/PIA/WebServerLog/PIA:
LoggingEnabled: true
If you have configured SSL through the WebLogic console before, these configuraiton options should look familiar. We tell WebLogic to use a custom keystore (pskey), the password to get into the keystore, the Private Key alias and the password for the Private Key.
In production systems, it’s not a good idea to have your unecrypted password in the yaml files. For Windows, support for encrypting password in the yaml files isn’t there yet. For Linux, eyaml can encrypt your passwords.
This is what a psft_customizations.yaml looks like for a web server domain:
pia_domain_list:
hr92dmo:
os_user: psadm
ps_cfg_home_dir: e:/psoft/hr92dmo
gateway_user: administrator
gateway_user_pwd: Passw0rd
auth_token_domain: ".%{::domain}"
webserver_settings:
webserver_type: "%{hiera('webserver_type')}"
webserver_home: "%{hiera('weblogic_location')}"
webserver_admin_user: system
webserver_admin_user_pwd: Passw0rd
webserver_admin_port: "%{hiera('pia_http_port')}"
webserver_http_port: "%{hiera('pia_http_port')}"
webserver_https_port: "%{hiera('pia_https_port')}"
config_settings:
Servers/PIA:
CustomIdentityKeyStorePassPhrase: Passw0rd
CustomTrustKeyStorePassPhrase: Passw0rd
KeyStores: CustomIdentityAndCustomTrust
Servers/PIA/SSL/PIA:
ServerPrivateKeyAlias: psadminio-2016
ServerPrivateKeyPassPhrase: Passw0rd
Servers/PIA/WebServer/PIA/WebServerLog/PIA:
LoggingEnabled: true
site_list:
hr92dmo:
appserver_connections: "%{hiera('pia_psserver_list')}"
domain_conn_pwd: "%{hiera('domain_conn_pwd')}"
webprofile_settings:
profile_name: DEV
profile_user: PTWEBSERVER
profile_user_pwd: Passw0rd
report_repository_dir: "%{hiera('report_repository_dir')}"
Update Existing Domains
Unlike other parts of the DPK, the WLST commands execute every time you run puppet apply .\site.pp. So, if you want to update a config value in your web domain, the DPK will make those changes for you after the domain was created. With the app server and process schedulers, the DPK doesn’t handle changes well. Once the domain is built, configuration changes are not applied to app and batch domains.
Repeatable Processes
The goal of the DPK, Puppet and other automation software is to create a dependable and repeatable process. Taking advantage of these features in the DPK will get you closer to the ideal of complete automation. The ability to issue WLST commands against WebLogic domains gives admins another tool with the DPK to build a system to your specifications.