Search

Chapter 2. Using views to create a virtual directory hierarchy

download PDF

You can create virtual directory-tree (DIT) views to organize entries in custom groupings or hierarchies and thus navigate the standard DIT from various perspectives. This way you can save costs on management of your directory, and make navigation through entries more intuitive to the users of your service.

2.1. About views

Virtual directory-tree views, or views, are an optional layer of structure in addition to your standard directory tree (DIT) to categorize and search entries in your DIT.

Using views, you can create virtual directory hierarchies, so it is easy to navigate entries, regardless of their placement in the standard DIT. A view uses attributes of entries to include them in the virtual hierarchy, similarly to members of a filtered role or a dynamic group. To client applications, views appear as ordinary container hierarchies.

This way, you can initially place entries in a flat DIT and use views to categorize the entries in complex hierarchies without the need to move the entries. Additionally, entries can appear in multiple views, which you cannot achieve with a standard DIT.

You can think of views as named filters. Each view is an entry of the nsView object class and may have the nsViewFilter attribute, which says what entries are visible in that view. It may be desirable to restrict the type of entries to be returned by specifying an object class in the filter.

You can use a view as a container of other views and thus create the virtual hierarchy. A nested view inherits filters from its ancestors and restricts the view by combining its filter and ancestor filters with an AND, such as (&(container filter)(view filter)).

When a search is performed with a view as the base, entries that match the filter are returned from this virtual search space. The entries only appear to be nested under the view virtually, but they can actually be stored at any position in the DIT.

Note

You can create a testing instance and explore how views work on data imported from the example file located in /usr/share/dirsrv/data/Example-views.ldif.

2.2. Directory design considerations

When you design a directory tree (DIT), you naturally tend to categorize entries with hierarchies to reflect hierarchies in your organization. A standard DIT without views ties the position of an entry in the DIT to the distinguished name (DN) of the entry and therefore it is more suitable for use with fixed hierarchies.

Figure 2.1. Standard hierarchy DIT based on functional units

views standard dit

However, the nature of hierarchies in an organization is dynamic. Moving an entry in a standard DIT is time-consuming, because with every change of the position of the entry, the entry and all its descendants must also be renamed. This leads to service disruptions and additional expenses, especially in changes of top-level subtrees.

It is a good idea to design a flat hierarchy with categorization of resources by characteristics that do not change, such as the resource type (people, equipment, etc.), and capture this hierarchy in a standard flat DIT.

Figure 2.2. Standard flat DIT based on resource types

views flat dit

However, a flat DIT is not convenient for navigating the resources. Different users need to navigate the resources from different perspectives, such as an association with a functional unit or a geographical location, which would require additional tools or complex search queries in case of a flat DIT.

The solution to overcome the limitations of a flat DIT is provided by virtual hierarchies of views. Views allow creation of flexible hierarchies by separating the name of an entry from the position of the entry in the hierarchy. The virtual hierarchies are based on attributes instead.

Figure 2.3. DIT With Virtual Hierarchies of Views

views virtual dit

2.3. Benefits of using views

Using virtual directory-tree views has the benefits of custom flexible hierarchies that are more intuitive for users to navigate and for administrators more efficient to maintain than a deeply-nested standard directory tree (DIT).

Flat and flexible naming

Views facilitate the use of a flat namespace for entries, because virtual DIT views provide navigational and managerial support similar to those provided by traditional hierarchies.

Whenever there is a change to the DIT, the entries never need to be moved; only the virtual DIT view hierarchies change. Because these hierarchies do not contain actual entries, they are simple and quick to modify.

Reduction of costs in case of design errors
Oversights during deployment planning are less catastrophic with virtual DIT views. If the hierarchy is not developed correctly in the first instance, it can be changed easily and quickly without disrupting the service.
Fast and cheap maintenance

View hierarchies can be completely revised in minutes and the results instantly realized, significantly reducing the cost of directory maintenance.

Changes to a virtual DIT hierarchy are instantly realized. When an organizational change occurs, a new virtual DIT view can be created quickly. The new virtual DIT view can exist at the same time as the old view, thereby facilitating a more gradual changeover for the entries themselves and for the applications that use them. Because an organizational change in the directory is not an all-or-nothing operation, it can be performed over a period of time and without service disruption.

