Views And Other Directory Features - Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT Deployment Manual

Chapter 4. Designing the Directory Tree
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). Conversely, a one-level search would return no entries other than the child view
entries because all qualifying entries reside in the three descendant 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 further restrict the entries
contained in the view. Any view may omit the filter. Although the example filters are very simple, the
filter used can be as complex as necessary.
It may be desirable to limit the type of entry that the view should contain. For example, to limit this
hierarchy to contain only people entries, 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 descendant views, while descendant views with
filters also restrict their ancestor's contents. For example, creating the top view ou=Location
Views first together with the new filter mentioned above would create a view with all entries with
the organization object class. When the descendant views are added that further restrict entries,
the entries that now appear in the descendant 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 can appear in more than one location. For example, to associate
Figure 4.12, "A DIT with a Virtual DIT
Entry B with both Mountain View and Sunnyvale (see
View Hierarchy"), add the Sunnyvale value to the location attribute, and the entry appears in both
views.

4.4.4. Views and Other Directory Features

Both class of service and roles in Directory Server support views; see Section 4.3, "Grouping Directory
Entries". 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.
For information on using these features, refer to "Advanced Entry Management," in the Red Hat
Directory Server Administrator's Guide.
The use of views requires a slightly different approach to access control. Because there is currently no
explicit support for ACLs in views, create role-based ACLs 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.
52