IBM Books

Command and Technical Reference, Volume 2

RS/6000 SP files and other technical information

auto.master file

Purpose

auto.master - Specifies the master input file to the AIX automount daemon defining the file systems to be controlled and their associated map files.

Description

The auto.master file is the master map file for the AIX automount daemon. It identifies the file systems that are to be controlled by the automounter and the directory map file associated with each file system. It may also contain default mount information for specific file systems. The auto.master file may reference a Network Information Service (NIS) configuration map that is to be used by the automounter. Entries in the master map file use one of the following formats: 

+NIS_map
 
Directory_path Automount_map_name [default_mount_options]

The first form specifies an NIS configuration map that contains mount point and automounter map information. The second form directly identifies the directory path of the file system that is to be controlled by the automounter, along with the map file containing entries for the supported directories within that file system. Default options to be used when the file system is mounted can be optionally specified.

Files

/etc/auto.master
Specifies map files for the AIX automount daemon.

Related Information

AIX daemons: automount

The "Managing the automounter" chapter in PSSP: Administration Guide

The "Network File System (NFS)" and "Network Information Service (NIS)" chapters in AIX System Management Guide: Communications and Networks

Examples

The following example is a copy of the default auto.master file shipped with the SP modified to support an NIS configuration map: 

# The following entry will use the NIS configuration map if NIS is
# defined for this system and the database exists
 +auto_master
# The following entry provides automount support for users' home
# directories
/u /etc/auto/maps/auto.u -rw,hard,retry=3,timeo=40,rsize=4096, \
wsize=4096

bootptab.info file

Purpose

|bootptab.info - Users can create this file to |specify the hardware Ethernet addresses of nodes. | |

Description

|Users can create this file to contain a list of nodes with their |hardware Ethernet addresses. When placed in the proper location, it is |used by the sphrdwrad command in place of node conditioning |(remember, node conditioning shuts down the node) to obtain the hardware |Ethernet addresses, saving a great deal of time. Each line of the |bootptab.info file must contain two tokens. The first |token represents the node, and the second token represents the hardware |Ethernet address. This information may be input in one of two |formats: 

node_number   hardware_ethernet_address

or 

frame,slot    hardware_ethernet_address

|Users do not have to specify every node and its hardware Ethernet |address in this file, but only those nodes on which they do not want to |perform node conditioning on. By putting an entry in this file for a |node, the node will not be shut down during the execution of the |sphrdwrad command.

|Location

|/etc/bootptab.info

Related Information

Commands: sphrdwrad

Examples

The following is an example of a bootptab.info file for a single framed system that contains four high nodes: 

1 02608CE8764D
5 02608CE87174
1,9 02608CE87180
13 02608CE8618B

haemloadlist file

Purpose

haemloadlist File - Event Management configuration data that is to be loaded into the System Data Repository (SDR).

Description

RS/6000 Cluster Technology (RSCT), which is included with the IBM Parallel System Support Programs (PSSP) Licensed Program (LP), contains a number of resource monitors that use the Resource Monitor Application Programming Interface (RMAPI) to supply information about system resources to the Event Management subsystem. Information about the monitors and the resources is defined in the haemloadlist file and includes:

Before the Event Management subsystem can use this information, it must first be loaded into the System Data Repository (SDR) and then compiled into a binary Event Management Configuration Database (EMCDB) file. The haemloadcfg command is used to load the data from the haemloadlist file into the SDR. The haemcfg command is then used to compile the data from the SDR into the binary EMCDB file. Both of these commands are issued automatically by the haemctrl command when it is used to start the Event Management subsystem on the control workstation.

For resource monitors other than those supplied by RSCT, you must create one or more separate files in load list format to contain their Event Management configuration data. You can specify the name of any file in load list format on the haemloadcfg command.

You can use SDR commands to work with objects in the Event Management classes directly. However, IBM suggests that you use load list files and the haemloadcfg command to work with objects in these classes. The haemloadcfg command provides validation, unique to the Event Management configuration data, not available in the SDR commands.

You cannot use System Management Interface Tool (SMIT) panels to work with objects in these classes.

The Format of an Event Management Load List File

Source information for the EMCDB is kept in the several partitioned classes in the SDR, each of which has a set of associated attributes. The format of an Event Management load list file, which can be used as input to the haemloadcfg command, follows the structure of the Event Management data in the SDR.

This man page describes the format of the Event Management load list file. For detailed information about its content (the Event Management SDR classes, attributes, and their values), see the description of the EMCDB in PSSP: Event Management Programming Guide and Reference.

The haemloadlist file consists of stanzas, each of which describes an object in one of the Event Management SDR classes. The stanzas may appear in any order in the file.

Each stanza begins with the SDR class name to which the object belongs, followed by one or more lines that define the attributes of the object. The SDR class name must begin in column 1.

