Managing profiles for non-root users
The non-root user can receive permissions for files and directories so that the non-root user can create a profile.
Before you begin
This task assumes a basic familiarity with the manageprofiles command, the Profile Management Tool, and system commands.
This task uses the following terms:
Remember:
About this task
Non-root 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.
Keep the following guidelines in mind when you are delegating profile management to non-root
users and setting the permissions that are required to manage each profile.
- For a particular profile, use the same non-root user ID to manage the entire profile. Profile
management includes running any command-line scripts that might act on the profile, such as
startServer.sh
,wsadmin.sh
, ,managesdk.sh
, andmanageprofile.sh
. Running these scripts with an alternative user ID, such as a root user ID, might cause other scripts to fail due to mismatched file permissions. In general, start any processes that run on a profile from the same user ID, or from user IDs with compatible file permissions. For example, if you run the deployment manager as the wasuser user ID and then also run the command line tool to generate plug-ins on that same profile, run the tool as wasuser. - Establish the proper permissions to the directory to which you plan to use the command.
- In WebSphere® Application Server Version 8.5, files that are 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.
- An ease-of-use limitation exists for non-root users who create profiles. Mechanisms within the Profile Management Tool that suggest unique names and port values are disabled for non-root users. The non-root user must change the default field values in the Profile Management Tool for the profile name, node name, and port assignments. Consider assigning non-root users a range of values for each of the fields. You can assign responsibility to the non-root users for adhering to their assigned value ranges and for maintaining the integrity of their own definitions.
- When you create a new profile, you can umask to 002 and then run the manageprofiles command to give group users the appropriate permissions.
Procedure
Results
Depending on the tasks that the installer followed, the
installer has completed the following actions:
Note: Connections to the Derby database might not work, and you might see errors like the following
in the
logs:
java.io.FileNotFoundException: C:\Program Files\IBM\WebSphere\AppServer\derby\derby.log (Access is denied.)
These errors can happen when files under app_server_root are
read-only. You 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 non-root user can create a profile, start WebSphere Application Server, or do both.