Installation and Migration Guide

Task B. Install PSSP on the control workstation

This section describes the steps you take to install PSSP on the control workstation. After you prepare the control workstation, you are ready to install the PSSP software.

Step 16: Copy the PSSP images

The RS/6000 SP package is comprised of these install images and file sets:

Image

Description

pssp.installp

Contains the PSSP install file sets |

|rsct.basic

|Contains the RS/6000 Cluster Technology Availability Subsystems (for use |with AIX 4.3.3) |

|rsct.clients

|Contains the RS/6000 Cluster Technology Availability Subsystems (for use |with AIX 4.3.3) |

|rsct.core

|Contains the RS/6000 Cluster Technology Availability Subsystems (for use |with AIX 4.3.3)

ssp.resctr

Contains the SP Resource Center

ssp.vsdgui

Contains the IBM Virtual Shared Disk Perspective

vsd.cmi

Contains the IBM Virtual Shared Disk Centralized Management Interface

vsd.hsd

Contains the IBM Virtual Shared Disk Hashed Shared Disk

vsd.rvsd.hc

Contains the IBM Recoverable Virtual Shared Disk Connection Manager

vsd.rvsd.rvsdd

Contains the IBM Recoverable Virtual Shared Disk Connection Daemon

vsd.rvsd.scripts

Contains the IBM Recoverable Virtual Shared Disk Recovery Scripts

vsd.sysctl

Contains the IBM Virtual Shared Disk sysctl commands

vsd.vsdd

Contains the IBM Virtual Shared Disk device driver

|The RS/6000 SP package also contains several PSSP prerequisites |files. They are:

|ipfx

|IBM Information Presentation Facility/6000

|vacpp.cmp

|Contains the VisualAge C++ Compiler

|vacpp.ioc

|Contains the VisualAge C++ IBM Open Class library runtime file set

|xlC.aix43

|Contains the VisualAge C++ Runtime file sets specific to AIX 4.3

|xlC.aix50

|Contains the VisualAge C++ Runtime file sets specific to AIX 5L 5.1

|xlC.rte

|Contains the VisualAge C++ Runtime file sets

Before you install the PSSP images on the control workstation, you first need to copy the images from the installation media to |/spdata/sys1/install/pssplpp/PSSP-3.4 directory on your hard disk.

Step 16.1: Copy PSSP images from media

Login to the control workstation as root and run bffcreate using SMIT or the command line.

If using:	Do this:
SMIT	TYPE smit bffcreate The Copy Software to Hard Disk for Future Installation window appears. PRESS List (F4) to show the available devices. Select the device containing the product installation media. PRESS Ok to display the target parameters. The Copy Software to Hard Disk for Future Installation window appears. TYPE /spdata/sys1/install/pssplpp/PSSP-3.4 in the DIRECTORY for storing software field. PRESS Ok to begin the install process.
bffcreate	This example shows the product media on cd0. Enter: bffcreate -d /dev/cd0 -t /spdata/sys1/install/pssplpp/PSSP-3.4 -X all
The following warning message is issued--ignore it: bffcreate: Warning: important size information is missing from the table of contents file. Consequently, there may not be enough free file system space to successfully create the bff image(s). Continuing anyway...

Step 16.2: Update the image table of contents (.toc)

|When bffcreate completes, rename |ssp.3.4.0.0.I, |rsct.clients.1.2.1.0.I, |rsct.basic.1.2.1.0.I, |rsct.core.1.2.1.0.I, in |/spdata/sys1/install/pssplpp/PSSP-3.4.

Enter the following:

|cd /spdata/sys1/install/pssplpp/PSSP-3.4
|mv ssp.3.4.0.0.I pssp.installp
|mv rsct.basic.1.2.1.0.I rsct.basic
|mv rsct.clients.1.2.1.0.I rsct.clients
|mv rsct.core.1.2.1.0.I rsct.core
|inutoc .

|Step 16.3: Move prerequisite files

|Several PSSP prerequisite files that are shipped on the PSSP media must be |moved to your AIX lppsource.

|Enter the following:

|cd /spdata/sys1/install/pssplpp/PSSP-3.4

|If your lppsource is for AIX 4.3.3, the |following prerequisite files must be copied:

|cp xlC.rte.* /spdata/sys1/install/name/lppsource
|cp xlC.aix43.* /spdata/sys1/install/name/lppsource
|cp ipfx.* /spdata/sys1/install/name/lppsource
|cp vacpp.ioc.* /spdata/sys1/install/name/lppsource
|cp vacpp.cmp.* /spdata/sys1/install/name/lppsource
|cd /spdata/sys1/install/name/lppsource
|inutoc .

|If your lppsource is for AIX 5L 5.1, the following |prerequisite files must be copied:

|cp xlC.rte.* /spdata/sys1/install/name/lppsource/installp/ppc
|cp xlC.aix5.* /spdata/sys1/install/name/lppsource/installp/ppc
|cp ipfx.* /spdata/sys1/install/name/lppsource/installp/ppc
|cp vacpp.ioc.* /spdata/sys1/install/name/lppsource/installp/ppc
|cp vacpp.cmp.* /spdata/sys1/install/name/lppsource/installp/ppc
|cd /spdata/sys1/install/name/lppsource/installp/ppc
|inutoc .

