Saturday, 12 November 2011

configure a slave replica


Creating the Supplier Bind DN Entry

A critical part of setting up replication is to create the entry, called the replication manager or supplier bind DN entry, that the suppliers use to bind to the consumer servers to perform replication updates.
The supplier bind DN must meet the following criteria:
  • It must be unique.
  • It must be created on the consumer server (or hub) and not on the supplier server.
  • It must correspond to an actual entry on the consumer server.
  • It must be created on every server that receives updates from another server.
  • It must not be part of the replicated database for security reasons.
  • It must be defined in the replication agreement on the supplier server.
For example, the entry cn=Replication Manager,cn=config can be created under the cn=config tree on the consumer server. This would be the supplier bind DN that all supplier servers would use to bind to the consumer to perform replication operations.

NOTE

Avoid creating simple entries under the cn=config entry in the dse.ldif file. The cn=cn=config entry in the simple, flat dse.ldif configuration file is not stored in the same highly scalable database as regular entries. As a result, if many entries, and particularly entries that are likely to be updated frequently, are stored under cn=config, performance will suffer. However, although Red Hat recommends not storing simple user entries under cn=config for performance reasons, it can be useful to store special user entries such as the Directory Manager entry or replication manager (supplier bind DN) entry undercn=config since this centralizes configuration information.
On each server that acts as a consumer in replication agreements, create a special entry that the supplier will use to bind to the consumers. Make sure to create the entry with the attributes required by the authentication method specified in the replication agreement.
  1. Stop the Directory Server. If the server is not stopped, the changes to the dse.ldif file will not be saved. SeeSection 1.3, “Starting and Stopping Servers” for more information on stopping the server.
  2. Create a new entry, such as cn=replication manager,cn=config, in the dse.ldif file.
  3. Specify a userPassword attribute-value pair.
  4. If password expiration policy is enabled or ever will be enabled, disable it on the replication manager entry to prevent replication from failing due to passwords expiring. To disable the password expiration policy on theuserPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.
  5. Restart the Directory Server. See Section 1.3, “Starting and Stopping Servers” for more information on starting the server.
The final entry should resemble this example:

dn: cn=replication manager,cn=config 
objectClass: inetorgperson 
objectClass: person 
objectClass: top 
cn: replication manager 
sn: RM 
userPassword: password 
passwordExpirationTime: 20380119031407Z
When configuring a replica as a consumer, use the DN of this entry to define the supplier bind DN.


Configuring Single-Master Replication

To set up single-master replication such as the configuration shown in Figure 8.1, “Single-Master Replication”, between supplier server A, which holds a read-write replica, and the two consumers server B and server C, which each hold a read-only replica, there are two major steps:

Configuring the Read-Write Replica on the Supplier Server

  1. Specify the supplier settings for the server.
    1. In the Directory Server Console, select the Configuration tab.
    2. In the navigation tree, select the Replication folder.
    3. In the right-hand side of the window, select the Supplier Settings tab.

    4. Check the Enable Changelog checkbox.
      This activates all of the fields in the pane below that were previously grayed out.
    5. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector.
    6. Set the changelog parameters for the number and age of the log files.
      Clear the unlimited checkboxes to specify different values.
    7. Click Save.
  2. Specify the replication settings required for a read-write replica.
    1. In the navigation tree on the Configuration tab, expand the Replication node, and highlight the database to replicate.
      The Replica Settings tab opens in the right-hand side of the window.
    2. Check the Enable Replica checkbox.
    3. In the Replica Role section, select the Single Master radio button.
    4. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive.
      The replica ID must be unique for a given suffix, different from any other ID used for read-write replicas on this server and on other servers.
    5. In the Common Settings section, specify a purge delay in the Purge delay field.
      The purge delay is how often the state information stored in the replicated entries is deleted.
    6. Click Save.

Configuring the Read-Only Replica on the Consumer

  1. Create the database for the read-only replica if it does not exist. See Section 3.1.1, “Creating Suffixes” for instructions on creating suffixes.
  2.  Create the entry for the supplier bind DN on the consumer server if it does not exist. The supplier bind DN is the special entry that the supplier will use to bind to the consumer. This is described in Section 8.3, “Creating the Supplier Bind DN Entry”.
  3. Specify the replication settings required for a read-only replica.
    1. In the Directory Server Console, select the Configuration tab.
    2. In the navigation tree, expand the Replication folder, and highlight the replica database.
      The Replica Settings tab for that database opens in the right-hand side of the window.
    3. Check the Enable Replica checkbox.
    4. In the Replica Role section, select the Dedicated Consumer radio button.
    5. In the Common Settings section, specify a purge delay in the Purge delay field.
      This option indicates how often the state information stored in the replicated entries is purged.
    6. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica. Enter the supplier bind DN in the Enter a new Supplier DN field, and click Add. The supplier bind DN appears in the Current Supplier DNs list.
      The supplier bind DN should be the entry created in step 2. The supplier bind DN is a privileged user because it is not subject to access control.

      NOTE

      There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement.
    7. Specify the URL for any supplier servers to which to refer updates.
      By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
      Automatic referrals assume that clients bind over a regular connection; this has a URL in the formldap://hostname:port. For clients to bind to the supplier using SSL, use this field to specify a referral of the form ldaps://hostname:port, where the s in ldaps indicates a secure connection.
  4. Click Save.
