1.2. Configuration Decisions
During Directory Server installation, you are prompted for basic configuration information. Decide how you are going to configure these basic parameters before you begin the installation process. You are prompted for some or all of following information, depending on the type of installation that you decide to perform:
Port number; refer to Section 1.2.1 Choosing Unique Port Numbers.
Server root; refer to Section 1.2.2 Creating a New Server Root.
Which users and groups you want to run Directory Server as; refer to Section 1.2.3 Deciding the User and Group for Your Servers.
Your directory suffix; refer to Section 1.2.5 Determining Your Directory Suffix.
Several different user IDs and passwords for authentication; refer to Section 1.2.4 Defining Authentication Entities.
The location of the configuration and user directory servers; refer to Section 1.2.6 Determining the Location of the Configuration Directory and Section 1.2.7 Determining the Location of the User Directory.
The administration domain; see Section 1.2.8 Determining the Administration Domain.
1.2.1. Choosing Unique Port Numbers
Port numbers can be any number from 1 to 65535. Keep the following in mind when choosing a port number for your Directory Server:
The standard Directory Server (LDAP) port number is 389.
Port 636 is reserved for secure LDAP (LDAPS). You can also use LDAP over TLS on the standard LDAP port.
For information on how to set up LDAP over SSL (LDAPS) for Directory Server, see the Red Hat Directory Server Administration Guide.
Port numbers between 1 and 1024 have been assigned to various services by the Internet Assigned Numbers Authority. Do not use port numbers below 1024 other than 389 or 636 for directory services as they will conflict with other services.
Directory Server must be run as root if it will listen on either port 389 or 636.
Make sure the ports you choose are not already in use. Additionally, if you are using both LDAP and LDAPS communications, make sure the port numbers chosen for these two types of access are not identical.
You should use the default directory ports (389 and 636) for the user directory. If your configuration directory is managed by a server instance dedicated to that purpose, you should use some non-standard port for the configuration directory.
1.2.2. Creating a New Server Root
Your server root is the directory where you install your Directory Server. The default server root for Directory Server on Linux is /opt/redhat-ds/; on other UNIX servers the directory is /opt/redhat-ds/servers/.
The server root must meet the following requirements:
The server root must be a directory on a local disk drive; you cannot use a networked drive for installation purposes. The file sharing protocols such as AFS, NFS, and SMB do not provide file locking and performance suitable for use by the Directory Server. The server database index files may be damaged if they are not held on a local filesystem.
The directory must not already exist or must be empty.
When using tarballs, the server root directory must not be the same as the directory from which you are running the setup program.
By default, the server root directory is /opt/redhat-ds/servers.
1.2.3. Deciding the User and Group for Your Servers
For security reasons, it is always best to run production servers with normal user privileges. That is, you do not want to run Directory Server with root privileges. However, you will have to run Directory Server with root privileges if you are using the default Directory Server ports. If Directory Server is to be started by Administration Server, Administration Server must run either as root or as the same user as Directory Server.
You must therefore decide which user accounts you will use for the following purposes:
The user and group under which you will run Directory Server.
Note If you will not be running the Directory Server as root, it is strongly recommended that you create a user account for all directory services. You should not use any existing operating system account and must not use the nobody account. Also, you should create a common group for the directory server files; again, you must not use the nobody group.
The user and group under which you will run Administration Server.
For installations that use the default port numbers, this must be root. However, if you use ports over 1024, then you should create a user account for all directory services and run Administration Server as this account.
As a security precaution, when Administration Server is being run as root, it should be shut down when it is not in use.
| Note |
|---|---|
On Linux, the group names must not contain spaces. |
You should use a common group for all directory services, such as gid DirectoryServer, to ensure that files can be shared between servers when necessary, and this GID should be the same across all servers that will be running Directory Server since the Directory Server uses this GID to check permissions. Also the UID of the users as whom the Directory Server will run should be the same on all systems.
Before you can install Directory Server and Administration Server, you must make sure that the user and group accounts you will use exist on your system.
1.2.4. Defining Authentication Entities
As you install Directory Server and Administration Server, you will be asked for various user names, distinguished names (DN), and passwords. This list of login and bind entities will differ depending on the type of installation that you are performing:
- Directory Manager DN and password.
The Directory Manager DN is the special directory entry to which access control does not apply. Think of the directory manager as your directory's superuser. (In former releases of Directory Server, the Directory Manager DN was known as the root DN).
The default Directory Manager DN is cn=Directory Manager. Because the Directory Manager DN is a special entry, the Directory Manager DN does not have to conform to any suffix configured for your Directory Server. Therefore, you must not manually create an actual Directory Server entry that has the same DN as the Directory Manager DN.
The Directory Manager password must be at least 8 characters long and is limited to ASCII letters, digits, and symbols.
- Configuration Directory Administrator ID and password.
The configuration directory administrator is the person responsible for managing all directory services accessible through Red Hat Console. If you log in with this user ID, then you can administer any Directory Server that you can see in the server topology area of Red Hat Console.
For security, the configuration directory administrator should not be the same as Directory Manager. The default configuration directory administrator ID is admin.
- Administration Server user and password.
You are prompted for this only during custom installations. The Administration Server user is the special user that has all privileges for the local Administration Server. Authentication as this person allows you to administer all the servers stored in the local server root.
The Administration Server user ID and password are used only when the Directory Server is down and you are unable to log in as the configuration directory administrator. The existence of this user ID means that you can access Administration Server and perform disaster recovery activities such as starting Directory Server, reading log files, and so forth. Normally, Administration Server user and password should be identical to the configuration directory administrator ID and password.
1.2.5. Determining Your Directory Suffix
A directory suffix is the directory entry that represents the first entry in a directory tree. You will need at least one directory suffix for the tree that will contain your enterprise's data. It is common practice to select a directory suffix that corresponds to the DNS host name used by your enterprise. For example, if your organization uses the DNS name example.com, then select a suffix of dc=example,dc=com.
For more information on planning the suffixes for your directory service, see the Red Hat Directory Server Deployment Guide.
1.2.6. Determining the Location of the Configuration Directory
The directory instance that stores the configuration information, such as port numbers, is called the configuration directory. The configuration information is stored in the o=NetscapeRoot tree, which is used by other Directory Server instances. A single instance of Directory Server can be both the configuration directory and the user directory, but it is recommended that you have a separate instance specifically for this configuration directory. The configuration directory can run on the same computer that hosts the user directory, but, for best performance, it should be located on a separate machine.
If you are installing Directory Server only to support other server applications, then that Directory Server is your configuration directory. If you are installing Directory Server to use as part of a general directory service, then you will have multiple Directory Servers installed in your enterprise, and you must decide which one will host the configuration directory tree, o=NetscapeRoot. You must make this decision before you install any compatible server applications, including Directory Server.
For ease of upgrades, you should use a Directory Server instance that is dedicated to supporting the o=NetscapeRoot tree; this server instance should perform no other function with regard to managing your enterprise's directory data. Also, do not use port 389 for this server instance because doing so could prevent you from installing a Directory Server on that host that can be used for management of your enterprise's directory data.
Because the configuration directory normally experiences very little traffic, you can allow its server instance to coexist on a machine with another more heavily loaded Directory Server instance. However, for very large sites that are installing a large number of server instances, you may want to dedicate a low-end machine to the configuration directory so as not to hurt the performance of your other production servers. Directory Server installations result in write activities to the configuration directory. For large enough sites, this write activity could result in a short-term performance hit to your other directory activities.
Also, as with any directory installation, consider replicating the configuration directory to increase availability and reliability. See the Red Hat Directory Server Deployment Guide for information on using replication and DNS round-robins to increase directory availability.
 | Caution |