An attribute line consists of leading whitespace (blanks or tabs) followed by the attribute name followed by an = (equal sign) followed by a data field. The = (equal sign) may not be surrounded by blank spaces. The data field consists of a single value for the attribute. If the field contains blanks, it must be surrounded by double quotes ("). If the field contains a double quote character, it should be preceded by a backslash ( \"). If the field contains a backslash character, it should be preceded by a second backslash (\\).

The data field must be on the same line as the attribute. The attribute lines for a stanza stop at either the start of a new stanza or at the end of the file.

Comments may be present in the file. Any line in which the first nonwhite space character is a pound sign (#) is a comment. Blank lines are also considered comment lines and are ignored.

The EM_Resource_Variable Stanza

The EM_Resource_Variable SDR class contains one object for each resource variable defined in the database. Accordingly, there is one EM_Resource_Variable stanza for each resource variable that is defined.

Here is an example of a stanza that defines a resource variable of type Quantity: 

EM_Resource_Variable
        rvName="IBM.PSSP.aixos.PagSp.totalsize"
        rvDescription="99"
        rvValue_type="Quantity"
        rvData_type="long"
        rvInitial_value="0"
        rvClass="IBM.PSSP.aixos.PagSp"
        rvPTX_name="PagSp/totalsize"
        rvLocator="NodeNum"
        rvDynamic_instance="0"

Here is an example of a stanza that defines a resource variable of type State: 

EM_Resource_Variable
        rvName="IBM.PSSP.Prog.pcount"
        rvDescription="1009"
        rvValue_type="State"
        rvData_type="SBS"
        rvClass="IBM.PSSP.Prog"
        rvLocator="NodeNum"
        rvDynamic_instance="1"

The EM_Structured_Byte_String Stanza

The EM_Structured_Byte_String SDR class contains one object for each structured field that is defined in a structured byte string. Accordingly, there is one EM_Structured_Byte_String stanza for each structured field that is defined.

The IBM.PSSP.Prog.pcount resource variable is an SBS that has three structured fields. Here is an example of the stanzas that define the fields: 

EM_Structured_Byte_String
        sbsVariable_name="IBM.PSSP.Prog.pcount"
        sbsField_name="CurPIDCount"
        sbsField_type="long"
        sbsField_SN="0"
 
EM_Structured_Byte_String
        sbsVariable_name="IBM.PSSP.Prog.pcount"
        sbsField_name="PrevPIDCount"
        sbsField_type="long"
        sbsField_SN="1"
 
EM_Structured_Byte_String
        sbsVariable_name="IBM.PSSP.Prog.pcount"
        sbsField_name="CurPIDList"
        sbsField_type="cstring"
        sbsField_SN="2"

The EM_Resource_ID Stanza

The EM_Resource_ID SDR class contains one object for each resource ID element that is defined for a resource and all of its resource variables. Accordingly, there is one EM_Resource_ID stanza for each resource ID element that is defined.

Here are some examples of stanzas that define resource IDs. The resource ID for the resource named IBM.PSSP.aixos.PagSp contains only one resource ID element. The resource ID for the resource named IBM.PSSP.Prog contains three elements. 

EM_Resource_ID
        riResource_name="IBM.PSSP.aixos.PagSp"
        riElement_name="NodeNum"
        riElement_description="701"

EM_Resource_ID
        riResource_name="IBM.PSSP.Prog"
        riElement_name="UserName"
        riElement_description="701"
 
EM_Resource_ID
        riResource_name="IBM.PSSP.Prog"
        riElement_name="ProgName"
        riElement_description="701"
 
EM_Resource_ID
        riResource_name="IBM.PSSP.Prog"
        riElement_name="NodeNum"
        riElement_description="701"

The EM_Resource_Class Stanza

The EM_Resource_Class SDR class contains one object for each resource variable class that is defined in the database. Accordingly, there is one EM_Resource_Class stanza for each resource variable class that is defined.

Here are two examples of stanzas that define resource classes: 

EM_Resource_Class
        rcClass="IBM.PSSP.aixos.PagSp"
        rcResource_monitor="aixos"
        rcObservation_interval="30"
        rcReporting_interval="0"

EM_Resource_Class
        rcClass="IBM.PSSP.Prog"
        rcResource_monitor="IBM.PSSP.harmpd"
        rcObservation_interval="0"
        rcReporting_interval="0"

The EM_Resource_Monitor Stanza

The EM_Resource_Monitor SDR class contains one object for each resource monitor that is defined in the database. Accordingly, there is one EM_Resource_Monitor stanza for each resource monitor that is defined.

Here are some examples of stanzas that define resource monitors: 

EM_Resource_Monitor
        rmName="IBM.PSSP.harmpd"
        rmPath="/usr/lpp/ssp/bin/haemRM/harmpd"
        rmMessage_file="PEM.cat"
        rmMessage_set="2"
        rmConnect_type="server"
        rmPTX_prefix="0"
        rmPTX_description="0"
        rmPTX_asnno="0"

EM_Resource_Monitor
        rmName="IBM.PSSP.harmld"
        rmPath="/usr/lpp/ssp/bin/haemRM/harmld"
        rmMessage_file="harm_des.cat"
        rmMessage_set="1"
        rmConnect_type="server"
        rmPTX_prefix="IBM/PSSP.harmld"
        rmPTX_description="1,2"
        rmPTX_asnno="2"

Location

/usr/sbin/rsct/install/config/haemloadlist

Related Information

Commands: haemcfg, haemloadcfg

For a general overview of configuring Event Management, see "The Event Management subsystem" chapter of PSSP: Administration Guide.

For a description of the SDR classes and attributes that are related to the EMCDB, see PSSP: Event Management Programming Guide and Reference.

hmacls file

Purpose

/spdata/sys1/spmon/hmacls - Defines the Access Control Lists (ACLs) used by the Hardware Monitor daemon.

Description

The /spdata/sys1/spmon/hmacls file contains permission specifications for users to execute the various Hardware Monitor operations. Each line in the file consists of three white-space separated tokens in the following format: 

obj    user_name     permissions

The obj token is either a frame ID or the host name of the control workstation (known as the Monitor and Control Node (MACN) by the Hardware Monitor). The user_name token is the user's principal name or principal name and instance.

The permissions token specifies which operations the user specified by the user_name token can execute against the object specified by the obj token.

If the obj token is a frame ID, the permissions token is one or more characters taken from the set v, s, and m. A definition of each follows:

v
Specifies Virtual Front Operator Panel (VFOP) permission

s
Specifies S1 permission

m
Specifies Monitor permission

The VFOP permission implies the monitor permission. These permissions are described in the various commands. If the obj token is the MACN host name, the permissions token must be the character a. The character a is the administrative permission required to use the hmadm command.

Users are authorized to use the Hardware Monitor by virtue of having their names in the /spdata/sys1/spmon/hmacls file and have issued the k4init command with that name.

Files

/spdata/sys1/spmon/hmacls
Specifies ACLs for the Hardware Monitor daemon.

Related Information

Commands: hmadm, hmcmds, hmmon, nodecond, s1term

Examples

The following is an example of a hmacls file: 

workstn3.kgn.ibm.com  john.admin  a
1  john.admin  vsm
2  john.admin  vsm
3  john.admin  vsm
1  mary        m
2  mary        m
3  mary        m

hmthresholds file

Purpose

hmthresholds - provides a software mechanism for applying threshold values to SP Frame, Node, and Switch environmental conditions such as voltage, amperage, and temperature. The Hardware Monitor (hardmon), with the aid of the Logging Daemon (splogd), provides notification to the ERRPT when an applied threshold value is crossed. This software checking, if enabled, is done in parallel with the internal self-checking done by the hardware itself.

Description

The /spdata/sys1/spmon/hmthresholds file contains threshold values in the form of low/high warning conditions, and low/high shutdown conditions. Each line in the file, excluding comment lines, which begin with a # (pound sign) in column one, consists of at least three white-space separated tokens in the following format:

node_type low_value high_value [ [low_value high_value] [... ...] ]

The node_type token is the value of the Hardware Monitor variable "type" which is the definitive identifier for the SP Supervisor card that is installed in the hardware for any given slot. Use the hmmon command to obtain the value of the variable "type" for a given node.

For example, using an SP2 wide node with 4.0 volt power: 

$ hmmon -G -Q -v type 1:1
 
frame 001, slot 01:
supervisor type 0x0051

low_value and high_value are token pairs that are the low/high values for the environmental condition you want to threshold.

For example, examine the following excerpt from the /spdata/sys1/spmon/hmthresholds file. 

#
# #### SP2 wide node w/4.0 volt power:
#       VOLTP5M    VOLTP12    VOLTN12    VOLTP5I     TEMP      VOLTP4
#      low  high  low  high  low  high  low  high  low  high  low  high
# Warning thresholds
# 0x51 4.75 5.4   11.0 13.0  11.0 13.0  4.75 5.4   0x00 45.0  3.46 4.2
# Shutdown thresholds
# 0x51 4.50 5.75  10.2 13.8  10.2 13.8  4.50 5.75  0x00 60.0  3.28 4.4
# Software thresholding disabled
  0x51 0x00 0xff  0x00 0xff  0x00 0xff  0x00 0xff  0x00 0xff  0x00 0xff

The node_type is 0x51. It is an SP2 wide node w/4.0 volt power. There are three sets of token pairs defined (only one is uncommented). Each of the three sets contain six token pairs. The six token pairs are the low/high threshold values for, in order from left to right, +5 volts memory, +12 volts, -12 volts, +5 volts I/O, temperature, and +4 volts. The first set establishes warning thresholds, the second establishes shutdown thresholds. The last set, which is the one used by the Hardware Monitor since its the one that's uncommented, effectively disables environmental checking since the low/high value pairs are set to maximum low and maximum high.

For hardware that does not report environmental conditions there is a dummy entry in the /spdata/sys1/spmon/hmthresholds file. Recall that at least three white-space separated tokens are required for each SP hardware type supported by the Hardware Monitor.

For example, examine the following excerpt from the /spdata/sys1/spmon/hmthresholds file for an SP Switch and Twin-Tail Frame hardware in basecode, or non-active, mode: 

#
# #### SP Switch - base code only; no supervisor:
#     DUMMY (cardtype has no A/D registers)
#     low  high
# Software thresholding disabled
0x80 0x00 0xff
#
# #### twin-tail frame - base code only; no supervisor:
#      DUMMY (cardtype has no A/D registers)
#      low  high
# Software thresholding disabled
0x10 0x00 0xff

Enabling Software Thresholding

Software thresholding can be enabled in one of following ways:

Environmental Condition Notification

Environmental condition checking and notification comes in two flavors, Hardware Out-Of-Spec Notification and Software Out-Of-Range Notification.

Implementation Specifics

This file is part of the PSSP ssp.basic fileset.

Location

/spdata/sys1/spmon/hmthresholds

Related Information

Commands: hmmon

Subsystems: Hardware Monitor (hardmon), Logging Daemon (splogd)

Examples

The following is an example of the software out-of-range environmental states for an SP2 wide node w/4.0 volt power. 

$ hmmon -G -Q -s 1:1
 
  1  1   voltP5mRange         FALSE    0x9092  +5 mem volts out of range
  1  1   voltP12Range         FALSE    0x908e  +12 voltage out of range
  1  1   voltN12Range         FALSE    0x9091  -12 voltage out of range
  1  1   voltP5iRange         FALSE    0x9090  +5 I/O volts out of range
  1  1   tempRange            FALSE    0x9084  temperature out of range
  1  1   voltP4Range          FALSE    0x9093  +4 voltage out of range

host file

Purpose

host - Contains all hostnames of the nodes within the SP.

Description

This file is used by file collection servers to restrict only the clients whose hostnames are listed in this host file. This file is used by non-DCE file collection servers. It is also used by DCE enabled control workstation file collection servers when the client is a non-DCE SP node. The lines starting from # characters are ignored and used to enter comments. The special comments 

delimiter #END_SP_NODES

is used by some scripts to update this file. This delimeter separates the non-SP node entries from SP node entries. The format of the file is: 

spnode_hostname1
spnode_hostname2
# This is a comment line...
#END_SP_NODES
non_spnode_host1
non_spnode_host2

Files

All /var/sysman/sup/*/host files:

Location

/var/sysman/sup/*/host

Related Information

Commands: supfilesrv, supper

Examples

An example host file: 

# This file is generated by filec_host script on Jan 7, 1998.
# This contains the hostnames of all the nodes in the SP.
spnode1
spnode2
#END_SP_NODES
workstation1
workstation2

hwevents file

Purpose

hwevents - Contains state change actions that are to be performed by the logging daemon (splogd). The Hardware Monitor (hardmon) detects these state changes, and notifies the logging daemon. The Logging Daemon (splogd) can perform three different operations, based on information in hwevents. It can 1) write state changes to the ERRPT, 2) write state changes to a log file, 3) run user exits when specified state changes occur.