|Remove the prerequisite files from the PSSP lppsource directory |since they have been moved to the AIX lppsource directories.

|cd /spdata/sys1/install/pssplpp/PSSP-3.4
|rm xlC*
|rm ipfx*
|rm vacpp*
|inutoc.

|If you never intend to install any nodes with AIX |4.3.3, you can also remove the RSCT files from the PSSP |lppsource directory and then rerun inutoc.

Step 17: Copy a basic AIX (mksysb) image

Note that there is no root password in the basic (minimal) AIX/6000 SP mksysb image. If you choose to use this image (it is the default) to install your nodes, you should take appropriate steps to make the system more secure. If your site uses NIS, you can use the |firstboot.cust file to define the NIS client. If you are not using NIS, you can use the script.cust file to copy the /etc/passwd and /etc/security/passwd files from the boot/install server. Refer to the example in the |/usr/lpp/ssp/samples/firstboot.cust file to determine how to copy a file.

Note:

|In order to reinstall your nodes, the mksysb image and the lppsource |that you use must both contain the same version, release, modification, and |fix levels of AIX. If you do not have a mksysb image at the same level |as your lppsource, you may do one of the following: |

1. |Make your own updated mksysb image. In order to do this, you will |need to: |
   1. |Update an existing lppsource to the most recent maintenance level of |AIX.
   2. |Perform a BOS node upgrade on a single node as described in BOS node upgrade or follow the steps in Installing updates on a per node basis.
   3. |Make a mksysb image of that node as described in Installing updates through reinstallation.
   4. |Use the mksysb created in Step 1c along with your updated lppsource to install your remaining |nodes. |
2. |Contact IBM Level 1 service to obtain an updated mksysb image. |

|

The media shipped with the SP hardware contains the spimg installp image. This image contains one or more AIX mksysb images. You may install any of these images for use on your nodes or use mksysb images of your own. You need to only install the AIX images that you intend to use.

If you intend to use your own mksysb image, copy it to /spdata/sys1/install/images and continue with Step 18: Install PSSP prerequisites.

Note:

If DCE is running on the host that the mksysb image is made from, you must first turn autostart off for the DCE daemons. To do this, issue:

config.dce -autostart off

then create the mksysb image.

installp -a -d /dev/cd0 -X spimg

|Step 18: Install PSSP prerequisites

|PSSP has prerequisites for certain file sets.

|Step 18.1: Install bos.net files

|Make sure that the bos.net (TCP/IP and NFS) and |bos.net.uucp (for Kerberos V4 systems only) files are installed |on your control workstation.

|Step 18.2: Install the perfagent.tools file set

|Make sure that the perfagent.tools file set, which is part of AIX |4.3.3 or later, is installed on your control workstation. |This file should have been placed in the lppsource directory in Step 15: Copy the Correct level of PAIDE. If it is not already installed on the control |workstation, it should be installed now.
|

If using:	Do this:
SMIT	TYPE smit install_latest The Install Software window appears. ENTER For AIX 4.3.3, /spdata/sys1/install/name/lppsource for Input Device ENTER For AIX 5L 5.1, /spdata/sys1/install/pssplpp/name/lppsource/installp/ppc for Input Device PRESS Ok to display the default install parameters. PRESS List for SOFTWARE to install to show options. SELECT One or more program options based on your AIX level as shown in the installp example that follows. SELECT Select program options as shown in the installp section of this table that follows. PRESS Ok to complete option selection and to begin installation. When the installation is complete, check the SMIT log file for the installation status. If errors occur, see IBM AIX Problem Solving Guide and Reference.
installp	For AIX 4.3.3, enter: installp -agXd /spdata/sys1/install/name/lppsource \ perfagent.tools For AIX 5L 5.1, enter: installp -agXd /spdata/sys1/install/name/lppsource/installp/ppc \ perfagent.tools

|Step 18.3: Install the runtime files

|PSSP has prerequisites for runtime libraries from the VisualAge C++ |product.

|For AIX 4.3.3, they are: |

|

vacpp.ioc.aix43.rte 5.0.2.0

|

xlC.aix43.rte 5.0.2.0 |

|For AIX 5L 5.1, they are: |

|

vacpp.ioc.aix50.rte 5.0.2.0

|

xlC.aix50.rte 5.0.2.0 |

|These file sets may not be part of the AIX installation package. |These files and their associated prerequisites were placed in your AIX |lppsource during Step 16.3: Move prerequisite files. They must be installed now.

|There may be more recent levels of these files available. Please |check the AIX Fix Distribution Service Web site at:

|http://techsupport.services.ibm.com/rs6k/fixdb.html
|

