Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 6. Managing indexes in Directory Server

Indexing makes searching for and retrieving information faster by classifying and organizing attributes or values. You can request a contiguous subset of a large search result by using virtual list view control.

6.1. About indexes
Copia collegamento

Understand the purpose of indexes in Red Hat Directory Server to optimize the performance of search operations. With indexes, the server can locate specific directory entries without scanning the entire database, ensuring faster response times for client applications and reduced server load.

6.1.1. The different index types
Copia collegamento

Red Hat Directory Server supports several index types, each optimized for specific search operations. Understanding these types helps you to apply the correct indexing strategy to your attributes, ensuring efficient query processing while minimizing storage overhead and write performance costs.

Directory Server stores the indexes of each indexed attribute in a separate database file in the instance’s database directory. For example, the indexes of the sn attribute are stored in the /var/lib/dirsrv/slapd-<instance_name>/db/database_name/sn.db file. Each index file can contain multiple index types if Directory Server maintains different indexes for an attribute.

Directory Server supports the following index types:

  • The presence index (pres) is a list of the entries that contain a particular attribute. For example, use this type when clients frequently perform searches, such as attribute=mail.
  • The equality index (eq) improves searches for entries containing a specific attribute value. For example, an equality index on the cn attribute enables faster searches for cn=first_name last_name.
  • The approximate index (approx) enables efficient approximate or sounds-like searches. For example, searches for cn~=first_name last_name, cn~=first_name, or cn~=first_nam (note the misspelling) would return an entry cn=first_name X last_name. Note that the metaphone phonetic algorithm in Directory Server supports only US-ASCII letters. Therefore, use approximate indexing only with English values.
  • The substring index (sub) is a costly index to maintain, but it enables efficient searching against substrings within entries. Substring indexes are limited to a minimum of three characters for each entry. For example, searches for telephoneNumber=*555* return all entries in the directory with a value that contains 555 in the telephoneNumber attribute.
  • International index speeds up searches for information in international directories. The process for creating an international index is similar to the process for creating regular indexes, except that it applies a matching rule by associating an object identifier (OID) with the attributes to be indexed.

6.1.2. Balancing the benefits of indexing
Copia collegamento

Indexing in Red Hat Directory Server accelerates search operations but consumes storage and impacts write performance. Understanding these trade-offs helps you to implement an indexing strategy that maximizes query speed without overburdening system resources or degrading update efficiency.

Before you create new indexes, balance the benefits of maintaining indexes against the costs:

  • Approximate indexes are not efficient for attributes commonly containing numbers, such as phone numbers.
  • Substring indexes do not work for binary attributes.
  • Avoid equality indexes on attributes that contain big values, such as an image.
  • Maintaining indexes for attributes that are not commonly used in searches increases the overhead without improving the search performance.
  • Attributes that are not indexed can still be used in search requests, although the search performance can be degraded significantly, depending on the type of search.

Indexes can become very time-consuming. For example, if Directory Server receives an add operation, the server examines the indexing attributes to determine whether an index is maintained for the attribute values. If the created attribute values are indexed, Directory Server adds the new attribute values to the index, and then the actual attribute values are created in the entry.

Example 6.1. Indexing steps Directory Server performs when a user adds an entry

Assume that Directory Server maintains the following indexes:

  • Equality, approximate, and substring indexes for the cn and sn attributes.
  • Equality and substring indexes for the telephoneNumber attribute.
  • Substring indexes for the description attribute.

For example, a user adds the following entry: 

dn: cn=John Doe,ou=People,dc=example,dc=com
objectclass: top
objectClass: person
objectClass: orgperson
objectClass: inetorgperson
cn: John Doe
cn: John
sn: Doe
ou: Manufacturing
ou: people
telephoneNumber: 408 555 8834
description: Manufacturing lead

When the user adds the entry, Directory Server performs the following steps:

  1. Create the cn equality index entry for John and John Doe.
  2. Create the cn approximate index entries for John and John Doe.
  3. Create the cn substring index entries for John and John Doe.
  4. Create the sn equality index entry for Doe.
  5. Create the sn approximate index entry for Doe.
  6. Create the sn substring index entry for Doe.
  7. Create the telephoneNumber equality index entry for 408 555 8834.
  8. Create the telephoneNumber substring index entry for 408 555 8834.
  9. Create the description substring index entry for Manufacturing lead.

