Commit caa8f514 authored by Gavin Henry's avatar Gavin Henry
Browse files

aspell --lang=en_US -c

parent 0e507714
......@@ -18,7 +18,7 @@ special utilities provided with slapd. This method is best if you
have many thousands of entries to create, which would take an
unacceptably long time using the LDAP method, or if you want to
ensure the database is not accessed while it is being created. Note
that not all database types support these utilitites.
that not all database types support these utilities.
H2: Creating a database over LDAP
......
......@@ -7,7 +7,7 @@ H2: Terms
!catalog terms ''; headings; columns="Term,Definition"
H2: Related Organizations
!catalog organisations ''; headings; columns="ORG:Name,Long,URL:Jump"
!catalog organizations ''; headings; columns="ORG:Name,Long,URL:Jump"
H2: Related Products
!catalog products ''; headings; columns="PRD:Name,URL:Jump"
......
......@@ -21,7 +21,7 @@ directly from the project's {{TERM:FTP}} service at
The project makes available two series of packages for {{general
use}}. The project makes {{releases}} as new features and bug fixes
come available. Though the project takes steps to improve stablity
come available. Though the project takes steps to improve stability
of these releases, it is common for problems to arise only after
{{release}}. The {{stable}} release is the latest {{release}} which
has demonstrated stability through general use.
......
......@@ -57,8 +57,8 @@ support browsing and searching.
While some consider the Internet {{TERM[expand]DNS}} (DNS) is an
example of a globally distributed directory service, DNS is not
browsable nor searchable. It is more properly described as a
globaly distributed {{lookup}} service.
browseable nor searchable. It is more properly described as a
globally distributed {{lookup}} service.
H2: What is LDAP?
......@@ -220,7 +220,7 @@ LDAPv3 adds the following features to LDAP:
LDAPv2 is historic ({{REF:RFC3494}}). As most {{so-called}} LDAPv2
implementations (including {{slapd}}(8)) do not conform to the
LDAPv2 technical specification, interoperatibility amongst
LDAPv2 technical specification, interoperability amongst
implementations claiming LDAPv2 support is limited. As LDAPv2
differs significantly from LDAPv3, deploying both LDAPv2 and LDAPv3
simultaneously is quite problematic. LDAPv2 should be avoided.
......@@ -308,8 +308,8 @@ Or the impossibility to add new objectclasses to an existing entry or remove
one of those present. The restrictions span the range from allowed restrictions
(that might be elsewhere the result of access control) to outright violations of
the data model. It can be, however, a method to provide LDAP access to preexisting
data that is used by other applications. But in the understanding that we don't r
eally have a "directory".
data that is used by other applications. But in the understanding that we don't
really have a "directory".
Existing commercial LDAP server implementations that use a relational database
are either from the first kind or the third. I don't know of any implementation
......
......@@ -13,7 +13,7 @@ H2: Directory Backups
MORE
You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8)
back-bdb or back-hdbdatabases.
back-bdb or back-hdb databases.
> slapcat -f slapd.conf -b "dc=example,dc=com"
......@@ -78,7 +78,7 @@ The advantages of {{F:DB_CONFIG}} usage can be the following:
To figure out the best-practice BDB backup scenario, the reader is highly
recommended to read the whole Chapter 9: Berkeley DB Transactional Data Store Applications.
This chapter is a set of small pages with examples in C language. Non-prorgamming
This chapter is a set of small pages with examples in C language. Non-programming
people can skip this examples without loss of knowledge.
......
......@@ -55,7 +55,7 @@ First, ensure {{core.schema}} schema configuration file is included
by your {{slapd.conf}}(5) file. The {{monitor}} backend requires
it.
Second, instanticate the {{monitor backend}} by adding a
Second, instantiate the {{monitor backend}} by adding a
{{database monitor}} directive below your existing database
sections. For instance:
......@@ -64,7 +64,7 @@ sections. For instance:
Lastly, add additional global or database directives as needed.
Like most other database backends, the monitor backend does honor
slapd(8) access and other adminstrative controls. As some monitor
slapd(8) access and other administrative controls. As some monitor
information may be sensitive, it is generally recommend access to
cn=monitor be restricted to directory administrators and their
monitoring agents. Adding an {{access}} directive immediately below
......@@ -99,7 +99,7 @@ Note that unlike general purpose database backends, the database
suffix is hardcoded. It's always {{EX:cn=Monitor}}. So no {{suffix}}
directive should be provided. Also note that general purpose
database backends, the monitor backend cannot be instantiated
multiple times. That is, there can only be one (or zero) occurances
multiple times. That is, there can only be one (or zero) occurrences
of {{EX:database monitor}} in the server's configuration.
......
......@@ -15,7 +15,7 @@ may also be configured globally.
Essentially they represent a means to:
* customise the behavior of existing backends without changing the backend
* customize the behavior of existing backends without changing the backend
code and without requiring one to write a new custom backend with
complete functionality
* write functionality of general usefulness that can be applied to
......@@ -159,7 +159,7 @@ entries corresponding to search filters instead of subtrees.
H3: Overview
The proxy cache extension of slapd is designed to improve the
responseiveness of the ldap and meta backends. It handles a search
responsiveness of the ldap and meta backends. It handles a search
request (query)
by first determining whether it is contained in any cached search
filter. Contained requests are answered from the proxy cache's local
......@@ -216,7 +216,7 @@ total number of entries which may be held in the cache. The
<nattrsets> parameter specifies the total number of attribute sets
(as specified by the {{EX:proxyAttrSet}} directive) that may be
defined. The <entrylimit> parameter specifies the maximum number of
entries in a cachable query. The <period> specifies the consistency
entries in a cacheable query. The <period> specifies the consistency
check period (in seconds). In each period, queries with expired
TTLs are removed.
......@@ -311,7 +311,7 @@ H2: Referential Integrity
H3: Overview
This overlay can be used with a backend database such as slapd-bdb (5)
to maintain the cohesiveness of a schema which utilises reference
to maintain the cohesiveness of a schema which utilizes reference
attributes.
......@@ -399,7 +399,7 @@ H2: Overlay Stacking
H3: Overview
H3: Example Senarios
H3: Example Scenarios
H4: Samba
......@@ -23,7 +23,7 @@ has been completely removed from 2.4.
{{Why was it replaced?}}
The slurpd daemon was the original replication mechanisim inherited from
The slurpd daemon was the original replication mechanism inherited from
UMich's LDAP and operates in push mode: the master pushes changes to the
slaves. It has been replaced for many reasons, in brief:
......@@ -41,9 +41,9 @@ Syncrepl.
{{Why is Syncrepl better?}}
- Syncrepl is self-synchronising; you can start with a database in any
state from totally empty to fully sync'd and it will automatically do
the right thing to achieve and maintain synchronisation
- Syncrepl is self-synchronizing; you can start with a database in any
state from totally empty to fully synced and it will automatically do
the right thing to achieve and maintain synchronization
- Syncrepl can operate in either direction
- Data updates can be minimal or maximal
......@@ -52,7 +52,7 @@ Syncrepl.
The easiest way is to point an LDAP backend ({{SECT: Backends}} and {{slapd-ldap(8)}})
to your slave/s directory and setup Syncrepl to point to your Master database.
REFERENCE test045/048 for better explaination of above.
REFERENCE test045/048 for better explanation of above.
If you imagine Syncrepl pulling down changes from the Master server, and then
pushing those changes out to your slave servers via {{slapd-ldap(8)}}. This is
......@@ -104,7 +104,7 @@ Here's an example:
> credentials=monitor
>
> # HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply
> # whithout the need to write the UpdateDN before starting replication
> # without the need to write the UpdateDN before starting replication
> syncrepl rid=1
> provider=ldap://localhost:9011/
> binddn="cn=Manager,dc=example,dc=com"
......@@ -122,7 +122,7 @@ Here's an example:
>
> database monitor
DETAILED EXPLAINATION OF ABOVE LIKE IN OTHER SECTIONS (line numbers?)
DETAILED EXPLANATION OF ABOVE LIKE IN OTHER SECTIONS (line numbers?)
ANOTHER DIAGRAM HERE
......
......@@ -353,7 +353,7 @@ allows zero or more repeats of the immediately preceding character
or pattern, and terms in parenthesis are remembered for the replacement
pattern.
The replacement pattern will produce either a DN or URL refering
The replacement pattern will produce either a DN or URL referring
to the user. Anything from the authentication request DN that
matched a string in parenthesis in the search pattern is stored in
the variable "$1". That variable "$1" can appear in the replacement
......@@ -543,7 +543,7 @@ database could then be only allowed by that DN, and in order to
become that DN, users must first authenticate as one of the persons
on the list. This allows for better auditing of who made changes
to the LDAP database. If people were allowed to authenticate
directly to the priviliged account, possibly through the {{EX:rootpw}}
directly to the privileged account, possibly through the {{EX:rootpw}}
{{slapd.conf}}(5) directive or through a {{EX:userPassword}}
attribute, then auditing becomes more difficult.
......@@ -577,7 +577,7 @@ or
In the first form, the <username> is from the same namespace as
the authentication identities above. It is the user's username as
it is refered to by the underlying authentication mechanism.
it is referred to by the underlying authentication mechanism.
Authorization identities of this form are converted into a DN format
by the same function that the authentication process used, producing
an {{authorization request DN}} of the form
......@@ -618,7 +618,7 @@ authentication DN entry, and if none of the {{EX:authzTo}} rules
specify the authorization is permitted, the {{EX:authzFrom}}
rules in the authorization DN entry are then checked. If neither
case specifies that the request be honored, the request is denied.
Since the default behaviour is to deny authorization requests, rules
Since the default behavior is to deny authorization requests, rules
only specify that a request be allowed; there are no negative rules
telling what authorizations to deny.
......@@ -662,7 +662,7 @@ comparison can be evaluated much faster than an LDAP search for
Also note that the values in an authorization rule must be one of
the two forms: an LDAP URL or a DN (with or without regular expression
characters). Anything that does not begin with "{{EX:ldap://}}" is
taken as a DN. It is not permissable to enter another authorization
taken as a DN. It is not permissible to enter another authorization
identity of the form "{{EX:u:<username>}}" as an authorization rule.
......
......@@ -5,7 +5,7 @@
H1: Schema Specification
This chapter describes how to extend the user schema used by
{{slapd}}(8). The chapter assumes the reader is familar with the
{{slapd}}(8). The chapter assumes the reader is familiar with the
{{TERM:LDAP}}/{{TERM:X.500}} information model.
The first section, {{SECT:Distributed Schema Files}} details optional
......@@ -72,7 +72,7 @@ matching rules and system schema, but this requires some programming
and hence is not discussed here.
There are five steps to defining new schema:
^ obtain Object Identifer
^ obtain Object Identifier
+ choose a name prefix
+ create local schema file
+ define custom attribute types (if necessary)
......@@ -104,7 +104,7 @@ OID Assignment
You are, of course, free to design a hierarchy suitable to your
organizational needs under your organization's OID. No matter what hierarchy you choose, you should maintain a registry of assignments you make. This can be a simple flat file or something more sophisticated such as the {{OpenLDAP OID Registry}} ({{URL:http://www.openldap.org/faq/index.cgi?file=197}}).
For more information about Object Identifers (and a listing service)
For more information about Object Identifiers (and a listing service)
see {{URL:http://www.alvestrand.no/harald/objectid/}}.
.{{Under no circumstances should you hijack OID namespace!}}
......@@ -130,7 +130,7 @@ prefixed with "x-" to place in the "private use" name space.
The name should be both descriptive and not likely to clash with
names of other schema elements. In particular, any name you choose
should not clash with present or future Standard Track names (this
is assured if you registered names or use names begining with "x-").
is assured if you registered names or use names beginning with "x-").
It is noted that you can obtain your own registered name
prefix so as to avoid having to register your names individually.
......@@ -238,7 +238,7 @@ distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP {{TERM:DN}}
integer 1.3.6.1.4.1.1466.115.121.1.27 integer
numericString 1.3.6.1.4.1.1466.115.121.1.36 numeric string
OID 1.3.6.1.4.1.1466.115.121.1.38 object identifier
octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitary octets
octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitrary octets
!endblock
>
......
......@@ -143,7 +143,7 @@ this mechanism should generally remain disabled.
A successful user/password authenticated bind results in a user
authorization identity, the provided name, being associated with
the session. User/password authenticated bind is enabled by default.
However, as this mechanism itself offers no evesdropping protection
However, as this mechanism itself offers no eavesdropping protection
(e.g., the password is set in the clear), it is recommended that
it be used only in tightly controlled systems or when the LDAP
session is protected by other means (e.g., TLS, {{TERM:IPsec}}).
......
......@@ -398,7 +398,7 @@ H4: olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+
This directive grants access (specified by <accesslevel>) to a
set of entries and/or attributes (specified by <what>) by one or
more requesters (specified by <who>).
more requestors (specified by <who>).
See the {{SECT:Access Control}} section of this chapter for a
summary of basic usage.
......@@ -734,7 +734,7 @@ This directive specifies how often to checkpoint the BDB transaction log.
A checkpoint operation flushes the database buffers to disk and writes a
checkpoint record in the log.
The checkpoint will occur if either <kbyte> data has been written or
<min> minutes have passed since the last checkpont. Both arguments default
<min> minutes have passed since the last checkpoint. Both arguments default
to zero, in which case they are ignored. When the <min> argument is
non-zero, an internal task will run every <min> minutes to perform the
checkpoint. See the Berkeley DB reference guide for more details.
......@@ -751,7 +751,7 @@ This attribute specifies a configuration directive to be placed in the
no such file exists yet, the {{EX:DB_CONFIG}} file will be created and the
settings in this attribute will be written to it. If the file exists,
its contents will be read and displayed in this attribute. The attribute
is multi-valued, to accomodate multiple configuration directives. No default
is multi-valued, to accommodate multiple configuration directives. No default
is provided, but it is essential to use proper settings here to get the
best server performance.
......@@ -781,7 +781,7 @@ cleanup procedure removes them. See the Berkeley DB documentation for the
Ideally the BDB cache must be
at least as large as the working set of the database, the log buffer size
should be large enough to accomodate most transactions without overflowing,
should be large enough to accommodate most transactions without overflowing,
and the log directory must be on a separate physical disk from the main
database files. And both the database directory and the log directory
should be separate from disks used for regular system activities such as
......@@ -898,7 +898,7 @@ created database index files should have.
H4: olcDbSearchStack: <integer>
Specify the depth of the stack used for search filter evaluation.
Search filters are evaluated on a stack to accomodate nested {{EX:AND}} /
Search filters are evaluated on a stack to accommodate nested {{EX:AND}} /
{{EX:OR}} clauses. An individual stack is allocated for each server thread.
The depth of the stack determines how complex a filter can be evaluated
without requiring any additional memory allocation. Filters that are
......
......@@ -91,7 +91,7 @@ H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
This directive grants access (specified by <accesslevel>) to a set
of entries and/or attributes (specified by <what>) by one or more
requesters (specified by <who>). See the {{SECT:The access
requestors (specified by <who>). See the {{SECT:The access
Configuration Directive}} section of this chapter for a summary of
basic usage.
......
......@@ -179,7 +179,7 @@ be configured on a system-wide basis, they may all be overridden by
individual users in their {{.ldaprc}} files.
The LDAP Start TLS operation is used in LDAP to initiate TLS
negotatation. All OpenLDAP command line tools support a {{EX:-Z}}
negotiation. All OpenLDAP command line tools support a {{EX:-Z}}
and {{EX:-ZZ}} flag to indicate whether a Start TLS operation is to
be issued. The latter flag indicates that the tool is to cease
processing if TLS cannot be started while the former allows the
......
......@@ -21,7 +21,7 @@ H2: 3rd party software error
The OpenLDAP Project only supports OpenLDAP software.
You may however seek commerical support ({{URL:http://www.openldap.org/support/}}) or join
You may however seek commercial support ({{URL:http://www.openldap.org/support/}}) or join
the general LDAP forum for non-commercial discussions and information relating to LDAP at:
{{URL:http://www.umich.edu/~dirsvcs/ldap/mailinglist.html}}
......
......@@ -78,7 +78,7 @@ General rule: don't go overboard with indexes. Unused indexes must be maintained
See {{slapd.conf}}(8) and {{slapdindex}}(8) for more information
H3: Presense indexing
H3: Presence indexing
If your client application uses presence filters and if the
target attribute exists on the majority of entries in your target scope, then
......@@ -214,7 +214,7 @@ check this number for both dn2id and id2entry.
Also note that {{id2entry}} always uses 16KB per "page", while {{dn2id}} uses whatever
the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing the,
your cache must be at least as large as the number of internal pages in both
the {{dn2id}} and {{id2entry}} databases, plus some extra space to accomodate the actual
the {{dn2id}} and {{id2entry}} databases, plus some extra space to accommodate the actual
leaf data pages.
For example, in my OpenLDAP 2.4 test database, I have an input LDIF file that's
......@@ -334,7 +334,7 @@ It will consume the memory resources of your system, and likely cause issues.
I try to cache the most actively used entries. Unless you expect all 400,000 entries of your DB to be accessed regularly, there is no need to cache that many entries. My entry cache is set to 20,000 (out of a little over 400,000 entries).
The idl cache has to do with how many unique result sets of searches you want to store in memory. Setting up this cache will allow your most frequently placed searches to get results much faster, but I doubt you want to try and cache the results of every search that hits your system. ;)
The idlcache has to do with how many unique result sets of searches you want to store in memory. Setting up this cache will allow your most frequently placed searches to get results much faster, but I doubt you want to try and cache the results of every search that hits your system. ;)
--Quanah
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment