From: Gavin Henry Date: Mon, 6 Aug 2007 16:08:05 +0000 (+0000) Subject: aspell --lang=en_US -c X-Git-Tag: OPENLDAP_REL_ENG_2_4_MP~260 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=caa8f5149871ccdc3f69b3ba081fc2f23c453460;p=openldap aspell --lang=en_US -c --- diff --git a/doc/guide/admin/dbtools.sdf b/doc/guide/admin/dbtools.sdf index 3de7710d30..61b2aec692 100644 --- a/doc/guide/admin/dbtools.sdf +++ b/doc/guide/admin/dbtools.sdf @@ -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 diff --git a/doc/guide/admin/glossary.sdf b/doc/guide/admin/glossary.sdf index 28507e18a7..1150c96b22 100644 --- a/doc/guide/admin/glossary.sdf +++ b/doc/guide/admin/glossary.sdf @@ -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" diff --git a/doc/guide/admin/install.sdf b/doc/guide/admin/install.sdf index 18e113f529..77d5288ba5 100644 --- a/doc/guide/admin/install.sdf +++ b/doc/guide/admin/install.sdf @@ -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. diff --git a/doc/guide/admin/intro.sdf b/doc/guide/admin/intro.sdf index aedc5b0a8b..4c8afea472 100644 --- a/doc/guide/admin/intro.sdf +++ b/doc/guide/admin/intro.sdf @@ -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 diff --git a/doc/guide/admin/maintenance.sdf b/doc/guide/admin/maintenance.sdf index b4160d717a..0680c04eca 100644 --- a/doc/guide/admin/maintenance.sdf +++ b/doc/guide/admin/maintenance.sdf @@ -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. diff --git a/doc/guide/admin/monitoringslapd.sdf b/doc/guide/admin/monitoringslapd.sdf index cc2311b605..f09ec97031 100644 --- a/doc/guide/admin/monitoringslapd.sdf +++ b/doc/guide/admin/monitoringslapd.sdf @@ -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. diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf index e0c253ea2c..36f78b195f 100644 --- a/doc/guide/admin/overlays.sdf +++ b/doc/guide/admin/overlays.sdf @@ -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 parameter specifies the total number of attribute sets (as specified by the {{EX:proxyAttrSet}} directive) that may be defined. The parameter specifies the maximum number of -entries in a cachable query. The specifies the consistency +entries in a cacheable query. The 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 diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 7f1beb3657..a63dc1d198 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -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 diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf index 0e078f31d9..5f30dc6bc2 100644 --- a/doc/guide/admin/sasl.sdf +++ b/doc/guide/admin/sasl.sdf @@ -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 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:}}" as an authorization rule. diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf index 927e94ef3a..543aaf7167 100644 --- a/doc/guide/admin/schema.sdf +++ b/doc/guide/admin/schema.sdf @@ -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 > diff --git a/doc/guide/admin/security.sdf b/doc/guide/admin/security.sdf index 645ca06c18..8616d5dc37 100644 --- a/doc/guide/admin/security.sdf +++ b/doc/guide/admin/security.sdf @@ -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}}). diff --git a/doc/guide/admin/slapdconf2.sdf b/doc/guide/admin/slapdconf2.sdf index cdcb27385e..001f3ae087 100644 --- a/doc/guide/admin/slapdconf2.sdf +++ b/doc/guide/admin/slapdconf2.sdf @@ -398,7 +398,7 @@ H4: olcAccess: to [ by [] [] ]+ This directive grants access (specified by ) to a set of entries and/or attributes (specified by ) by one or -more requesters (specified by ). +more requestors (specified by ). 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 data has been written or - minutes have passed since the last checkpont. Both arguments default + minutes have passed since the last checkpoint. Both arguments default to zero, in which case they are ignored. When the argument is non-zero, an internal task will run every 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: 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 diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf index 90981e609d..0e19d779ac 100644 --- a/doc/guide/admin/slapdconfig.sdf +++ b/doc/guide/admin/slapdconfig.sdf @@ -91,7 +91,7 @@ H4: access to [ by [] [] ]+ This directive grants access (specified by ) to a set of entries and/or attributes (specified by ) by one or more -requesters (specified by ). See the {{SECT:The access +requestors (specified by ). See the {{SECT:The access Configuration Directive}} section of this chapter for a summary of basic usage. diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf index c1b22a6aa9..e1fa756cba 100644 --- a/doc/guide/admin/tls.sdf +++ b/doc/guide/admin/tls.sdf @@ -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 diff --git a/doc/guide/admin/troubleshooting.sdf b/doc/guide/admin/troubleshooting.sdf index 5790e15ae5..fdfce7d3e3 100644 --- a/doc/guide/admin/troubleshooting.sdf +++ b/doc/guide/admin/troubleshooting.sdf @@ -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}} diff --git a/doc/guide/admin/tuning.sdf b/doc/guide/admin/tuning.sdf index 486aef445a..e791e0a9d8 100644 --- a/doc/guide/admin/tuning.sdf +++ b/doc/guide/admin/tuning.sdf @@ -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