Deployment Guide
Red Hat Directory Server                                                            
Previous
 Contents
 Index
 Next

Chapter 4

Designing the Directory Tree

Your directory tree provides a way to refer to the data stored by your directory. The types of information you store in your directory, the physical nature of your enterprise, the applications you use with your directory, and the types of replication you use shape the design of your directory tree.

This chapter outlines the steps for designing your own directory tree. It includes the following sections:

Introduction to the Directory Tree

Your directory tree provides a means for your directory data to be named and referred to by client applications. Your directory tree interacts closely with other design decisions, including the choices available to you when you decide on how to distribute, replicate, or control access to your directory data. Taking the time to design your directory tree well before deployment saves headaches later if you find it inadequate after you have launched your directory.

A well-designed directory tree provides the following:

The structure of your directory tree follows the hierarchical LDAP model. Your directory tree provides a way to organize your data, for example, by group, by people, or by place. It also determines how you partition data across multiple servers. For example, each database needs data to be partitioned at the suffix level. Without the proper directory tree structure, you may not be able to spread your data across multiple servers as you would like.

In addition, replication is constrained by what sort of directory tree structure you use. You must carefully define partitions for replication to work. If you want to replicate only portions of your directory tree, you need to take that into account during the design process. If you plan to use access controls on branch points, that is also a consideration in your directory tree design.

Note

Directory Server supports a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views. Be sure to read "Virtual Directory Information Tree Views," on page 78, before you design your directory tree.


Designing Your Directory Tree

This section guides you through the major decisions you make during the directory tree design process. The directory tree design process involves the following steps:

The following sections describe the directory tree design process in more detail.

Choosing a Suffix

The suffix is the name of the entry at the root of your tree, below which you store your directory data. Your directory can contain more than one suffix. You may choose to use multiple suffixes if you have two or more directory trees of information that do not have a natural common root.

By default, the standard Directory Server deployment contains multiple suffixes, one for storing data and the others for data needed by internal directory operations (such as configuration information and your directory schema). For more information on these standard directory suffixes, see the Red Hat Directory Server Administrator's Guide.

Suffix Naming Conventions

All entries in your directory should be located below a common base entry, the root suffix. In naming the root directory suffix, consider the following recommendations for what the name should be:

In a single enterprise environment, choose a directory suffix that aligns with a DNS name or Internet domain name of your enterprise. For example, if your enterprise owns the domain name of example.com, then you should use a directory suffix of dc=example,dc=com.

The dc (domainComponent) attribute represents your suffix by breaking your domain name into its component parts.

Normally, you can use any attribute that you like to name your root suffix. However, for a hosting organization, we recommend that the root suffix contain only the following attributes:

The presence of these attributes allows for interoperability with subscriber applications. For example, a hosting organization might use these attributes to create the following root suffix for one of its clients, example_a: 
o=example_a,st=Washington,c=US
Using an organization name followed by a country designation is typical of the X.500 naming convention for suffixes.

Naming Multiple Suffixes

Each suffix that you use with your directory is a unique directory tree. There are several ways that you can include multiple trees in your directory. The first is to create multiple directory trees stored in separate databases served by Directory Server. For example, you could create separate suffixes for example_a and example_b and store them in separate databases as shown below:




The databases could be stored on a single server or multiple servers depending upon resource constraints.

Creating Your Directory Tree Structure

You need to decide whether you use a flat or hierarchical tree structure. As a general rule, strive to make your directory tree as flat as possible. However, a certain amount of hierarchy can be important later when you partition data across multiple databases, prepare replication, and set access controls.

The structure of your tree involves the following steps and considerations:

Branching Your Directory

Design your hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely the names are to change. The likelihood of a name changing is roughly proportional to the number of components in the name that can potentially change. The more hierarchical the directory tree, the more components in the names, and the more likely the names are to change.

Following are some guidelines for designing your directory tree hierarchy:

