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. Read the documentation for your
operating system for information about how to create groups.
- Create a user named
user1
to create profiles.
Read the documentation for your operating system for information
on how to create users.
- 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:
-
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
-
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.
- 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
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
where
profile_template_name is
default
,
dmgr
,
or
managed
.
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
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
C:\Program Files\IBM\WebSphere\AppServer\properties\profileRegistry.xml.semaphore
You
might have to change the permissions on additional files if the non-root
user encounters permission errors. If you authorize a non-root user
to delete a profile, for example, the user might have to delete the
following file:
app_server_root/properties/profileRegistry.xml_LOCK
app_server_root/properties/profileRegistry.xml.semaphore_LOCK
app_server_root\properties\profileRegistry.xml_LOCK
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:
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.