Operating System Tuning For Directory Server

Default system settings do not necessarily result in top directory service performance. This section addresses how to tune the operating system for top performance.

• Operating System Version and Patch Support

• Basic Security Checks

• Accurate System Clock Time

• Restart When System Reboots

• System-Specific Tuning With The idsktune Command

Operating System Version and Patch Support

See Oracle Directory Server Enterprise Edition Release Notes for an updated list of supported operating systems.

You want to maintain overall system security. You also want to ensure proper Directory Server operation. You therefore install the latest recommended system patches, service packs, or fixes. See Oracle Directory Server Enterprise Edition Release Notes for an updated list of the latest patches to apply for your platform.

Basic Security Checks

The recommendations in this section do not eliminate all risk. Instead, the recommendations are intended as a short checklist to help you limit typical security risks.

• Isolate and firewall the system. If at all possible, isolate the system where Directory Server runs from the public Internet with a network firewall.

• Do not allow dual boot. Do not run other operating systems on the system that runs a production Directory Server. Other systems can permit access to files, which you should not allow.

• Use strong passwords. Use a root password at least eight characters long. The password should include punctuation or other non-alphabetic characters.

  You can use the Strong Password Check server plug-in to refuse weak passwords. The dsconf server property pwd-strong-check-enabled can be used to turn the plug-in on.

  If you choose to use longer operating system passwords, you might have to configure the way passwords are handled by the system. See your operating system documentation for instructions.

• Use a safe user and group ID for the server. For security reasons, do not run Directory Server with super user privileges.

  You can, for example, use the UNIX commands groupadd and useradd to create a user and group without login privileges. You can then run the server as this user and group.

  For example, to add a group that is named servers, do the following.

  # groupadd servers

  To add a user named server1 as a member of the group servers, use the following command.

  # useradd -g servers -s /bin/false -c "server1"

  A particular deployment can call for sharing Directory Server files with other servers, such as a messaging server. In such a deployment, consider running the servers with the same user, group ID.

• Use the core facility. To facilitate debugging, you can allow processes running with this user, group ID to dump core. Use a utility such as the Solaris command coreadm. For example, you can enable Directory Server to generate core files by allowing setuid processes to do so, and updating the coreadm configuration:

  # coreadm -e proc-setid
  # coreadm -u

  When scripting server startup, you can add the following line to your startup script. The line allows Directory Server to generate core files of the form core.ns-slapd.pid, where pid is the process ID.

  coreadm -p core.%f.%p $$

• Disable unnecessary services. For top performance with less risk, dedicate the system to Directory Server. As explained elsewhere in this guide, do not run Directory Service Control Center on the same system. When you run additional services, especially network services, you negatively affect server performance and scalability. You can also thereby increase security risks.

  Disable as many network services as possible. Directory Server does not require file sharing and other services. Disable services such as IP Routing, Mail, NetBIOS, NFS, RAS, Web Publishing, and Windows Network Client services. Consider disabling telnet, and ftp.

  As with many network services, telnet and ftp pose security risks. These two services are particularly dangerous, because the commands transmit user passwords in clear text over the network. Work around the need for telnet and ftp by using clients such as Secure Shell, ssh, and Secure FTP, sftp, instead. See your operating system documentation for details on disabling network services.

  If the Directory Server instance does not provide the naming service for the network, consider enabling a naming service for the system. Directory Server then uses the naming service for example when resolving ACIs.

Accurate System Clock Time

Ensure the system clock is reasonably in sync with other systems. Good clock synchronization facilitates replication. Good synchronization also facilitates correlation of date and time stamps in log files between systems. Consider using a Network Time Protocol, NTP, client to set the correct system time.

Restart When System Reboots

You can enable a server instance to restart at system boot time by using the dsadm command. For example, use the dsadm enable-service command on Solaris 10 and Windows systems. On other systems, use the dsadm autostart command. If you did not install from native packages, refer to your operating system documentation for help ensuring the server starts at system boot time.

When possible, stop Directory Server with the dsadm command, or from DSCC. If the Directory Server is stopped abruptly during system shutdown, there is no way to guarantee that all data has been written to disk correctly. When Directory Server restarts, it must therefore verify the database integrity. This process can take some time.

Furthermore, consider using a logging option with your file system. File system logging generally both improves write performance, and also decreases the time required to perform a file system check. The system must check the file system when the file system is not cleanly unmounted during a crash. Also, consider using RAID for storage.

System-Specific Tuning With The idsktune Command

The idsktune(1M) utility that is provided with the product can help you diagnose basic system configuration shortcomings. The utility offers recommendations for tuning the system to support high performance directory services. The utility does not actually implement any of the recommendations. The recommendations should be implemented by a qualified system administrator.

When you run the utility as root, idsktune gathers information about the system. The utility displays notices, warnings, and errors with recommended corrective actions. The idsktune command checks the following.

• Operating system and kernel versions are supported for this release.

• Available memory, and available disk space meet minimum requirements for typical use.

• System resource limits meet minimum requirements for typical use.

• Required patches are installed.

Individual deployment requirements can exceed minimum requirements. You can provide more resources than the resources identified as minimum system requirements by the idsktune utility.

Consider local network conditions and other applications before implementing specific recommendations. Refer to the operating system documentation for additional tips on tuning network settings.

File Descriptor Settings

Directory Server uses file descriptors when handling concurrent client connections. A low maximum number of file descriptors that are available for the server process can thus limit the number of concurrent connections. Recommendations that concern the number of file descriptors therefore relate to the number of concurrent connections Directory Server can handle.