If using:	Do this:
SMIT	TYPE smit install_latest The Install Software window appears. ENTER For AIX 4.3.3, /spdata/sys1/install/name/lppsource for Input Device ENTER For AIX 5L 5.1, /spdata/sys1/install/pssplpp/name/lppsource/installp/ppc for Input Device PRESS Ok to display the default install parameters. PRESS List for SOFTWARE to install to show options. SELECT One or more program options based on your AIX level as shown in the installp example that follows. SELECT Select program options as shown in the installp section of this table that follows. PRESS Ok to complete option selection and to begin installation. When the installation is complete, check the SMIT log file for the installation status. If errors occur, see IBM AIX Problem Solving Guide and Reference.
installp	For AIX 4.3.3, enter: installp -agXd /spdata/sys1/install/name/lppsource xlC.rte \ xlC.aix43.rte vacpp.ioc.aix43.rte For AIX 5L 5.1, enter: installp -agXd /spdata/sys1/install/name/lppsource/installp/ppc \ xlC.rte xlC.aix50.rte vacpp.ioc.aix50.rte

|Step 18.4: Install the RSCT files

|If you are installing with AIX 5L 5.1, you must install the RSCT |shipped with AIX 5L 5.1. You can skip this step if you are |installing PSSP 3.4 on AIX 4.3.3.
|

If using:	Do this:
SMIT	TYPE smit install_latest The Install Software window appears. ENTER /spdata/sys1/install/name/lppsource/installp/ppc for Input Device PRESS Ok to display the default install parameters. PRESS List for SOFTWARE to install to show options. SELECT One or more RSCT program options, or select the header files (called rsct.basic, rsct.compat.basic, rsct.compat.clients, and rsct.core with ALL on the far right side) to do the full installation. PRESS Ok to complete option selection and to begin installation. When the installation is complete, check the SMIT log file for the installation status. If errors occur, see IBM AIX Problem Solving Guide and Reference.
installp	Enter: installp -agXd /spdata/sys1/install/name/lppsource/installp/ppc rsct

|Step 18.5: Install pSeries 690 files (optional)

|Install the pSeries 690 files using the following command:

|/bin/rpm -i openCIMOM-0.61-1.aix5.1.noarch.rpm

Step 19: Install PSSP on the control workstation

The PSSP images are made up of one or more file sets. Some of these file sets must be installed on the control workstation while others are optional. A subset of the file sets is installed on the individual nodes later in the installation process. Refer to the following table for more information.

Note:

Do not create the /usr/lpp/ssp directory as a separate file system. It must be part of the /usr file system.

File sets installed on the control workstation

Notes:

1. ssp.authent contains the parts required on a system that are used by the Kerberos V4 authentication server.

   You must install ssp.authent if the control workstation will be configured as a Kerberos V4 authentication server. If you are using MIT Kerberos V4 or Andrew File System (AFS) authentication services, ssp.authent is not required. You can install ssp.authent on any other RS/6000 SP system that is used as a Kerberos V4 authentication server. You cannot install ssp.authent if the system already has an MIT Kerberos V4 or AFS authentication server installed. If you want to use the SP authentication facilities, you must first remove the other authentication service.

2. If you are planning to set up system partitions, you must install ssp.top.

3. ssp.spmgr contains an SNMP manager. If you already have an SNMP manager running on the control workstation, UDP port 162 usage by the SP manager included as part of this file set must change. You will need to update the spmgrd-trap entry in the /etc/services file on the control workstation to specify an unused port. Any new port configured on the control workstation also has to be configured on the SNMP agents supporting dependent nodes.

For a complete list of file sets, refer to RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment.

File sets installed on the control workstation in later steps

Note:

|You must install the IBM Virtual Shared Disk file sets in Step 26: Complete IBM Virtual Shared Disk installation (optional). |

Installation without AIX preinstalled

Because your system may not have AIX preinstalled on the nodes, you should add an install image to your list of installation options. You can install one of the mksysb images shipped with the PSSP package.

Or if you prefer, you can provide your own AIX image for installation on the nodes.

PSSP installation instructions

Login to the control workstation as root, install the file sets selected for the control workstation, and follow one of the procedures described in the following table.

|Notes:

1. |If you are installing PSSP on AIX 4.3.3, install RSCT in |/spdata/sys1/install/pssplpp/PSSP-3.4.

2. |Do not install RSCT from this directory if you are installing PSSP |3.4 on AIX 5L 5.1.

installp -a -g -d /spdata/sys1/install/pssplpp/PSSP-3.4 -X ssp rsct

installp -a -g -d /spdata/sys1/install/pssplpp/PSSP-3.4 -X ssp

installp -l -d /spdata/sys1/install/pssplpp/PSSP-3.4/pssp.installp

SP administrative locale

When PSSP is installed on the control workstation, an SP administrative language is created. This locale is used on the SP to determine:

• The language that the data can be written in to the SDR
• The default AIX locale to set when installing a new node

This locale can also be used by some SP subsystems for locale-specific operations. It is not necessary for every node on the SP to operate in the same locale. Nodes can operate in a locale that is different from the SP administrative locale.

The SP administrative locale is initially set to the base AIX locale installed on the control workstation. This value can be changed at anytime using standard PSSP procedures for modifying site environment variables (see Step 30: Enter site environment information).

A related site environment variable is used to control the type of information that can be written to the SDR. This variable indicates whether only ASCII data can be written to the SDR (that is, data in the '00'x to '7F'x code range), or whether non-ASCII data is allowed.

