Every product using Liberty seems to have a different way of configuring the product. As first I thought specifying parameters to z/OSMF was great, as you do it by a SYS1.PARMLIB member. Then I found you have other files to configure; then I found that I could not reuse my existing definitions from z/OS Connect, and MQWEB. Then I found it erases any local copy of the server.xml file, and links to the one shipped as part of the server.xml file from the configuration files each time. Later I used this to my advantage. Once again I seemed to be struggling against the product to do simple things. Having gone through the pain, and learnt how to configure z/OSMF, its configuration is OK.
This is not a “how to” post, but what you need in addition of the IBM documentation.
You specify some parameters in SYS1.PARMLIB(IZUPRMxx) concatenation. See here for the syntax and the list of parameters. In mid 2020 there was an APAR PH24088 which allowed you to change change these parameters dynamically, using a command such as:
SETIZU ILUNIT=SYSDA
Thanks to Dani Kalmar who gave some additional steps to get it working.
Before you start.
I had many problems with certificates before I could successfully logon to z/OSMF.
I initially found it hard to understand where to specify configuration options, as I was expecting to specify them in the server.xml file. See z/OSMF configuration options mapping for the list of options you can specify.
If you change the options you have to restart the server. Other systems that use Liberty have a refresh option which tells the system to reread the server.xml file. z/OSMF stores the variables in variable strings in the bootstrap.options file, and I could not find a refresh command which refreshed the data. (There is a refresh command which does not refresh.) See z/OSMF commands.
Define the userid
I used a userid with a home directory /var/zosmfcp/data/home/izusvr. I had to issue
mkdir /var/zosmfcp
chown izusvr /var/zosmfcp
mkdir -p /var/zosmfcp/data/home/izusvr
chown izusvr /var/zosmfcp/data/home/izusvr
touch /var/zosmfcp/configuration/local_override.cfg
chmod g+r /var/zosmfcp/configuration/local_override.cfg
chown :IZUADMIN /var/zosmfcp/configuration/local_override.cfg
Additional changes
In order to resolve the authorization errors use:
chown izusvr /global/zosmf/configuration/servers/zosmfServer/jvm.options.old chgrp izuadmin /global/zosmf/configuration/workflow/izu.provisioning.security.config.properties
To setup access to the angel task run:
- ADCD.Z24D.ZOSMF.CONF(IZUSEC)
- ADCD.Z24D.ZOSMF.CONF(RESTAPIP)
Modify the hostname value to ‘*’.
Getting the digital certificate right.
I had problems using the provided certificate definitions.
- The CN did not match what I expected.
- There was no ALTNAME specified. For example ALTNAME((IP(10.1.1.2)) (where 10.1.1.2 was the external IP address of my z/OS). The browser complained because it was not acceptable. An ALTNAME must match the IP address or host name the data came from. Without a valid ALTNAME you can get into a logon loop. Using Chrome I got
- “Your connection is not private”. Common name invalid.
- Click on Advanced and “proceed to.. (unsafe)”
- Enter userid and password.
- I had the display with all of the icons. Click on the Pul-up and switch to “classic interface”
- I got “Your connection is not private”. Common name invalid, and round the loop again.
- The keystore is also used as the trust store, so it needs the Certificate Authority’s certificates. Other products using Liberty use a separate trust store. (The keystore contains the certificate the server uses to identify itself. The trust store contains the certificates (such as Certificate Authority certificates) to validates certificates sent from clients to the server). With z/OSMF there is no definition for the trust store. To make the keystore work as a trust store, the keystore needs:
- the CA for the server (z/OSMF talks to itself over TLS) this means the each end of the conversation within the server, needs it to validate the server’s certificate.
- the CA for any certificates in any browsers being used.
- I had to use the following statements to convert my keystore to add the trust store entries.
RACDCERT ID(IZUSVR) CONNECT(CERTAUTH -
LABEL('MVS-CA') RING(KEY) )
RACDCERT ID(IZUSVR) CONNECT(CERTAUTH -
LABEL('Linux-CA2') -
RING(KEY ) USAGE(CERTAUTH))
Reusing my existing keyring
Eventually I got this to work. I had to…
- Connect the CA of the z/OS server into the keyring.
- Update /var/zosmfcp/configuration/local_override.cfg for ring //START1/KEY2
-
KEYRING_NAME=KEY2
KEYRING_OWNER_USERID=START1
KEYRING_TYPE=JCERACFKS
KEYRING_PASSWORD=password
The z/OSMF started task userid requests CONTROL access to the keyring.
It requests CONTROL access (RACF reports this!), but UPDATE access seems to work See RACF: Sharing one certificate among multiple servers.
With only READ access I got.
CWWKO0801E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
If it does not have UPDATE access, then z/OSMF cannot see the private certificate.
Use the correct keystore type.
My RACF KEYRING keystore only worked when I had a keystore type of JCERACFKS. I specified it in /var/zosmf/configuration/local_override.cfg
KEYSTORE_TYPE=JCERACFKS
Before starting the server the first time
Ensure you have followed the configuration instructions, for example review and submit SYS1.SAMPLIB(IZUSEC) to create the RACF definitions.
If you specify TRACE=’Y’, either in the procedure or as part of the start command, it traces the creating of the configuration file, and turns on the debug script. TRACE=’X’ gives a BASH trace as well.
It looks like the name of the server is hard coded internally as zosmfServer, and the value in the JCL PARMS= is ignored.
Once it has started
If you do not get the logon screen, you may have to wait. Running z/OS under my Ubuntu Laptop is normally fine for editing etc. it takes about 10 minutes to start z/OSMF. If you get problems, with incomplete data displayed, or messages saying resources not found, wait and see if it gets resolved. Sometimes I had to close and restart my browser.
Useful to know…
- Some, but not all, error messages are in the STDERR output from the started task.
- The logs and trace are in /var/zosmfcp/data/logs/zosmfServer/logs/. Other products using Liberty have /var/zosmfcp/
data/logs/zosmfServer/logs/ so all the files are under /var/zosmfcp/zosmfServer - The configuration is in /var/zosmfcp/configuration and /var/zosmfcp/configuration/servers/zosmfServer. This is a different directory tree layout from other Liberty components.
- If you want to add one JVM option, edit the local_override.cfg and add JVM_OPTIONS=-Doption=value. See here if you want to add more options. I used JVM_OPTIONS=-Djavax.net.debug=ssl:handshake to give me the trace of the TLS handshake.
- If you have problems with certificate not being found on z/OS, you might issue the SETROPTS command to be 100% sure that what is defined to RACF is active in RACF. Use SETROPTS RACLIST(DIGTCERT,DIGTRING,RDATALIB) refresh.
- Check keyring contents using racdcert listring(KEY2) id(START1)
- Check certificate status using RACDCERT LIST(LABEL(‘IZUZZZZ2’ )) ID(START1) and check it has status:trust and the dates are valid.
- If your browser is not working as expected – restart it.
Tailoring your web browser environment.
Some requests, for example workflow, use a REST request to perform an action. Although I had specified a HOSTNAME of 10.1.1.2, z/OSMF used an internal address of S0W1.DAL-EBIS.IHOST.COM When the rest request was issued from my browser – it could not find the back end z/OS. I had to add this site to my Linux /etc/hosts
10.1.1.2 S0W1.DAL-EBIS.IHOST.COM
Even after I had resolved the TCPIP problem on z/OS which caused this strange name to be used, z/OSMF continued to use it. When I recreated the environment the problem was resolved. I could not see this value in any of the configuration files.
Getting round the configuration problems
I intially found it hard so specify additional configuration options, to override what was provided by z/OSMF. For example reuse what I had from other Liberty servers.
I changed the server.xml file to include
<include optional="false" location="${server.config.dir}/colin.xml"/>
This allowed me to put things in the colin.xml file. Im sure this solution is not recommended by IBM, but it is a practical solution. This file may be read only to you.
You should not need this solution if you can use the z/OSMF configuration options mapping.
One thought on “A practical guide to getting z/OSMF working.”