SSL Server and GSKADMIN Initialization Problems
(Level 540 and Later)

Below are several initialization problems that one might encounter during initial configuration of the z/VM SSL server (for the 540, and later, levels), with actions that can be taken which should help with their resolution.

  • DMSLIO201W warning and DTCSSL300E error reported during server initialization

     DTCRUN1011I Server started at hh:mm:dd on dd mon yyyy (day)
     DTCRUN1011I Running server command: VMSSL
     DTCRUN1011I Parameters in use:
     DTCRUN1011I  MAXSESSIONS 20 KEYFILE /etc/gskadm/Database.kdb
     DTCSSL2423I Using server module: SSLSERV MODULE E2 - 2/26/09 16:28:52
     DTCSSL002I SSLSERV main() - PROGMAP:
     Name        Entry       Origin      Bytes        Attributes
     SSLSERV     0FD63288    0FD63288    00041D73    Amode 31  Reloc:
     DTCSSL002I DEBUG settings: Debug: 0
     DTCSSL002I main() started...
     DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850)
     DTCSSL100I This software incorporates the RSA algorithm
     DTCSSL132I Server ID: SSLSERV
     DMSLIO201W The following names are undefined:
      EDCUCSNM
     DMSLIO201W The following names are undefined:
      EDCUCSNM
     DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009
     reason: File or keyring not found
     DTCSSL127E Server shutdown has commenced
     DTCSSL128E Server shutdown is complete
     DTCRUN1015I Server ended with RC=1 at hh:mm:dd on dd mon yyyy (day)
     DTCRUN1019I Server will not be logged off because you are connected
     Ready;
    

    For this case, the DMSLIO201W warning and the 0x3353009 return code might result from referencing a non-540 (or later) level SSL server :type.class definition within one of the DTCPARMS configuration files available to the SSL server, or from erroneous mount parameters that have been specified for the :mount. tag.

    Check the various DTCPARMS files for an outdated :nick.ssl :type.class entry, such as this sample:

     :nick.ssl     :type.class
                   :name.SSL daemon
                   :command.VMSSL
                   :diskwarn.YES
    

    A :nick.ssl :type.class entry (appropriate for the level 540, or later) SSL server should be similar to that shown here, from the PK65850-level IBM DTCPARMS file:

      :nick.ssl     :type.class
                    :name.SSL daemon
                    :command.VMSSL
                    :runtime.C
                    :diskwarn.YES
                    :Admin_ID_list.TCPMAINT GSKADMIN
                    :memory.256M
                    :mixedcaseparms.YES
                    :mount. /../VMBFS:VMSYS:ROOT/      /     ,
                            /../VMBFS:VMSYS:SSLSERV/   /tmp  ,
                            /../VMBFS:VMSYS:GSKSSLDB/  /etc/gskadm
     
                    :parms.KEYFile /etc/gskadm/Database.kdb
    
  • DTCSSL300E error (only) reported during server initialization

     DTCRUN1011I Server started at hh:mm:dd on dd mon yyyy (day)
     DTCRUN1011I Running server command: VMSSL
     DTCRUN1011I Parameters in use:
     DTCRUN1011I  KEYFile /etc/gskadm/Database.kdb
     DTCSSL2423I Using server module: SSLSERV MODULE E2 - 12/30/08 12:26:53
     DTCSSL002I SSLSERV main() - PROGMAP:
     Name        Entry       Origin      Bytes        Attributes
     SSLSERV     0F8E8288    0F8E8288    00041D73    Amode 31  Reloc
     DTCSSL002I DEBUG settings: Debug: 0
     DTCSSL002I main() started...
     DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850)
     DTCSSL100I This software incorporates the RSA algorithm
     DTCSSL132I Server ID: SSLSERV
     DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009
     reason: File or keyring not found
     DTCSSL127E Server shutdown has commenced
     DTCSSL128E Server shutdown is complete
     DTCRUN1015I Server ended with RC=1 at hh:mm:dd on dd mon yyyy (day)
     DTCRUN1019I Server will not be logged off because you are connected
     Ready;
    

    This error (more specifically, the 0x3353009 return code) likely has resulted due to incorrect file permissions assigned to the Database.sth (or Database.kdb) file.

    To check the file permissions, issue the following OPENVM LISTFILE command after logon of the GSKADMIN user ID:

     openvm listfile /etc/gskadm (own
    

    Confirm that the file permissions reflect read permission for the security group for the Database.sth and Database.kdb files:

     Directory = '/etc/gskadm/'
     User ID    Group Name  Permissions Type  Path name component
     gskadmin   security    rwx r-- ---  F    'Database.kdb'
     gskadmin   security    rw- --- ---  F    'Database.rdb'
     gskadmin   security    rwx r-- ---  F    'Database.sth'
    

    If this is not the case, issue the following OPVENVM PERMIT commands to establish such permission:

     openvm permit /etc/gskadm/Database.kdb rw- r-- ---
     openvm permit /etc/gskadm/Database.sth rw- r-- ---
    
  • DMSOVZ2120E Unable to resolve current working directory for path name
    (From attempted mount of the /../VMBFS:VMSYS:GSKSSLDB/ filespace)

    One possible cause for this error is due to the VMSERVU file pool server not being in operation. By default, the /etc, /tmp and /var directories are maintained in the VMSYSU: file pool, and not in VMSYS file pool that manages the root directory. Ensuring that the VMSERVU server is fully operational (not just logged on) likely will resolve this problem.

    The following command can be used to confirm the VMSERVU server is active:

     query filepool overview vmsysu:
    

    Another possible (but uncommon) cause for this error is due to lack of availability of one (or all) of the /etc, /tmp or /var directories. Such a condition could result if the VMSYSU: filepool is regenerated, perhaps to recover filepool operation after a significant file pool problem.

    To confirm the filespaces for these directories are present, issue this filepool QUERY command:

     query enroll filespace for all vmsysu:
    
    The query results should be similar to this (with BFS entries being important):
     Number Of file spaces =  5
     <PUBLIC>   SFS
     ETC        BFS
     MAINT      SFS
     TMP        BFS
     VAR        BFS
    
    If one or more BFS filespaces are not present, it likely is necessary to recreate these. The root file space proper is created by running the BFSROOT command, while those for the TCP/IP SSL (and, LDAP) server, and the key database are created by running respective LOADBFS commands. The commands cited below will accomplish this task.

    Notes

    • Use the MAINTvrm user ID (or its equivalent) to issue these commands, after having ensured that the VMSERVS and VMSERVU file pool servers are up and running.
    • For the commands listed here, it is assumed that no PPF overrides to the SERVP2P $PPF file are in use by your installation. If this is not the case, adjust the VMFSETUP commands accordingly.
    • One can expect messages to be produced indicating that certain resources are already defined. Such messages likely can be dismissed.

     set filepool vmsys:
     access 493 z
     bfsroot
     vmfsetup detach
     vmfsetup servp2p tcpipp2p (link
     loadbfs sslserv loadbfs
     loadbfs ldapsrv loadbfs
     loadbfs gskssldb loadbfs
     vmfsetup detach
    

    After having completed these commands, you can again issue the QUERY ENROLL FILESPACE FOR ALL VMSYSU: command cited previously, to confirm the necessary filespaces are present.