This example illustrates that the number of actions required to create and maintain databases for a large directory can be very resource-intensive.

Important

Do not define a substring index for membership attributes (for example, member,uniquemember) because it can impact Directory Server performance. When adding or removing members, for example,uniquemember to a group with many members, the computation of the uniquemember substring index requires to evaluating all uniquemember values and not only added or removed values.

6.2. Defining a default index that applies to all newly created databases
Copia collegamento

Define a default index in Red Hat Directory Server to automatically apply specific indexing rules to all newly created databases.

The default index in Directory Server defines a set of attributes to be indexed. When you create a new database, Directory Server copies the default index attributes from cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config entry to the database-specific cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config entry.

Note

Directory Server does not apply changes in the default index to existing databases.

6.2.1. Default index attributes
Copia collegamento

Red Hat Directory Server includes a preconfigured set of default index attributes that support common LDAP search operations immediately after installation and stores these default index attributes in the cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config entry.

To display the default index attributes, including their index types, enter: 

# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config" -s one -o ldif-wrap=no
Expand
Table 6.1. Directory Server default index attributes

aci

cn

entryUSN

entryUUID

givenName

mail

mailAlternateAddress

mailHost

member

memberOf

nsUniqueId

nsCertSubjectDN

nsTombstoneCSN

ntUniqueId

ntUserDomainId

numSubordinates

objectClass

owner

parentId

seeAlso

sn

targetUniqueId

telephoneNumber

uid

uniqueMember

  
Warning

Removing the attributes listed in the table (system indexes) from the index of databases can significantly affect the Directory Server performance.

6.2.2. Maintaining the default index
Copia collegamento

Manage the default index configuration in Red Hat Directory Server to control the standard index types applied to attributes. Modifying these defaults helps you to optimize search performance and storage usage by ensuring that only necessary indexes are created automatically for new attributes.

Directory Server stores the default index attributes in the cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config entry. Note that you can only maintain the default index attributes by using LDIF statements.

Procedure

  • For example, to add the roomNumber attribute to the default index with the index types eq and sub, enter: 

    # ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

    The ldapadd utility requests you to provide the LDIF statement: 

    dn: cn=roomNumber,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
objectClass: nsIndex
objectClass: top
cn: roomNumber
nsSystemIndex: false
nsIndexType: eq
nsIndexType: sub

    where:

    objectClass: nsIndex
    Defines that this entry is an index entry.
    objectClass: top
    This object class is additionally required in index entries.
    cn
    Sets the name of the attribute to index.
    nsSystemIndex
    Indicates whether or not the index is essential to Directory Server operations.
    nsIndexType
    This multi-value attribute specifies the index types.

  • For example, to add the pres index type to the default index attributes of the roomNumber attribute, enter: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

    The ldapmodify utility requests you to provide the LDIF statement with updated index type: 

    dn: cn=roomNumber,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add: nsIndexType
nsIndexType: pres

  • For example, to remove the pres index type from the default index attributes of the roomNumber attribute, enter: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

    The ldapmodify utility requests you to provide the LDIF statement: 

    dn: cn=roomNumber,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
delete: nsIndexType
nsIndexType: pres

  • For example, to remove the roomNumber attribute from the default index, enter: 

    # ldapdelete -D "cn=Directory Manager" -W -H ldap://server.example.com -x cn=roomNumber,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config

Verification

  • List the default index attributes to verify your changes: 

    # ldapsearch -H ldap://server.example.com:389 -D "cn=Directory Manager" -W -b "cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config" -x -s one -o ldif-wrap=no

6.3. Maintaining the indexes of a specific database
Copia collegamento

Maintain the indexes of a specific database in Red Hat Directory Server to optimize search performance and ensure data integrity. Rebuilding or verifying indexes helps you to repair fragmented or corrupted index files.

Each database in Red Hat Directory Server has its own set of indexes. You can create, update, and delete indexes by using the dsconf utility or the web console.

Important

When you regenerate an index while the server is online, after a new index creation or an index type change, Red Hat Directory Server continues to process search requests. However, this might lead to incorrect or inconsistent search results.

