From: Kurt Zeilenga Date: Thu, 10 Aug 2000 23:57:21 +0000 (+0000) Subject: Fix up more hyperlinks and general cleanup X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~2273 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=5ea6422c77c78e82d5bdd0c658be069a5dae9e5e;p=openldap Fix up more hyperlinks and general cleanup --- diff --git a/doc/guide/admin/dbtools.sdf b/doc/guide/admin/dbtools.sdf index fd123912c4..192f1bbd56 100644 --- a/doc/guide/admin/dbtools.sdf +++ b/doc/guide/admin/dbtools.sdf @@ -238,21 +238,28 @@ H3: The {{EX:ldif}} program The {{ldif}}(1) program is used to convert arbitrary data values to {{TERM:LDIF}} format. This can be useful when writing a program or script to create the LDIF file you will feed into the {{slapadd}}(8) -or {{ldapadd}}(1) program, or when writing a SHELL backend. ldif takes an -attribute name as an argument, and reads the attribute +or {{ldapadd}}(1) program, or when writing a SHELL backend. {{ldif}}(1) +takes an attribute descriptin as an argument and reads the attribute value(s) from standard input. It produces the LDIF formatted attribute line(s) on standard output. The usage is: -> ldif [-b] +> ldif [-b] -where {{EX:}} is the name of the attribute. Without the +where {{EX:}} is an attribute description. Without the -b option, ldif considers each line of standard input to be a separate value of the attribute. +> ldif description << EOF +> leading space +> # leading hash mark +> EOF + The -b option can be used to force ldif to interpret its input as a single raw binary value. This option is useful when converting binary data such as a {{EX:jpegPhoto}} or {{EX:audio}} -attribute. +attribute. For example: + +> ldif -b jpegPhoto < photo.jpeg H2: The LDIF text entry format @@ -269,19 +276,20 @@ entries in a simple text format. The basic form of an entry is: Lines starting with '{{EX:#}}' character are comments. An attribute description may be a simple attribute -type like {{EX:cn}} or {{objectClass}} or {{1.2.3}} (an {{TERM:OID}} +type like {{EX:cn}} or {{EX:objectClass}} or {{EX:1.2.3}} (an {{TERM:OID}} associated with an attribute type) or may include options such as {{EX:cn;lang_en_US}} or {{EX:userCertificate;binary}}. A line may be continued by starting the next line with a -{{single}} space or tab character. e.g., +{{single}} space or tab character. For example: > dn: cn=Barbara J Jensen, dc=example, dc= > com > cn: Barbara J > Jensen -which is equivalent to: +is equivalent to: + > dn: cn=Barbara J Jensen, dc=example, dc=com > cn: Barbara J Jensen @@ -327,11 +335,11 @@ three entries. > A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ > ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG -Notice that the {{EX:jpegPhoto}} in Jennifer Jensen's entry is +Notice that the {{EX:jpegPhoto}} in Jennifer's entry is encoded using base 64. The {{ldif}}(1) program (described in -Section 8.2.6) can be used to produce an attribute -description/base64-value pair suitable for inclusion in an -LDIF file. +{{SECT:The {{EX:ldif}} program}} section above) can be used to +produce an attribute-description/base64-value pair suitable for +inclusion in an LDIF file. Note: Trailing spaces are not trimmed from values in an LDIF file. Nor are multiple internal spaces compressed. If diff --git a/doc/guide/admin/referrals.sdf b/doc/guide/admin/referrals.sdf index f1989186b1..227731e363 100644 --- a/doc/guide/admin/referrals.sdf +++ b/doc/guide/admin/referrals.sdf @@ -38,7 +38,7 @@ values. This is best demonstrated by example. If the server {{EX:a.example.net}} holds {{EX:dc=example,dc=net}} and wished to delegate the subtree {{EX:ou=subtree,dc=example,dc=net}} to another server {{EX:b.example.net}}, the following named referral -object would be added to {{a.example.net}}: +object would be added to {{EX:a.example.net}}: > dn: dc=subtree, dc=example, dc=net > objectClass: referral diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index ea9ebd5894..6af81da568 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -92,7 +92,7 @@ operational attributes were added by the master {{slapd}}. H2: Command-Line Options -{{slurpd}}(8) supports the following command-line options. +This section details commonly used {{slurpd}}(8) command-line options. > -d | ? @@ -125,7 +125,7 @@ Under normal circumstances, slurpd reads the name of the slapd replication log file from the slapd configuration file. However, you can override this with the -r flag, to cause slurpd to process a different replication log file. See -section 10.5, Advanced slurpd Operation, for a discussion +the {{SECT:Advanced slurpd Operation}} section for a discussion of how you might use this option. > -o @@ -137,26 +137,14 @@ see if new entries have been added to the replication log. In one-shot mode, by comparison, slurpd processes a replication log and exits immediately. If the -o option is given, the replication log file must be explicitly specified -with the -r option +with the -r option. See the {{SECT:One-shot mode and reject files}} +section for a discussion of this mode. > -t Specify an alternate directory for slurpd's temporary copies of replication logs. The default location is /usr/tmp. -> -k - -When slurpd uses Kerberos to authenticate to slave slapd -instances, it needs to have an appropriate srvtab file for -the remote slapd. This option allows you to specify an -alternate filename containing Kerberos keys for the remote -slapd. The default filename is /etc/srvtab. You can also -specify the srvtab file to use in the slapd configuration -file's replica option. See the documentation on the srvtab -directive in section 5.2.2, General Backend Options. A -more complete discussion of using Kerberos with slapd -and slurpd may be found in Appendix D. - H2: Configuring slurpd and a slave slapd instance @@ -169,56 +157,56 @@ steps are detailed in the following sections. You can set up as many slave slapd instances as you wish. -H3: Set up the master slapd +H3: Set up the master {{slapd}} -Follow the procedures in Section 4, Building and Installing -slapd. Be sure that the slapd instance is working properly -before proceeding. Be sure to do the following in the -master slapd configuration file. +The following section assumes you have a properly +working {{slapd}}(8) instance. To configure your working +{{slapd}}(8) server as a replication master, you need +to make the following changes to your {{slapd.conf}}(5). -^ Add a replica directive for each replica. The binddn= -parameter should match the {{F:updatedn}} option in the +^ Add a {{EX:replica}} directive for each replica. The {{EX:binddn=}} +parameter should match the {{EX:updatedn}} option in the corresponding slave slapd configuration file, and should name an entry with write permission to the slave database -(e.g., an entry listed as rootdn, or allowed access via -access directives in the slave slapd configuration file). +(e.g., an entry listed as {{EX:rootdn}}, or allowed access via +{{EX:access}} directives in the slave slapd configuration file). -+ Add a replogfile directive, which tells slapd where to log ++ Add a {{EX:replogfile}} directive, which tells slapd where to log changes. This file will be read by slurpd. -H3: Set up the slave slapd +H3: Set up the slave {{slapd}} Install the slapd software on the host which is to be the slave slapd server. The configuration of the slave server should be identical to that of the master, with the following exceptions: -^ Do not include a replica directive. While it is possible to -create "chains" of replicas, in most cases this is +^ Do not include a {{EX:replica}} directive. While it is +possible to create "chains" of replicas, in most cases this is inappropriate. -+ Do not include a replogfile directive. ++ Do not include a {{EX:replogfile}} directive. + Do include an updatedn line. The DN given should -match the DN given in the {{EX: binddn=}} parameter of the -corresponding {{EX: replica=}} directive in the master slapd +match the DN given in the {{EX:binddn=}} parameter of the +corresponding {{EX:replica=}} directive in the master slapd config file. -+ Make sure the DN given in the {{EX: updatedn}} directive has -permission to write the database (e.g., it is listed as rootdn -or is allowed access by one or more access directives). ++ Make sure the DN given in the {{EX:updatedn}} directive has +permission to write the database (e.g., it is listed as {{EX:rootdn}} +or is allowed {{EX:access}} by one or more access directives). -H3: Shut down the master slapd +H3: Shut down the master {{slapd}} In order to ensure that the slave starts with an exact copy of the master's data, you must shut down the master slapd. Do this by sending the master slapd process an -interrupt signal with {{EX: kill -TERM }}, where {{EX: }} is the -process-id of the master slapd process. +interrupt signal with {{EX:kill -INT }}, where +{{EX:}} is the process-id of the master slapd process. If you like, you may restart the master slapd in read-only mode while you are replicating the database. During this @@ -242,6 +230,9 @@ The current possibilities are In general, you should copy all files found in the database {{EX: directory}} unless you know it not used by {{slapd}}(8). +Note: The copy process assumes homogeneous servers with +identically configured OpenLDAP installations. + H3: Configure the master slapd for replication @@ -249,7 +240,7 @@ To configure slapd to generate a replication logfile, you add a "{{EX: replica}}" configuration option to the master slapd's config file. For example, if we wish to propagate changes to the slapd instance running on host -slave.example.com: +{{EX:slave.example.com}}: > replica host=slave.example.com:389 > binddn="cn=Replicator,dc=example,dc=com" @@ -258,16 +249,15 @@ slave.example.com: In this example, changes will be sent to port 389 (the standard LDAP port) on host slave.example.com. The slurpd process will bind to the slave slapd as -"cn=Replicator,dc=example,dc=com" using simple authentication -with password "secret". Note that the DN given by the binddn= +"{{EX:cn=Replicator,dc=example,dc=com}}" using simple authentication +with password "{{EX:secret}}". Note that the DN given by the {{EX:binddn=}} directive must either exist in the slave slapd's database (or be the rootdn specified in the slapd config file) in order for the bind operation to succeed. The DN should also be listed as the {{EX:updatedn}} for the database in the slave's slapd.conf(5). -Note: use of simple authentication is discouraged. Use -of strong SASL mechanisms such as DIGEST-MD5 or GSSAPI is -recommended. +Note: The use of strong authentication and transport security +is highly recommended. H3: Restart the master slapd and start the slave slapd @@ -298,8 +288,8 @@ receives an error return code, it writes the reason for the error and the replication record to a reject file. The reject file is located in the same directory with the per-replica replication logfile, and has the same name, but with the -string ".rej" appended. For example, for a replica running -on host slave.example.com, port 389, the reject file, if it +string "{{F:.rej}}" appended. For example, for a replica running +on host {{EX:slave.example.com}}, port 389, the reject file, if it exists, will be named > /usr/local/var/openldap/replog.slave.example.com:389. @@ -322,12 +312,12 @@ A sample rejection log entry follows: > - Note that this is precisely the same format as the original -replication log entry, but with an ERROR line prepended to +replication log entry, but with an {{EX:ERROR}} line prepended to the entry. -H3: {{I:Slurpd}}'s one-shot mode and reject files +H3: One-shot mode and reject files It is possible to use slurpd to process a rejection log with its "one-shot mode." In normal operation, slurpd watches @@ -350,9 +340,9 @@ and exit, use the command H2: Replication to an X.500 DSA -In mixed environments where both X.500 DSAs and slapd +In mixed environments where both {{TERM:X.500}} DSAs and slapd are used, it may be desirable to replicate changes from a -slapd directory server to an X.500 DSA. This section +slapd directory server to an X.500 {{TERM:DSA}}. This section discusses issues involved with this method of replication, and describes the currently-available facilities. @@ -366,7 +356,7 @@ the X.500 DSA: FT: Figure 6: Replication from slapd to an X.500 DSA Note that the X.500 DSA must be a read-only copy. Since -the replication is one-way, updates from DAP clients +the replication is one-way, updates from {{TERM:DAP}} clients connecting to the X.500 DSA simply cannot be handled. A problem arises where attribute names differ between the