Description

The /spdata/sys1/spmon/hwevents file contains lines that specify one of the three operations described in the Purpose section. Each line in the file, excluding comment lines, which begin with a # (pound sign) in column one, consists of at least seven white-space separated tokens in the following format:

 
frame slot variable operator value time function [argument[...]]

Following is a description of these tokens:

frame
Specifies a frame number (1-n) or * for all frames.

slot
Specifies the following:

variable
Specifies a hardware variable, as returned from the Hardware Monitor (for example, nodePower, temp, LED7SegA). For a list of all variables, issue the command hmmon -V.

operator
Specifies how to compare the value. Acceptable values are: =, <, >, and !=.

value
Specifies the value of the variable to match with the operator wildcard (*), or a partial match with the wildcard at the end (23*).

time
Specifies if the function should be called at startup, when the state changes, or at both times. Valid options are startup, change, or both.

function
Specifies the program to call when an event occurs. Any 'argument' tokens will be passed as arguments to the program.

There are two special keywords for function. If function is SP_ERROR_LOG, error logging is performed provided that syslog is set up and AIX error logging is set up to perform SP logging. Refer to the setup_logd command for details.

If function is SP_STATE_LOG, these state changes that meet the statement's criteria are logged to /var/adm/SPlogs/spmon/splogd.state_changes.timestamp.