6.3.1. Maintaining the indexes of a specific database using the command line
Copia collegamento

Maintain the indexes of a specific database in Red Hat Directory Server by using the dsconf utility to ensure optimal search performance and data integrity.

Procedure

  • For example, to add the roomNumber attribute to the index of the userRoot database with the index types eq and sub, enter: 

    # dsconf <instance_name> backend index add --attr roomNumber --index-type eq --index-type sub --reindex userRoot

    The --reindex option causes that Directory Server automatically re-indexes the database.

  • For example, to add the pres index type to the index settings of the roomNumber attribute in the userRoot database, enter: 

    # dsconf <instance_name> backend index set --attr roomNumber --add-type pres userRoot

  • For example, to remove the pres index type from the index settings of the roomNumber attribute in the userRoot database, enter: 

    # dsconf <instance_name> backend index set --attr roomNumber --del-type pres userRoot

  • For example, to remove the roomNumber attribute from the index in the userRoot database, enter: 

    # dsconf <instance_name> backend index delete --attr roomNumber userRoot

Verification

  • List the index settings of the userRoot database: 

    # dsconf <instance_name> backend index list userRoot

6.3.2. Recreating an index while the instance is offline
Copia collegamento

Recreate an index in Red Hat Directory Server by using the dsctl db2index command while the server instance is stopped. Performing an offline index rebuild helps you to repair corrupted files or apply new configuration settings, ensuring maximum data integrity and processing speed.

Prerequisites

  • You created an indexing entry or added additional index types to the existing userRoot database.

Procedure

  1. Shut down the instance: 

    # dsctl <instance_name> stop

  2. Recreate the index:

    1. For all indexes in the database, run: 

      # dsctl <instance_name> db2index
       
      [23/Feb/2023:05:38:28.034826108 -0500] - INFO - check_and_set_import_cache - pagesize: 4096, available bytes 1384095744, process usage 27467776
[23/Feb/2023:05:38:28.037952026 -0500] - INFO - check_and_set_import_cache - Import allocates 540662KB import cache.
[23/Feb/2023:05:38:28.055104135 -0500] - INFO - bdb_db2index - userroot: Indexing attribute: aci
...
[23/Feb/2023:05:38:28.134350191 -0500] - INFO - bdb_db2index - userroot: Finished indexing.
[23/Feb/2023:05:38:28.151907852 -0500] - INFO - bdb_pre_close - All database threads now stopped
db2index successful

    2. For specific attribute indexes, run: 

      # dsctl <instance_name> db2index userRoot --attr aci cn givenname

      The following command recreates indexes for aci, cn, and givenname attributes.

      Note that if no database is specified, the command recreates indexes for all attributes.

    3. For more information regarding dsctl (offline) command, run: 

      # dsctl <instance_name> db2index --help

  3. Start the instance: 

    # dsctl <instance_name> start

Verification

  • List the index settings of the userRoot database: 

    # dsconf <instance_name> backend index list userRoot

6.3.3. Maintaining the indexes of a specific database using the web console
Copia collegamento

Maintain the indexes of a specific database in Red Hat Directory Server by the web console to ensure optimal search performance and data integrity.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  • Navigate to Database Suffixes suffix_name Indexes Database Indexes.

    • To add an attribute to the index:

      • Click Add Index.
      • Enter the attribute name to the Select An Attribute field.
      • Select the index types.
      • Select Index attribute after creation.
      • Click Create Index.

    • To update the index settings of an attribute:

      • Click the overflow menu next to the attribute, and select Edit Index.
      • Update the index settings to your needs.
      • Select Index attribute after creation.
      • Click Save Index.

    • To delete an attribute from the index:

      • Click the overflow menu next to the attribute, and select Delete Index.
      • Select Yes, I am sure, and click Delete.
      • In the Suffix Tasks menu, select Reindex Suffix.

Verification

  • Navigate to Database Suffixes suffix_name Indexes Database Indexes, and verify that the index settings reflect the changes you made.

6.4. Changing the search key length in a substring index
Copia collegamento

Optimize substring search performance and disk space usage by adjusting the index key length for specific attributes in Red Hat Directory Server.

