Home Operating Systems: z/OS

 

Performing required z/OS system configurations

Before starting IHS, there are required z/OS system configurations that set up.

In order to run IHS, set the following z/OS system configurations:

• Set the MEMLIMIT parameter. The MEMLIMIT parameter controls the amount of virtual memory above 2 gigabytes for a particular address space. The default setting for MEMLIMIT is 0. However, all binary programs provided with IBM HTTP Server are 64-bit applications, and these applications will not be operational with the default setting for MEMLIMIT.The MEMLIMIT parameter can be set:

  • In the OMVS segment of the user ID used to run the server:

    ALTUSER WWWSERV OMVS(MEMLIMIT(512M))

  • In the parmlib member SMFPRMxx. Setting the parmlib member SMFPRMxx will establish the system-wide MEMLIMIT default.

  For a complete description of how to set MEMLIMIT, refer to the section "Limiting the use of memory objects" in z/OS MVS™ Programming Extended Addressability Guide (SA22-7614). You can link to this document from the z/OS Internet Library.

  IBM HTTP Server requires approximately 5.4 megabytes of 64-bit virtual memory per thread. The minimum recommended MEMLIMIT setting for proper IHS operation is: 6 * (ThreadsPerChild + 3) megabytes.

• Configure a mechanism for allowing access to low ports.

  The Web server user ID must have access to the TCP ports on which it will handle client connections. If port values less than 1024 are used, such as Web server ports 80 and 443, special configuration is required to allow the Web server to bind to the port. You can use one of the following mechanisms to allow access to low ports:

  • Set the PORT directive in the TCP/IP configuration.

  • Disable RESTRICTLOWPORTS in the TCP/IP configuration.

  • Code the Web server job name on a PORT statement in the TCP/IP configuration.

  • Code a wildcard for the job name on a PORT statement in the TCP/IP configuration.

  • Code SAF and a safname value on the PORT statement in the TCP/IP configuration, and permit the Web server user ID read access to the SAF FACILITY class profile EZB.PORTACCESS.sysname.stackname.safname.

  For more information on configuration methods for allowing access to low ports, refer to the sections "Port access control" and "Setting up reserved port number definitions in PROFILE.TCPIP" in z/OS Communications Server IP Configuration Guide (SC31-8775). You can link to this document from the z/OS Internet Library.

  For an explanation of how Unix System Services jobnames (such as those for IHS instances) are determined, refer to the section "Generating jobnames for OMVS address spaces" in z/OS UNIX System Services Planning (GA22-7800). Link to this document from the z/OS Internet Library.

