From: Kurt Zeilenga Date: Fri, 8 Dec 2006 01:57:07 +0000 (+0000) Subject: More term updates X-Git-Tag: OPENLDAP_REL_ENG_2_4_4ALPHA~8^2~404 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=5e3303a6b71a5b7a6062f50f8bd37dc5f6fcd554;p=openldap More term updates --- diff --git a/doc/guide/admin/proxycache.sdf b/doc/guide/admin/proxycache.sdf index 5fd2b3420f..1e13bc645d 100644 --- a/doc/guide/admin/proxycache.sdf +++ b/doc/guide/admin/proxycache.sdf @@ -4,12 +4,12 @@ H1: The Proxy Cache Engine -LDAP servers typically hold one or more subtrees of a DIT. Replica -(or shadow) servers hold shadow copies of entries held by one or -more master servers. Changes are propagated from the master server -to replica (slave) servers using LDAP Sync or {{slurpd}}(8). An -LDAP cache is a special type of replica which holds entries -corresponding to search filters instead of subtrees. +{{TERM:LDAP}} servers typically hold one or more subtrees of a +{{TERM:DIT}}. Replica (or shadow) servers hold shadow copies of +entries held by one or more master servers. Changes are propagated +from the master server to replica (slave) servers using LDAP Sync +or {{slurpd}}(8). An LDAP cache is a special type of replica which +holds entries corresponding to search filters instead of subtrees. H2: Overview diff --git a/doc/guide/admin/quickstart.sdf b/doc/guide/admin/quickstart.sdf index 38864491bf..a2cc04f99a 100644 --- a/doc/guide/admin/quickstart.sdf +++ b/doc/guide/admin/quickstart.sdf @@ -5,7 +5,7 @@ H1: A Quick-Start Guide The following is a quick start guide to [[DOC_NAME]], -including the stand-alone LDAP daemon, {{slapd}}(8). +including the stand-alone {{TERM:LDAP}} daemon, {{slapd}}(8). It is meant to walk you through the basic steps needed to install and configure OpenLDAP Software. It should be used in conjunction @@ -27,7 +27,7 @@ Guide. ^{{B: Get the software}} . You can obtain a copy of the software by following the -instructions on the OpenLDAP download page +instructions on the OpenLDAP Software download page ({{URL: http://www.openldap.org/software/download/}}). It is recommended that new users start with the latest {{release}}. @@ -56,7 +56,7 @@ name of the release. {{F:README}} and {{F:INSTALL}} documents provided with the distribution. The {{F:COPYRIGHT}} and {{F:LICENSE}} provide information on acceptable use, copying, and limitation of warranty of OpenLDAP -software. +Software. .{{S: }} . You should also review other chapters of this document. @@ -198,7 +198,8 @@ in the {{slapd}}(8) manual page and the +{{B:Add initial entries to your directory}}. . You can use {{ldapadd}}(1) to add entries to your LDAP directory. -{{ldapadd}} expects input in LDIF form. We'll do it in two steps: +{{ldapadd}} expects input in {{TERM:LDIF}} form. We'll do it in two +steps: ^^ create an LDIF file ++ run ldapadd diff --git a/doc/guide/admin/runningslapd.sdf b/doc/guide/admin/runningslapd.sdf index 07f205438a..1d9e896655 100644 --- a/doc/guide/admin/runningslapd.sdf +++ b/doc/guide/admin/runningslapd.sdf @@ -22,16 +22,17 @@ The default is normally {{F:/usr/local/etc/openldap/slapd.conf}}. > -h This option specifies alternative listener configurations. The -default is {{EX:ldap:///}} which implies LDAP over TCP on all -interfaces on the default LDAP port 389. You can specify -specific host-port pairs or other protocol schemes (such as -ldaps:// or ldapi://). For example, -{{EX:-h "ldaps:// ldap://127.0.0.1:666"}} will create -two listeners: one for LDAP over SSL on all interfaces on -the default LDAP/SSL port 636, and one for LDAP over TCP on -the {{EX:localhost}} ({{loopback}}) interface on port 666. -Hosts may be specified using IPv4 dotted-decimal form or -using host names. Port values must be numeric. +default is {{EX:ldap:///}} which implies {{TERM:LDAP}} over +{{TERM:TCP}} on all interfaces on the default LDAP port 389. You +can specify specific host-port pairs or other protocol schemes (such +as {{EX:ldaps://}} or {{EX:ldapi://}}). For example, {{EX:-h +"ldaps:// ldap://127.0.0.1:666"}} will create two listeners: one +for the (non-standard) {{EX:ldaps://}} scheme on all interfaces on +the default {{EX:ldaps://}} port 636, and one for the standard +{{EX:ldap://}} scheme on the {{EX:localhost}} ({{loopback}}) interface +on port 666. Hosts may be specified using using hostnames or +{{TERM:IPv4}} or {{TERM:IPv6}} addresses. Port values must be +numeric. > -n @@ -67,7 +68,7 @@ exits, regardless of any other options you give it. Current debugging levels are !block table; colaligns="RL"; align=Center; \ - title="Table 6.1: Debugging Levels" + title="Table 7.1: Debugging Levels" Level Description -1 enable all debugging 0 no debugging @@ -113,7 +114,7 @@ terminal and run in the background. H2: Stopping slapd -To kill off slapd safely, you should give a command like this +To kill off {{slapd}}(8) safely, you should give a command like this > kill -INT `cat /usr/local/var/slapd.pid` diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf index 4b36cafa7e..cb7773af35 100644 --- a/doc/guide/admin/sasl.sdf +++ b/doc/guide/admin/sasl.sdf @@ -10,18 +10,18 @@ SASL in OpenLDAP. There are several industry standard authentication mechanisms that can be used with SASL, including {{TERM:GSSAPI}} for {{TERM:Kerberos}} -V, DIGEST-MD5, and PLAIN and EXTERNAL for use with {{TERM[expand]TLS}} -(TLS). +V, {{TERM:DIGEST-MD5}}, and {{TERM:PLAIN}} and {{TERM:EXTERNAL}} +for use with {{TERM[expand]TLS}} (TLS). The standard client tools provided with OpenLDAP Software, such as {{ldapsearch}}(1) and {{ldapmodify}}(1), will by default attempt -to authenticate the user to the {{slapd}}(8) server using SASL. -Basic authentication service can be set up by the LDAP administrator -with a few steps, allowing users to be authenticated to the slapd -server as their LDAP entry. With a few extra steps, some users and -services can be allowed to exploit SASL's proxy authorization -feature, allowing them to authenticate themselves and then switch -their identity to that of another user or service. +to authenticate the user to the {{TERM:LDAP}} directory server using +SASL. Basic authentication service can be set up by the LDAP +administrator with a few steps, allowing users to be authenticated +to the slapd server as their LDAP entry. With a few extra steps, +some users and services can be allowed to exploit SASL's proxy +authorization feature, allowing them to authenticate themselves and +then switch their identity to that of another user or service. This chapter assumes you have read {{Cyrus SASL for System Administrators}}, provided with the {{PRD:Cyrus SASL}} @@ -56,19 +56,19 @@ document. The DIGEST-MD5 mechanism is the mandatory-to-implement authentication mechanism for LDAPv3. Though DIGEST-MD5 is not a strong authentication mechanism in comparison with trusted third party authentication -systems (such as Kerberos or public key systems), it does offer -significant protections against a number of attacks. Unlike the -CRAM-MD5 mechanism, it prevents chosen plaintext attacks. DIGEST-MD5 -is favored over the use of plaintext password mechanisms. The -CRAM-MD5 mechanism is deprecated in favor of DIGEST-MD5. Use of -{{SECT:DIGEST-MD5}} is discussed below. - -The GSSAPI mechanism utilizes Kerberos V to provide secure -authentication services. The KERBEROS_V4 mechanism is available -for those using Kerberos IV. Kerberos is viewed as a secure, -distributed authentication system suitable for both small and large -enterprises. Use of {{SECT:GSSAPI}} and {{SECT:KERBEROS_V4}} are -discussed below. +systems (such as {{TERM:Kerberos}} or public key systems), it does +offer significant protections against a number of attacks. Unlike +the {{TERM:CRAM-MD5}} mechanism, it prevents chosen plaintext +attacks. DIGEST-MD5 is favored over the use of plaintext password +mechanisms. The CRAM-MD5 mechanism is deprecated in favor of +DIGEST-MD5. Use of {{SECT:DIGEST-MD5}} is discussed below. + +The GSSAPI mechanism utilizes {{TERM:GSS-API}} {{TERM:Kerberos}} V +to provide secure authentication services. The KERBEROS_V4 mechanism +is available for those using Kerberos IV. Kerberos is viewed as a +secure, distributed authentication system suitable for both small +and large enterprises. Use of {{SECT:GSSAPI}} and {{SECT:KERBEROS_V4}} +are discussed below. The EXTERNAL mechanism utilizes authentication services provided by lower level network services such as {{TERM:TLS}} (TLS). When @@ -85,18 +85,18 @@ document. H2: SASL Authentication Getting basic SASL authentication running involves a few steps. -The first step configures your slapd server environment so -that it can communicate with client programs using the security -system in place at your site. This usually involves setting up a -service key, a public key, or other form of secret. The second step -concerns mapping authentication identities to LDAP DN's, which +The first step configures your slapd server environment so that it +can communicate with client programs using the security system in +place at your site. This usually involves setting up a service key, +a public key, or other form of secret. The second step concerns +mapping authentication identities to LDAP {{TERM:DN}}'s, which depends on how entries are laid out in your directory. An explanation of the first step will be given in the next section using Kerberos V4 as an example mechanism. The steps necessary for your site's authentication mechanism will be similar, but a guide to every mechanism available under SASL is beyond the scope of this chapter. -The second step is described in the section -{{SECT:Mapping Authentication Identities}}. +The second step is described in the section {{SECT:Mapping +Authentication Identities}}. H3: GSSAPI diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf index 6a14fb3e7e..44508dbe3b 100644 --- a/doc/guide/admin/schema.sdf +++ b/doc/guide/admin/schema.sdf @@ -28,7 +28,7 @@ indirectly). H2: Distributed Schema Files -OpenLDAP is distributed with a set of schema specifications for +OpenLDAP Software is distributed with a set of schema specifications for your use. Each set is defined in a file suitable for inclusion (using the {{EX:include}} directive) in your {{slapd.conf}}(5) file. These schema files are normally installed in the @@ -55,7 +55,7 @@ desired file in the global definitions portion of your > include /usr/local/etc/openldap/schema/inetorgperson.schema Additional files may be available. Please consult the OpenLDAP -FAQ ({{URL:http://www.openldap.org/faq/}}). +{{TERM:FAQ}} ({{URL:http://www.openldap.org/faq/}}). Note: You should not modify any of the schema items defined in provided files. @@ -229,22 +229,22 @@ and a brief description. Each name is an alias for the OID. {{slapd}}(8) returns the first listed name when returning results. The first attribute, {{EX:name}}, holds values of {{EX:directoryString}} -(UTF-8 encoded Unicode) syntax. The syntax is specified by OID -(1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString -syntax). A length recommendation of 32768 is specified. Servers -should support values of this length, but may support longer values -The field does NOT specify a size constraint, so is ignored on -servers (such as slapd) which don't impose such size limits. In -addition, the equality and substring matching uses case ignore -rules. Below are tables listing commonly used syntax and -matching rules (OpenLDAP supports these and many more). +({{TERM:UTF-8}} encoded Unicode) syntax. The syntax is +specified by OID (1.3.6.1.4.1.1466.115.121.1.15 identifies the +directoryString syntax). A length recommendation of 32768 is +specified. Servers should support values of this length, but may +support longer values The field does NOT specify a size constraint, +so is ignored on servers (such as slapd) which don't impose such +size limits. In addition, the equality and substring matching uses +case ignore rules. Below are tables listing commonly used syntax +and matching rules ({{slapd}}(8) supports these and many more). !block table; align=Center; coltags="EX,EX,N"; \ title="Table 8.3: Commonly Used Syntaxes" Name OID Description boolean 1.3.6.1.4.1.1466.115.121.1.7 boolean value directoryString 1.3.6.1.4.1.1466.115.121.1.15 Unicode (UTF-8) string -distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP DN +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 @@ -406,8 +406,8 @@ and {{EX:givenName}} and allows {{EX:x-my-Photo}}. H2: Transferring Schema Since the {{slapd.conf}}(5) schema directives use {{REF:RFC4512}} -format values, you can extract schema elements published by -any LDAPv3 server and easily construct directives for use with +format values, you can extract schema elements published by any +{{TERM:LDAPv3}} server and easily construct directives for use with {{slapd}}(8). LDAPv3 servers publish schema elements in special {{subschema}} diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf index 0ad1b2308c..c97e145f8d 100644 --- a/doc/guide/admin/slapdconfig.sdf +++ b/doc/guide/admin/slapdconfig.sdf @@ -142,7 +142,7 @@ correspond to what kind of debugging, invoke slapd with {{EX:-?}} or consult the table below. The possible values for are: !block table; colaligns="RL"; align=Center; \ - title="Table 5.1: Debugging Levels" + title="Table 6.1: Debugging Levels" Level Description -1 enable all debugging 0 no debugging @@ -229,7 +229,7 @@ H4: backend This directive marks the beginning of a backend declaration. {{EX:}} should be one of the -supported backend types listed in Table 5.2. +supported backend types listed in Table 6.2. !block table; align=Center; coltags="EX,N"; \ title="Table 5.2: Database Backends" @@ -264,7 +264,7 @@ H4: database This directive marks the beginning of a database instance declaration. {{EX:}} should be one of the -supported backend types listed in Table 5.2. +supported backend types listed in Table 6.2. \Example: @@ -716,7 +716,7 @@ access. Note that access is granted to "entities" not "entries." The following table summarizes entity specifiers: !block table; align=Center; coltags="EX,N"; \ - title="Table 5.3: Access Entity Specifiers" + title="Table 6.3: Access Entity Specifiers" Specifier|Entities *|All, including anonymous and authenticated users anonymous|Anonymous (non-authenticated) users @@ -749,7 +749,7 @@ H3: The access to grant The kind of granted can be one of the following: !block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \ - title="Table 5.4: Access Levels" + title="Table 6.4: Access Levels" Level Privileges Description none =0 no access disclose =d needed for information disclosure on error diff --git a/doc/guide/admin/syncrepl.sdf b/doc/guide/admin/syncrepl.sdf index 29536bf0ad..ac42ae3042 100644 --- a/doc/guide/admin/syncrepl.sdf +++ b/doc/guide/admin/syncrepl.sdf @@ -4,14 +4,14 @@ H1: LDAP Sync Replication -The LDAP Sync replication engine, syncrepl for short, is a consumer-side -replication engine that enables the consumer LDAP server to maintain -a shadow copy of a DIT fragment. A syncrepl engine resides at the -consumer-side as one of the {{slapd}} (8) threads. It creates and -maintains a consumer replica by connecting to the replication -provider to perform the initial DIT content load followed either -by periodic content polling or by timely updates upon content -changes. +The LDAP Sync Replication engine, {{syncrepl}} for short, is a +consumer-side replication engine that enables the consumer {{TERM:LDAP}} +server to maintain a shadow copy of a DIT fragment. A syncrepl +engine resides at the consumer-side as one of the {{slapd}} (8) +threads. It creates and maintains a consumer replica by connecting +to the replication provider to perform the initial {{TERM:DIT}} +content load followed either by periodic content polling or by +timely updates upon content changes. Syncrepl uses the LDAP Content Synchronization (or LDAP Sync for short) protocol as the replica synchronization protocol. It provides diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf index 240064d740..116f04af9a 100644 --- a/doc/guide/admin/tls.sdf +++ b/doc/guide/admin/tls.sdf @@ -6,25 +6,26 @@ H1: Using TLS OpenLDAP clients and servers are capable of using the {{TERM[expand]TLS}} ({{TERM:TLS}}) framework to provide integrity and confidentiality protections and to support -LDAP authentication using the {{TERM:SASL}} EXTERNAL mechanism. +LDAP authentication using the {{TERM:SASL}} {{TERM:EXTERNAL}} mechanism. TLS is defined in {{REF:RFC4346}}. H2: TLS Certificates TLS uses {{TERM:X.509}} certificates to carry client and server -identities. All servers are required to have valid certificates, -whereas client certificates are optional. Clients must have a +identities. All servers are required to have valid certificates, +whereas client certificates are optional. Clients must have a valid certificate in order to authenticate via SASL EXTERNAL. For more information on creating and managing certificates, see the {{PRD:OpenSSL}} documentation. H3: Server Certificates -The DN of a server certificate must use the CN attribute -to name the server, and the {{EX:CN}} must carry the server's -fully qualified domain name. Additional alias names and wildcards -may be present in the {{EX:subjectAltName}} certificate extension. -More details on server certificate names are in {{REF:RFC4513}}. +The {{TERM:DN}} of a server certificate must use the {{EX:CN}} +attribute to name the server, and the {{EX:CN}} must carry the +server's fully qualified domain name. Additional alias names and +wildcards may be present in the {{EX:subjectAltName}} certificate +extension. More details on server certificate names are in +{{REF:RFC4513}}. H3: Client Certificates @@ -117,29 +118,29 @@ and {{EX:SSLv2}}. H4: TLSRandFile This directive specifies the file to obtain random bits from when -{{EX:/dev/urandom}} is not available. If the -system provides {{EX:/dev/urandom}} then this option is not needed, -otherwise a source of random data must be configured. -Some systems (e.g. Linux) -provide {{EX:/dev/urandom}} by default, while others (e.g. Solaris) +{{FILE:/dev/urandom}} is not available. If the system provides +{{FILE:/dev/urandom}} then this option is not needed, otherwise a +source of random data must be configured. Some systems (e.g. Linux) +provide {{FILE:/dev/urandom}} by default, while others (e.g. Solaris) require the installation of a patch to provide it, and others may not support it at all. In the latter case, EGD or PRNGD should be installed, and this directive should specify the name of the EGD/PRNGD -socket. The environment variable {{EX:RANDFILE}} can also be used to specify -the filename. Also, in the absence of these options, the {{EX:.rnd}} -file in the slapd user's home directory may be used if it exists. To -use the {{EX:.rnd}} file, just create the file and copy a few hundred -bytes of arbitrary data into the file. The file is only used to -provide a seed for the pseudo-random number generator, and it doesn't -need very much data to work. +socket. The environment variable {{EX:RANDFILE}} can also be used +to specify the filename. Also, in the absence of these options, the +{{EX:.rnd}} file in the slapd user's home directory may be used if +it exists. To use the {{EX:.rnd}} file, just create the file and +copy a few hundred bytes of arbitrary data into the file. The file +is only used to provide a seed for the pseudo-random number generator, +and it doesn't need very much data to work. H4: TLSEphemeralDHParamFile -This directive specifies the file that contains parameters for Diffie-Hellman -ephemeral key exchange. This is required in order to use a DSA certificate on -the server side (i.e. {{EX:TLSCertificateKeyFile}} points to a DSA key). -Multiple sets of parameters can be included in the file; all of them will -be processed. Parameters can be generated using the following command +This directive specifies the file that contains parameters for +Diffie-Hellman ephemeral key exchange. This is required in order +to use a DSA certificate on the server side (i.e. +{{EX:TLSCertificateKeyFile}} points to a DSA key). Multiple sets +of parameters can be included in the file; all of them will be +processed. Parameters can be generated using the following command > openssl dhparam [-dsaparam] -out @@ -177,8 +178,8 @@ 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 {{E:-Z}} -and {{E:-ZZ}} flag to indicate whether a Start TLS operation is to +negotatation. 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 command to continue.