Files

/spdata/sys1/spmon/hwevents

/var/adm/SPlogs/spmon/splogd.state_changes.timestamp

Related Information

PSSP commands: hmmon

Subsystems: Logging Daemon (splogd), Hardware Monitor (hardmon)

Examples

The following is an example of an hwevents file: 

# frame slot   variable        operator value time  function
   *     *      *                 =      *     b   SP_ERROR_LOG
   *     *      type              =      *     b   /usr/lpp/ssp/install/bin/SDR_config -l
   *     *      hostHWFrameID    !=      0     c   /usr/lpp/ssp/install/bin/SDR_config -l
   *     *      hostHWSlotID     !=      0     c   /usr/lpp/ssp/install/bin/SDR_config -l
   *     *      mux               =      *     c   /usr/lpp/ssp/bin/Eclock.state_change -s
   *     *      portClkMissing    =      1     c   /usr/lpp/ssp/bin/Eclock.state_change -s
   *     *      chipClkMissing    =      1     c   /usr/lpp/ssp/bin/Eclock.state_change -s
   *     17     nodePower         =      *     c   /usr/lpp/ssp/bin/Eclock.state_change -p
   * NODES_ONLY PowerOnRequest    =      1     b   /usr/lpp/ssp/install/bin/spexpon
#
#
# Uncomment the SP_STATE_LOG line to turn state change logging on.
# If you run with state change logging on, be sure you have a large enough /var.
# The state change logs will be closed each night on the control workstation
# if they exist and any that are older than a week will be removed by
# cleanup.logs.ws.
#
#  *      *     *            =       *     c    SP_STATE_LOG

.klogin file

Purpose

.klogin - Specifies remote principals that can use a local user account.

Description

The $HOME/.klogin file defines which users and services on any remote hosts (computers in a network) within an authentication realm are allowed to invoke commands on the local user account.

The format of the $HOME/.klogin file is: 

principal.instance@realm

A typical .klogin file, if present, looks similar to the following: 

harry@KGN.IBM.COM
beverly.root@KGN.IBM.COM
root.admin@KGN.IBM.COM
user.wkst3@KGN.IBM.COM
user1@KGN.IBM.COM
rcmd.wkst3@KGN.IBM.COM

The principal name is the name of the remote user using SP authentication to execute remote commands on a local user account.

The instance is used to distinguish among variations on the principal name and may be used to indicate special privileges such as root authorization. In many environments, the instance is used with a service to indicate the workstation the service is running on. The service entries are usually found only in the root directory .klogin file.

The realm is the authentication realm. This may be different if there are several authentication realms, each with a different realm name, in your environment.

If the originating remote user is authenticated to one of the principals named in the .klogin file, access is granted to the account. The owner of the account is granted access if there is no .klogin file. If a .klogin file is present, the owner must also be listed to gain access to his or her account from a remote host.

For security reasons, any $HOME/.klogin file must be owned by either the local user or root, and only the owner should have read and write access.

Files

$HOME/.klogin
Specifies remote users that can use a local user account.

Prerequisite Information

Related Information

Commands: k4init

Examples

The following examples assume both Jeff and Anna have principal names in the authentication database (anna@KGN.IBM.COM, jeff@KGN.IBM.COM) and have issued a k4init to be authenticated on their local host. In addition, there is one authentication realm signified by KGN.IBM.COM.

  1. To allow only user Anna on host wkst3 to rsh into her own account on host wkst7, a .klogin file is not required.
  2. To allow user Jeff on host wkst3 to rsh into Anna's account on host wkst7, the .klogin file in Anna's account on wkst7 must have the following entries: 
    anna@KGN.IBM.COM
jeff@KGN.IBM.COM

    Anna's entry must be present in the .klogin file since the .klogin file exists. Jeff can now use the -l flag on the rsh or rcp to access Anna's account.

Kerberos

Purpose

Kerberos - Contains an introduction to SP authentication services.

Description

Kerberos authenticates individual users in a network environment. After authenticating your identity, you can use facilities such as Sysctl, the SP System Monitor, and the authenticated versions of network utilities rsh and rcp, without having to present passwords to remote hosts and without having to use .rhosts files.

Before you can use the SP authenticated commands, you must make sure that you are added to the authentication database. You can use the k4init command to find out. This command tries to authenticate your identity in the system. The k4init command prompts you for a principal name and password. Enter your principal name and password. If the command accepts your authentication information without sending you a message, you are already registered. If you enter your user name and k4init responds with the following message: 

Kerberos principal unknown

contact your system administrator.

A principal identifier contains three parts. The first is the user or service name. The second is the instance, which in the case of a user is usually null. Some users can have privileged instances, however, such as root or admin. In the case of a service, the instance is the name of the machine on which it runs (for example, there can be a rcmd ( sysctld daemon) service running on the machine abc, which is different from the kshd service running on the machine xyz). The third part of the name is the realm. The realm corresponds to the service providing authentication for the principal. For example, computing resources within an enterprise can be partitioned into multiple administrative units for convenience or other business reasons.

When writing a principal identifier, the user or service name is separated from the instance (if not null) by a period, and the realm (if not the local realm) follows, preceded by an at sign (@).

When you authenticate your identity using the k4init command, you are given an initial ticket (which is an encrypted protocol message that provides authentication). This ticket is used to request other tickets from the authentication service for SP authenticated services such as SP sysctl. The ticket transactions are done transparently, so you do not have to worry about their management.

Be aware that tickets expire. Some tickets, such as admin instance tickets, may expire in a few minutes, while other tickets may be good for hours, days, or weeks depending on the installation's policy. If your login session extends beyond the time limit, you have to reauthenticate your identity using the k4init command to get new tickets.

For more information about the k4init and k4destroy commands, see the k4init and k4destroy command.

Related Information

