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

The
ou=Location Views, dc=example,dc=com
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
attribute to
nsfilter
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
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
and
View Sunnyvale
simply adding the
Sunnyvale
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 75. 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.
ou=Location Views, dc=example,dc=com
ou=Location Views
Entry B
(see Figure 4-3, on page 84), you can accomplish that by
value to the location attribute, and the entry would
Virtual Directory Information Tree Views
view entry itself does not contain
.
first along with the new filter would
be associated with both
Chapter 4 Designing the Directory Tree
with the filter
Mountain
87