(Dist) Manage profiles for nonroot users

The nonroot user can receive permissions for files and directories so that the nonroot user can create a profile.

This task assumes a basic familiarity with the manageprofiles command, the Profile Management Tool, and system commands.

This task uses the following terms:

• Root users refers to:
  • (Linux) (HPUX) (Solaris) (AIX) Root users
  • (Windows) Administrators

• Non-root users refers to:
  • (Linux) (HPUX) (Solaris) (AIX) Non-root users
  • (Windows) Non-administrators

• Installer refers to a root user or a non-root user.

Remember: An ease-of-use limitation exists for nonroot users who create profiles. Mechanisms within the Profile Management Tool that suggest unique names and port values are disabled for nonroot users. The nonroot user must change the default field values in the Profile Management Tool for the profile name, node name, cell name, and port assignments. Consider assigning nonroot users a range of values for each of the fields. We can assign responsibility to the nonroot users for adhering to their assigned value ranges and for maintaining the integrity of their own definitions.

Start processes that run on the same profile with user IDs that have mutually compatible file permissions, meaning that each process can read or update files that the other processes create. This ensures that the processes can access the same files without encountering a permission-denied error. For example, if we run the deployment manager as user wasuser and then also run the command line tool to generate plug-ins on that same profile, we should run the tool as user wasuser.bprac

(Windows) Tip: In WebSphere Application Server v9.0, files created by an administrator outside of the Program Files directory are usable by non-administrators. Therefore, profiles created outside of the Program Files directory can be used by non-administrators to start the server and so on.

When creating a new profile, we can umask to 002 and then run the manageprofiles command to give group users the appropriate permissions.

Nonroot users might typically need these tasks completed so that they can start their own application servers in development environments. For instance, an application developer might test an application on an application server in a profile assigned to that application developer.

Tasks

• Create a profile as an installer and assign ownership to a nonroot user.

  This article describes how the installer creates a profile and assigns ownership of the profile directory to a nonroot user so that the nonroot user can start the application server for a specific profile.

• Grant write permission of files and directories to a nonroot user for profile creation.

  This article describes how an installer can create 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.

• Install maintenance as an installer and change the ownership of profile-related files.

  This article describes how to install product maintenance and change the ownership of new profile files to the nonroot user that owns the profile. The installer changes ownership of the files so that the nonroot user can then successfully start the application server.

Depending on the tasks that the installer followed, the installer has completed the following actions:

• Created a profile for a nonroot user and assigned ownership of the profile directory to the nonroot user
• Granted permission to the appropriate directories so that nonroot users can create profiles

• After installing maintenance, changed ownership of new profile files in a directory that is owned by a nonroot user, so that the nonroot user can successfully start the application server

Connections to the Derby database might not work, and we might see errors like the following in the logs:

java.io.FileNotFoundException: C:\IBM\WebSphere\AppServer\derby\derby.log (Access is denied.)

This can happen when files under app_server_root are read-only. We can configure Derby to write its log to another location by setting the following property in the app_server_root/derby/derby.properties file

# This property can be set to make Derby log to System.err.  This is useful if you 
# do not have write permission to the default location: 
/opt/wasprofile/derby/derby.log derby.stream.error.field=java.lang.System.err

What to do next

Depending on the tasks that the installer completes, a nonroot user can create a profile, start WAS, or do both.

Subtopics

• Assigning profile ownership to a non-root user
  An installer can create 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.
• Granting write permission for profile-related tasks
  The installer can grant write permission of the appropriate files and directories to a non-root user. The non-root user can then create the profile. The installer can create a group for users who are authorized to create profiles, or the installer can give individual users the authority to create profiles. The following example task shows how to create a group that is authorized to create profiles.
• Changing ownership for profile maintenance
  When an installer installs a maintenance package containing service for a profile that a non-root user owns, the installer owns any new files that the maintenance package creates. The installer can change the ownership of the new files so that a non-root user can successfully start the product.

Assigning profile ownership to a non-root user

Granting write permission for profile-related tasks

Change ownership for profile maintenance