An installer can create and augment a profile, and assign ownership of the profile directory to a non-root user so that the non-root user can start the product for a specific profile. Use this example to accomplish the tasks through commands.
This task assumes a basic familiarity with the manageprofiles command and system commands.
Before you can create and augment a profile, you must install the product.
An installer must perform the following steps to create, optionally augment a profile, and assign ownership for the profile directory and the logs directory. The ownership is assigned to a non-root user ID that is different from the installer ID. The non-root user needs access to these directories to start the product.
If augmentation of a particular profile is supported, then the installer might need to create a profile and later augment that profile for a feature pack. However, as the installer, create a feature pack-enabled profile when possible. To create a feature pack-enabled profile, use the appropriate feature-pack profile template, and skip the augmentation step.
The installer might have already completed the steps in this task to create a profile for a non-root user and changed ownership of particular directories to the non-root user. If you, as the installer, must now augment the profile for a non-root user, then begin with the step on augmentation.
For more information, see the topic on augmentation rules and limitations for feature packs.
This example creates a default profile.
The commands are split on multiple lines for printing purposes.
The installer has created a default profile, optionally augmented the profile, and changed ownership of the profile directory and log directory to a non-root user.
As the installer, you can continue to create and augment profiles, and assign ownership to non-root users as needed.
A non-root user ID can manage multiple profiles. Have the same non-root user ID manage an entire profile, whether it is the deployment manager profile, a profile that contains the application servers and the node agent, or a custom profile. A different user ID can be used for each profile in a cell, whether global security or administrative security is enabled or disabled. The user IDs can be a mix of root and non-root user IDs. For example, the root user might manage the deployment manager profile, while a non-root user might manage a profile that contains application servers and the node agent, or vice versa. However, typically, a root user or a non-root user manages all profiles in a cell.
The non-root user can use the same tasks to manage a profile that the root user uses.
In this information ... | IBM Redbooks, demos, education, and more(Index) |