Installing DB2 Servers > Installing on Linux and UNIX > Installing as a non-root user >
Limitations of non-root installations
In addition to the differences between root installations
and non-root installations, there are several limitations on non-root
installations. This topic discusses the limitations to help you decide
if you want to use a non-root installation.
- Product limitations
- Some DB2® products are not
supported in non-root installations:
- Features and tools limitations
- The following features and tools are not available in non-root
installations:
- The DB2 Administration Server
(DAS) and its associated commands: dascrt, dasdrop,
daslist, dasmigr, and dasupdt
- The Configuration Assistant
- The Control Center
- The ability for the db2governor to increase priority is not supported
- In the Work Load Manager (WLM), attempts to set agent priority
in a DB2 service class in a
non-root DB2 instance are allowed.
However, the agent priority will not be respected, and no SQLCODE
error is returned.
- Automatic starting of non-root DB2 instances
at system reboot is not supported
- Health monitor limitations
- The following health monitor features are not supported in non-root
installations:
- Running script or task actions on alert occurrences
- Sending alert notifications
- Partitioned database limitation
- Only single-partition
databases are supported in non-root installations. You cannot add
additional database partitions.
- Listing DB2 products
- The output produced by the db2ls command, when
run as a non-root user, is different than the output produced when
run as a root user. For details, refer to the db2ls command
topic.
- DB2 copies
- Each non-root user can have only one copy of a DB2 product installed.
- DB2 instance limitation
- In non-root installations, one DB2 instance
is created during installation. Additional instances cannot be created.
- DB2 instance actions can
be performed only by the instance owner
- Root installations and non-root installations can coexist on the
same computer in different installation paths. However, a non-root
instance can be updated, or dropped (using the db2_deinstall command),
only by the non-root user who owns the non-root instance.
A DB2 instance created by a user with
root privilege can be updated or dropped only by a user with root
privilege.
- DB2 instance commands
- The following DB2 instance
commands are unavailable in non-root installations:
- db2icrt
- When installing a DB2 product
as a non-root user, a single instance is automatically created and
configured. Further instances cannot be created in non-root installations.
However, if the automatically created instance needs to be configured,
you can use the non-root install configuration command, db2nrcfg.
- db2iupdt
- The db2iupdt command cannot be used for non-root
instances. Instead, use the non-root install configuration command
(db2nrcfg) to update the non-root DB2 instance. However, updating the non-root
instance is normally not required because it gets updated automatically
when updating your DB2 product.
- db2idrop
- The instance that gets automatically created during non-root installations
cannot be dropped. The DB2 product
must be uninstalled to drop the DB2 instance.
- db2iupgrade
- Upgrading is not supported for non-root installations.
- Upgrading limitation
- Root instances cannot be upgraded to a non-root instance.
- Post-installation actions can be performed only by the DB2 instance owner
- Root
installations and non-root installations can coexist on the same computer.
However, only the original non-root user who installed the DB2 product can perform subsequent
actions such as:
- Applying fix packs
- Adding features
- Installing add-on products
- Adjusting ulimit values
- The ulimit command on UNIX® and Linux® sets
or reports user resource limits, such as data and stack limits. For
root instances, the database server dynamically updates required ulimit
settings without changing the permanent settings. However, for non-root
instances, the ulimit settings can only be checked during installation.
A warning message is displayed if the settings are inadequate. Root
authority is required to change the ulimit settings.
Limitations that can be overcome by running db2rfe
There
are further limitations on non-root installations which can be overcome
by running the db2rfe command. The following features
and abilities are initially unavailable in non-root installations:
- Operating system-based authentication
- High Availability (HA) feature
- The ability to reserve service names in the /etc/services file
- The ability to increase user data limits (ulimits). This ability
applies only to AIX®. On other
platforms, user data limits must be increased manually.
Run the Enable root features for non-root install command
(db2rfe) to enable these features and abilities.
Running the db2rfe command is optional, and must
be run by a user with root authority.
Authentication type in non-root installations
Operating
system-based authentication is the default authentication type for DB2 products. Since non-root installations
do not support operating system-based authentication, if you choose
not to run the db2rfe command after installing
your DB2 product as a non-root
user, then you must manually set the authentication type. You can
do so by updating the following parameters in the database manager
configuration (dbm cfg) file:
- clnt_pw_plugin (Client userid-password plug-in configuration parameter)
- group_plugin (Group plug-in configuration parameter)
- srvcon_pw_plugin (Userid-password plug-in for incoming connections
at the server configuration parameter)
[ Top of Page | Previous Page | Next Page | Contents ]