Enhanced overall flexibility

Using multiple virtual DIT views for navigation and management allows for more flexible use of the directory service.

With the functionality provided by virtual DIT views, an organization can use both the old and new methods to organize directory data without any requirement to place entries at certain positions in the DIT.

Intuitive user navigation

Views promote flexibility in working practices and reduce the requirement that directory users create complex search filters, using attribute names and values that they would otherwise have no need to know.

The flexibility of having more than one way to view and query directory information allows end users and applications to find what they need intuitively through hierarchical navigation.

Shortcut to frequent search queries
Virtual DIT view hierarchies can be created as a kind of ready-made queries to facilitate the retrieval of frequently-required information.

2.4. Compatibility of views with other features

When working with views, the search space is limited to entries under a single suffix. Users must base their search queries on a view to get results from a virtual hierarchy. You must take a slightly different approach to access control. You can use entry grouping with roles and classes of service in views.

Multiple back ends

Virtual DIT views are not entirely compatible with multiple back ends.

The search is limited to a single back end, which means that the entries to be returned by the views must reside under the same suffix.

Search space

The virtual search space is separate from the standard search space. The virtual search space is accessible only when a search is based on a view node with a filter. Otherwise it is a conventional search over the standard directory tree (DIT) that does not return entries contained under virtual DIT hierarchies.

For example, a search based on dc=example,dc=com does not return any entries from the virtual search space of views; in fact, no virtual-search-space search is performed. Views processing occurs if the search base is such as ou=Cupertino,ou=Location Views,dc=example,dc=com.

This way, Directory Server ensures that the search does not result in entries from both places.

Access control
The use of views requires a slightly different approach to access control. Because there is currently no explicit support for access control lists (ACL) in views, create role-based ACL at the view parent and add the roles to the appropriate parts of the view hierarchy. In this way, take advantage of the organizational property of the hierarchy.
Entries grouping
Both class of service and roles in Directory Server support views. When adding a class of service or a role under a view hierarchy, the entries that are both logically and actually contained in the view are considered within scope. This means that roles and class of service can be applied using a virtual DIT view, but the effects of that application can be seen even when querying the flat namespace.

2.5. Compatibility of views with client applications

Virtual directory tree (DIT) views are designed to mimic standard DITs to a high degree. The existence of views should be transparent to most applications; there should be no indication that they are working with views. Except for a few specialized cases, there is no need for directory users to know that views are being used in a Directory Server instance; views appear and behave like standard DITs.

Certain types of applications may have problems working with a views-enabled directory service. For example:

  • Applications that use the distinguished name (DN) of a target entry to navigate up the DIT.

    This type of application would find that it is navigating up the hierarchy in which the entry physically exists instead of the view hierarchy in which the entry was found. The reason for this is that views make no attempt to disguise the true location of an entry by changing the DN of the entry to conform to the view’s hierarchy.

    This is by design - many applications would not function if the true location of an entry were disguised, such as those applications that rely on the DN to identify a unique entry. This upward navigation by deconstructing a DN is an unusual technique for a client application, but, nonetheless, those clients that do this may not function as intended.

  • Applications that use the numSubordinates operational attribute to determine how many entries exist beneath a node.

    For the nodes in a view, this is currently a count of only those entries that exist in the standard search space, ignoring the virtual search space. Consequently, applications may not evaluate the view in a search.

2.6. Creating a view

This procedure instructs you how to create a virtual directory-tree view on the command line.

Procedure

  • Add a view entry with the ldapadd utility.

    Specify the nsView object class and define a view filter in the nsViewFilter attribute:

    # ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: ou=PeopleInRoom0466,dc=example,dc=com
    objectClass: top
    objectClass: organizationalUnit
    objectClass: nsView
    ou: PeopleInRoom0466
    description: People in the room 0466
    nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=0466))

Verification

  • Perform a search with the view as the search base:

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b ou=PeopleInRoom0466,dc=example,dc=com

2.7. Creating indexes to improve the performance of views using the command line

Views are derived from search results based on a given filter. Part of the filter are the attributes given explicitly in the nsViewFilter; the rest of the filter is based on the entry hierarchy, looking for the entryid and parentid operational attributes of the actual entries included in the view.