By default, the length of the search key for substring indexes must be at least three characters. For example, Directory Server will add the string abc as a search key to an index while ab* will not. However, to improve the search performance, particularly for searches with many wildcard characters, you can shorten the search key length. This increases the number of search keys in the index.

Directory Server has three attributes that change the minimum number of characters required for a search key:

  • nsSubStrBegin: Sets the minimum number of characters for the beginning of a search key, before the wildcard character. For example: 
abc*
  • nsSubStrMiddle: Sets the minimum number of characters in the search key between wildcard characters. For example: 
*abc*
  • nsSubStrEnd: Sets the number of characters for the end of a search key, after the wildcard character. For example: 
*xyz

Improve search speeds by setting a new search key length for an attribute index.

Procedure

  1. To set new search key length, add the extensibleObject object class and then add the nsSubStrBegin, nsSubStrEnd, or nsSubStrMiddle attributes to the entry. For example: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

    The ldapmodify utility requires you to provide the LDIF statement with the new search key length details: 

    dn: <attribute_name>,cn=index,cn=<database_name>,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add: objectclass
objectclass: extensibleObject
-
add: nsSubStrBegin
nsSubStrBegin: 2
-
add: nsSubStrMiddle
nsSubStrMiddle: 2
-
add: nsSubStrEnd
nsSubStrEnd: 2

  2. Recreate the index to apply the new setting. For example, while the Directory Server instance is running, use the following command to recreate the index for the specified attribute: 

    # dsconf <instance_name> backend index reindex --attr <attribute_name> <database_name>

Verification

  1. Select the attribute for which you want to change the search key length, for example, cn.

  2. Dump the cn index: 

    # dbscan -f /var/lib/dirsrv/slapd-<instance_name>/db/database/cn.db > /tmp/default_len
  3. Configure the new search key length as described in section Changing the search key length in a substring index using the command line.

  4. Stop the instance to synchronize the database on the disk: 

    # dsctl <instance_name> stop

  5. Dump the cn index: 

    # dbscan -f /var/lib/dirsrv/slapd-<instance_name>/db/database/cn.db > /tmp/len_2

  6. Compare len_2 and default_len files: 

    # diff /tmp/len_2 /tmp/default_len

Use the Virtual List View (VLV) control in Red Hat Directory Server to efficiently retrieve contiguous subsets of large search results. With configured VLV, clients can display sorted data in scrolling lists or pages without retrieving the entire dataset, ensuring faster response times and reduced network load.

The VLV control enables an LDAP client to request a contiguous subset of a large search result.

For example, you have stored an address book with 100.000 entries in Red Hat Directory Server. By default, a query for all entries returns all entries at once. This is a resource and time-consuming operation, and clients often do not require the whole data set because, if the user scrolls through the results, only a partial set is visible.

However, if the client uses the VLV control, the server only returns a subset and, for example, if the user scrolls in the client application, the server returns more entries. This reduces the load on the server, and the client does not need to store and process all data at once.

VLV also improves the performance of server-sorted searches when all search parameters are fixed. Red Hat Directory Server pre-computes the search results within the VLV index. Therefore, the VLV index is much more efficient than retrieving the results and sorting them afterwards.

In Red Hat Directory Server, the VLV control is always available. However, if you use it in a large directory, a VLV index, also called browsing index, can significantly improve the speed.

Red Hat Directory Server does not maintain VLV indexes for attributes, such as for standard indexes. The server generates VLV indexes dynamically based on attributes set in entries and the location of those entries in the directory tree. Unlike standard entries, VLV entries are special entries in the database.

6.5.1. How the VLV control works in ldapsearch commands
Copia collegamento

Typically, you use the virtual list view (VLV) feature in LDAP client applications. For example, for testing, you can use the ‎ldapsearch utility to request only partial results.

To use the VLV feature in ldapsearch commands, specify the -E option for both the sss (server-side sorting) and vlv search extensions: 

# ldapsearch ... -E 'sss=attribute_list' -E 'vlv=query_options'

The sss search extension has the following syntax: 

[!]sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]

The vlv search extension has the following syntax: 

