Administration Guide

Preparing the control workstation before you define system partitions

In the beginning, after you have installed the PSSP software, but before you have configured system partitions, there is one system partition corresponding to the name and IP address of the control workstation, that returned by the hostname command. This is the default or persistent system partition. It always exists. When you configure more than one system partition, one of them must be defined as the default system partition with this name and IP address and you must define alias IP addresses and names for all other system partitions. When you add a security method to a system, some additional steps must be done before you proceed to partitioning. This section discusses the following procedures that must be completed before you partition the SP system:

Defining alias IP addresses
Preparing the control workstation for adding a security configuration

After completing the procedures in this section, proceed with Partitioning the SP system to select, customize, and apply a system partition configuration.

Defining alias IP addresses

When configuring more than one system partition, you must define alias IP addresses and names for all but the default system partition. To configure an alias IP address use the ifconfig command with the alias parameter, establishing an additional IP address for the interface to which the hostname of the control workstation can map.

Note:: The alias must be defined on the same subnet as the interface to which the hostname of the control workstation maps. IPv6 aliases are not supported. For more information about IPv6, see Appendix G, Tolerating IPv6 alias addresses.

Also add alias names that map to these alias IP addresses through your name resolution mechanism. Add the alias IP addresses to the rc.net file so that they are automatically configured when the control workstation reboots.

The steps for defining alias IP addresses are:

In the Part II - Traditional Configuration section of the /etc/rc.net file, a template is provided for changing inet0 to an alias. Follow the template and edit the file to define alias IP addresses and names. (After editing the /etc/rc.net file, make sure that you have execute permission on the file or the control workstation will not boot correctly.) For example:
```
/usr/sbin/ifconfig tr0 alias 129.40.127.101 netmask 255.255.255.0
up >>$LOGFILE 2>&1;
```
Execute the /etc/rc.net script. Alternatively, you could enter the ifconfig command directly. For example:
```
ifconfig tr0 alias 129.40.127.101 netmask 255.255.255.0 up
```
Validate that the alias is defined correctly (that is, that the same interface is defined for the alias and the control workstation host name). For example, to list the IP addresses and aliases on your system:
```
netstat -in
tr0   129.40.127   129.40.127.43
tr0   129.40.127   129.40.127.101
```
|If you are running DCE on your control workstation, to define the |new alias IP address in the DCE data base, do the following: |
1. |Log in to the DCE data base as a cell administrator.
2. |Run the command:
```
|kerberos.dce -type admin -ip_name hostname_of_adapter
```
3. |Log in as root on the control workstation and run the command:
```
|kerberos.dce -type local
```
  |

Note:: When you add an alias for the control workstation for the purpose of defining a name for a new system partition, you must run the setup_server command on the control workstation to properly define the new rcmd principal associated with the new host name alias.

To delete the alias we defined in the previous example, the command is:

/usr/sbin/ifconfig tr0 delete 129.40.127.101

Remember to comment out or delete any entries you made to define aliases in the /etc/rc.net file.

Preparing the control workstation for adding a security configuration

Security configuration is a complex task. There are many steps in addition to setting the security attributes in the SDR.

When adding a security method to a system, before the partitioning procedure Partitioning the SP system, do the following:

If Kerberos V4 is added to a system, the setup_authent command must be run before the auth_install attribute is changed to include k4. Similarly, if a new system partition is to contain Kerberos V4, the setup_authent command must have been run before the partition is applied by the spapply_config command. The setup_authent command might have been run as part of your original system installation or it can be run just before the partitioning process that applies the new Kerberos V4 partition.
When Kerberos V4 authentication is added for a node, the node must be customized. Use the spbootins command to set the node to customize and run setup_server. The actual customization will occur when you reboot the node after spapply_config execution is complete. If partitioning is being done when the node is already set to install, then customization is not needed.
If DCE is added to an existing system partition there are several configuration steps in "Chapter 5. Adding DCE to the SP System" of the book PSSP: Installation and Migration Guide that must be run.
If a new partition is to contain DCE, and if it is the first configuration of DCE on the SP system, the DCE configuration steps must be done on the control workstation before applying the new partition.
You must have DCE cell administrator authority to run the config_spsec and setupdce commands. They are shown in these procedures as being run from the SP control workstation. Using different option flags, you can run them remotely from any appropriately configured workstation. If you do not intend to run them from the SP control workstation, see the book PSSP: Command and Technical Reference for the options available and note your changes in the steps of the procedures where those commands occur.
The DCE configuration steps on the control workstation are the following:
1. Make sure that the control workstation has been properly defined as a DCE client in the DCE database. Be sure to have a valid network connection to the DCE primary server for the control workstation and target SP nodes.
2. Set the DCE hostname for each node in the SDR. For example, enter:
  create_dcehostname
3. Update the SDR with the DCE Master Security and CDS Server host names. For example, enter:
  setupdce -u -s master_sec_svr -d cds_svr
4. Configure SP trusted services to use DCE authentication. You must have cell administrator authority to run this step. The config_spsec command gets its input from two files. Since DCE is being configured for the first time, you should consider whether you can use the SP services /usr/lpp/ssp/config/spsec_defaults file as is, or if you need to change any of the SP service names using the /spdata/sys1/spsec/spsec_overrides file.
  For instance, each partition name can be appended to the group names by using the :p option in the spsec_overrides file. That way different groups can be defined for each partition. For example, partition1 could be used to specify the haem-users group for a partition called partition1, while partition2 can be used to specify the haem-users group for another partition. Different principles can then be assigned to each group. See DCE entities used by SP security services for related information.
  To configure SP trusted services to use DCE authentication, enter:
  config_spsec -v
5. Create SP services DCE key files. You must be root with self host (the default) DCE credentials to run the create_keyfiles command:
  create_keyfiles -v
|Configure the admin portion of the DCE clients on the |node by running the setupdce command. You are prompted to |enter the password of the cell administrator. You do not need to be |root to run this command. You can use the -c and |-l flags or you can accept the defaults for the cell administrator |ID and the LAN profile ID.
When an existing partition containing DCE is split into two partitions, DCE principles and key files must be created for the new partition before the partition is applied. Two commands are supplied for this purpose and are included in the SMIT Syspar menu (smitty syspar). They are shown in Step 6: Configure SP partition-sensitive services for using DCE.
All nodes with security settings affected by the system partitioning process should be shutdown as directed in Step 8: Shut down all nodes in the changing partitions before the spapply_config command is run. Any node that is being newly configured with Kerberos V4 must also be set to customize before it is rebooted.
|If authorization for AIX remote commands is to be set to |none, the restricted root access and secure remote commands process |options must be enabled.
|Note:
The restricted root access and secure remote command process options are |enabled for the entire SP system, not for a partition. |

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