Be careful when setting the SP system to allow non-ASCII data in the SDR. This should be done only if all nodes on the SP will be operating in the same locale and you have no future requirements to change the SP administrative locale. The base ASCII code range is available in all currently AIX-supported locales. Non-ASCII data written in one locale cannot be properly processed when operating in a different locale. Therefore, switching from one SP administrative locale to another is prohibited if the SDR contains non-ASCII data.

System language environment

PSSP runs in the base AIX locale for the machine. PSSP ships message catalogs only for en_US and En_US. Running in a locale for which a message catalog does not exist (including the C and POSIX locales) can result in text similar to the following embedded in messages:

Message not found

Refer to the "Considering AIX and PSSP in another language" section in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment for additional information.

Installing the ssp.docs HTML files

The ssp.docs file set includes HTML files that contain online versions of the PSSP publications. Once you have installed the ssp.docs file set, the PSSP HTML publications will be located at /usr/lpp/ssp/html. Since other parts of PSSP link to the HTML publications, these files should not be moved from the /usr/lpp/ssp/html directory.

A sample index file, /usr/lpp/ssp/html/psspbooks.html, has also been provided. It shows you how to set up a single launching point from which users can access all of the online books.

Installing the RS/6000 SP Resource Center

The RS/6000 SP Resource Center (ssp.resctr) provides a single interface to all of the online SP documentation and information resources. It contains links to SP publications, READMEs, product information, performance information, Redbooks, white papers, education, and up-to-date service information.

When the SP Resource Center is run, it detects which documentation file sets are installed (ssp.docs, LoadL.html.en_US, ppe.docs, and mmfs.gpfs). The SP Resource Center contains links to documents that are locally installed, or if a document is not installed, the link points to the document on the IBM World Wide Web site. If you are unsure that you have access to the World Wide Web, the documentation file sets should be installed to allow you to view them from the SP Resource Center.

The SP Resource Center consists of HTML, Java, and JavaScript. The files are installed in /usr/lpp/ssp/resctr.

The SP Resource Center does not have any requisites to other PSSP file sets, so it may be installed on any machine that is running AIX Version 4.2.1 or later. You must have the Netscape Navigator Version 4 or later to run the SP Resource Center. The SP Resource Center can also be run from a CD-ROM that can be used on AIX, or on the Microsoft Windows 95, 98, or NT platforms.

Once the SP Resource Center is installed, you can invoke it by issuing:

/usr/lpp/ssp/bin/resource_center

You can also invoke the SP Resource Center by selecting its icon from the CDE Desktop or by selecting its icon from the Perspectives Launch Pad. The first time you invoke the SP Resource Center, you will be prompted to enter the path name to the Netscape Navigator. This path name is stored on a per-user basis in $HOME/.resctr.

Step 20: Set authentication methods for AIX remote commands on the control workstation

When filling out your worksheet in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment, you decided which types of authentication methods you wanted to use on your SP system. You must select one or more authentication method for the control workstation. Your choices are k5, k4, or standard. This setting is used to determine initial security settings for PSSP in Step 25: Complete system support installation on the control workstation when the install_cw script is run.

Valid authentication settings for AIX remote commands are:

If using:	Do this:
DCE	Enter: chauthent -k5
Kerberos V4	Enter: chauthent -k4
Standard AIX	Enter: chauthent -std
DCE and Kerberos V4	Enter: chauthent -k5 -k4
DCE and Standard AIX	Enter: chauthent -k5 -std
Kerberos V4 and Standard AIX	Enter: chauthent -k4 -std
DCE, Kerberos V4, and Standard AIX	Enter: chauthent -k5 -k4 -std

Notes:

1. If you are using Kerberos V4 and the primary Kerberos V4 server is on an external system, issue the chauthent command to ensure rsh can be issued by the external Kerberos V4 server to the control workstation. For example, issue:

   chauthent -k4 -std
   

2. After issuing the chauthent command, you can verify that your authentication setting is accurate by issuing the lsauthent command.

Step 21: Initialize RS/6000 SP Kerberos V4 (optional)

Prior to performing this step, you must have decided what type of Kerberos V4 authentication server to use: RS/6000 SP, AFS, or another MIT Kerberos V4 implementation. In preparation, you should have completed the checklist in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment. See that book for more information.

RS/6000 SP authentication provides a program, /usr/lpp/ssp/bin/setup_authent, to initialize RS/6000 SP authentication services on RS/6000 SP workstations (including the control workstation) for Kerberos V4 authentication servers and authentication client systems. This program defines instances of the hardmon and rcmd authenticated services, and does one of the following:

1. Creates a primary Kerberos V4 authentication server and database
2. Creates a secondary Kerberos V4 authentication server and database
3. Configures the control workstation as a Kerberos V4 client
4. Initializes the control workstation or other RS/6000 SP workstations to use AFS authentication

Note the following when running setup_authent:

• <screenclear> shows where setup_authent clears the screen before displaying an explanation of the next part of the initialization procedure.
• root refers to the administration ID. It can be root or any name you choose. It must be a user in the system.