|---|---|
Corrupting the configuration directory tree can result in the necessity of reinstalling all other Directory Servers that are registered in that configuration directory. Remember the following guidelines when dealing with the configuration directory:
|
1.2.7. Determining the Location of the User Directory
Just as the configuration directory is the Directory Server that is used for server administration, the user directory is the Directory Server that contains the entries for users and groups in your enterprise.
For most directory installations, the user directory and the configuration directory should be two separate server instances. These server instances can be installed on the same machine, but, for best results, you should consider placing the configuration directory on a separate machine.
Between your user directory and your configuration directory, it is your user directory that will receive the overwhelming percentage of the directory traffic. For this reason, you should give the user directory the greatest computing resources. Because the configuration directory should receive very little traffic, it can be installed on a machine with very low-end resources.
You cannot install a user directory until you have installed a configuration directory somewhere on your network.
1.2.8. Determining the Administration Domain
The administration domain allows you to group servers together logically so that you can more easily distribute server administrative tasks. A common scenario is for two divisions in a company to each want control of their individual servers. However, you may still want some centralized control of all the servers in your enterprise. Administration domains allow you to meet these conflicting goals.
Administration domains have the following qualities:
All servers share the same configuration directory, regardless of the domain to which they belong.
Servers in two different domains may use two different user directories for authentication and user management.
The configuration directory administrator has complete access to all installed Directory Servers, regardless of the domain to which they belong.
Each administration domain can be configured with an administration domain owner. This owner has complete access to all the servers in the domain but does not have access to the servers in any other administration domain.
The administration domain owner can grant individual users administrative access on a server by server basis within the domain.
For many installations, you can have just one administration domain. In this case, choose a name that is representative of your organization. For other installations, you may want different domains because of the demands at your site. In the latter case, try to name your administration domains after the organizations that will control the servers in that domain.
For example, if you are an ISP and you have three customers for whom you are installing and managing Directory Server instances, create three administration domains each named after a different customer.