Table of Contents
Advertisement
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 of arbitrary
complexity.
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
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; that is, entries may appear in more than
one place. For example, if it were required that
and
Mountain View
that by simply adding the
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 71. 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 Netscape 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
(see Figure 4-3, on page 80), you can accomplish
Sunnyvale
value to the location attribute, and the entry
Sunnyvale
Virtual Directory Information Tree Views
view entry itself does not contain
.
first along with the new filter
be associated with both
Entry B
Chapter 4
Designing the Directory Tree
with the filter
83
Advertisement
Table of Contents