The procedure for completing this step varies, depending on the authentication configuration you select. Optionally, you can set up other workstations as secondary servers or client systems. Each configuration includes an example where the setup_authent command is invoked. Review the examples. Substitute the principal names and passwords on your system for the DescriptiveTerms shown in the examples, and use them to initialize the authentication services on your system.

If initializing as:	Refer to:
Primary Kerberos V4 Authentication Server	Step 21.2: Initializing as the primary Kerberos V4 authentication server
Secondary Kerberos V4 Authentication Server	Step 21.1: Setting up an external primary server and Step 21.3: Initializing as a secondary Kerberos V4 authentication server
Authentication Client System	Step 21.1: Setting up an external primary server and Step 21.4: Initializing as an authentication client system
Use AFS Authentication	Step 21.5: Initializing to use AFS authentication
Select only one authentication step to follow. Do not perform the steps for the Kerberos V4 authentication server you did not choose.

Step 21.1: Setting up an external primary server

Perform the following tasks to set up a primary Kerberos V4 server as an external workstation (not the control workstation).

1. Install the ssp.authent file set, if you have not already done so.
2. Set up the configuration file on the workstation. See the section on "Creating the Kerberos V4 configuration files" in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment for more information.
3. Run the setup_authent command on the external server.

After performing these tasks, follow the instructions in either Step 21.3: Initializing as a secondary Kerberos V4 authentication server or Step 21.4: Initializing as an authentication client system.

Step 21.2: Initializing as the primary Kerberos V4 authentication server

Follow this procedure to initialize your primary Kerberos V4 authentication server on the RS/6000 SP control workstation or another RS/6000 SP system:

1. Create a /etc/krb.conf file, unless you want setup_authent to create a default configuration file with one Kerberos V4 authentication server for the default local realm name.
2. Create a /etc/krb.realms file, if you need to map any domains to the local realm name.
3. Run the /usr/lpp/ssp/bin/setup_authent program.

For more information, see Installing and configuring Kerberos V4.

The following example shows the interaction you can expect when you run setup_authent when initializing the primary Kerberos V4 authentication server.

#setup_authent
<screenclear>
***********************************************************************
Creating the Kerberos Database
 
Invoking the kdb_init and kstash utilities to create the database.
 
You must decide on a master password for the database. You will be
prompted to enter it twice.  Save this password in a very secure
place, since it is used to encrypt all keys in the database and you
will need it for other administrative tasks.
 
After you complete this task, the Kerberos daemons will be started:
kerberos for ticket-granting services, kadmind for administration.
 
For more information see the kdb_init and kstash man pages.
************************************************************************
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
 
Enter Kerberos master key:  YourDatabasePassword
 
Enter Kerberos master key:  YourDatabasePassword
 
0513-004 The Subsystem or Group, kerberos, is currently inoperative
0513-083 Subsystem has been Deleted
0513-071 The kerberos Subsystem has been added
0513-059 The kerberos Subsystem has been started.  Subsystem PID is 18394
<screenclear>
************************************************************************
Defining an Administrative Principal to Kerberos
 
The kdb_edit utility is used to define the initial Kerberos users.
You must define a user whose UID is 0 as a Kerberos database
administrator. This user will have to login to Kerberos with this name
prior to performing installation tasks that result in execution of the
setup_server command, during installation or whenever network
interfaces have been added or renamed in the SP system configuration.
 
kdb_edit prompts you separately for the name and the instance. First
enter the user name, specifying the login name of the user who will be
the primary Kerberos administrator for the local realm. When you are
prompted for the instance, you must enter admin.  You must assign a
Kerberos password for this user and enter it twice (you may use the
AIX login password). To take default values on other options, hit
<Enter>.
 
You may create any number of other Kerberos principals at this time.
To exit kdb_edit, hit <Enter> when prompted for another
principal name.

For more information see the kdb_edit man page.
************************************************************************
 
Opening database...
Previous or default values are in [brackets];
hit <enter> to leave the same, or new value.
 
Principal name: root
Instance: admin
 
<not found>, Create [yes]?  <Enter>
 
Principal: root, Instance: admin, kdc_key_ver: 1
New Password: <password>
Verifying, please re-enter
New Password: <password>
 
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [2037-12-31] ?<Enter>
Max ticket lifetime [ 255 ] ? <Enter>
Attributes [ 0 ] ? <Enter>
Edit O.K.
Principal name: <Enter>
*************************************************************************
 
Logging into Kerberos as an admin user
You must assume the role of a Kerberos administrator <user>.admin
to complete the initialization of kerberos on the local system. The
k4init command is invoked and will prompt you for the password. If you
are setting up your primary server here, you just defined it. If you
have defined multiple administrative principals, or if your primary
authentication server is on another system, you must first enter the
name of an administrative principal who has root privilege (UID 0).
You need to be authenticated as this administrator so that this program
can create the principals and service keyfiles for the authenticated
services that run on the SP system. For more information, see the
k4init man page.
************************************************************************
Kerberos Initialization for "root.admin"
Password: rootPassword

Step 21.3: Initializing as a secondary Kerberos V4 authentication server

