- Installing DB2 UDB Servers
- Prerequisites
- Before You Begin
- Installing DB2 UDB
- Installed Directory Structure
- Considerations in an NIS Environment
- Distributed Installation
- Sample Response Files
- Creating a Response File
- Distributed Installation with a Response File
- Installing DB2 with db2_install
- DB2 UDB Environment Definitions
- DB2 Profile Registry
- Managing the DB2 Profile Registry
- The db2set Command
- Environment Variables
- Hierarchy of the DB2 UDB Environment
- DB2 Administration Server (DAS)
- DAS Process
- DB2 Instances
- Creating the Sample Database
- Using the Command Line Processor (CLP)
- Uninstalling DB2 Products
- Stopping the DAS Instance
- Stopping All DB2 Instances
- Removing the DAS Instance
- Removing DB2 Instances
- Removing DB2 Products
Considerations in an NIS Environment
If your site is large, you may be using a name service such as NIS (Network Information Service) or NIS+. NIS and NIS+ are quite useful because they enable you to store user account information in a centralized manner instead of storing user account information in every system's /etc files.
Since DB2 UDB uses the standard Solaris APIs to get user and group information, it is able to use any source configured in the file /etc/nsswitch.conf. A particular site may have a locally developed module for managing user or group data, such as an LDAP implementation, and as long as it follows the conventions for name service switch modules and is configured correctly, it should work with DB2.
As already discussed, the installation program (db2setup) of DB2 UDB server can create the DB2 instance and DAS service, and user accounts are also created for the instance and service. However, if the user accounts are centralized on a machine other than the DB2 server machine using NIS or NIS+, the user account should be created at that NIS server. In fact, the db2setup installation program, if it detects NIS or NIS+ on your system, will not present the option to create users; instead, you will be prompted to choose existing users.
There are some performance issues to consider if you choose to keep user and group information in a network source, such as NIS or NIS+. Since DB2 UDB performs authentication based on UNIX user and group information, if that information is not local to the machine running the DB2 instance, every authentication action will generate network traffic. This can be particularly problematic for group information. For example, DB2 UDB occasionally requests the list of all groups that a certain user is a member of, and the only portable way to obtain that list is to ask for the list of all members of all groups and then sort through them inside the DB2 server code. If the group information is remote, this will create network traffic and increase the length of time the authentication activity takes.