Differences from Solaris 7 Installation and Configuration of the Sun Enterprise 10000

For administrators familiar with Trusted Solaris installation, installing a Trusted Solaris SSP and a Trusted Solaris domain are extensions of installing the Trusted 7 operating environment with trusted packages. Administrators familiar with installing Solaris software on a Sun Enterprise 10000 should be aware of the differences between the Solaris and Trusted Solaris environments.

Trusted Solaris Roles Replace Solaris Users

The Trusted Solaris environment does not have a superuser. Superuser tasks are divided among administrative roles. Trusted Solaris administrative roles run with a special shell, the profile shell (pfsh(1M). Roles do not directly log in; they are "assumed" by a user who is assigned the role by the security administrator. A role can only log in remotely from the same role on another Trusted Solaris workstation. For more information on roles, see "Assuming a Role and Working in a Role Workspace" in Trusted Solaris Administrator's Procedures.

SSP User Versus SSP Role

The ssp user on Solaris SSP 3.1.1 has been replaced by the ssp role on Trusted Solaris SSP 3.1.1. Any commands that the ssp user runs in the Solaris environment are run by the ssp role in the Trusted Solaris environment. The ssp role runs with the profile shell (pfsh), and should not be changed to run with other shells.

The home directory (/export/home/ssp) for the ssp role is created at installation as a multilevel directory (MLD). The ssp role runs at label admin_low, and its files are stored in an SLD (single-label directory) at the label admin_low. See Trusted Solaris Administration Overview for an explanation of the Trusted Solaris environment and concepts.

Superuser (root) Versus root Role

The Solaris superuser (root) has been replaced by the Trusted Solaris root role. For the Trusted Solaris SSP 3.1.1 and the Trusted Solaris AP 2.2, any commands that superuser runs in a Solaris environment are run by the root role in a Trusted Solaris environment. The root role runs with the profile shell (pfsh), and should not be changed to run with other shells.

SSP Local and Remote Access Using Trusted Solaris Software

Trusted Solaris access to the SSP console is different from Solaris access because of Trusted Solaris role constraints.

SSP Local Access

On a Solaris SSP console, the ssp user can directly log in. On a Trusted Solaris SSP console, an administrator first logs in as a user who can assume the ssp role, then assumes the role.

On a Solaris SSP console, the superuser can directly log in, or can use the su(1M) command to become superuser. On a Trusted Solaris SSP console, an administrator who can assume the root role first logs in as a user, then assumes the role.

SSP Remote Access

To access the ssp user remotely on a Solaris SSP, a user can rlogin(1) or telnet(1) to the SSP and then log in as the ssp user. A user can also CDE rlogin to the SSP, then CDE log in as the ssp user.

To access the ssp role remotely on a Trusted Solaris SSP:

From another Trusted Solaris workstation, assume the ssp role. In the ssp role, rlogin(1) to the SSP. This method works only from another Trusted Solaris SSP because only a Trusted Solaris SSP has the ssp role.
From another Trusted Solaris workstation, perform a CDE remote login to the SSP. The SSP becomes the remote host on your local Trusted Solaris workstation. Then perform a CDE login to the SSP as a user who can assume the ssp role, and assume the ssp role. This method does not require the local Trusted Solaris workstation to have the ssp role. You can use this method to access remotely the Trusted Solaris SSP from any local Trusted Solaris workstation.

These methods also work for accessing the root role on the Trusted Solaris SSP. See "Remote Administration Options" in Trusted Solaris Administrator's Procedures for a full discussion of remote administration.

Domain Access Using Trusted Solaris Software

Solaris and Trusted Solaris domains can be accessed from the SSP console or from other workstations.

From the SSP Console

A Solaris domain can be logged into from a netcon(1M) session. Trusted Solaris does not support command line login, so a Trusted Solaris domain can not be logged into from a netcon session. The netcon window still receives the domain's console messages and can be used for OBP (OpenBoot Prom) commands.

To log in to a Trusted Solaris domain from an SSP console:

From a Solaris SSP console, you can rlogin(1) as a user to the Trusted Solaris domain. However, you cannot access the root role on a Trusted Solaris domain from a Solaris SSP console.
From a user workspace on a Trusted Solaris SSP console, you can rlogin as a user to the Trusted Solaris domain. For performing administrative tasks, you assume an administrative role on the Trusted Solaris SSP console, and then rlogin to the domain as the same role.

From Other Workstations

You can rlogin to a Solaris domain from a Solaris workstation. You can rlogin(1) as a user to the Trusted Solaris domain from a Solaris workstation. You cannot perform administrative tasks in a Trusted Solaris domain from a Solaris workstation, because you do not have access to any administrative roles.

To log in to a Trusted Solaris domain from a Trusted Solaris workstation:

From a user workspace on a Trusted Solaris workstation, you can rlogin as a user to the Trusted Solaris domain. From an administrative role on a Trusted Solaris workstation (example: root role), you can rlogin to the domain as the same role. This method enables access to a Trusted Solaris domain when the Trusted Solaris SSP is not available.
From another Trusted Solaris workstation, you can also perform a remote CDE login to the Trusted Solaris domain. The Trusted Solaris domain becomes the remote host on your local Trusted Solaris workstation. You can CDE login as a user to the domain and then assume roles. This method is useful when there is a spare Trusted Solaris workstation available. It is generally not desirable to do this using the Trusted Solaris SSP because it prevents the SSP from being used for SSP tasks.

Installation Options are Reduced

Trusted Solaris 7 installation does not fully support the following options offered by Solaris 7 installation software:

WebStart. Trusted Solaris SSP 3.1.1 is installed from a CDROM.
Upgrade. You cannot upgrade from the Solaris operating environment to the Trusted Solaris 7 operating environment. You cannot upgrade to Trusted Solaris 3.1.1 or to Trusted Solaris AP 2.2 from their Solaris versions.
SSP Backup. Like its Solaris version, Trusted Solaris 3.1.1 can use the ssp_restore command to restore the SSP environment from a backup file created by the ssp_backup command on a Solaris SSP 3.1 or 3.1.1.
NIS. Trusted Solaris 7 supports the NIS+ name service, not NIS.

Trusted Solaris Installation

The Trusted Solaris 7 operating environment must be installed and configured on the SSP workstation before the Trusted Solaris SSP 3.1.1 software is installed on it.

Trusted Solaris SSP Installation

Installing the Trusted Solaris 7 operating environment on the SSP is the same as installing Trusted Solaris 7 on a NIS+ client workstation or a NIS+ master server. Please see Trusted Solaris Installation and Configuration for details.

After the Trusted Solaris operating environment is installed and configured on the SSP, the Trusted Solaris version of SSP 3.1.1 software can be installed. See Chapter 3, Installing and Configuring the Trusted Solaris SSP 3.1.1 for details.

After Trusted Solaris SSP 3.1.1 is installed, the Trusted Solaris version of AP 2.2 software can be installed. See Chapter 5, Trusted Solaris Alternate Pathing 2.2 on the Sun Enterprise 10000 Server for details.

Trusted Solaris Domain Installation

Installation of the Trusted Solaris operating environment on a domain can be done using the Trusted Solaris SSP as the net install server. See Chapter 4, Trusted Solaris 7 on a Sun Enterprise 10000 Domain for details.

After the Trusted Solaris operating environment is installed and configured on the domain, the Trusted Solaris version of AP 2.2 software can be installed. See Chapter 5, Trusted Solaris Alternate Pathing 2.2 on the Sun Enterprise 10000 Server for details.

Creating a Sun Enterprise 10000 System Running Trusted Solaris 7

The following are examples of creating recommended Trusted Solaris 7 configurations on a Sun Enterprise 10000:

Note -

The examples are very high level. Each site should create a detailed plan that best fits the site and site security requirements.

A New Sun Enterprise 10000 Server with No Domains

On the SSPs, install the Trusted Solaris 7 operating environment and Trusted Solaris SSP 3.1.1. If alternate pathing is required, install Trusted Solaris AP 2.2.
Create each domain and install the Trusted Solaris 7 operating environment on each. If alternate pathing is required, install Trusted Solaris AP 2.2.

An Existing Sun Enterprise 10000 Server with Domains

Back up the current SSP environment.
On the spare SSP, install the Trusted Solaris 7 operating environment and Trusted Solaris SSP 3.1.1. If alternate pathing is required, install Trusted Solaris AP 2.2. Restore the SSP environment on the spare SSP so that the spare is synchronized with the main SSP.
Switch the SSPs so that the main SSP is now running Trusted Solaris 7, Trusted Solaris SSP 3.1.1, and Trusted Solaris AP 2.2.
On the spare SSP, install the Trusted Solaris 7 operating environment and Trusted Solaris SSP 3.1.1. If alternate pathing is required, install Trusted Solaris AP 2.2. Restore the spare SSP environment so it is synchronized with the main SSP.
To convert each domain from Solaris software to Trusted Solaris 7, install the Trusted Solaris 7 operating environment on each domain. If alternate pathing is required, install Trusted Solaris AP 2.2.