[!]vlv=<before>/<after>(/<offset>/<count>|:<value>)
  • before sets the number of entries returned before the targeted one.
  • after sets the number of entries returned after the targeted one.
  • index, count, and value help to determine the target entry. If you set value, the target entry is the first one having its first sorting attribute starting with the value. Otherwise, you set count to 0, and the target entry is determined by the index value (starting from 1). If the count value is higher than 0, the target entry is determined by the ratio index * number of entries / count.

Example 6.2. Output of an ldapsearch command with VLV search extension

The following command searches in ou=People,dc=example,dc=com. The server then sorts the results by the cn attribute and returns the uid attributes of the 70th entry together with one entry before and two entries after the offset. 

# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid
 
# user069, People, example.com
dn: uid=user069,ou=People,dc=example,dc=com
uid: user069

# user070, People, example.com
dn: uid=user070,ou=People,dc=example,dc=com
uid: user070

# user071, People, example.com
dn: uid=user071,ou=People,dc=example,dc=com
uid: user071

# user072, People, example.com
dn: uid=user072,ou=People,dc=example,dc=com
uid: user072

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.474 false MIQAAAADCgEA
sortResult: (0) Success
control: 2.16.840.1.113730.3.4.10 false MIQAAAALAgFGAgMAnaQKAQA=
vlvResult: pos=70 count=40356 context= (0) Success

# numResponses: 5
# numEntries: 4
Press [before/after(/offset/count|:value)] Enter for the next window.

For details about the -E parameter, see the ldapsearch(1) man page on your system.

6.5.2. Enabling unauthenticated users to use the VLV control
Copia collegamento

Enable unauthenticated users to use the Virtual List View (VLV) control in Red Hat Directory Server to allow anonymous clients to perform sorted and paged search operations.

By default, the access control instruction (ACI) in the oid=2.16.840.1.113730.3.4.9,cn=features,cn=config entry enables only authenticated users to use the VLV control. To enable unauthenticated users to use the VLV control, update the ACI by changing userdn = "ldap:///all" to userdn = "ldap:///anyone"

Procedure

  • Update the ACI in oid=2.16.840.1.113730.3.4.9,cn=features,cn=config: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

    The ldapmodify utility requests you to provide the LDIF statement with the ACI update information: 

    dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