On Solaris systems, the number of file descriptors available is configured through the rlim_fd_max parameter. Refer to the operating system documentation for further instructions on modifying the number of available file descriptors.

Transmission Control Protocol (TCP) Settings

Specific network settings depend on the platform. On some systems, you can enhance Directory Server performance by modifying TCP settings.

This section discusses the reasoning behind idsktune recommendations that concern TCP settings, and provides a method for tuning these settings on Solaris 10 systems.

Inactive Connections

Some systems allow you to configure the interval between transmission of keepalive packets. This setting can determine how long a TCP connection is maintained while inactive and potentially disconnected. When set too high, the keepalive interval can cause the system to use unnecessary resources to keep connections for clients that have become disconnected. For most deployments, set this parameter to a value of 600 seconds. This value, which is 600,000 milliseconds, or 10 minutes, allows more concurrent connections to Directory Server.

When set too low, however, the keepalive interval can cause the system to drop connections during transient network outages.

On Solaris systems, this time interval is configured through the tcp_keepalive_interval parameter.

Outgoing Connections

Some systems allow you to configure how long a system waits for an outgoing connection to be established. When set too high, establishing outgoing connections to destination servers such as replicas not responding quickly can cause long delays. For Intranet deployments on fast, reliable networks, you can set this parameter to a value of 10 seconds to improve performance. Do not, however, use such a low value on networks with slow, unreliable, or WAN connections, however.

On Solaris systems, this time interval is configured through the tcp_ip_abort_cinterval parameter.

Retransmission Timeout

Some systems allow you to configure the initial time interval between retransmission of packets. This setting affects the wait before retransmission of an unacknowledged packet. When set too high, clients can be kept waiting on lost packets. For Intranet deployments on fast, reliable networks, you can set this parameter to a value of 500 milliseconds to improve performance. Do not, however, use such a low value on networks with round trip times of more than 250 milliseconds.

On Solaris systems, this time interval is configured through the tcp_rexmit_interval_initial parameter.

Sequence Numbers

Some systems allow you to configure how the system handles initial sequence number generation. For extranet and Internet deployments, set this parameter so initial sequence number generation is based on RFC 1948 to prevent sequence number attacks. In such environments, other TCP tuning settings mentioned here are not useful.

On Solaris systems, this behavior is configured through the tcp_strong_iss parameter.

Tuning TCP Settings on Solaris 10 Systems

On Solaris 10 systems, the simplest way to tune TCP settings is to create a simple SMF service as follows:

• Create an SMF profile for Directory Server tuning.

• Edit the following xml file according to your environment and save the file as /var/svc/manifest/site/ndd-nettune.xml.

  <?xml version="1.0"?>
  <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/ service_bundle.dtd.1">
  <!--
      ident    "@(#)ndd-nettune.xml    1.0    04/09/21 SMI"
  -->
  
  <service_bundle type='manifest' name='SUNWcsr:ndd'>
  
  <service
      name='network/ndd-nettune'
      type='service'
      version='1'>
  
              <create_default_instance enabled='true' />
  
              <single_instance />
  
          <dependency
          name='fs-minimal'
          type='service'
          grouping='require_all'
          restart_on='none'>
              <service_fmri value='svc:/system/filesystem/minimal' />
          </dependency>
  
          <dependency
          name='loopback-network'
          grouping='require_any'
          restart_on='none'
          type='service'>
              <service_fmri value='svc:/network/loopback' />
          </dependency>
  
          <dependency
          name='physical-network'
          grouping='optional_all'
          restart_on='none'
          type='service'>
              <service_fmri value='svc:/network/physical' />
          </dependency>
  
          <exec_method
          type='method'
          name='start'
          exec='/lib/svc/method/ndd-nettune'
          timeout_seconds='3' />
          </exec_method>
  
          <exec_method
                 type='method'
                 name='stop'
                 exec=':true'
                 timeout_seconds='3' >
          </exec_method>
  
          <property_group name='startd' type='framework'>
              <propval name='duration' type='astring'  value='transient' />
          </property_group>
  
          <stability value='Unstable' />
  
          <template>
              <common_name>
                  <loctext xml:lang='C'>
                      ndd network tuning
                  </loctext>
              </common_name>
              <documentation>
                  <manpage title='ndd' section='1M'
                  manpath='/usr/share/man' />
              </documentation>
          </template>
  
  </service>
  
  </service_bundle>

• Before you import the ndd-nettune.xml configuration, verify that the syntax is correct. You can do this by running the following command:

  $ svccfg validate /var/svc/manifest/site/ndd-nettune.xml

• Import the configuration by running the following command:

  $ svccfg import /var/svc/manifest/site/ndd-nettune.xml

  For more information see the svccfg(1M) man page.

• Copy the following shell script into /lib/svc/method/ndd-nettune.

  #!/sbin/sh
  #
  # ident   "@(#)ndd-nettune.xml    1.0     01/08/06 SMI"
  
  . /lib/svc/share/smf_include.sh
  . /lib/svc/share/net_include.sh
  
  # Make sure that the libraries essential to this stage of booting  can be found.
  LD_LIBRARY_PATH=/lib; export LD_LIBRARY_PATH
  echo "Performing Directory Server Tuning..." >> /tmp/smf.out
  /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024
  /usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 600000
  /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 10000
  /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000
  
  
  # Reset the library path now that we are past the critical stage
  unset LD_LIBRARY_PATH

• Run svcadm to enable nettune (for more information, see the svcadm(1M) man page).

• Run svcs -x (for more information see the svcs(1) man page).