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.
Before you begin
This task assumes a basic familiarity with system commands.
About this task
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 you must 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.
Procedure
- Log on as the installer
to the system where the product is installed.
- Create
the profilers group that you can use to create profiles.
- Create
a user named user1 to create 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
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 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.