changetype: modify
replace: aci
aci: (targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap:///anyone";)

Verification

  • Perform a query with VLV control not specify a bind user: 

    # ldapsearch -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid

    This command requires that the server allows anonymous binds.

    If the command succeeds but returns no entries, run the query again with a bind user to ensure that the query works when using authentication.

Create a Virtual List View (VLV) index in Red Hat Directory Server to optimize the performance of search operations that request sorted and paged results. VLV indexes reduce the time and resources required to display large lists of entries to client applications.

For example, create a virtual list view (VLV) index, also called browsing index, for entries in ou=People,dc=example,dc=com that contain a mail attribute and have the objectClass attribute set to person.

Prerequisites

  • Your client applications use the VLV control.
  • Client applications require to query a contiguous subset of a large search result.
  • The directory contains a large number of entries.

Procedure

  1. Create the VLV search entry: 

    # dsconf <instance_name> backend vlv-index add-search --name "VLV People" --search-base "ou=People,dc=example,dc=com" --search-filter "(&(objectClass=person)(mail=*))" --search-scope 2 userRoot

    This command uses the following options:

    • --name sets the name of the search entry. This can be any name.
    • --search-base sets the base DN for the VLV index. Directory Server creates the VLV index on this entry.
    • --search-scope sets the scope of the search to run for entries in the VLV index. You can set this option to 0 (base search), 1 (one-level search), or 2 (subtree search).
    • --search-filter sets the filter Directory Server applies when it creates the VLV index. Only entries that match this filter become part of the index.
    • userRoot is the name of the database in which to create the entry.

  2. Create the index entry: 

    # dsconf <instance_name> backend vlv-index add-index --index-name "VLV People - cn sn" --parent-name "VLV People" --sort "cn sn" --index-it userRoot

    This command uses the following options:

    • --index-name sets the name of the index entry. This can be any name.
    • --parent-name sets the name of the VLV search entry and must match the name you set in the previous step.
    • --sort sets the attribute names and their sort order. Separate the attributes by space.
    • --index-it causes that Directory Server automatically starts an index task after the entry was created.
    • userRoot is the name of the database in which to create the entry.

Verification

  1. Verify the successful creation of the VLV index in the /var/log/dirsrv/slapd-<instance_name>/errors file: 

    [26/Nov/2021:11:32:59.001988040 +0100] - INFO - bdb_db2index - userroot: Indexing VLV: VLV People - cn sn
[26/Nov/2021:11:32:59.507092414 +0100] - INFO - bdb_db2index - userroot: Indexed 1000 entries (2%).
...
[26/Nov/2021:11:33:21.450916820 +0100] - INFO - bdb_db2index - userroot: Indexed 40000 entries (98%).
[26/Nov/2021:11:33:21.671564324 +0100] - INFO - bdb_db2index - userroot: Finished indexing.

  2. Use the VLV control in an ldapsearch command to query only specific records from the directory: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid
     
    # user069, People, example.com
dn: uid=user069,ou=People,dc=example,dc=com
cn: user069

# user070, People, example.com
dn: uid=user070,ou=People,dc=example,dc=com
cn: user070

# user071, People, example.com
dn: uid=user071,ou=People,dc=example,dc=com
cn: user071

# user072, People, example.com
dn: uid=user072,ou=People,dc=example,dc=com
cn: user072

    This example assumes you have entries continuously named uid=user001 to at least uid=user072 in ou=People,dc=example,dc=com.

    For details about the -E parameter, see the ldapsearch(1) man page on your system.

Create a Virtual List View (VLV) index in Red Hat Directory Server to optimize the performance of search operations that request sorted and paged results. VLV indexes reduce the time and resources required to display large lists of entries to client applications.

For example, create a virtual list view (VLV) index, also called browsing index, for entries in ou=People,dc=example,dc=com that contain a mail attribute and have the objectClass attribute set to person.

Prerequisites

  • You are logged in to the instance in the web console.
  • Your client applications use the VLV control.
  • Client applications require to query a contiguous subset of a large search result.
  • The directory contains a large number of entries.

Procedure

  1. Navigate to Database Suffixes dc=example,dc=com VLV Indexes.

  2. Click Create VLV Index, and fill the fields:

    Creating a VLV index
    • VLV Index Name: The name of the search entry. This can be any name.
    • Search base: The base DN for the VLV index. Directory Server creates the VLV index on this entry.
    • Search Filter: The filter Directory Server applies when it creates the VLV index. Only entries that match this filter become part of the index.
    • Search Scope: The scope of the search to run for entries in the VLV index.
  3. Click Save VLV Index.
  4. Click Create Sort Index

  5. Enter the attribute names, and select Reindex After Saving.

    Creating VLV sort index
  6. Click Create Sort Index.

Verification

  1. Navigate to Monitoring Logging Errors Log and verify the successful creation of the VLV index: 

    [26/Nov/2021:11:32:59.001988040 +0100] - INFO - bdb_db2index - userroot: Indexing VLV: VLV People - cn sn
[26/Nov/2021:11:32:59.507092414 +0100] - INFO - bdb_db2index - userroot: Indexed 1000 entries (2%).
...
[26/Nov/2021:11:33:21.450916820 +0100] - INFO - bdb_db2index - userroot: Indexed 40000 entries (98%).
[26/Nov/2021:11:33:21.671564324 +0100] - INFO - bdb_db2index - userroot: Finished indexing.

  2. Use the VLV control in an ldapsearch command to query only specific records from the directory: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid
     
    # user069, People, example.com
dn: uid=user069,ou=People,dc=example,dc=com
cn: user069

# user070, People, example.com
dn: uid=user070,ou=People,dc=example,dc=com
cn: user070

# user071, People, example.com
dn: uid=user071,ou=People,dc=example,dc=com
cn: user071

# user072, People, example.com
dn: uid=user072,ou=People,dc=example,dc=com
cn: user072

    This example assumes you have entries continuously named uid=user001 to at least uid=user072 in ou=People,dc=example,dc=com.

    For details about the -E parameter, see the ldapsearch(1) man page on your system.

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Legal Notice

Theme

© 2026 Red HatTorna in cima