When LoadLeveler is configured to exploit DCE security, it uses PSSP and DCE security services to:
You can skip this section if you do not plan to use these security features or if you plan to continue to use only the limited support for DCE available in LoadLeveler 2.1. Please consult Usage notes for additional information.
When LoadLeveler is configured to exploit DCE security, most of its interactions with DCE are through the PSSP security services API. For this reason, it is important that you configure PSSP security services before you configure LoadLeveler for DCE. For more information on PSSP security services, please refer to: RS/6000 SP Planning Volume 2, Control Workstation and Software Environment (GA22-7281-05), Parallel System Support Programs for AIX Installation and Migration Guide Version 3 Release 2 (GA22-7347-02), and Parallel System Support Programs for AIX Administration Guide Version 3 Release 2 (SA22-7348-02).
DCE maintains a registry of all DCE principals which have been authorized to login to the DCE cell. In order for LoadLeveler daemons to login to DCE, DCE accounts must be set up, and DCE key files must be created for these daemons. Each LoadLeveler daemon on each node is associated with a different DCE principal. The DCE principal of the Schedddaemon running on node A is distinct from the DCE principal of the Schedd daemon running on node B. Since it is possible for up to seven LoadLeveler daemons to run on any particular node (Master, Negotiator, Schedd, Startd, Kbdd, Starter, and GSmonitor), the number of DCE principal accounts and key files that must be created could reach as high as 7x(number of nodes). Since it is not always possible to know in advance on which node a particular daemon will run, a conservative approach would be to create accounts and key files for all seven daemons on all nodes in a given LoadLeveler cluster. However, it is only necessary to create accounts and key files for DCE principals which will actually be instantiated and run in the cluster.
These are the steps used for configuring LoadLeveler for DCE. We recommend that you use SMIT and the lldcegrpmaint command to perform this task. The manual steps are also described in Manual configuration, and may be useful should you need to create a highly customized LoadLeveler environment. Some of the names used in this section are the default names as defined in the file /usr/lpp/ssp/config/spsec_defaults and can be overridden with appropriate specifications in the file /spdata/sys1/spsec/spsec_overrides. Also, the term "LoadLeveler node" is used to refer to a node on an SP system that will be part of a LoadLeveler cluster.
DCE_ENABLEMENT = TRUE DCE_ADMIN_GROUP = LoadL-admin DCE_SERVICES_GROUP = LoadL-servicesDCE_ENABLEMENT must be set to TRUE to activate the DCE security features of LoadLeveler. The LoadL-admin group should be populated with DCE principals of users who are to be given LoadLeveler administrative privileges. For more information on populating the LoadL-admin group, see 9. The LoadL-services group should be populated with the DCE principals of all the LoadLeveler daemons that will be running in the current cluster. You can use the lldcegrpmaint command to automate this process. For more information on populating the LoadL-services group, see step 8. Note that these daemons are already members of the spsec-services group. If there is more than one DCE-enabled LoadLeveler cluster within the same DCE cell, then it is important that the name assigned to DCE_SERVICES_GROUP for each cluster be distinct; this will avoid any potential operational conflict.
dce_host_name = DCE hostnameExecute either "SDRGetObjects Node dcehostname," or "llextSDR" to obtain a listing of DCE hostnames of nodes on an SP system.
lldcegrpmaint config_pathname admin_pathnameWhere config_pathname is the pathname of the LoadLeveler global configuration file and admin_pathname is the pathname of the LoadLeveler administration file. The lldcegrpmaint command will:
For more information about the lldcegrpmaint command, see lldcegrpmaint - LoadLeveler DCE group maintenance utility.
dcecp -c group add LoadL-admin -member loadl
Here is an example of the steps you must take to configure LoadLeveler for DCE.
In this example, the LoadLeveler cluster consists of 3 nodes of an SP system which belong to the same DCE cell. Their hostnames and DCE hostnames are the same: c163n01.pok.ibm.com, c163n02.pok.ibm.com, and c163n03.pok.ibm.com. Assume that the basic PSSP security setup steps have been performed, and that the DCE group spsec-services and the DCE organization spsec-services have been created.
dcecp -c cdsli /.:/subsys
This command lists the contents of the /.:/subsys directory in DCE. LoadLeveler's product name within DCE is LoadL, so its product directory is /.:/subsys/LoadL. If this directory already exists, then continue to the next step. If it does not exist, issue to following command to create it:
dcecp -c directory create /.:/subsys/LoadL
product_name/dce_host_name/dce_daemon_name
Where:
SERVICE:LoadL/Master:kw:root:system
The relevant portion of this record is Master; this is the DCE daemon name of LoadL_master. The DCE daemon names of other daemons can be identified in a similar manner.
For the c163n01.pok.ibm.com node, the following commands will create the desired principal names:
dcecp -c principal create LoadL/c163n01.pok.ibm.com/Master dcecp -c principal create LoadL/c163n01.pok.ibm.com/Negotiator dcecp -c principal create LoadL/c163n01.pok.ibm.com/Schedd dcecp -c principal create LoadL/c163n01.pok.ibm.com/Kbdd dcecp -c principal create LoadL/c163n01.pok.ibm.com/Startd dcecp -c principal create LoadL/c163n01.pok.ibm.com/Starter dcecp -c principal create LoadL/c163n01.pok.ibm.com/GSmonitor
These commands must then be repeated for each node in the LoadLeveler cluster, replacing the dce_host_name with the DCE hostname of each respective node.
dcecp -c group add spsec-services -member LoadL/c163n01.pok.ibm.com/Master
This operation must be repeated for all of the other LoadLeveler daemons on c163n01, and the complete set of operations must be repeated for all of the nodes in the LoadLeveler cluster.
dcecp -c organization add spsec-services -member LoadL/c163n01.pok.ibm.com/Master
This operation must be repeated for all of the other LoadLeveler daemons on c163n01, and the complete set of operations must be repeated for all of the nodes in the LoadLeveler cluster.
dcecp <Enter>
dcecp> account create LoadL/c163n01.pok.ibm.com/Master \
-group spsec-services -organization spsec-services \
-password service-password -mypwd cell_admin's-password
dcecp> quit
The service-password passed to DCE in this command can be any valid DCE password. Please take note of it since you will need it when you create the key file for this daemon in step 8. The continuation character "\" is not supported by dcecp, but appears in the example merely for clarity. This operation must be repeated for the other LoadLeveler daemons on c163n01, and the complete set of operations must be repeated for all of the nodes in the LoadLeveler cluster.
mkdir -p /spdata/sys1/keyfiles/LoadL/dce_host_name
You must login to the appropriate node to perform this operation. This operation must be repeated for every node in the LoadLeveler cluster.
NOTE: The directory /spdata/sys1/keyfiles should already exist on each node in the cluster which has been installed with a level of PSSP software that supports DCE Security exploitation. If this directory does not exist, then the node cannot support DCE Security and LoadLeveler 2.2 in DCE mode will not run on it. If this configuration seems to be in error, contact your system administrator to determine which nodes in the cluster should support DCE Security.
dcecp <Enter>
dcecp> keytab create LoadL/c163n01.pok.ibm.com/Master \
-storage /spdata/sys1/keyfiles/LoadL/c163n01.pok.ibm.com/Master \
-data { LoadL/c163n01.pok.ibm.com/Master plain 1 service-password }
dcecp> quit
You must login to node c163n01 to perform this operation. DCE must be able to locate the key file locally, otherwise the daemon's login to DCE on startup will fail. The principal name passed to DCE in the preceding example is the same principal name defined in step 3. The AIX path passed with the "-storage" flag should point to the same directory created in step 7. The principal name passed with the "-data" flag should match the principal name used at the beginning of the command. The password used in the service-password field must be the same as the service password defined when this principal's account was created in step 6.
This operation must be repeated for all of the other LoadLeveler daemons on node c163n01, and the complete set of operations must be repeated for all of the nodes in the LoadLeveler cluster.
dcecp -c group create LoadL-admin
dcecp -c group add LoadL-admin -member loadl
dcecp -c group add LoadL-services -member LoadL/c163n01.pok.ibm.com/Master
This operation must be repeated for all of the other LoadLeveler daemons on node c163n01, and the complete set of operations must be repeated for all of the nodes in the LoadLeveler cluster.
If the DCE_ENABLEMENT keyword is not defined or set to FALSE, the limited form of DCE authentication introduced in LoadLeveler 2.1 can still be activated through the use of the DCE_AUTHENTICATION_PAIR keyword in conjunction with the llgetdce and llsetdce programs or an installation defined functionally equivalent pair of programs. If this level of DCE support meets your requirements, then you can ignore the setup steps in this section.