Any such branch points should be limited to divisions (Corporate Information Services, Customer Support, Sales and Professional Services, and so forth). Make sure that divisions you use to branch your directory tree are stable; do not perform this kind of branching if your enterprise reorganizes frequently.
Names change, and you do not want to have to change your directory tree every time your enterprise renames its divisions. Instead, use generic names that represent the function of the organization (for example, use Engineering instead of Widget Research and Development).
For example, even if you have multiple marketing organizations, each of which is responsible for a specific product line, create a single Marketing subtree. All marketing entries then belong to that tree.

Following are specific guidelines for the enterprise and hosting environment.

Branching in an Enterprise Environment

Name changes can be avoided if you base your directory tree structure on information that is not likely to change. For example, base the structure on types of objects in the tree rather than organizations. Some of the objects you might use to define your structure are:

A directory tree organized using these objects might appear as shown below.




Branching in a Hosting Environment

For a hosting environment, create a tree that contains two entries of the object class organization (o) and one entry of the organizationalUnit (ou) object class beneath the root suffix. For example, the ISP example branches their directory as shown below.




Identifying Branch Points

As you decide how to branch your directory tree, you will need to decide what attributes you will use to identify the branch points. Remember that a DN is a unique string composed of attribute-data pairs. For example, the DN of an entry for Barbara Jensen, an employee of example.com Corporation, appears as follows: 

uid=Barbara Jensen,ou=people,dc=example,dc=com

Each attribute-data pair represents a branch point in your directory tree. For example, the directory tree for the enterprise example.com Corporation appears as follows:




The directory tree for example, an Internet host, appears as follows:




Beneath the root suffix entry o=example,c=US, the tree is split into three branches. The ISP branch contains customer data and internal information for example. The Internet branch is the domain tree. The groups branch contains information about the administrative groups.

There are some points to consider when choosing attributes for your branch points:

Some LDAP client applications may be confused if the distinguished name (DN) format is inconsistent across your directory tree. That is, if l is subordinate to o in one part of your directory tree, then make sure l is subordinate to o in all other parts of your directory.
Using traditional attributes increases the likelihood of retaining compatibility with third-party LDAP client applications. Using the traditional attributes also means that they will be known to the default directory schema, which makes it easier to build entries for the branch DN.
Table 4-1 Traditional DN Branch Point Attributes  
Attribute Name    
Definition
c
A country name.
o
An organization name. This attribute is typically used to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise. You should also use this attribute to represent a domain name as discussed in "Suffix Naming Conventions," on page 61.
ou
An organizational unit. This attribute is typically used to represent a smaller divisional branching of your enterprise than an organization. Organizational units are generally subordinate to the preceding organization.
st
A state or province name.
l
A locality, such as a city, country, office, or facility name.
dc
A domain component as discussed in "Suffix Naming Conventions," on page 61.

Note

A common mistake is to assume that you search your directory based on the attributes used in the distinguished name. However, the distinguished name is only a unique identifier for the directory entry and cannot be searched against.

Instead, search for entries based on the attribute-data pairs stored on the entry itself. Thus, if the distinguished name of an entry is uid=Babs Jensen,ou=People,dc=example,dc=com, then a search for dc=example will not match that entry unless you have explicitly put dc:example as an attribute in that entry.


Replication Considerations

During directory tree design, consider which entries you are replicating. A natural way to describe a set of entries to be replicated is to specify the distinguished name (DN) at the top of a subtree and replicate all entries below it. This subtree also corresponds to a database, a directory partition containing a portion of the directory data.

For example, in an enterprise environment, you can organize your directory tree so that it corresponds to the network names in your enterprise. Network names tend not to change, so the directory tree structure will be stable. Further, using network names to create the top level branches of your directory tree is useful when you use replication to tie together different Directory Servers.

For instance, example.com Corporation has three primary networks known as flightdeck.example.com, tickets.example.com, and hanger.example.com. They initially branch their directory tree as follows:




After creating the initial structure of the tree, they create additional branches as follows:




As another example, the ISP example.com branches their directory as follows:




After creating the initial structure of their directory tree, they create additional branches as follows:




Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often.

Access Control Considerations

Introducing hierarchy into your directory tree can be used to enable certain types of access control. As with replication, it is easier to group together similar entries and then administer them from a single branch.

You can also enable the distribution of administration through a hierarchical directory tree. For example, if you want give an administrator from the marketing department access to the marketing entries and an administrator from the sales department access to the sales entries, you can do so through your directory tree design.

You can set access controls based on the directory content rather than the directory tree. The ACI filtered target mechanism lets you define a single access control rule stating that a directory entry has access to all entries containing a particular attribute value. For example, you could set an ACI filter that gives the sales administrator access to all the entries containing the attribute ou=Sales.

However, ACI filters can be difficult to manage. You must decide which method of access control is best suited to your directory: organizational branching in your directory tree hierarchy, ACI filters, or a combination of the two.

Naming Entries

After designing the hierarchy of your directory tree, you need to decide which attributes to use when naming the entries within the structure. Generally, names are created by choosing one or more of the attribute values to form a relative distinguished name (RDN). The RDN is the left-most DN attribute value. The attributes you use depend on the type of entry you are naming.

Your entry names should adhere to the following rules:

A unique name ensures that a DN can refer to at most one entry in your directory.

When creating entries, define the RDN within the entry. By defining at least the RDN within the entry, you can locate the entry more easily. This is because searches are not performed against the actual DN but rather the attribute values stored in the entry itself.

Attribute names have a meaning, so try to use the attribute name that matches the type of entry it represents. For example, do not use l (locality) to represent an organization, or c (country) to represent an organizational unit.

The following sections provide tips on naming entries:

Naming Person Entries

The person entry's name, the DN, must be unique. Traditionally, distinguished names use the commonName, or cn, attribute to name their person entries. That is, an entry for a person named Babs Jensen might have the distinguished name of: 

cn=Babs Jensen,dc=example,dc=com

While allowing you to recognize instantly the person associated with the entry, it might not be unique enough to exclude people with identical names. This quickly leads to a problem known as DN name collisions, multiple entries with the same distinguished name.

You can avoid common name collisions by adding a unique identifier to the common name. For example: 

cn=Babs Jensen+employeeNumber=23,dc=example,dc=com

However, this can lead to awkward common names for large directories and can be difficult to maintain.

A better method is to identify your person entries with some attribute other than cn. Consider using one of the following attributes:

Use the uid (userID) attribute to specify some unique value of the person. Possibilities include a user login ID or an employee number. A subscriber in a hosting environment should be identified by the uid attribute.
Use the mail attribute to contain the value for the person's email address. This option can lead to awkward DNs that include duplicate attribute values (for example: [email protected], dc=example,dc=com), so you should use this option only if you cannot find some unique value that you can use with the uid attribute. For example, you would use the mail attribute instead of the uid attribute if your enterprise does not assign employee numbers or user IDs for temporary or contract employees.
For employees of the inetOrgPerson object class, consider using an employer assigned attribute value such as employeeNumber.

Whatever you decide to use for an attribute-data pair for person entry RDNs, you should make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, uid=bjensen, dc=example,dc=com is preferable to uid=b12r56A, dc=example,dc=com because recognizable DNs simplify some directory tasks, such as changing directory entries based on their distinguished names. Also, some directory client applications assume that the uid and cn attributes use human-readable names.

Considerations for Person Entries in a Hosted Environment

If a person is a subscriber to a service, the entry should be of object class inetUser, and the entry should contain the uid attribute. The attribute must be unique within a customer subtree.

If a person is part of the hosting organization, represent them as an inetOrgPerson with the nsManagedPerson object class.

Placing Person Entries in the DIT

Here are some guidelines for placing people entries in your directory tree:

Naming Group Entries

There are four main ways to represent a group:

Static group entries must contain a uniqueMember attribute value because uniqueMember is a mandatory attribute of the groupOfUniqueNames object. This object class requires the cn attribute, which can be used to form the DN of the group entry.