(|(parentid=search_base_id)(entryid=search_base_id)

If any of the searched attributes — entryid, parentid, or the attributes in the nsViewFilter — are not indexed, then the search becomes partially unindexed and Directory Server searches the entire directory tree for matching entries.

To improve views performance, create the indexes as follows:

  • Create equality index (eq) for entryid. The parentid attribute is indexed in the system index by default.
  • If a filter in nsViewFilter tests presence (attribute=*), then create presence index (pres) for the attribute being tested. You should use this index type only with attributes that appear in a minority of directory entries.
  • If a filter in nsViewFilter tests equality (attribute=value), create equality index (eq) for the attribute being tested.
  • If a filter in nsViewFilter tests a substring (attribute=value*), create substring index (sub) for the attribute being tested.
  • If a filter in nsViewFilter tests approximation (attribute~=value), create approximate index (approximate) for the attribute being tested.

For example, when you use the following view filter:

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))

you should index objectClass with the equality index, which is done by default, and roomNumber with the substring index.

Prerequisites

  • You are aware of the attributes that you use in a view filter.

Procedure

  1. Optional: List the back ends to determine the database to index:

    # dsconf -D "cn=Directory Manager" instance_name backend suffix list
    dc=example,dc=com (userroot)

    Note the selected database name (in parentheses).

  2. Create index configuration with the dsconfig utility for the selected back-end database.

    Specify the attribute name, index type, and, optionally, matching rules to set collation order (OID), especially in case of an internationalized instance.

    # dsconf -D "cn=Directory Manager" instance_name backend index add --attr roomNumber --index-type sub userroot

    Repeat this step for each attribute used in the view filter.

  3. Reindex the database to apply the new indexes:

    # dsconf -D "cn=Directory Manager" instance_name backend index reindex userroot

Verification

  1. Perform a search that is based on the standard directory tree with the same filter that you use in the view:

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com (&(objectClass=inetOrgPerson)(roomNumber=*66))
    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com "(&(objectClass=inetOrgPerson)(roomNumber=*66))"
  2. View the access log in /var/log/dirsrv/slapd-instance_name/access.

    The RESULT of your search should not contain note=U or Partially Unindexed Filter in the details.

Additional resources

2.8. Creating indexes to improve the performance of views using the web console

Views are derived from search results based on a given filter. Part of the filter are the attributes given explicitly in the nsViewFilter; the rest of the filter is based on the entry hierarchy, looking for the entryid and parentid operational attributes of the actual entries included in the view.

(|(parentid=search_base_id)(entryid=search_base_id)

If any of the searched attributes — entryid, parentid, or the attributes in the nsViewFilter — are not indexed, then the search becomes partially unindexed and Directory Server searches the entire directory tree for matching entries.

To improve views performance, create the indexes as follows:

  • Create equality index (eq) for entryid. The parentid attribute is indexed in the system index by default.
  • If a filter in nsViewFilter tests presence (attribute=*), then create presence index (pres) for the attribute being tested. You should use this index type only with attributes that appear in a minority of directory entries.
  • If a filter in nsViewFilter tests equality (attribute=value), create equality index (eq) for the attribute being tested.
  • If a filter in nsViewFilter tests a substring (attribute=value*), create substring index (sub) for the attribute being tested.
  • If a filter in nsViewFilter tests approximation (attribute~=value), create approximate index (approximate) for the attribute being tested.

For example, when you use the following view filter:

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))

you should index objectClass with the equality index, which is done by default, and roomNumber with the substring index.

Prerequisites

  • You are logged in to the instance in the web console.
  • You are aware of the attributes that you use in a view filter.

Procedure

  1. Under Database, select a suffix from the configuration tree for which you want to create an index.
  2. Navigate to Indexes and Database Indexes.
  3. Click the Add Index button.
  4. Type the name of the attribute and select the attribute.
  5. Select the Index Types that should be created for this attribute.
  6. Optionally, add Matching Rules to specify collation order (OID), especially in case of an internationalized instance.
  7. Select Index attribute after creation to rebuild the index afterwards.
  8. Click Create Index.
  9. Repeat the steps for each attribute to be indexed.

Verification

  • Filter Indexes by typing the name of the added attribute.
  • The newly indexed attribute should appear in the results.

Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.