Commands: kadmin, k4destroy, k4init, k4list, kpasswd

krb.conf file

Purpose

krb.conf - Contains the SP authentication configuration file.

Description

The krb.conf file contains configuration information describing the local authentication realm and the location of authentication servers for known realms.

The first line of the krb.conf file contains the name of the local authentication realm. Each additional line specifies the location (hostname) of a Kerberos V4 authentication server for a realm. The krb.conf file must contain at least one entry for each realm used by the local system. The krb.conf file must contain at least one entry for each realm that is accessible from the local system. Each line specifying the location of an authentication server must be of the form: 

REALM_NAME host_name

or 

REALM_NAME host_name admin server

An entry containing "admin server" identifies the primary Kerberos V4 authentication server for a realm. Only one system can be the primary server for a realm. Any number of systems can be secondary servers. For example, the following is a krb.conf file describing a realm named XYZ.ORG, with a primary server named host2, and a secondary server on host1: 

XYZ.ORG
XYZ.ORG  host1.xyz.org
XYZ.ORG  host2.xyz.org admin server

The file may contain multiple entries for a system, each containing a different network interface name for the server system. This is useful in improving availability in case a particular interface is down or in case not all systems in the realm can access the server on the same network. The example shown above might have the additional entries: 

XYZ.ORG  host1a.xyz.org
XYZ.ORG  host2a.abc.xyz.org admin server
XYZ.ORG  host2b.xyz.org admin server

Note that all entries for any given system must include "admin server" or not, since a system cannot be the primary Kerberos V4 server and a secondary server at the same time.

All lines after the first can be in any order. When there are multiple server entries for a realm, Kerberos V4 authentication requests are directed to each listed interface in the order listed. When a connection request times out, the next entry for the realm is used.

The setup_authent command uses the krb.conf file to decide how to configure an RS/6000 workstation for Kerberos V4 authentication. You may or may not have to create this file, depending on the Kerberos V4 configuration choices you have made about the types and location of servers:

Location

/etc/krb.conf

Related Information

Files: krb.realms

Refer to the chapter on security in PSSP: Administration Guide for additional Kerberos information.

Examples

The following example of an /etc/krb.conf shows a simple configuration consisting a single realm with two servers, the primary and one secondary: 

EAST.COAST
EAST.COAST master.authent.abc.com admin server
EAST.COAST backup.authent.abc.com

Here, "admin server" identifies the system whose full host name is "master.authent.abc.com" as the primary server, responsible for administration of the master database. Note that, in this case, there would have to be information in the /etc/krb.realms file to map the two host names or the domain name authent.abc.com to the local realm name, "EAST.COAST". See the Example section of the krb.realms file.

krb.realms file

Purpose

krb.realms - Specifies the translations from host names to authentication realms.

Description

The krb.realms file provides a translation from a host name or a network domain name to the authentication realm name for the services provided by that host. Each line of the translation file is in one of the following forms (domain names should begin with a period (.)): 

host_name    realm_name
domain_name  realm_name

If a host name exactly matches the host_name field in a line of the first form, the corresponding realm is the realm of the host. If a host name does not match any host_name in the file but its domain exactly matches a domain name, the corresponding realm is the realm of the host.

If no translation entry applies, the host's realm is considered to be the host name's domain portion converted to uppercase. If the host name does not contain a domain name, the host's realm is considered to be the host name converted to uppercase.

Location

/etc/krb.realms

Related Information

Files: krb.conf

Refer to the chapter on security in PSSP: Administration Guide for additional Kerberos information.

Examples

The following example of an /etc/krb.realms shows the entries that could be used to map a host name or a domain name to a realm. These names correspond to those used in the krb.conf file example. 

master.authent.abc.com EAST.COAST


.authent.abc.com EAST.COAST

The first line maps a specific host name to the realm "EAST.COAST". If the host name were "master.east.coast", no entry would have been required. The second entry maps all host names whose domain portion is "authent.abc.com" to the same domain. The default mapping for this realm is: 

.east.coast EAST.COAST

This type of mapping is always assumed, even if the /etc/krb.realms file is empty.

|plane.info file

|Purpose

|plane.info - Overrides SDR_config's |default switch plane assignments for the switches. | |

|Description
Attention

The switch plane numbering scheme you provide in this file must match the physical switch-to-switch wiring of the switches in the system.

|The plane.info input file overrides |SDR_config's default switch plane assignments for the |switches. |This file can be used only on SP Switch2 systems. This file consists of one line for each node with the following |format: 

|frame_number:slot_number plane_number sequence_number

|The sequence number is the switch number within the plane. For |example, the first switch in each plane has a sequence number of 1, the second |switch in each plane has a sequence number of 2, and so on.

|When SDR_config is run, it creates a version of the |plane.info file in /var/adm/SPlogs/sdr that contains |the configuration SDR_config used for the system. To override |this configuration, copy the /var/adm/SPlogs/sdr/plane.info |file to /etc/plane.info, edit it to reflect the configuration |you want, and rerun SDR_config.

|Location

|/etc/plane.info

|Examples

|A plane.info file on a two plane system with four switch |frames may look similar to the following: 

|1:17 0 1
|2:17 1 1
|3:17 0 2
|4:17 1 2

P3_PCI.addrs file

Purpose

P3_PCI.addrs - Contains the mapping of the Power3 SMP High Node ports to PCI adapter addresses. It is used to determine the physical SP Expansion I/O unit that an adapter resides in.

Description

To determine the physical SP Expansion I/O unit an adapter resides in, perform the following steps:

  1. Find the entry in the following table for the adapter address in question (you may have obtained this through the AIX lscfg command, an error report, or some other means).
  2. Note the corresponding PCI slot number (this is a PCI slot in an SP Expansion I/O unit).
  3. Note the corresponding node port value. This is the port on the Power3 SMP High Node that the SP Expansion I/O Unit is connected to.
  4. Run the command: 
    splstdata -x -l <node_number>
  5. Search the "node_port" column for the node port value obtained in step 3. Use this entry to determine the SP Expansion I/O Unit that contains the adapter in question. 
      node_port  PCI_1  PCI_2  PCI_3  PCI_4  PCI_5  PCI_6  PCI_7  PCI_8
  ---------  -----  -----  -----  -----  -----  -----  -----  -----
   Q1        E0-58  E0-60  D0-58  D0-60  G0-58  G0-60  F0-58  F0-60
   Q2        A0-58  A0-60  90-58  90-60  C0-58  C0-60  B0-58  B0-60
   Q3        W0-58  W0-60  V0-58  V0-60  Y0-58  Y0-60  X0-58  X0-60
   Q4        S0-58  S0-60  R0-58  R0-60  U0-58  U0-60  T0-58  T0-60
   Q5        N0-58  N0-60  M0-58  M0-60  Q0-58  Q0-60  P0-58  P0-60
   Q6        J0-58  J0-60  H0-58  H0-60  L0-58  L0-60  K0-58  K0-60
   Q7        60-58  60-60  50-58  50-60  80-58  80-60  70-58  70-60