In a deployment containing hosted organizations, we recommend using the groupOfUniqueNames object class to contain the values naming the members of groups used in directory administration. In a hosted organization, we also recommend that group entries used for directory administration be located under the ou=Groups branch.

Naming Organization Entries

The organization entry name, like other entry names, must be unique. Using the legal name of the organization along with other attribute values helps ensure the name is unique. For example, you might name an organization entry as follows: 

o=example_a+st=Washington,o=ISP,c=US

You can also use trademarks; however, they are not guaranteed to be unique.

In a hosting environment, you need to include the following attributes in the organization's entry:

Naming Other Kinds of Entries

Your directory will contain entries that represent many things, such as localities, states, countries, devices, servers, network information, and other kinds of data.

For these types of entries, use the commonName (cn) attribute in the RDN if possible. Then, if you are naming a group entry, name it as follows: 

cn=administrators,dc=example,dc=com

However, sometimes you need to name an entry whose object class does not support the commonName attribute. Instead, use an attribute that is supported by the entry's object class.

There does not have to be any correspondence between the attributes used for the entry's DN and the attributes actually used in the entry. However, a correspondence between the DN attributes and attributes used by the entry simplifies administration of your directory tree.

Grouping Directory Entries

Once you have created entries, you can group them for ease of administration. The Directory Server supports several methods for grouping entries and sharing attributes between entries:

The following sections describe each of these mechanisms in more detail.

About Roles

Roles are a new entry grouping mechanism. Your directory tree organizes information hierarchically. This hierarchy is a grouping mechanism, though it is not suited for short-lived, changing organizations. Roles provide another grouping mechanism for more temporary organizational structures.

Roles unify static and dynamic groups. You use static groups to create a group entry that contains a list of members. Dynamic groups allow you to filter entries that contain a particular attribute and include them in a single group.

Each entry assigned to a role contains the nsRole attribute, a computed attribute that specifies all of the roles an entry belongs to. A client application can check role membership by searching the nsRole attribute, which is computed by the directory and therefore always up-to-date.

Roles are designed to be more efficient and easier to use for applications. For example, applications can locate the roles of an entry rather than select a group and browse the members list.

You can use roles to do the following:

Having an enumerated list of role members can be useful for resolving queries for group members quickly.
Knowing the roles possessed by an entry can help you determine whether the entry possesses the target role.

Each role has members, entries that possess the role. You can specify members either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles depending upon an attribute contained by the entry). How you specify role membership depends upon the type of role you are using. There are three types of roles:

Deciding Between Roles and Groups

Both methods of grouping entries have advantages and disadvantages. Roles reduce client-side complexity at the cost of increased server complexity. With roles, the client application can check role membership by searching the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions and then runs the filter. For static groups, the application must make sure the user is part of a particular UniqueMember attribute value. The method for determining group membership is not uniform.

You can use managed roles to do everything you would normally do with static groups. You can filter group members using filtered roles as you used to do with dynamic groups.

While roles are easier to use, more flexible, and reduce client complexity, they do so at the cost of increased server complexity. Determining role membership is more resource intensive because the server does the work for the client application.

About Class of Service

A class of service (CoS) allows you to share attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

For example, your directory contains thousands of entries that all share the common attribute facsimileTelephoneNumber. Traditionally, to change the fax number, you would need to update each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, you can generate the attribute dynamically. The facsimileTelephoneNumber attribute is stored in one place, and each entry points to that place to give a value to their fax number attribute. For the application, these attributes appear just like all other attributes despite not actually being stored on the entries themselves.

Each CoS is comprised of the following entries in your directory:

The CoS definition entry and the template entry interact to provide attribute values to their target entries, the entries within their scope. The value they provide depends upon the following:

The absence of a service class attribute can imply a specific default CoS.
Each CoS template entry supplies the attribute value for a particular CoS.
CoS attribute values are generated only when an entry contains an object class allowing the attribute when schema checking is turned on; otherwise, all attribute values are generated.