• Required System Authorization Facility (SAF) configurations.

  • Create a user ID and group for IBM HTTP Server.You can use a new or existing user ID. It must have an OMVS segment and the UID cannot be zero.

    The following example contains RACF commands to create a new user and group.

    Password example
    
    ADDGROUP WWWGROUP OMVS(GID(999))
    ADDUSER  WWWSERV  DFLTGRP(WWWGROUP) OMVS(UID(999)) PASSWORD(password)

    Password phrase example
    
    ADDGROUP WWWGROUP OMVS(GID(999))
    ADDUSER  WWWSERV  DFLTGRP(WWWGROUP) OMVS(UID(999)) PHRASE('my0users@99#701_workgroup')

    The security administrator should define the password for the Web server user ID, instead of allowing it to default, to prevent an unauthorized user from being able to log in with that user ID. The ALTUSER command can be used to modify the password of an existing user ID.

    If you use a JCL cataloged procedure to start an IBM HTTP Server instance, create a SAF STARTED profile to assign the server user ID and group ID to the server started task. For example, to use a cataloged procedure named WEBSRV1:

    RDEFINE STARTED WEBSRV1.* STDATA(USER(WWWSERV) GROUP(WWWGROUP) TRACE(YES))

  • Set program control for required MVS data sets. Ensure that program control is turned on for the following MVS data sets. For hlq, enter the high level qualifier for your system installation, for example: SYS1.LINKLIB.

    • hlq.LINKLIB

    • hlq.SCEERUN

    • hlq.SCEERUN2

    • hlq.SCLBDLL
    The following example shows how to turn on program control using RACF commands. If we are using another security product, refer to that product's documentation for instructions. If we are turning on program control for the first time, you should use RDEFINE statements instead of RALTER statements:

    RALTER PROGRAM * ADDMEM('hlq.LINKLIB'
    //NOPADCHK) UACC(READ)
    RALTER PROGRAM * ADDMEM('hlq.SCEERUN'
    //NOPADCHK) UACC(READ)
    RALTER PROGRAM * ADDMEM('hlq.SCLBDLL') UACC(READ)
    SETROPTS WHEN(PROGRAM) REFRESH

    In this example, an asterisk (*) is used to specify all programs in the data set.

  • Set program control for HFS files.The SMP/E installation logic enables the program control bit for the provided libraries and executable files that need it. If we install custom plug-in modules, use the extattr command to enable the APF and Program Control flags. For example:

    # extattr +ap /opt/IBM/HTTPServer/modules/mod_jauth.so

    In this example, substitute the IHS installation location for /opt/IBM/HTTPServer/. (You can build custom plug-in modules using the apxs script that is provided.)

  • Set program control for z/OS System SSL. If we set up your IBM HTTP Server to provide secure communications over the Internet, IBM HTTP Server uses z/OS System SSL (SSL) to establish the secure connections. Before IBM HTTP Server can use System SSL, :

    • Add the System SSL load library (hlq.SIEALNKE) to the system link list or to the STEPLIB DD concatenation in the HTTP Server cataloged procedure

    • Set program control hlq.SIEALNKE in RACF.
    The variable hlq is the high level qualifier for your system installation, for example: SYS1.SIEALNKE. To turn on program control using RACF, issue the following command:

    RALTER PROGRAM * ADDMEM('hlq.SIEALNKE'
    //NOPADCHK) UACC(READ)
    SETROPTS WHEN(PROGRAM) REFRESH

    If we are turning on program control for the first time, use the RDEFINE statements instead of the RALTER statements. If we are using another security product, refer to that product's documentation for instructions.

  • Access to SAF key rings.The SSL and LDAP authentication support can optionally use certificates stored in SAF key rings. This requires that the Web server user ID have certain SAF permissions. Specifically, the Web server user ID must be permitted to the IRR.DIGTCERT.LISTRING facility in order to use key rings. Here are the general steps required:

    1. Define the IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING resources with universal access of None.

    2. Permit the Web server user ID read access to the IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING resources in the FACILITY class.

    3. Activate the FACILITY general resource class.

    4. Refresh the FACILITY general resource class.

    The following commands are RACF commands. Replace WWWSERV with the actual user ID under which IBM HTTP Server is started.

    RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
    PE IRR.DIGTCERT.LIST CLASS(FACILITY) ID(WWWSERV) ACCESS(READ)
    RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
    PE IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(WWWSERV) ACCESS(READ)
    SETR CLASSACT(FACILITY)
    SETR RACLIST(FACILITY) REFRESH

    For a complete guide to RACF commands, refer to z/OS Security Server RACF Security Administrator's Guide (SA22-7683). You can link to this document from the z/OS Internet Library.

  • Permitting user IDs to CSFSERV for hardware encryption:

    Integrated Cryptographic Services Facility (ICSF) is the software interface to the cryptographic hardware. If we plan to run IBM HTTP Server with cryptographic hardware capability, you can restrict the use of ICSF services. To restrict the use of ICSF services, you can permit user IDs to certain profiles in the CSFSERV general resource class. CSFSERV controls the use of ICSF software. If we have defined your IHS to execute with a nonzero user ID, you can give the nonzero user ID READ access to CSFSERV. If we are using a security product other than RACF, refer to that product's documentation for instructions.

    If we want to restrict the use of ICSF services, issue RACF commands similar to the commands in the following examples. If we have applications other than IHS that are using ICSF, customize the examples. Otherwise, the other applications will no longer have access to ICSF services.

    The following example shows how to permit the WWWSERV ID and the PUBLIC ID access to profiles in CSFSERV.

    SETROPTS RACLIST(CSFSERV) GENERIC(CSFSERV)
    RDEFINE CSFSERV CSF* UACC(NONE)
    PERMIT CSF%%C CLASS(CSFSERV) ID(WWWSERV PUBLIC) ACCESS(READ)
    PERMIT CSFPK% CLASS(CSFSERV) ID(WWWSERV PUBLIC) ACCESS(READ)
    PERMIT CSFCK% CLASS(CSFSERV) ID(WWWSERV PUBLIC) ACCESS(READ)
    SETROPTS CLASSACT(CSFSERV)
    SETROPTS RACLIST(CSFSERV) GENERIC(CSFSERV) REFRESH

    The following example shows how to give user IDs and the WWWSERV ID access to profiles in CSFSERV.

    SETROPTS RACLIST(CSFSERV) GENERIC(CSFSERV)
    RDEFINE CSFSERV CSF%%C UACC(READ)
    RDEFINE CSFSERV CSFPK% UACC(READ)
    RDEFINE CSFSERV CSFCK% UACC(READ)
    SETROPTS CLASSACT(CSFSERV)
    SETROPTS RACLIST(CSFSERV) GENERIC(CSFSERV) REFRESH

  • Using cryptographic hardware for key storage (optional):

    To perform key storage on cryptographic devices refer to the section "Integrated Cryptographic Service Facility (ICSF) Considerations" in z/OS Security Server RACF Security Administrator's Guide (SA22-7683).

    For information on ICSF options refer to the section "Using Hardware Cryptographic Features with System SSL" in z/OS Cryptographic Services System SSL (SSL) Programming (SC24-5901).

    You can link to both of these documents from the z/OS Internet Library.

• Setting environment variable * _BPX_JOBNAME (optional):

  IHS provides the file <installroot>/bin/envvars for setting environment variables for the httpd processes. You can set the environmental variable * _BPX_JOBNAME to give the server a distinct jobname. This allows you to:

  • See the server in MVS operator commands and System Display and Search Facility (SDSF).

  • Categorize the server in workload management (WLM) to give web traffic adequate priority.

  • Use syslogd isolation for the server.

  • Use PORT statements in the TCP/IP configuration that select by job name.

  A typical setting is: export _BPX_JOBNAME=HTTPD. The default is to append an incrementing integer to your jobname, such as HTTPD1, HTTPD2, HTTPD3. For more information refer to the section "Generating jobnames for OMVS address spaces" in z/OS UNIX System Services Planning (GA22-7800). Link to this document from the z/OS Internet Library. If we use the _BPX_JOBNAME variable to set the jobname, the user ID which you use to run the server must have read access to the SAF FACILITY profile BPX.JOBNAME. For example:

  RDEFINE FACILITY BPX.JOBNAME  UACC(NONE)
  SETROPTS RACLIST(FACILITY) REFRESH 
  PERMIT BPX.JOBNAME CLASS(FACILITY) ACCESS(READ) ID(WWWSERV) 
  SETROPTS RACLIST(FACILITY) REFRESH 
  RLIST FACILITY BPX.JOBNAME ALL

  For more information refer to the section "Setting up the BPX.* FACILITY class profiles" in z/OS UNIX System Services Planning (GA22-7800). Link to this document from the z/OS Internet Library.

---

 

Related information

z/OS Internet Library