Location

/usr/lpp/ssp/config/hardware/P3_PCI.addrs

Examples

See the Description section.

SDR_dest_info file

Purpose

SDR_dest_info - Provides connection addresses for System Data Repository (SDR) clients.

Description

The SDR_dest_info file provides connection addresses for System Data Repository (SDR) clients. It contains the following fields:

primary
Specifies the IP address of the system partition to which the node belongs. On the control workstation, this is the IP address of the default system partition.

default
Specifies the IP address of the default system partition.

nameofprimary
Specifies the host name of the system partition to which the node belongs.

nameofdefault
Specifies the host name of the default system partition.

Related Information

Refer to the PSSP: Administration Guide for additional information on the SDR_dest_info file.

Examples

This example shows the contents of an SDR_dest_info file for a node. The node is a member of system partition 129.40.127.46. The default system partition on this system is 129.40.127.47. The host name of the node's system partition is k99sp1. The host name of the default system partition is k99s. 

default:129.40.127.47
primary:129.40.127.46
nameofprimary:k99sp1
nameofdefault:k99s

spsec_overrides file

Purpose

spsec_overrides - Specifies the format for the SP Security Services customization file.

Description

The spsec_overrides file is used by a system administrator to override the default names and attributes of DCE entities created when SP trusted services are configured to use DCE authentication. The default names and attributes are defined in the /usr/lpp/ssp/config/spsec_defaults file. Refer to this defaults file when customizing your spsec_overrides file.

The overrides must be defined and applied to the file on the control workstation prior to the configuration of DCE for SP trusted services using the config_spsec command or its SMIT interface. The same file is automatically propagated to each node when DCE is configured on it. For independent workstations, you must insure that the same overrides file is copied to each |node prior to running config_spsec there.

Possible reasons for changing one or more names could be:

Each entry consists of one line of ASCII text. Fields are separated by colons. An entry containing a pound sign (#) as the first character is considered a comment with all characters between the pound sign and the new-line character part of the comment. All comment entries and empty lines are ignored.

Entries have the general format: entry-type:default-name:override-information.

SVC-GRP entry: to override the name of the DCE group to which the principals used by SP trusted services belong, add a line with the following format: SVC-GRP:spsec-services:override-name where override-name a DCE group name to be used in place of "spsec-services."

SVC-ORG entry: to override the name of the DCE organization to which the principals used by SP trusted services belong, add a line with the following format: SVC-ORG:spsec-services:override-name where: override-name a DCE organization name to be used in place of "spsec-services."

ADM-GRP entry: to override the name of the DCE group which will have "control" access to all ACLs created by SP trusted services, add a line with the following format: ADM-GRP:spsec-admin: override-name where: override-name a DCE group name to be used in place of "spsec-admin."

SERVICE entry: to override the default name of a trusted service (used as the constant part of its service principal name) and/or the user and group that owns the keytab file, add a line with the following format: SERVICE:default-name:[override-name][:new-owner:new-group] where:

default-name
Specifies the name assigned to the service in its entry in the security services defaults file /usr/lpp/ssp/config/spsec_defaults. This name has the form product/service, for example, ppe/dpcl.

override-name
Specifies a service name to be used in place of the service portion of the default-name. (The leading product portion of the name may not be overridden.)

new-owner
Specifies the AIX user under whose UID the service runs and the owner of the keytab file used by the service.

new-group
Specifies the primary AIX group for new-owner.

ACC-GRP entry: to override the name of the DCE group which will have access to some resources managed by an SP trusted service, add a line with the following format: ACC-GRP:default-name:[override-name][ :p] where:

default-name
Specifies the name assigned to the group in its default entry in the security services defaults file /usr/lpp/ssp/config/spsec_defaults.

override-name
Specifies a DCE group name to be used in place of default-name.

:p
This is an optional attribute that the system administrator can specify to configure separate access groups for each System Partition (for groups used by partitioned services (those with the "p" attribute in the defaults file). Use this to allow different groups of users to access a service in each partition. Omit it to allow a single group to have access to a service in all partitions. If you specify :p, each partition's access group will be named group-name.syspar_name, where group-name is the override-name, if any, else the default-name, and syspar is the name of the system partition.

Location

/spdata/sys1/spsec/spsec_overrides

Related Information

Commands: sptgtprin, spgrpname

Examples

  1. When you have no overrides to apply, the spsec_overrides file contains no entries (but may contain comments and empty lines). All security configuration information is obtained from the file /usr/lpp/ssp/config/spsec_defaults.
  2. To override the service name used by POE, the administrative group name and use separate groups for access to event management services in each system partition, you could create a spsec_overrides file containing: 
    # Local overrides for security services information
# Rename a service from ppe/pmdv2 to ppe/psched
SERVICE:ppe/pmdv2:psched
# Rename group 'haem-users' to 'operators' and partition it
ACC-GRP:haem-users:operators:p
# Rename the control group for ACLs
ADM-GRP:spsec-admin:system-admin

|switch.info file

|Purpose

|switch.info - Overrides SDR_config's |default switch node number assignments for the nodes. | |

|Description
Attention

If your system contains an SP Switch, the switch node numbering scheme you provide in this file must match the physical wiring of the nodes to the switch ports.

|The switch.info file is an input file that overrides |SDR_config's default switch node number assignments for the |nodes. It cannot be used in SP Switch2 systems.

|For SP-attached servers and for clustered enterprise servers with the SP |Switch, entries are automatically placed in this file by the spframe |command when the command is run with the -n flag.

|For IBM e(logo)server pSeries 690 servers that are running in SMP mode or |which only have one logical partition (LPAR) defined, the spframe |command with the -n flag can be used to specify the node's |switch node number. For p690 servers that have more than one LPAR |defined, you must manually edit the switch.info file to |include switch node numbers for all LPARs in that server before running the |spframe command. In this case, do not specify the |-n flag when running the spframe command. Each |LPAR corresponds to one node in the frame and the node slot number is |equivalent to the "Partition ID" that has been assigned to the LPAR by the |Hardware Management Console (HMC). The "Partition ID" can be viewed |from the "Properties" menu for that LPAR from the HMC GUI.

|This file consists of one line for each node with the following |format: 

|node_number|frame_number,slot_number
|switch_node_number
|Note:
The switch.info file can also be used to override switch node |numbering assignments in switchless systems. |

|Location

|/etc/switch.info

|Examples

|To define switch node numbers for nodes 16, 20, 24, and 28 in one of two |ways: 

|16 0
|20 1
|24 2
|28 3

|or 

|2,1 0
|2,5 1
|2,9 2
|2,13 3

sysctl_acl file

Purpose

sysctl_acl - Contains the format for the ACL files used by Sysctl.

Description

The sysctl_acl file is used to specify the authority that various individual clients or types of clients are to be granted with respect to accessing objects associated with it. These objects represent resources controlled by Sysctl when DCE is not being used.

The ACLs used by Sysctl have a format that is upwardly compatible with those used by the Sysctl service in prior PSSP releases. They are ASCII text files and may be edited directly by the root user or managed using the Sysctl built-in commands provided for that purpose.

An ACL consists of a set of one or more ACL entries. ACL entries are separated by the new-line character. Each ACL file is identified by a first line containing #acl#.

ACL Entries

Each entry is a single line of ASCII text composed of three fields in the following format: entry_type [name] [-] where:

entry_type
Determines the type of subject referred to by name.

name
Specifies the name of the subject to which access is to be granted or denied.

-
Indicates that permission is denied to the subject.

ACL entry fields are separated by white space characters. White space characters are allowed within an ACL entry:

White space characters are not allowed within a subject's name.

An ACL entry containing a pound sign (#) as the first character of the entry is considered a comment, with all characters between the pound sign and the new-line character part of the comment. All comment entries will be ignored during the access check algorithm and will not affect the access granted (or denied) by the ACL. (This includes the #acl# line that was required to be the first line in the file in prior releases; it is no longer required.)

ACL Entry Types

The ACL entry_type specifies the type of client to which the entry applies or indicates another ACL file. The following ACL entry types are supported:

_principal
The entry specifies that access is to be granted or denied to the Kerberos V4 principal or AIX user specified by the name field.

_acl_file
The name field specifies the path for a file which contains additional ACL entries.

_any_other
The entry specifies that access is to be granted to all users whose identity can be authenticated but whose principal name does not match the name field of any _principal entry in the file.

_other_unauth
The entry specifies that access is to be granted to all users whose identity cannot be authenticated and whose identity does not match any other entry in the ACL and to users for whom no identity is provided. If a client is explicitly denied access, the ACL is not checked for this entry.

ACL entry_type keywords are not case sensitive, and can be lowercase characters, uppercase characters, or mixed upper and lowercase characters. Unique abbreviations containing a minimum of two characters may be used.

Note:
When ACL entries are created on hosts running PSSP Version 3.2 or later using the Sysctl ACL management commands, the entry type fields will be lowercase. (Earlier versions used only uppercase.)

ACL Entry Name

The ACL entry name field is required for entries of type _principal and _acl_file. A name may not be specified for entries of type _any_other and _other_unauth.

For ACL entries of type _principal, the name field should contain a Kerberos V4 principal name, when the Sysctl server host uses Kerberos V4 authentication. The name may be specified in any of the following forms:

If you want to authorize unauthenticated users, the name field should contain an AIX user name, which may be specified in either of the following forms:

Note that unauthenticated AIX names are checked for authorization only if the client has no authenticated identity. If an authenticated client is denied access, the ACL is not checked for an entry containing the client's AIX user name.

The access rights granted to a client by the ACL file are determined by the following algorithm:

For ACL entries of type _acl_file, the name field should contain a fully qualified pathname.

Denial of permission

The character '-' may be specified as a third field of _principal entry to indicate that access is to be denied to a user.

Access Checking

The ordering of types of entries within an ACL is not relevant in the granting or denying of access based on an ACL.

Only one entry for any subject is recognized by the access checking algorithm; the first one encountered when reading the file. Others will be ignored without notification. If you create or update your ACL files using an editor, you should avoid entering multiple entries for the same subject. When you use the Sysctl ACL management procedures, you will be prevented from doing so.

Prior to processing other entry types, all _acl_file entries are resolved. All ACL entries contained in files referenced by _acl_file entries are merged with the initial set of entries to produce a single set of ACL entries. If any ACL file cannot be read or if an _acl_file entry names an already processed ACL file (a circular chain is detected), access is denied because access control policy may be compromised by using an incomplete set of ACL entries. When such an error occurs, the fact is logged in the sysctld daemon log file. You should inspect the log file if users experience unexplained denial of access.

The access rights granted to a client by the ACL file are determined by the following algorithm: if the Kerberos V4 principal name from the user's authenticated credentials matches the principal name contained in a _principal entry, then:

Related Information

Daemons: sysctld

Examples

  1. This example shows the various entry types as they might appear. A useful ACL would not contain all entry types: 
    #acl#
#Sample SP ACL file
_principal herbie
_principal suzanne -
_any_other
_other_unauth
_acl_file /u/jan/my_acl
  2. This example shows ACL entries that grant access to a number of Kerberos V4 principals. These principals might be a group of people with similar administrative roles in the organization. Since Kerberos V4 does not have any concept of a group, each principal must be listed individually: 

    #acl#
# ACL for xyz Sysctl procedure
_p frank
_p lucinda
_p paula
_p gerry.admin
  3. This example shows ACL entries that grant access to two unauthenticated AIX users: 
    #acl#
_principal operator@sp3cws.abc.org
_principal operator@node5.sp3.abc.org

sysctl.conf file

Purpose

sysctl.conf - Configures the Sysctl server (sysctld) running on the local SP node.

Description

The sysctl.conf file configures the local Sysctl server daemon by optionally creating variables, procedures and classes, setting variables, loading shared libraries, and executing Sysctl commands. These items are used by the server in the processing of requests from local and remote Sysctl clients.

The default location of this file is /etc/sysctl.conf. An alternate configuration file location can be specified by using the -f flag when starting the server (see the sysctld command).

The /etc/sysctl.conf file contains Sysctl commands which are read and executed by the Sysctl server during its initialization. The following commands are supported:

create var var_name var_value [auth_callback]
The create var statement creates a variable, assigns it a value, and assigns it an authorization callback. This variable can then be referenced from within other Sysctl procedures and commands. If the auth_callback parameter is not supplied, a value of NONE is assumed. For example: 
create var buildTop /usr/lpp/ssp AUTH

creates the variable buildTop, assigns it a value of /usr/lpp/ssp, and assigns it an authorization callback of AUTH. The variable buildTop can be referenced within Sysctl commands and procedures.

Another example: 

create var STARTTIME [exec /bin/date] NONE

creates the variable STARTTIME, assigns it the value returned from the execution of the /bin/date command at server initialization, and assigns it an authorization callback of NONE. This variable contains the date and time at which the server was started on the node.

create proc proc_name { parameters} auth_callback {procedure}
The create proc statement creates a new procedure in the Sysctl server. This new procedure can be invoked from a client by supplying its name along with any defined parameters. For example: 
create proc mydate {} AUTH {exec /bin/date}

creates the procedure mydate which has no parameters. This procedure has an authorization callback of AUTH. The procedure is comprised of a single statement (exec /bin/date).

create class class_name class_file_name [auth_callback]
The create class statement creates a class of commands in the Sysctl server. An optional authorization callback can be supplied. The authorization callback assigned to each object in the class is the logical OR of the class' callback (if supplied) and the object's callback. Thus, access to a class' object is granted if either the object's or the class' authorization callback allows access. For example: 
create class sys $buildTop/samples/sysctl/sys.cmds

creates the class sys. If $buildTop is defined as /usr/lpp/ssp, the file /usr/lpp/ssp/samples/sysctl/sys.cmds contains the definition of the sys class.

include
The include statement includes the contents of another file in the configuration file. This provides a way of organizing the Server configuration statements into manageable groupings. For example: 
include $buildTop/samples/sysctl/pdfpfck.cmds

causes the Sysctl server to read the contents of the specified file at initialization time.

set
The set statement sets the value of the server variables ACL, LOG, or KEY, or sets values in the env() array. The default values for the Sysctl server's ACL file, log file, and service key file can be overridden by assigning values to the ACL, LOG, and KEY variables in the configuration file. For example, the following line overrides the default value for the log file name: 
set LOG /var/sysctld.log_file

The values assigned to the ACL, LOG, and KEY variables are overridden by the optional command line arguments -a, -l, and -k.

Environment variables (such as the default PATH) can also be set within the configuration file by assigning values to the env() array. For example: 

set env(PATH) /usr/bin:/bin:/usr/etc:/etc

sets the PATH for the Sysctl server. The env() array is assigned an authorization callback of SYSTEM which prevents its modification from outside the Sysctl server by a request sent by a Sysctl client.

load lib_path [init_proc]
The load command dynamically loads the shared library at lib_path into memory. If the init_proc parameter is given, it is used as the library's initialization procedure. Otherwise, the name of the initialization function is derived from the library name as follows: 
library name    init function
 
------------    -------------
 
libxxx.sl       xxx_Init()
 
libxxx.a        xxx_Init()

The Sysctl server exports an API which the library uses to define commands, variables, authorization callbacks, and interpreter deletion callbacks. See the load() help page for details.

Other Sysctl Commands
The configuration file can also contain other Sysctl commands to modify the behavior of the server. For example, the following command in the configuration file causes the authorization callback for the svcconnect command to be changed from the default value of AUTH to NONE. This would allow nonauthenticated clients to connect to the server. 
setauth -cmd svcconnect NONE

Prerequisite Information

See the description of Sysctl in PSSP: Administration Guide.

Related Information

Commands: sysctl

Daemons: sysctld

tuning.commercial file

Purpose

tuning.commercial - Contains initial performance tuning parameters for a typical commercial SP environment.

Description

This file is a Korn shell script file containing commands to set network performance tuning parameters. It can be copied to the /tftpboot/tuning.cust file on the control workstation for propagation to the nodes.

Related Information

PSSP commands: cptuning

AIX commands: This file contains invocations of the no command.

PSSP Files: tuning.default, tuning.development, tuning.scientific

PSSP: Installation and Migration Guide

tuning.default file

Purpose

tuning.default - Contains initial (default) performance tuning parameters for an SP environment.

Description

This file is a Korn shell script file containing commands to set network performance tuning parameters. In the absence of explicit administrator action, this file is copied to the /tftpboot/tuning.cust file on the control workstation for propagation to the nodes.

Related Information

PSSP commands: cptuning

AIX commands: This file contains invocations of the no command.

PSSP files: tuning.commercial, tuning.development, tuning.scientific

PSSP: Installation and Migration Guide

tuning.development file

Purpose

tuning.development - Contains initial performance tuning parameters for a typical software development/interactive SP environment.

Description

This file is a Korn shell script file containing commands to set network performance tuning parameters. It can be copied to the /tftpboot/tuning.cust file on the control workstation for propagation to the nodes.

Related Information

PSSP commands: cptuning

AIX commands: This file contains invocations of the no command.

PSSP files: tuning.commercial, tuning.default, tuning.scientific

PSSP: Installation and Migration Guide

tuning.scientific file

Purpose

tuning.scientific - Contains initial performance tuning parameters for a typical engineering or scientific SP environment.

Description

This file is a Korn shell script file containing commands to set network performance tuning parameters. It can be copied to the /tftpboot/tuning.cust file on the control workstation for propagation to the nodes.

Related Information

PSSP commands: cptuning

AIX commands: This file contains invocations of the no command.

PSSP files: tuning.commercial, tuning.default, tuning.development

PSSP: Installation and Migration Guide

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]