You can use different types of CoS depending upon how you want the value of your dynamic attributes to be generated. There are three types of CoS:

Roles and the classic CoS can be used together to provide role-based attributes. These attributes appear on an entry because it possesses a particular role with an associated class of service template. For example, you could use a role-based attribute to set the server look through limit on a role-by-role basis.

Directory Tree Design Examples

The following sections provide examples of directory trees designed to support a flat hierarchy as well as several examples of more complicated hierarchies.

Directory Tree for an International Enterprise

To support an international enterprise, root your directory tree in your Internet domain name, and then branch your tree for each country where your enterprise has operations immediately below that root point. In "Suffix Naming Conventions," on page 61, you are advised to avoid rooting your directory tree in a country designator. This is especially true if your enterprise is international in scope.

Because LDAP places no restrictions on the order of the attributes in your DNs, you can use the c (countryName) attribute to represent each country branch as follows:




However, some administrators feel that this is stylistically awkward, so instead you could use the l (locality) attribute to represent different countries:




Directory Tree for an ISP

Internet service providers (ISPs) may support multiple enterprises with their directories. If you are an ISP, consider each of your customers as a unique enterprise and design their directory trees accordingly. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.

You can assign each customer a separate database and store these databases on separate servers. Placing each directory tree in its own database allows you to back up and restore data for each directory tree without affecting your other customers.

In addition, partitioning helps reduce performance problems caused by disk contention and reduces the number of accounts potentially affected by a disk outage.

For example, the directory tree for example, an ISP, appears as follows:




Virtual Directory Information Tree Views

Directory Server supports a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views or virtual DIT views.

Note

Virtual views are not entirely compatible with multiple backends in that the entries to be returned by the views must reside in the same backend; the search is limited to one backend.


Overview

When considering directory namespace, you have the choice of creating either of the following:

The hierarchical DIT is useful for navigating the directory but is cumbersome and time-consuming to change. The flat DIT, while requiring little to no change, does not provide a convenient way to navigate or manage the entries in the directory. A flat DIT also presents many management challenges as administration becomes more complex without any natural hierarchical groupings. On the other hand, a major organizational change to a hierarchical DIT can be an expensive and time-consuming operation as it usually involves considerable service disruption, which can only be minimized by operating during late hours and periods of low traffic. Also, moving millions of entries from one place in a hierarchy to another is a lot of work.

Figure 4-1 shows examples of a flat and an organizationally-based DIT.

Figure 4-1 Examples of a Flat and an Organizationally-Based DIT

Having decided upon a hierarchical DIT, a deployment must then decide upon the subject domain of the hierarchy. Only one choice can be made, and that tends to mean that only one natural choice is available: the organizational hierarchy.

This view of the organization serves well in many cases, but having just this one view can be very limiting for directory navigation and management. For example, an organization hierarchy is fine if you are looking for entries belonging to people in the Accounts department. However, this view is much less useful for finding entries that belong to people in a geographical location, such as Mountain View, California. The second query is equally valid as the first one, yet it requires knowledge of the attributes contained in the entries and additional search tools. For such a case, navigation via the DIT is not an option.

In a similar vein, management of the directory is made very much easier by having a DIT that matches the requirements of the management function. The organization of your DIT may be affected by other factors, too, such as replication and migration considerations, that cause the DIT to have functional utility for those applications but very little practical utility in other cases.

From the above discussion, it is clear that hierarchies are a useful mechanism for navigation and management. Yet, to avoid the burden of making changes to an existing DIT, a deployment may elect to forgo a hierarchy altogether in favor of a flat DIT.

It would be advantageous for deployments if the directory provided a way to create an arbitrary number of hierarchies that get mapped to entries without having to move the target entries in question. The virtual DIT views feature of Directory Server resolves the quandary of deciding the DIT type you should elect for your directory deployment.

Introduction to Virtual DIT Views