Repeat these steps for every consumer server in the replication configuration.

8.4.3. Create the Replication Agreement

Create one replication agreement for each read-only replica. For example, in the scenario illustrated in Figure 8.1, “Single-Master Replication”, server A has two replication agreements, one for server B and one for server C.
  1. In the navigation tree of the Configuration tab, right-click the database to replicate, and selectNew Replication Agreement.
    Alternatively, highlight the database, and select New Replication Agreement from the Object menu to start theReplication Agreement Wizard.
  2. In the first screen, fill in a name and description for the replication agreement, and hit Next.
  3. In the Source and Destination screen, fill in the URL for the consumer and the supplier bind DN and password on that consumer. If the target server is not available, hit in other to fill in the information manually.
    • Unless there is more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu.
    • The port listed is the non-SSL port, even if the Directory Server instance is configured to run over SSL. This port number is used only for identification of the Directory Server instance in the Console; it does not specify the actual port number or protocol that is used for replication.
    • If SSL is enabled on the servers, it is possible to select the Using encrypted SSL connection radio button for SSL client authentication. Otherwise, fill in the supplier bind DN and password.

      NOTE

      If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated.
    Hit Next.
  4. Fractional replication controls which entry attributes are replicated between servers. By default, all attributes are replicated. To select attributes that will not be replicated to the consumer, check the Enable Fractional Replicationcheckbox. Then, highlight the attribute (or attributes) in the Included column on the right, and click Remove. All attributes that will not be replicated are listed in the Excluded column on the left, as well as in the summary the replication agreement is complete.

    NOTE

    To safeguard against potential integrity problems, the consumer in fractional replication must be a dedicated consumer, not a multi-master supplier or hub. This is not enforced at the time the replication agreement is made, but replication will fail if the consumer is not a read-only replica.
  5. Set the schedule for when replication runs. By default, replication runs continually.
    Hit Next.
  6. Set when the consumer is initialized. Initializing a consumer manually copies all data over from the supplier to the consumer. The default is to create an initialization file (an LDIF of all supplier data) so that the consumer can be initialized later. It is also possible to initialize the consumer as soon as the replication agreement is completed or not at all. For information on initializing consumers, see Section 8.10, “Initializing Consumers”.

    NOTE

    Replication will not begin until the consumer is initialized.
    Hit Next.
  7. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. HitDone to save the agreement.

Wednesday, 9 November 2011

Configure a system to authenticate using LDAP

system-config-authentication

install CA-signed server certificate

You will need to do the following so that the server starts without prompting for a password


#vim /etc/dirsrv/slapd-ds1/pin.txt
Internal (Software) Token:PASSWORD

#chmod 400 /etc/dirsrv/slapd-ds1/pin.txt

#chown nobody:nobody  /etc/dirsrv/slapd-ds1/pin.txt

for the admin server do the following

#vim /etc/dirsrv/admin-serv/password.conf
internal:PASSWORD

#chmod 400 /etc/dirsrv/admin-srv/password.conf

#chown nobody:nobody  /etc/dirsrv/admin-serv/password.conf

#vim /etc/dirsrv/admin-serv/nss.conf
NNSPassPhraseDialog file://///etc/dirsrv/admin-serv/password.conf

Install the Certificate

  1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
  2. Select the Server Certs tab, and click Install.
  3. Give the certificate location or paste the certificate text in the text box, then click Next.

    • In this file. Enter the absolute path to the certificate in this field.
    • In the following encoded text block. Copy the text from the CA's email or from the created text file, and paste it in this field.
  4. Check that the certificate information displayed is correct, and click Next.
  5. Give a name to the certificate, and click Next.
  6. Provide the password that protects the private key. This password is the same as the one provided in step 5 inSection 11.2.1, “Step 1: Generate a Certificate Request”.
After installing the server certificate, configure the Directory Server to trust the CA which issued the server's certificate.

Trust the Certificate Authority

