Granting write permission for profile-related tasks

(Dist) 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.

The steps that you follow to grant write permission of files and directories to a non-root user for profile creation depend on whether a profile was previously created.

If at least one profile was created prior to implementing the following steps, then certain directories and files were created. Because these directories and files were created, skip the steps that create these directories and files. If no profile was previously created, then complete the steps to create the required directories and files. In most cases, a profile has been created previously.

The installer can perform the following steps to create the profilers group and give the group appropriate permissions to create a profile.

Tasks

Log on as the installer to the system where the product is installed.
Create the profilers group that we can use to create profiles.
Read the documentation for our operating system for information about how to create groups.

Create a user named user1 to create profiles.
Read the documentation for our operating system for information on how to create users.

Add the installer and user1 to the profilers group.
(Linux) (HPUX) (Solaris) (AIX) Log off and log back on again as the installer to use the new group.
Create the following directories as the installer if no profile was previously created:

(Linux) (HPUX) (Solaris) (AIX) Create the app_server_root/logs/manageprofiles directory:
mkdir app_server_root/logs/manageprofiles

(Windows) Create the app_server_root\logs\manageprofiles directory by following instructions in the Windows documentation. For this example, the directory is:
app_server_root\logs\manageprofiles

(Linux) (HPUX) (Solaris) (AIX) Create the app_server_root/properties/fsdb directory:
mkdir app_server_root/properties/fsdb

(Windows) Create the app_server_root\properties\fsdb directory by following instructions in the Windows documentation. For this example, the directory is:
app_server_root\properties\fsdb

As the installer, create the profileRegistry.xml or profileRegistry.xml.semaphore file and add the appropriate information if no profile was previously created.
Follow directions for our operating system to create the profileRegistry.xml or profileRegistry.xml.semaphore file. For this example, the file paths are:

(Linux) (HPUX) (Solaris) (AIX)
app_server_root/properties/profileRegistry.xml

(Linux) (HPUX) (Solaris) (AIX)
app_server_root/properties/profileRegistry.xml.semaphore

(Windows)
app_server_root\properties\profileRegistry.xml

(Windows)
app_server_root\properties\profileRegistry.xml.semaphore

Follow instructions for our operating system to add the following information to the profileRegistry.xml or profileRegistry.xml.semaphore file. The file must be encoded as UTF-8.
<?xml version="1.0" encoding="UTF-8"?>
<profiles/>

As the installer, use operating system tools to change directory and file permissions.
(Linux) (HPUX) (Solaris) (AIX) The following example assumes that the installation root directory is /opt/IBM/WebSphere/AppServer:
chgrp profilers /opt/IBM/WebSphere/AppServer/logs/manageprofiles
chmod g+wr /opt/IBM/WebSphere/AppServer/logs/manageprofiles
chgrp profilers /opt/IBM/WebSphere/AppServer/properties
chmod g+wr /opt/IBM/WebSphere/AppServer/properties
chgrp profilers /opt/IBM/WebSphere/AppServer/properties/fsdb
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/fsdb
chgrp profilers /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml
chgrp profilers /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml.semaphore
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml.semaphore
chgrp -R profilers /opt/IBM/WebSphere/AppServer/profileTemplates

(HPUX) If we create a cell profile, additionally issue the following commands:
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profileTemplates/cell/default/documents
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profileTemplates/cell/dmgr/documents

(HPUX) If we create an application server profile, a deployment manager profile, or a custom profile, then additionally issue the following command:
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profileTemplates/profile_template_name/documents

where profile_template_name is default, dmgr, or managed.
(HPUX) The ownership of files is preserved when the files are copied to the profile directory during profile creation. You granted write permission to the profile directory so that files copied to the profile directory can be modified as part of the profile creation process. Files that are already in the profileTemplate directory structure prior to the start of profile creation are not modified during profile creation.

(Linux)
chgrp profilers /opt/IBM/WebSphere/AppServer/properties/Profiles.menu
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/Profiles.menu

(Windows) The following example assumes that the installation root directory is C:\IBM\WebSphere\AppServer. Follow instructions in the Windows documentation to give the profilers group read and write permission to the following directories and their files:
C:\IBM\WebSphere\AppServer\logs\manageprofiles
C:\IBM\WebSphere\AppServer\properties
C:\IBM\WebSphere\AppServer\properties\fsdb
C:\IBM\WebSphere\AppServer\properties\profileRegistry.xml
C:\IBM\WebSphere\AppServer\properties\profileRegistry.xml.semaphore

We might have to change the permissions on additional files if the non-root user encounters permission errors. If we authorize a non-root user to delete a profile, for example, the user might have to delete the following file:

(Linux) (HPUX) (Solaris) (AIX) app_server_root/properties/profileRegistry.xml_LOCK

(Windows) app_server_root\properties\profileRegistry.xml_LOCK

(Linux) (HPUX) (Solaris) (AIX) app_server_root/properties/profileRegistry.xml.semaphore_LOCK

(Windows) app_server_root\properties\profileRegistry.xml.semaphore_LOCK

Give write access to the non-root user for the file to authorize the user to delete the file. If the non-root user still cannot delete the profile, then the installer can delete the profile.

Make the configuration directory accessible to non-root users.
Perform one of the following actions:

Redirect pointers to the configuration directory to a location other than app_server_root/configuration.
Point to a directory that is writable by non-root users. For example, in app_server_root/bin/setupCmdLine.sh change
OSGI_CFG="-Dosgi.configuration.area=$WAS_HOME/configuration"

...to...
OSGI_CFG="-Dosgi.configuration.area=writable_directory/configuration"

Make the app_server_root/configuration directory writable by non-root users.

The installer created the profilers group and gave the group proper permissions to certain directories and files to create profiles.

These directories and files are the only ones in the installation root of the product to which a non-root user needs to write to create profiles.

What to do next

The non-root user that belongs to the profilers group can create profiles in a directory that the non-root user owns and to which the non-root user has write permission. However, the non-root user cannot create profiles in the installation root directory of the product.

A non-root user ID can manage multiple profiles. The same non-root user ID can manage an entire profile, whether it is the deployment manager profile, a profile containing 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 containing application servers and the node agent, or vice versa. However, typically, a root user or a non-root user can manage all profiles in a cell.

The non-root user can use the same tasks to manage a profile that the root user uses.