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
The
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.
The
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.
Read the documentation for your
operating system for information about how to create groups.
- Create
a user named user1 to create and augment 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:
![[AIX]](../../aixlogo.gif)
Create the
app_server_root/logs/
manageprofiles directory:
mkdir app_server_root/logs/manageprofiles
![[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 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
The
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.