Configuring the Directory Server to trust the certificate authority consists of obtaining the CA's certificate and installing it into the server's certificate database. This process differs depending on the certificate authority. Some commercial CAs provide a web site that allow users to automatically download the certificate. Others will email it back to users.
After receiving the CA certificate, use the Certificate Install Wizard to configure the Directory Server to trust the certificate authority.
  1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
  2. Go to the CA Certs tab, and click Install.
  3. If the CA's certificate is saved to a file, enter the path in the field provided. Alternatively, copy and paste the certificate, including the headers, into the text box. Click Next.
  4. Check that the certificate information that opens is correct, and click Next.
  5. Name the certificate, and click Next.
  6. Select the purpose of trusting this certificate authority; it is possible to select both options:
    • Accepting connections from clients (Client Authentication). The server checks that the client's certificate has been issued by a trusted certificate authority.
    • Accepting connections to other servers (Server Authentication). This server checks that the directory to which it is making a connection (for replication updates, for example) has a certificate that has been issued by a trusted certificate authority.
  7. Click Done.
Once both the server and CA certificates are installed, it is possible to configure the Directory Server to run in TLS/SSL. However, Red Hat recommends verify ingthat the certificates have been installed correctly.

Confirm That The New Certificates Are Installed

  1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
  2. Select the Server Certs tab.
    A list of all the installed certificates for the server opens.
  3. Scroll through the list. The certificates installed previously should be listed.
It is now possible to set up the Directory Server to run in TLS/SSL

request a certificate from a certificate authority (CA)


 Generate a Certificate Request

Generate a certificate request, and send it to a CA. The Directory Server Console has a tool, theCertificate Request Wizard, which generates a valid certificate request to submit to any certificate authority (CA).
  1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
  2. Select the Server Certs tab, and click the Request button. This opens the Certificate Request Wizard.
  3. Click Next.
  4. Enter the Requester Information in the blank text fields, then click Next.
    • Server Name. Enter the fully qualified hostname of the Directory Server as it is used in DNS and reverse DNS lookups; for example, dir.example.com. The server name is critical for client-side validation to work, which prevents man-in-the-middle attacks.
    • Organization. Enter the legal name of the company or institution. Most CAs require this information to be verified with legal documents such as a copy of a business license.
    • Organizational Unit. Optional. Enter a descriptive name for the organization within the company.
    • Locality. Optional. Enter the company's city name.
    • State or Province. Enter the full name of the company's state or province (no abbreviations).
    • Country. Select the two-character abbreviation for the country's name (ISO format). The country code for the United States is US.
  5.  Enter the password that will be used to protect the private key, and click Next.
    The Next button is grayed out until a password is supplied.
  6. The Request Submission dialog box provides two ways to submit a request: directly to the CA (if there is one internally) or manually. To submit the request manually, select Copy to Clipboard or Save to File to save the certificate request which will be submitted to the CA.
  7. Click Done to dismiss the Certificate Request Wizard.
Send the Certificate Request
After generating the certificate request, send it to the CA.
After the certificate request is generated, send it to a certificate authority (CA); the CA will generate return a server certificate.
  1. Most certificate requests are emailed to the CA, so open a new message.
  2. Copy the certificate request information from the clipboard or the saved file into the body of the message.
    -----BEGIN NEW CERTIFICATE REQUEST----- 
    MIIBrjCCARcCAQAwbjELMAkGA1UEBhMCVXMxEzARBgNVBAgTCkNBTElGT1J 
    OSUExLDAqBgVBAoTI25ldHNjYXBlIGNvbW11bmljYXRpb25zIGNvcnBvcmF 
    0aW9uMRwwGgYDVQQDExNtZWxsb24ubmV0c2NhcGUuY29tMIGfMA0GCSqGSI 
    b3DQEBAQUAA4GNADCBiQKBgQCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7 
    ug0EfgSLR0f+K41eNqqRftGR83emqPLDOf0ZLTLjVGJaH4Jn4l1gG+JDf/n 
    /zMyahxtV7+mT8GOFFigFfuxaxMjr2j7IvELlxQ4IfZgWwqCm4qQecv3G+N 
    9YdbjveMVXW0v4XwIDAQABoAAwDQYK 
    ------END NEW CERTIFICATE REQUEST-----
    
  3. Send the email message to the CA.
After emailing the certificate request, wait for the CA to respond with the server certificate. Response time for requests varies. For example, if the CA is internal to the company, it may only take a day or two to respond to the request. If the selected CA is a third-party, it could take several weeks to respond to the request.
After receiving the certificate, install it in the Directory Server's certificate database. When the CA sends a response, be sure to save the information in a text file. The certificate must be available to install in the Directory Server.
Also, keep a backup of the certificate data in a safe location. If the system ever loses the certificate data, the certificate can be reinstalled using the backup file.


Tuesday, 1 November 2011

Install Red Hat Directory Server


Then increase the maximum number of open files on the system by editing the /etc/security/limits.confconfiguration file. Add the following entry:
*        -        nofile        8192


1. Install OpenJDK 1.6.0.
  • yum install java-openjdk -y
  • /usr/sbin/alternatives --config java
2. Install the Directory Server packages.
  • yum install redhat-ds
3. Run the setup-ds-admin.pl script.
  • /usr/sbin/setup-ds-admin.pl