• To do this step, the primary Kerberos V4 authentication server must already be initialized.
• Ensure clock synchronization between the primary and secondary Kerberos V4 authentication servers.

For more information, see Installing and configuring Kerberos V4.

Follow this procedure to initialize a secondary Kerberos V4 authentication server on the control workstation or another RS/6000 SP workstation.

1. Copy the /etc/krb.conf file from the primary Kerberos V4 authentication server to this secondary Kerberos V4 server system.
2. Add a line to the /etc/krb.conf file, listing this system (by its full host name) as a secondary Kerberos V4 server for the local authentication realm.

   For example, to add sp2cw.xyz.com as a secondary Kerberos V4 server for the authentication realm XYZ.COM, add this line to /etc/krb.conf:

   XYZ.COM sp2cw.xyz.com

3. Copy the /etc/krb.realms file from the primary Kerberos V4 server to this secondary Kerberos V4 server system.
4. Run the setup_authent program.

   setup_authent requires you to login to the authentication service using the same administrative principal name that was defined for the primary Kerberos V4 server. The remainder of the initialization of authentication services on this secondary local Kerberos V4 system takes place automatically.

5. After setup_authent completes, add an entry for the new server to the /etc/krb.conf file on all SP systems on which you have already initialized authentication.
6. On the primary Kerberos V4 server, if this is the first secondary Kerberos V4 server, you should create a root crontab entry that invokes the script /usr/kerberos/etc/push-kprop to periodically propagate database changes.

The following example shows the interaction you can expect when you run setup_authent when initializing as a secondary Kerberos V4 authentication server:

#setup_authent
<screenclear>
************************************************************************
Logging into Kerberos as an admin user
 
You must assume the role of a Kerberos administrator <user>.admin
to complete the initialization of kerberos on the local system.
The k4init command is invoked and will prompt you for the password.
If you are setting up your primary server here, you just defined it.
If your primary server is on another system, you must first enter
the user name of an administrative principal defined on that server.
 
You need to be authenticated as an administrator so that this
program can create the service principals required by the
authenticated services that are included in the ssp package.
 
hardmon - for the System Monitor facilities
rcmd    - for sysctl and Kerberos-authenticated rsh and rcp
 
For more information, see the k4init man page.
************************************************************************
setup_authent: Enter name of admin user: root
Kerberos Initialization for "root.admin"
Password: rootPassword
backup.abc.com: success.backup.abc.com:         Succeeded
#

The last two messages shown in the previous example are issued by the programs that transfer the database from primary to secondary Kerberos V4 servers, to indicate that the backup database has been installed.

Step 21.4: Initializing as an authentication client system

To do this step, the primary Kerberos V4 authentication server must already be initialized.

For more information, see Installing and configuring Kerberos V4.

Follow this procedure to initialize the control workstation or another RS/6000 SP system as an authentication client system.

1. Copy the /etc/krb.conf file from the primary Kerberos V4 authentication server to this system.
2. Copy the /etc/krb.realms file from the primary Kerberos V4 server.

   If the new workstation is outside the realm of the primary server, you must add this new workstation to the /etc/krb.realms file on the primary Kerberos V4 server before you copy the /etc/krb.realms file from the primary Kerberos V4 server to the new workstation.

3. Run the setup_authent program.

   setup_authent requires you to login to the authentication service using the same administrative principal name that was defined when the primary Kerberos V4 server was set up.

4. The .klogin file on a client workstation contains just the administrative principal name you used to install authentication. You may want to edit the /spdata/sys1/spsec/.klogin file to add other principals in your configuration.

The following example shows the interaction you can expect when you run setup_authent when initializing as an authentication client system. The initial warning message shown in the example is issued if you have installed the ssp.authent option on a system configured as a client rather than a server.

#setup_authent
setup_authent: This system is not listed as a Kerberos server in
/etc/krb.conf. Continuing setup as a Kerberos client system only.
<screenclear>
************************************************************************
Logging into Kerberos as an admin user
 
You must assume the role of a Kerberos administrator <user>.admin
to complete the initialization of kerberos on the local system.
The k4init command is invoked and will prompt you for the password.
If you are setting up your primary server here, you just defined it.
If your primary server is on another system, you must first enter
the user name of an administrative principal defined on that server.
 
You need to be authenticated as an administrator so that this
program can create the service principals required by the
authenticated services that are included in the ssp package.
 
hardmon - for the System Monitor facilities
rcmd    - for sysctl and Kerberos-authenticated rsh and rcp
 
For more information, see the k4init man page.
************************************************************************

setup_authent: Enter name of admin user: root

Kerberos Initialization for "root.admin"

Password: rootPassword

Step 21.5: Initializing to use AFS authentication

To do this step, the AFS primary authentication server must already be initialized.

For more information, see Installing and configuring Kerberos V4.

Follow this procedure to initialize using AFS authentication servers.