Virtual DIT views are a way to navigate hierarchically entries that do not require the physical existence of those entries in any particular place. The virtual DIT view uses information about the entries to place them in the view hierarchy. To client applications, virtual DIT views look just like ordinary container hierarchies. In a sense, virtual DIT views superimpose a DIT hierarchy over a set of entries, irrespective of whether those entries are in a flat namespace or in another hierarchy of their own.

Creating a virtual DIT view hierarchy is just like creating a normal DIT hierarchy. You create the same entries (for example, organizational unit entries) but with an additional object class (nsview) and a filter attribute (nsviewfilter) that describes the view. Once you add the additional attribute, the entries that match the view filter will instantly populate the view. The target entries only appear to exist in the view; their true location never changes. Virtual DIT views act just like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned.

For information about adding and modifying entries, refer to chapter 2 , "Creating Directory Entries," in the Red Hat Directory Server Administrator's Guide

Figure 4-2 A Combined DIT With Added Features Using Views

The DIT shown in Figure 4-2 illustrates what happens when the two DITs shown in Figure 4-1 are combined using views. Because views inherently allow entries to appear in more than one place in a view hierarchy, this feature has been used to expand the ou=Sales entry to enable viewing the Sales entries either by location or by product.

Given a set of virtual DIT view hierarchies, a directory user can navigate using the view that makes the most sense to get to the required entries. For example, if your target entries were those which dwell in Mountain View, a view which starts out navigating down using location-based information is most appropriate. If it were an organizational question, the organization view would work better. Both of these views exist in the Directory Server at the same time and operate on the same entries-they just have different concerns or objectives when displaying their version of the directory structure.

The entries in the views-enabled directory depicted in Figure 4-2 are contained in a flat namespace just below the parent of the top most view in the hierarchy. This is not required. The entries can exist in a hierarchy of their own. The only concern that a view has about the placement of an entry is that it must be a descendent of the parent of the view hierarchy.

Figure 4-3 A DIT With a Virtual DIT View Hierarchy

The DIT illustrated in Figure 4-3 shows a view hierarchy.

These are leaf nodes because they do not contain the real entries. However, when a client application searches these views, it will find Entry A under ou=Sunnyvale and Entry B under ou=Mountain View. This virtual search space is described by the nsviewfilter attributes of all ancestor views. A search made from a view will return both entries from the virtual search space and those from the actual search space. This enables the view hierarchies to function as a conventional DIT or turn a conventional DIT into a view hierarchy.

Advantages of Using Virtual DIT Views

Your deployment decisions become easier with virtual DIT views:

In addition, whenever there is a change to the DIT, the entries will never need to be moved; only the virtual DIT view hierarchies will change. Because these hierarchies contain no real entries, they are simple and quick to modify.
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 virtual DIT view, thereby facilitating a more gradual changeover for the entries themselves and for the applications that operate on them. Because an organizational change in the directory isn't an all-or-nothing operation, it may be performed over a period of time and without service disruption.
With the functionality provided by virtual DIT views, an organization can use both the old and new ways to organize directory data without any requirement to place entries at certain points in the DIT.
The flexibility of having more than one way to view and query directory information allows end users to find what they need intuitively through hierarchical navigation and for new applications to take advantage this feature.

Example of Virtual DIT Views

The LDIF entries below show a virtual DIT view hierarchy that is based on location. Any entry which resides below dc=example,dc=com and fits the view description will appear in this view, organized by location. 

dn: ou=Location Views,dc=example,dc=com

objectclass: top

objectclass: organizationalUnit

objectclass: nsView

ou: Location Views

description: views categorized by location



dn: ou=Sunnyvale, ou=Location Views,dc=example,dc=com

objectclass: top

objectclass: organizationalUnit

objectclass: nsView

ou: Sunnyvale

nsViewFilter: (l=Sunnyvale)

description: views categorized by location



dn: ou=Santa Clara, ou=Location Views,dc=example,dc=com

objectclass: top

