The installer can grant write permission
of the appropriate files and directories to a non-root user. The non-root
user can then create and augment the profile. The installer can create a group
for users who are authorized to create and augment profiles, or the installer
can give individual users the authority to create and augment profiles. The
following example shows how to create a group that is authorized to create
and augment profiles.
Before you begin
This task assumes a basic familiarity with system commands.
About this task
newfeatThe steps that you follow to grant write
permission of files and directories to a non-root user for profile creation
and augmentation depends 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 you must complete the steps to create the required directories and files.
In most cases, a profile has been created previously.
newfeatThe installer
can perform the following steps to create the profilers group and give the
group appropriate permissions to create and augment a profile.
Procedure
- Log on as the installer
to the system where the product is installed.
- Create the profilers group
that you can use to create and augment profiles.
- Create a user named user1 to
create and augment profiles.
- Add the
installer and user1 to the profilers group.
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:
-
![[Windows]](../../windows.gif)
Create the
app_server_root\logs\
manageprofiles directory by following
instructions in the Windows documentation. For this example procedure the
directory is:
app_server_root\logs\manageprofiles
-
![[Windows]](../../windows.gif)
Create the
app_server_root\properties\fsdb
directory by following instructions in the Windows documentation. For this
example procedure the directory is:
app_server_root\properties\fsdb
- As
the installer, create the profileRegistry.xml file and add the appropriate
information, if no profile was previously created.
Follow
directions for your operating system to create the profileRegistry.xml file.
For this example, the file paths are:
app_server_root/properties/profileRegistry.xml
app_server_root\properties\profileRegistry.xml
Follow
instructions for your operating system to add the following information to
the profileRegistry.xml 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.
If you 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
![[HP-UX]](../../hpux.gif)
If
you 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
profile_template_name is
default,
dmgr,
or
managed, respectively.
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.
chgrp profilers /opt/IBM/WebSphere/AppServer/properties/Profiles.menu
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/Profiles.menu
![[Windows]](../../windows.gif)
The following example assumes that the installation root
directory is C:\Program Files\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:\Program Files\IBM\WebSphere\AppServer\logs\manageprofiles
C:\Program Files\IBM\WebSphere\AppServer\properties
C:\Program Files\IBM\WebSphere\AppServer\properties\fsdb
C:\Program Files\IBM\WebSphere\AppServer\properties\profileRegistry.xml
You
might have to change the permissions on additional files if the non-root user
encounters permission errors. For example, if you authorize a non-root user
to delete a profile, then the user might have to delete the following file:
app_server_root/properties/profileRegistry.xml_LOCK
app_server_root\properties\profileRegistry.xml_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.
Results
newfeatThe
installer created the profilers group and gave the group proper permissions
to certain directories and files to create and augment profiles. These directories
and files are the only ones in the installation root of WebSphere Application
Server to which a non-root user needs to write to create and augment profiles.
What to do next
newfeatThe
non-root user that belongs to the profilers group can create profiles, or
create and augment 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 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 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.