1. If the AFS configuration files (ThisCell, CellServDb) are not in /usr/vice/etc, you must create a symbolic link from /usr/vice/etc to the directory containing those files:
2. If the kas command is not installed in /usr/afsws/etc, create a symbolic link from /usr/afsws/etc to the directory containing the kas command.
3. If you are using AFS Version 3.4, you must reconcile the conflicting port assignments used by the kaserver and RS/6000 SP authentication commands, as described in RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment and PSSP: Administration Guide.
4. Run the setup_authent program.

   setup_authent requires you to enter the name and password of the AFS administrator.

The following example shows the interaction you can expect when you run setup_authent when initializing to use AFS authentication. The message always appears when the workstation has AFS installed, either as a client or server:

#setup_authent
<screenclear>
***********************************************************************
Option to Use AFS
 
Because this system is configured for use of AFS, you may choose to
use the AFS authentication servers instead of installing RS/6000 SP
authentication servers or using other Kerberos V4 servers.
 
The choice of AFS indicates that you will be using AFS authentication
servers exclusively in your RS/6000 SP system's local realm.
 
Do you want to set up authentication services to use AFS servers?
***********************************************************************
 
Enter y or n: y

afs_add_principal: Enter afs admin principal name [login-name] user-name Password: UserNamePassword

Step 22: Configure DCE for the control workstation (required for DCE)

If you want PSSP to use DCE authenticated services, you must:

1. Install DCE on the control workstation.

   If you plan to install DCE on the control workstation, become familiar with "Tips for installing DCE on the SP." If you modify the /etc/environment file, you will need to reboot the control workstation in order for the DCE processes to use those changes.

   Tips for installing DCE on the SP

   DCE will use all configured network interfaces available for any DCE runtime traffic. There may be circumstances where certain network interfaces or addresses should not be used. DCE provides a mechanism to exclude these interfaces or adapters. Excluding these interfaces does not preclude their use for remote command traffic. DCE accomplishes this through the use of environment variables. These are: RPC_UNSUPPORTED_NETADDRS and RPC_UNSUPPORTED_NETIFS. The two variables accomplish the same task, so only use one of these variables. The recommended value to use is RPC_UNSUPPORTED_NETIFS. Within the SP, there are specific adapters or interfaces, like the switch (css#) adapters, which do not communicate between the control workstation and the nodes. These adapters are prime candidates for exclusion from DCE traffic. For example, to exclude the switch adapter, css0, do one of the following: Edit the /etc/environment file on all nodes and add RPC_UNSUPPORTED_NETIFS=css0. On the command line, enter export RPC_UNSUPPORTED_NETIFS=css0 Start DCE within the same session the previous command was entered. If there are adapters on the control workstation, through which no DCE communication is expected, exclude these adapters as well using the same method described previously.

2. Be configured either as a client or server in the cell.

Step 22.1: Update the spsec_overrides file (optional)

The config_spsec command reads from two files. The defaults file is /usr/lpp/ssp/config/spsec_defaults. If the defaults need to be modified, for example, if any of the names in spsec_defaults conflict with items already in the DCE database, the /spdata/sys1/spsec/spsec_overrides file should be modified.

Note:

If the spsec_overrides file has been modified on the control workstation, it must be copied to the remote workstation in order to run the config_spsec command off of the SP.

For more information, refer to RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment and PSSP: Command and Technical Reference.

Step 22.2: Create DCE groups, organizations, principals, and accounts

As the cell administrator on the control workstation, issue the following command to create SP Trusted Services groups, organizations, and principals for the control workstation:

config_spsec -c -v

Note:

Refer to the config_spsec command in PSSP: Command and Technical Reference for a description of the -r (remote) flag to run this command remotely off of the SP.

Step 22.3: Create SP administrative principals

There must be a DCE principal that is a member of hm-admin, sdr-admin, sdr-system-class-admin, sdr-restricted, spsec-admin, and the hm-control groups to continue the install.

Use the appropriate DCE commands to define an administrative principal. The principal can be added to the SP access groups by a cell administrator using dcecp:

dcecp -c group add sdr-admin -member your_principal
dcecp -c group add hm-admin -member your_principal

Note:

The administrative principals may need access to additional SP groups. Refer to RS/6000 SP: Planning, Volume 2, Control Workstation and Software Environment for a complete list of groups defined by PSSP to DCE. The access groups (ACC-GRP) whose name does not end in "-services" are intended for end users. For example, these control facilities could be sysctl, problem management, event management, the switch commands, LoadLeveler, Parallel Environment, and so on.

Step 22.4: Create control workstation-specific keyfiles

As root on the control workstation with default credentials, issue the following command to create control workstation-specific keyfiles:

create_keyfiles -c -v

Step 23: Set the authentication method for SP Trusted Services on the control workstation

Depending on the authentication method you selected in either Step 21: Initialize RS/6000 SP Kerberos V4 (optional) or Step 22: Configure DCE for the control workstation (required for DCE), determine the appropriate authentication method to use for SP Trusted Services during installation.

Notes:

1. If the authentication methods enabled for use by SP Trusted Services includes DCE, the authentication methods enabled for use by the AIX remote commands must include Kerberos V5.

2. If the authentication methods enabled for use by SP Trusted Services includes compatibility, the authentication methods enabled for use by the AIX remote commands must include Kerberos V4.

chauthts dce

chauthts compat

chauthts dce compat

chauthts

To verify your settings, issue the lsauthts command. If your setting was DCE, DCE will be returned. If your setting was Kerberos V4, Compatibility will be returned.

Step 24: Obtain credentials

If DCE or Kerberos V4 was enabled in Step 23: Set the authentication method for SP Trusted Services on the control workstation, you must obtain credentials using dce_login or k4init. If DCE was selected, you should dce_login to the SP administrative principal created in Step 22.3: Create SP administrative principals. If Kerberos V4 was selected, you should use the appropriate administrative principal created in Step 21: Initialize RS/6000 SP Kerberos V4 (optional).

Step 25: Complete system support installation on the control workstation

This step does the following:

• Configures the control workstation
• Installs PSSP SMIT Panels
• Starts SP daemons
• Configures the SDR
• Updates /etc/inittab and /etc/services
• Sets node_number for the control workstation to 0 in the Object Data Management (ODM) databases
• Creates the hardmon hmacls file
• Configures the system as one system partition. There is one system partition corresponding to the name of the control workstation in the SP object. It is called the default or persistent system partition because it always exists.
• Sets security attributes for the default system partition.

Using install_cw

Use the install_cw command to finish installing PSSP on the control workstation.

If using:	Do this:
install_cw	Enter: install_cw

There are certain conditions that can cause the install_cw command to fail. This will be shown by a message such as:

The SDR_init script completed unsuccessfully with a return code of 1.
Exiting...

Additional messages in /var/adm/SPlogs/sdr/SDR_config.log will provide more detailed information about the failure. Typical conditions that can cause a failure are:

1. The lsauthts command indicates that the chauthts command was never run. (The chauthts command should have been run in Step 23: Set the authentication method for SP Trusted Services on the control workstation.) To recover from this failure, run the chauthts command and rerun the install_cw command.
2. In a system where the lsauthts command indicates DCE, install_cw was invoked by a user lacking sdr-system-class-admin and sdr-admin authority. To recover from this failure, dce_login to a correctly-authorized principal and rerun the install_cw command.

Note:

At this point, you can bring up the Perspectives GUI for use in the rest of the installation. The Launch Pad will let you bring up SMIT menus and issue commands, but the sphardware Perspective may not function at this stage of the installation. See Appendix C, SP Perspectives tasks for more information on using Perspectives. If you do not wish to use Perspectives for the install steps, you can use SMIT or the command line.

To bring up the Perspectives Launch Pad, make sure your DISPLAY environment variable is set correctly and enter the following command:

perspectives &

You may receive the following message which you can ignore:

Warning: locale not supported by C library, locale unchanged.

Use the splstdata command to check the initial system partition security settings.

If using:	Do this:
splstdata	Enter: splstdata -p

Step 26: Complete IBM Virtual Shared Disk installation (optional)

Note:

Perform this step only if you are installing IBM Virtual Shared Disk.

Use SMIT or the installp command to install the IBM Virtual Shared Disk file sets.

If using:	Do this:
SMIT	TYPE smit install_latest The Install Software window appears. ENTER /spdata/sys1/install/pssplpp/PSSP-3.4 for Input Device PRESS Ok to display the default install parameters. PRESS List for SOFTWARE to install to show options. SELECT Select vsd with ALL on the far right side to do the IBM Virtual Shared Disk installation. PRESS Ok to complete option selection and to begin installation. When the installation is complete, check the SMIT log file for the installation status. If errors occur, see IBM AIX Problem Solving Guide and Reference.
installp	You can use installp to install multiple file sets. For example: installp -a -g -d /spdata/sys1/install/pssplpp/PSSP-3.4 -X vsd Note: For AIX 4.3.3 or later, installp automatically commits the packaging file set when you specify the -a option. To list all of the options for IBM Virtual Shared Disk, enter: installp -l -d /spdata/sys1/install/pssplpp/PSSP-3.4/vsd

|Step 27: Apply PSSP PTFs (optional)

|Software maintenance (PTFs) may now be applied to the ssp and |rsct file sets installed on the control workstation. Refer to Installing program updates for planning considerations. Follow the |instructions in Preparing the control workstation to install the PTFs.

Step 28: Add the PSSP T/EC adapter (optional)

At this point, you can optionally add the PSSP T/EC adapter to your system. Refer to Chapter 9, Installing the optional PSSP T/EC adapter for more information.

Step 29: Run SDR and System Monitor verification tests

If using:	Do this:
Perspectives	SELECT smit SP_verify on CWS from Launch Pad The RS/6000 SP Installation/Configuration Verification menu appears. From this point, you can follow the rest of the SMIT steps described in the next row of this table.
SMIT	TYPE smit SP_verify The RS/6000 SP Installation/Configuration Verification menu appears. SELECT System Data Repository PRESS Done to return to the previous screen SELECT System Monitor Installation
SDR_test spmon_itest	Enter: SDR_test spmon_itest

After the tests are run, the system creates the spmon_itest.log in /var/adm/SPlogs/spmon and the SDR_test.log in /var/adm/SPlogs.

See PSSP: Command and Technical Reference for more information about SDR_test and spmon_itest and on what these tests do.