objectclass: organizationalUnit

objectclass: nsView

ou: Santa Clara

nsViewFilter: (l=Santa Clara)

description: views categorized by location



dn: ou=Cupertino, ou=Location Views,dc=example,dc=com

objectclass: top

objectclass: organizationalUnit

objectclass: nsView

ou: Cupertino

nsViewFilter: (l=Cupertino)

description: views categorized by location

A subtree search based at ou=Location Views, dc=example,dc=com would return all entries below dc=example,dc=com which match the filters (l=Sunnyvale), (l=Santa Clara), or (l=Cupertino), whereas a one-level search would return no entries other than the child view entries because all qualifying entries reside in the three descendent views.

The ou=Location Views, dc=example,dc=com view entry itself does not contain a filter. This feature facilitates hierarchical organization without the requirement to restrict the entries contained in the view further. Any view may omit the filter. Although the example filters are very simple, the filter used may be as complex as necessary.

It may be desirable to limit the type of entry that the view is to contain. For example, to limit this hierarchy to contain only people entries, simply add an nsfilter attribute to ou=Location Views, dc=example,dc=com with the filter value (objectclass=organizationalperson).

Each view with a filter restricts the content of all descendent views while descendent views with filters also restrict their ancestor's contents. For example, creating the top view ou=Location Views first along with the new filter mentioned above would create a view with all entries with the organizational object class. When you add the descendent views that further restrict entries, the entries that now appear in the descendent views are removed from the ancestor views. This demonstrates how virtual DIT views mimic the behavior of traditional DITs.

Although virtual DIT views mimic the behavior of traditional DITs, views can do something that traditional DITs cannot: entries may appear in more than one place. For example, if it were required that Entry B be associated with both Mountain View and Sunnyvale (see Figure 4-3, on page 82), you can accomplish that by simply adding the Sunnyvale value to the location attribute, and the entry would appear in both views.

Views and Other Directory Features

Both class of service and roles features of the Directory Server support views; see "Grouping Directory Entries," on page 73. 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; for information on using these features, refer to chapter 5, "Advanced Entry Management," in the Red Hat Directory Server Administrator's Guide. 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.

Access control with views must be performed slightly differently than is usual. Because there is currently no explicit support for ACLs in views, it is recommended that you create role-based ACIs at the view parent and add the roles to the appropriate parts of the view hierarchy. In this way, you can take advantage of the organizational property of the hierarchy.

To clarify any doubts that you have about the effects of views on searching, understand that if the base of the search is a view and the scope of the search is not a base, then it is a views-based search. Otherwise, it is a conventional search. For example, if you perform a search with a base of dc=example,dc=com, then no entries from the virtual search space will be returned - in fact, no virtual-search-space search is performed. Views processing occurs only if the search base is ou=Location Views (or below). This way, views ensure that your search does not result in entries from both places (you would would get entries back from both places if it were a conventional DIT).

Effects of Virtual Views on Performance

The performance of views-based hierarchies is dependent on the make up of the hierarchy itself and the number of entries in the DIT. In general, you may see a marginal change in performance (within a few percentage points of equivalent searches on a conventional DIT) if virtual DIT views are enabled in your directory. If a search does not invoke a view, then there is no performance impact. As always, we recommend that before deployment, you must test your virtual DIT views against expected search patterns and loads.

We also recommend that the attributes used in view filters be indexed if the views are to be used as general-purpose navigation tools in the organization. Further, when a sub-filter used by views matches a configured virtual list view index, that index will be used in views evaluation.

There is no need to tune any other part of the directory specifically for views.

Compatibility with Existing Applications

Virtual DIT views are designed to mimic conventional DITs to a high degree. Most applications should continue to work without any knowledge 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 look and act like conventional DITs.

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

Other Directory Tree Resources

Take a look at the following links for more information about designing your directory tree:




Previous
 Contents
 Index
 Next
© 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
Read the Full Copyright and Third-Party Acknowledgments.

 last updated May 20, 2005