はじめに
ここでは、製品提供のADCDのz/OS環境に関してカスタマイズの対象になりそうな箇所について補足しておきます。
関連記事
Wazi: OpenShift上でのメインフレーム開発環境構築 - (1)事前準備
Wazi: OpenShift上でのメインフレーム開発環境構築 - (2)ライセンス・サーバーの構成
Wazi: OpenShift上でのメインフレーム開発環境構築 - (3)イメージ・ストレージ・サーバーの構成
Wazi: OpenShift上でのメインフレーム開発環境構築 - (4)OpenShiftクラスターの構成
Wazi: OpenShift上でのメインフレーム開発環境構築 - (5)Sandboxインスタンスの作成
Wazi: OpenShift上でのメインフレーム開発環境構築 - (6)Sandboxインスタンスの確認
Wazi: OpenShift上でのメインフレーム開発環境構築 - (7)Sandboxインスタンスへの接続
Wazi: OpenShift上でのメインフレーム開発環境構築 - (8)Sandboxのカスタマイズ
Wazi: OpenShift上でのメインフレーム開発環境構築 - (9)Wazi Developer for Workspacesの作成
カスタマイズ例
TN3270サーバー
TLS接続構成
TN3270サーバーはAT-TLSの機能を使用してTLS通信ができるように構成されています。ただ、デフォルトで提供されているTN3270サーバー用のサーバー証明書(ユーザー: TCPIP, KeyRing: TN3270.TTLS, 証明書ラベル: ADCDCert.TTLS) は、公開キーの長さが512bitで作られており、最近のクライアント(Windows10など)ではセキュリティ要件を満たさずTLS通信に失敗してしまいます。
そのため、TN3270でのTLS通信を行いたい場合はサーバー証明書を作成しなおす必要があります。
サーバー証明書作成
参考: RACDCERT (Manage RACF digital certificates)
TSOコマンドにて以下の証明書作成の操作を行います。(USSから実行している例です)
IBMUSER:/u/ibmuser: >tsocmd "RACDCERT ID(TCPIP) GENCERT SUBJECTSDN(CN('S0W1.DAL-EBIS.IHOST.COM') O('IBM') OU('DTSC') C('US') S('Texas') L('Dallas-Coppell')) SIZE(2048) SIGNWITH(CERTAUTH LABEL('ADCDCA')) WITHLABEL('ADCDCert.TTLS2') NOTAFTER(DATE(2022-02-01)) ALTNAME(DOMAIN('*.DAL-EBIS.IHOST.COM'))"
RACDCERT ID(TCPIP) GENCERT SUBJECTSDN(CN('S0W1.DAL-EBIS.IHOST.COM') O('IBM') OU('DTSC') C('US') S('Texas') L('Dallas-Coppell')) SIZE(2048) SIGNWITH(CERTAUTH LABEL('ADCDCA')) WITHLABEL('ADCDCert.TTLS2') NOTAFTER(DATE(2022-02-01)) ALTNAME(DOMAIN('*.DAL-EBIS.IHOST.COM'))
IRRD175I The new profile for DIGTCERT will not be in effect until a SETROPTS REFRESH has been issued.
パラメーター補足
WITHLABEL('ADCDCert.TTLS2'): 新しいラベル名。
SIZE(2048): 公開キーの長さとして2048bitを指定。
ALTNAME(DOMAIN('*.DAL-EBIS.IHOST.COM')): サーバーのドメイン名。PC側でサーバーのホスト名を検証する場合、PCから接続する際に使用するTN3270サーバーのホスト名のドメイン(今回の場合OpenShiftクラスターのServiceに接続する際に使用されるホスト名のドメイン)と合わせる必要がある。
NOTAFTER(DATE(2022-02-01)): 証明書の有効期限です。元の証明書に合わせて2050-01-02を指定すると「IRRD113I The certificate that you are creating has an incorrect date range. The certificate is added with NOTRUST status.」というエラーが出たのでとりあえず1年くらい先を指定。
(そういえば、こういう話がありましたね。多分PCOM接続では関係ないと思うけど。 => https://www.itmedia.co.jp/enterprise/articles/2006/30/news064.html)
※その他、基本的には既存の証明書(ADCDCert.TTLS)に合わせて設定しています。ちなみに、元の証明書と同様ADCDCAという証明書をCA証明書として使用して署名しています(ADCDCAは自己署名証明書)。
IBMUSER:/u/ibmuser: >tsocmd "SETROPTS RACLIST(DIGTCERT) REFRESH"
SETROPTS RACLIST(DIGTCERT) REFRESH
IBMUSER:/u/ibmuser: >tsocmd "RACDCERT ID(TCPIP) CONNECT(RING(TN3270.TTLS) LABEL('ADCDCert.TTLS2'))"
RACDCERT ID(TCPIP) CONNECT(RING(TN3270.TTLS) LABEL('ADCDCert.TTLS2'))
IBMUSER:/u/ibmuser: >tsocmd "RACDCERT ID(TCPIP) LISTRING(TN3270.TTLS)"
RACDCERT ID(TCPIP) LISTRING(TN3270.TTLS)
Digital ring information for user TCPIP:
Ring:
>TN3270.TTLS<
Certificate Label Name Cert Owner USAGE DEFAULT
-------------------------------- ------------ -------- -------
ADCDCA CERTAUTH CERTAUTH NO
ADCDCert.TTLS ID(TCPIP) PERSONAL YES
ADCDCert.TTLS2 ID(TCPIP) PERSONAL NO
Policy Agent設定変更
ADCD.Z24B.TCPPARMS(TLSPOLY1)を編集して、CertificateLabelの値を、ADCDCert.TTLS から ADCDCert.TTLS2に変更
...
TTLSConnectionAction TN3270-GrpConAct
{
HandshakeRole Server
TTLSCipherParmsRef TN3270-CipherPrm_AT-TLS_Platinum
TTLSConnectionAdvancedParmsRef TN3270-ConAdvPrm
CtraceClearText Off
Trace 2
}
TTLSConnectionAdvancedParms TN3270-ConAdvPrm
{
##SSLv3 Off
ApplicationControlled On
CertificateLabel ADCDCert.TTLS2
SecondaryMap Off
}
TTLSKeyringParms TN3270-EnvKeyPrm
{
Keyring TN3270.TTLS
}
TTLSCipherParms TN3270-CipherPrm_AT-TLS_Platinum
{
V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
}
...
変更を反映させるため、以下のMVSコマンドを実行
参考: MODIFY command: Policy Agent
F PAGENT,REFRESH
EZZ8443I PAGENT MODIFY COMMAND ACCEPTED
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
grp_CICS54_CMCI
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
grp_CICS55_CMCI
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIP : TTLS
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
grp_Debug_Secure
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
grp_Production
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
GrpActOff
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
GrpActOn
ログオン画面
TN3270プロファイルにincludeされるTLS接続用のポートの設定はデフォルトで以下のようになっています。
...
BeginVTAM
Port 2023
DEFAULTLUS
TLS00001..TLS00030
ENDDEFAULTLUS
DEFAULTAPPL TSO ; Set the default application for all TN3270(E)
ALLOWAPPL TSO* DISCONNECTABLE ; Allow all users access to TSO
; applications.
; TSO is multiple applications all beginning with TSO,
; so use the * to get them all. If a session is closed,
; disconnect the user rather than log off the user.
ALLOWAPPL * ; Allow all applications that have not been
; previously specified to be accessed.
...
USSTCP USSN
...
DEFAULTAPPL TSOが指定されているので、接続するとTSOのログイン画面となり、TSOユーザー入力が求められます。つまりこれだとAPPLID指定で他のアプリケーションへの接続ができません(例えばCICS端末としてのログオンができません)。
APPLID指定できるようにするには、以下のようにDEFAULTAPPL TSOをコメントアウトし、LINEMODEAPPL TSOを追加しTN3270サーバーを再起動します。
...
BeginVTAM
Port 2023
DEFAULTLUS
TLS00001..TLS00030
ENDDEFAULTLUS
; DEFAULTAPPL TSO ; Set the default application for all TN3270(E)
LINEMODEAPPL TSO ; Send all line-mode terminals directly to TSO.
ALLOWAPPL TSO* DISCONNECTABLE ; Allow all users access to TSO
; applications.
; TSO is multiple applications all beginning with TSO,
; so use the * to get them all. If a session is closed,
; disconnect the user rather than log off the user.
ALLOWAPPL * ; Allow all applications that have not been
; previously specified to be accessed.
...
USSTCP USSN
...
TIMEZONE
CLOCKxx
参考: Statements and parameters for CLOCKxx
デフォルトでは以下のような設定になっています。
OPERATOR NOPROMPT
TIMEZONE W.04.00.00
ETRMODE NO
ETRZONE NO
ETRDELTA 10
STPMODE NO
STPZONE NO
ローカルタイムを日本時間にするために以下のように変更します。
OPERATOR NOPROMPT
TIMEZONE E.09.00.00
ETRMODE NO
ETRZONE NO
ETRDELTA 10
STPMODE NO
STPZONE NO
USS
/etc/profileもしくは各ユーザーの.profileにて、TZ環境変数を指定してexportします。
ローカルタイムを日本時間にするためにはTZ=JST-9を設定します。
参考: Environment variables that you can customize for /etc/profile
ユーザー管理
既存ユーザー
製品提供のADCDパッケージでは、いくつか既存のユーザーが設定されています。
参考:ADCD z/OS V2R4 November Edition of 2019 - USERIDS
初期パスワードも設定されているので、必要に応じてパスワード変更やユーザー削除などの処理をしておく必要があります。
参考: ALTUSER (Alter user profile)
新規ユーザー作成
TSOユーザー作成用のサンプルJCL
//ADDUSER JOB (),
// CLASS=A,
// MSGCLASS=D,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID,
// TIME=1440
//*
//S0 EXEC PGM=IKJEFT01,DYNAMNBR=75,TIME=100,REGION=6M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTERM DD DUMMY
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR
//SYSTSIN DD *
ADDUSER (TEST01) PASSWORD(PSWD) SPECIAL OPERATIONS -
OWNER(SYS1) DFLTGRP(SYS1) -
TSO(ACCTNUM(ACCT#) PROC(ISPFPROC) JOBCLASS(A) MSGCLASS(X) -
HOLDCLASS(X) SYSOUTCLASS(X) SIZE(4048) MAXSIZE(0)) -
OMVS(UID(100100) HOME(/u/TEST01) PROGRAM(/bin/sh))
PERMIT ACCT# ACCESS(READ) CLASS(ACCTNUM) ID(TEST01)
PERMIT ISPFPROC ACCESS(READ) CLASS(TSOPROC) ID(TEST01)
PERMIT JCL ACCESS(READ) CLASS(TSOAUTH) ID(TEST01)
PERMIT OPER ACCESS(READ) CLASS(TSOAUTH) ID(TEST01)
PERMIT ACCT ACCESS(READ) CLASS(TSOAUTH) ID(TEST01)
PERMIT MOUNT ACCESS(READ) CLASS(TSOAUTH) ID(TEST01)
PERMIT RECOVER ACCESS(READ) CLASS(TSOAUTH) ID(TEST01)
SETROPTS RACLIST(ACCTNUM) REFRESH
SETROPTS RACLIST(TSOPROC) REFRESH
SETROPTS RACLIST(TSOAUTH) REFRESH
CONNECT TEST01 GROUP(IZUADMIN)
/*
//*----------------------------------------------------------------
//ALIAS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEF ALIAS(NAME(TEST01) REL(USERCAT.Z24B.USER)) -
CATALOG(CATALOG.Z24B.MASTER)
/*
//
※既存のユーザー・カタログUSERCAT.Z24B.USERがあったのでそれを利用しています。
上の定義に合わせてUSS上にHomeディレクトリを作成してOwner変更
mkdir /u/TEST01
chown TEST01 /u/TEST01
パスワード関連設定
セキュリティ対策として、必要に応じてパスワード試行回数制限(SETROPTS - PASSWORD - REVOKE)などを指定しておくとよいでしょう。
参考: SETROPTS
自動起動ミドルウェアの制御
製品提供のADCDパッケージは、デフォルトでは各種ミドルウェアが自動起動するような設定になっています。これらを起動させるとリソースの消費が大きいので、必要なものを選別して不要なものは停止し、IPL時にも自動起動しないようにしておくとよいでしょう。
各サブシステムはNetview管理となっており、環境変数(IEASYMxx)でIPL時に自動起動するかどうかが制御できます。
参考
Wazi: OpenShift上でのメインフレーム開発環境構築 - (6)Sandboxインスタンスの確認 - Netview関連
NetView automation for Sandbox
...
SYMDEF(&DBGMGR='IPL')
SYMDEF(&EQAPROF='IPL')
SYMDEF(&EQARMTD='IPL')
SYMDEF(&BLZBFA='IPL')
SYMDEF(&BLZISPFD='IPL')
SYMDEF(&BUZAGNT='IPL')
SYMDEF(&CICSTS55='IPL')
SYMDEF(&CICSTS54='NOS')
SYMDEF(&CSQ9CHIN='NOS')
SYMDEF(&CSQ9MSTR='NOS')
SYMDEF(&DBBGMSTR='NOS')
SYMDEF(&DBCGMSTR='IPL')
SYMDEF(&HTTPD1='NOS')
SYMDEF(&IMS14CR1='NOS')
SYMDEF(&IMS14RL1='NOS')
SYMDEF(&IMS15CR1='IPL')
SYMDEF(&IMS15RL1='IPL')
SYMDEF(&IZUANG1='IPL')
SYMDEF(&IZUSVR1='IPL')
SYMDEF(&JMON='IPL')
SYMDEF(&NFSS='NOS')
SYMDEF(&RSED='IPL')
SYMDEF(&RSEAPI='IPL')
SYMDEF(&DBB='IPL')
SYMDEF(&DBBS='IPL')
SYMDEF(&ZOSCSRV='IPL')
IPL時に自動起動しないようにするには、IPL=>NOSに変更します。
DASD管理
DASDイメージファイルの追加はSandboxのコンテナに接続してibmsys1ユーザーにスイッチすれば、基本的にZD&Tと同じように行えます。
参考: クラウド上でのメインフレーム開発環境構築 - (9) DASD管理補足 - 新規DASD追加
例えば、100シリンダーのDASDイメージファイルを作成してみます。
[ibmsys1@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 zvolumes]$ alcckd DASD01 -d 3390 -s 100
AWSCKE035I Creating file 'DASD01', 3390, 100 cylinders
AWSCKE072I 100 percent complete ...
AWSCKE005I Processing file 'DASD01' ...
AWSCKE006I Device type: 3390-1
AWSCKE009I Cylinders: 100, heads 15
AWSCKE010I Track size: 56832
AWSCKE011I File version: 0
AWSCKE014I Version pend: No
AWSCKE017I IPL text: No
AWSCKE018I Volume serial: <None>
DeviceMapファイルに以下の定義を追加します。(末尾3行は動的追加用にアドレスを追加指定しています)
...
device 0300 3390 3390 /zdt/zvolumes/DASD01
device 0301 3390 3390
device 0302 3390 3390
device 0303 3390 3390
これでIPLすればアドレス0300にDASDが追加されているので、INITIALIZEして利用可能です。
ADCDではDASDは基本的にSMSで管理するようになっています。必要に応じてACS Routineの変更なども合わせて実施してください。
参考: Wazi: OpenShift上でのメインフレーム開発環境構築 - (6)Sandboxインスタンスの確認 - SMS関連
RSE(Remote System Explorer)
これは、前の記事でもあげたWazi Developer for Eclipseや、z/OS ExplorerなどEclipseベースのクライアントツールとの接続を管理するz/OS側コンポーネントです。デフォルトではこのサーバーも構成されていますが、Eclipseからの接続構成を行うにあたって、RSEの設定も変える必要があります。
EclipseクライアントとRSE間接続の挙動については前記事の以下の箇所もご参照ください。
参考: Wazi: OpenShift上でのメインフレーム開発環境構築 - (7)Sandboxインスタンスへの接続 - Eclipse (Wazi Developer for Eclipse)
ここでは動的に割り当てられるポートの設定を変更します。
USS上のRSE関連の設定ファイルを以下のように編集します。
# Specify the port range for RSE client connections
#-------------------------------------------------------------
#_RSE_PORTRANGE=4037-4038
#_RSE_PORTRANGE=7337-7338
_RSE_PORTRANGE=32300-32301
_RSE_PORTRANGEは動的に割り当てられる通信用のポート番号の範囲を指定します。末尾の数字は含まれないので、上の例では実質32300番ポートに固定されます。今回の例では32300ポートを使用していますが。OpenShiftクラスターでNodePortタイプのServiceで公開するので、NodePortとして使用可能な30000～32767までのポートのうち未使用のものを選択して設定します。
設定したら、以下のようにMVSコマンドを実行してRSEDを再起動します。
停止: P RSED
開始: S RSED
その後、この動的ポート(とはいえ32300番に無理やり固定したもの)を、同じ番号でNodePortとしてServiceで公開します。
以下のService定義用のYAMLを作成してSandboxと同じProjectに適用します。
apiVersion: v1
kind: Service
metadata:
name: wazi-rsed-svc
namespace: wazi-test01
spec:
type: NodePort
selector:
app.kubernetes.io/instance: wazi-sandbox01
app.kubernetes.io/name: wazi-sandbox-system
ports:
- name: rsed-dynamic-port
nodePort: 32300
port: 32300
protocol: TCP
targetPort: 32300
nodePortとtargetPortに_RSE_PORTRANGEで限定したポート番号と同じ番号を指定します。
これでEclipseからRSEに接続できるようになります。
Debug Profile Service
VSCodeからデバッガーを利用する場合、Debug Profile Service および、Remote Debug Serviceというz/OS側の2つのコンポーネントと通信を行うことになります。それぞれデフォルトではセキュアな接続用(TLS)の構成がされており、セキュアなポートが公開されることになります。
TLSの通信を行う際はサーバー証明書が送られてくるのですが、デフォルトの構成ではいずれのサービスも自己署名証明書が使われています。VSCode側は自己署名されたサーバー証明書は基本的に拒否するようになっているらしく、そのままではTLS通信が行えません。
Remote Debug Service用の設定ではそのエラーを無視するプロパティがあるのですが、Debug Profile Service用の設定にはそのようなプロパティが無さそうです。そのため、セキュアな接続を行う場合、Debug Profile Serviceで使用するサーバー証明書を作成して設定し直す必要があります。
以下に、新たにサーバー証明書を作成してDebug Profile Serviceが使用しているKeystoreを更新する手順を示します。ただし、ここでは一般的なCA(Verisignなど)を利用するのではなく、自前のCA証明書を作成しています。証明書の作成についてはopensslが使えるLinux環境で操作します。
手順のイメージは以下の通りです。
(1)CSR作成 (USS上での操作)
既存のKeystoreを元にCSR(証明書署名要求)を作成します。
Debug Profile Serviceの起動プロシージャーから、参照しているENVFILEを辿ってください。デフォルトでは、/etc/debug/eqaprof.envが参照されています。使用しているKeystoreファイルは、このENVFILEのkeystoreFileの指定から辿れます。
...
# The pathname of the keystore file where the server certificate is loaded
keystoreFile="/etc/debug/keystore.p12"
# The password to access the server certificate from the keystore file
keystorePass="ibmuser"
# The type of keystore file to be used for the server certificate
keystoreType="PKCS12"
...
以下のコマンドでCSRを作成します。
IBMUSER:/S0W1/etc/debug: >keytool -certreq -alias tomcat -file tomcat.csr -keystore keystore.p12 -storetype PKCS12 -storepass ibmuser
UTF-8でtomcat.csrが作成されるのでそれをopensslが入ったLinuxにバイナリーモードで転送します。
(2)CA証明書作成(Linux上での操作)
CA証明書(自己署名証明書)を作成します。
# openssl genrsa -out myCA.key 2048
Generating RSA private key, 2048 bit long modulus
.................................................+++
....................+++
e is 65537 (0x10001)
# openssl req -x509 -new -key myCA.key -days 825 -out myCA.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Chiba
Locality Name (eg, city) [Default City]:Chiba
Organization Name (eg, company) [Default Company Ltd]:yyy
Organizational Unit Name (eg, section) []:xxx
Common Name (eg, your name or your server's hostname) []:xxx.yyy
Email Address []:
# ls -la
合計 12
drwxr-xr-x. 2 root root 38 3月 5 10:44 .
drwxr-xr-x. 8 root root 4096 3月 5 10:33 ..
-rw-r--r--. 1 root root 1679 3月 5 10:43 myCA.key
-rw-r--r--. 1 root root 1285 3月 5 10:44 myCA.pem
CA証明書が作成されました。myCA.pem
(3)サーバー証明書作成(Linux上での操作)
以下のファイルを作成します。
subjectAltName=@alt_section
[alt_section]
DNS.1=s0w1.dal-ebis.ihost.com
DNS.2=ocpw01
DNS.xには、クライアント(VSCode)から接続する時のホスト名、IPアドレスを指定します。
tomcat.csr、prof_service.extを元に、上で作成したmyCA.pemで署名したサーバー証明書を作成します。
# openssl x509 -req -in tomcat.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out tomcat_server.crt -extfile prof_service.ext -days 3650
Signature ok
subject=/C=US/O=IBM/OU=z/OS Debugger/CN=Profile Service
Getting CA Private Key
サーバー証明書"tomcat_server.crt"が作成されました。
CA証明書(myCA.pem)、サーバー証明書(tomcat_server.crt)をUSSに転送します(テキストなのでテキストモードで転送)。
(4)CA証明書、サーバー証明書登録(USS上での操作)
まずCA証明書をKeystoreにインポートします。
IBMUSER:/S0W1/etc/debug: >keytool -import -alias root -file myCA.pem -storetype PKCS12 -keystore keystore.p12 -storepass ibmuser
Owner: CN=xxx.yyy, OU=xxx, O=yyy, L=Chiba, ST=Chiba, C=JP
Issuer: CN=xxx.yyy, OU=xxx, O=yyy, L=Chiba, ST=Chiba, C=JP
Serial number: a59159615c61b8d4
Valid from: 3/4/21 8:44 PM until: 6/7/23 9:44 PM
Certificate fingerprints:
MD5: 59:E8:87:17:AB:7F:9E:3B:3A:39:3F:9A:90:87:C4:A0
SHA1: 1D:17:82:3E:AF:D7:31:26:93:E9:02:AD:25:E5:05:27:DB:20:C8:B1
SHA256: 93:7E:52:9D:B9:3F:D1:7E:7C:14:BE:F7:4D:1F:8D:D7:F8:47:AD:50:D8:7A:3F:C3:65:B1:BA:DF:F4:38:22:49
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: cb ba af f2 c8 fa 5d 99 de 8d e0 02 04 b9 49 00 ..............I.
0010: 75 23 ec 1f u...
]
]
#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: cb ba af f2 c8 fa 5d 99 de 8d e0 02 04 b9 49 00 ..............I.
0010: 75 23 ec 1f u...
]
]
#3: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
Trust this certificate? [no]: yes
Certificate was added to keystore
次に、サーバー証明書をkeystoreにインポートします。
IBMUSER:/S0W1/etc/debug: >keytool -import -alias tomcat -file tomcat_server.crt -storetype PKCS12 -keystore keystore.p12 -storepass ibmuser
Certificate reply was installed in keystore
補足
変更が完了したら、Debug Profile Serviceを再起動します。
/F CNMPROC,STOPTASK EQAPROF
/F CNMPROC,STRTTASK EQAPROF
クライアント側(VSCode)側としては、上で使用したCA証明書(myCA.pem)を信頼できるルート証明機関として登録しておけばOKです。
手動IPL
z/OS環境をカスタマイズした場合、IPLが必要なケースも出てくると思いますので、手動でIPLする手順を示しておきます。
Shutdown
(1)各サブシステムの停止
個別に稼働しているサービスなどがあれば適宜停止します。
(2)Netview管理のサブシステムの停止
参考: NetView automation for Sandbox
TSOもしくはマスターコンソールからNetviewの以下コマンドを実行します。
F CNMPROC,SHUTSYS
VTAM, JES2, OMVSなどNetview管理の各種サブシステムが一通り停止します。
(3)zpdtの停止
IBM Zのエミュレーターであるzpdtのプロセスを停止します。これは、Sandboxのコンテナに入って操作するので、ocコマンドをセットアップしたLinux環境から行います。
Sandboxのコンテナに接続し、ibmsys1ユーザーにスイッチし、logからIEF352I ADDRESS SPACE UNAVAILABLEのメッセージを確認します。
[root@Test05 ~/openshift/Wazi]# oc exec wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 -c wazi-sandbox-system -it -- bash
[root@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 ibmsys1]# su - ibmsys1
Last login: Fri Jan 22 07:01:26 UTC 2021 on pts/0
[ibmsys1@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 ~]$ cd z1090/logs
[ibmsys1@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 logs]$ tail log_console_p41566_t2021-01-22_07-15-16.txt
INFO: 012321 05:42:26: : OPRMSG: DSI531I 'DSIHLLMT' : 'DSIHLLMT' IS TERMINATING
INFO: 012321 05:42:26: : OPRMSG: DSI200I TASK DSIHLLMT HAS TERMINATED
INFO: 012321 05:42:26: : OPRMSG: DSI531I 'DSITIMMT' : 'DSITIMMT' IS TERMINATING
INFO: 012321 05:42:26: : OPRMSG: DSI200I TASK DSITIMMT HAS TERMINATED
INFO: 012321 05:42:27: : OPRMSG: DSI531I 'DSIMONIT' : 'DSIMONIT' IS TERMINATING
INFO: 012321 05:42:27: : OPRMSG: DSI200I TASK DSIMONIT HAS TERMINATED
INFO: 012321 05:42:27: : OPRMSG: DSI135I NetView termination complete
INFO: 012321 05:42:29: : OPRMSG: IRRB005I (#) RACF SUBSYSTEM TERMINATION IS COMPLETE.
INFO: 012321 05:42:29: : OPRMSG: IEF352I ADDRESS SPACE UNAVAILABLE
INFO: 012321 05:42:29: : OPRMSG: IEF352I ADDRESS SPACE UNAVAILABLE
awsstopコマンドでzpdtを停止します。
[ibmsys1@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 logs]$ awsstop
AWSSTP012I Shutdown accepted
起動
Shutdownと同様、Sandboxのコンテナに接続してibmuserにスイッチし、awsstart /zdt/zvolumes/devmap.txt --cleanコマンドを実行します。
[ibmsys1@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 ~]$ awsstart /zdt/zvolumes/devmap.txt --clean
IBM System z Personal Development Tool (zPDT)
Licensed Materials - Property of IBM
5799-ADE
(C) Copyright IBM Corp. 2007,2013 All Rights Reserved.
z1091, version 1-10.55.05.01, build date - 09/15/20 for Linux on Redhat 64bit
AWSSTA014I Map file name specified: /zdt/zvolumes/devmap.txt
AWSSTA090I All zPDT log files purged as requested
AWSSTA204I zPDT started in directory '/home/ibmsys1'.
AWSSTA146I Starting independent 1090 instance 'ibmsys1'
LDK license obtained for CPU 2
LDK license obtained for CPU 1
AWSEMI005I Waiting for 1090 license
LDK license obtained for CPU 0
OSA code level = 0x7617
AWSDSA010I AWSOSA is ready for chpid: 0xA0 device: 0x400
AWSDSA010I AWSOSA is ready for chpid: 0xA0 device: 0x401
AWSDSA010I AWSOSA is ready for chpid: 0xA0 device: 0x402
AWSMIP008I zArchitecture IPL mode (ZARCH_ONLY=ON)
AWSSTA059I System initialization complete
AWSSTA012I All configured subsystems started
その後自動的にIPLが走り、同シェルの標準出力にIPL時のログが出力されます。
OPRMSG: *IEA247I USING IEASYSNZ FOR z/OS 02.04.00 HBB77C0
OPRMSG: Beep!
OPRMSG: ISG313I SYSTEM IS INITIALIZING IN GRS NONE MODE. RING OR STAR CONFIGURATION KEYWORDS IN GRSCNF00 ARE IGNORED.
OPRMSG: IAR040I REAL STORAGE AMOUNTS:
OPRMSG: TOTAL AVAILABLE ONLINE: 8G
OPRMSG: LFAREA LIMIT FOR xM, xG, OR xT : 4505M
OPRMSG: LFAREA LIMIT FOR SUM OF 1M= AND 2G= : 3276M
OPRMSG: LFAREA LIMIT FOR 2GB PAGES FOR 2G= : 1
OPRMSG: IAR048I LFAREA=(1M=(15%,0%),NOPROMPT) WAS PROCESSED WHICH RESULTED IN 614 1MB PAGES AND 0 2GB PAGES.
OPRMSG: IEA598I TIME ZONE = W.04.00.00
OPRMSG: CNZ2600I AUTO-REPLY POLICY ACTIVATED.
OPRMSG: IXC470I SYSTEM S0W1 EFFECTIVE VALUES: INTERVAL=165 OPNOTIFY=168
OPRMSG: DEFAULT USER INTERVAL: 165
OPRMSG: DERIVED SPIN INTERVAL: 165
OPRMSG: DEFAULT USER OPNOTIFY: + 3
OPRMSG: COMPUTED FOR: XCF INITIALIZATION
OPRMSG: IXC413I MULTISYSTEM SYSPLEX CONFIGURATION PREVENTED BY SYSTEM COMPONENT
OPRMSG: ISG150I GRS=NONE IS NOT SUPPORTED WHEN RUNNING IN A MULTISYSTEM SYSPLEX.
OPRMSG: IXC418I SYSTEM S0W1 IS NOW ACTIVE IN SYSPLEX ADCDPL
OPRMSG: IEE712I SET CNGRP PROCESSING COMPLETE
OPRMSG: IEA549I SYSTEM CONSOLE FUNCTIONS AVAILABLE
OPRMSG: SYSTEM CONSOLE NAME ASSIGNED HWCI
OPRMSG: CEE3739I LANGUAGE ENVIRONMENT INITIALIZATION COMPLETE
OPRMSG: IEE389I MVS COMMAND PROCESSING AVAILABLE
しばらく待てば各種サブシステムが起動するので、TCP/IPやTN3270、TSOが上がってくればPCOMからの接続などができるようになります。
※Pod起動時のIPLについては、systemdのサービスとして登録されているipl-zOS.serviceを自動起動するように設定されています。
systemctl start ipl-zOS.service
手動で起動する場合には上のコマンドも利用可能ですが、手動でrootからこのコマンドを実行すると、コマンドの戻りが返らない状態となりサービスのステータスとしては以下のようにactivatingのままになってしまいました。これでもz/OSは特に問題無く稼働します。
[root@wazi-sandbox01-wazi-sandbox-system-6679544c49-c8ww6 ~]# systemctl status ipl-zOS.service
● ipl-zOS.service - Emulator z1090
Loaded: loaded (/etc/systemd/system/ipl-zOS.service; enabled; vendor preset: disabled)
Active: activating (start) since Mon 2021-01-25 23:35:12 UTC; 9min ago
Process: 696868 ExecStartPre=/bin/sleep 60 (code=exited, status=0/SUCCESS)
...
※OpenShiftのDeploymentのReplica数を一度0にして1に戻すとPodが再作成されるので、一応そのような再起動も可能です。ただ、ミドルの停止はしてあげないとバチンと電源落とすイメージになるので注意してください(IMSとかDb2とかリソースマネージャーが動いていると面倒なことになると思います)。また、この方法だとServiceも再作成になってNodePortとして公開しているポート番号が変わってしまうのでその辺も注意が必要です。