The administrator ID and password must be the same on all IBM® Content
Analytics with Enterprise Search servers.
When you run the installation program, you can specify an existing
user ID and password to use for the administrator ID or allow the
installation program to create the user ID and password. If the installation
program creates the user ID, it assigns all required user rights.
Non-root users
If
you run the installation program as a non-root user, the program uses
that user ID as the administrator ID. You cannot change this value
and you cannot select the option to have the program create the administrator
ID for you.
If you want the installation program to create the
administrator ID for you, log in as the root user and select the option
to create the user ID.
Restriction: If you want to
install the product in a multiple server configuration, you must log
in as the root user. Use this same user ID when you install additional
servers to ensure that the administrator ID is the same on all servers.
Root and non-root user IDs cannot co-exist in the same system.
If
you use
WebSphere® Application
Server as the
application server,
WebSphere Application
Server and IBM HTTP Server must be installed
as the
IBM Content
Analytics with Enterprise Search administrative
user. The following product limitations occur when you install
IBM Content
Analytics with Enterprise Search as a non-root user:
When you install the product as a non-root user,
you do not need to restart the computer after the installation program
completes. The First Steps program automatically starts after the
installation program ends.
Special character restrictions
Ensure that
the administrator ID and password conform to the following requirements.
- User IDs
- If you use an existing user ID for the administrator
ID, and an ID that is not a Windows domain
ID, ensure that the ID contains only letters, digits, and underscore
characters. The user ID cannot contain other special characters and
the user ID must begin with a letter. The user ID cannot contain characters
from the double byte character set (DBCS). Only ASCII characters are
supported.
- Passwords
- You can use the following special characters in passwords:
! @ # $ % ^ & * () - _ = + , . / < > ?
Windows domain IDs
If
you want to use a Windows domain
user account for the administrative user, you must create the domain
ID in advance. When you install the product, you specify this existing
user ID for the administrator ID. Specify the domain ID in the following
format:
user_name@fully_qualified_domain_name
You must ensure that the ID is not a Windows domain ID that uses a roaming profile.
There is a difference between a local user ID that belongs to a Windows domain and a domain
ID:
- Local ID
- With a local user ID, the user's local profile is stored on the
local computer. Any changes made to the local user profile are specific
to the computer on which the changes are made. This is the only type
of user ID that can be used as the administrator ID.
- Domain ID
- With a domain ID, a copy of the user's local profile is stored
on a shared server. This profile, which is known as a roaming user
profile, is downloaded whenever the user logs on to any computer on
the network. Changes made to the profile are synchronized with the
server copy when the user logs off. To use this type of profile, the
computer must belong to a Windows domain
or Active Directory. The administrator ID cannot be this type of user
ID.
To obtain domain privileges for an ID, you can add the local
user ID that you use for the administrator ID to a domain. If you
add the local user ID to a domain, however, you must ensure that the
domain security rights do not override the local user rights that
are required by IBM Content
Analytics with Enterprise Search.
Existing domain policies
If you install
the product on Windows,
and you specify an existing user ID for the administrator ID, any
domain policies that are in effect will be honored and will not be
changed by the installation program. For example, the installation
program will attempt to grant the user ID the authority to act as
part of the operating system. If a domain policy denies that right,
then the user ID will not have the required authority. Ensure that
the domain policies do not deny the following user rights, which are
required for administering the system:
- Act as part of the operating system
- Lock pages in memory
- Create a token object
- Replace a process level token
- Impersonate a client after authentication
- Increase quotas (In Windows 2003,
this option is labeled Adjust memory quotas for a process.)
- Log on as a service
If an attempt to install the product fails because these
user rights are not correctly assigned, you must remove the software,
assign the correct user rights to the user ID that you use to install
the product, and run the installation program again.
Directory permissions
The administrator
ID must have read and execute permissions for the parent directories
of the installation and data directories. For example, if the installation
directory (ES_INSTALL_ROOT) is the /opt/IBM/es directory,
then the administrator ID must have read and execute permissions
for the /opt and /opt/IBM directories.