Correction of spelling errors in manpages
authorMathieu Parent <math.parent@gmail.com>
Tue, 5 Jan 2010 09:59:44 +0000 (10:59 +0100)
committerRonnie Sahlberg <ronniesahlberg@gmail.com>
Wed, 24 Feb 2010 12:21:29 +0000 (23:21 +1100)
thanks to lintian

See https://bugzilla.samba.org/show_bug.cgi?id=6935

(This used to be ctdb commit 402aad596e143c1ae3ec4bf2dfe3863c505bfc40)

ctdb/doc/ctdb.1.xml
ctdb/doc/ctdbd.1.xml

index d792cbc0ab1737079ac95147c24452c02e35bcbd..f19e45a0d618b11d8dc97b88b988122e30b32774 100644 (file)
@@ -49,7 +49,7 @@
         <listitem>
           <para>
             This specifies the physical node number on which to execute the 
-           command. Default is to run the command on the deamon running on 
+           command. Default is to run the command on the daemon running on 
            the local host.
          </para>
          <para>
@@ -1190,7 +1190,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist
 
     <refsect2><title>setmonmode &lt;0|1&gt;</title>
       <para>
-        This command can be used to explicitely disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
+        This command can be used to explicitly disable/enable monitoring mode on a node. The main purpose is if one wants to attach GDB to a running ctdb daemon but wants to prevent the other nodes from marking it as DISCONNECTED and issuing a recovery. To do this, set monitoring mode to 0 on all nodes before attaching with GDB. Remember to set monitoring mode back to 1 afterwards.
       </para>
     </refsect2>
 
@@ -1246,7 +1246,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist
         Administratively ban a node for bantime seconds. A bantime of 0 means that the node should be permanently banned. 
       </para>
       <para>
-        A banned node does not participate in the cluster and does not host any records for the clustered TDB. Its ip address has been taken over by an other node and no services are hosted.
+        A banned node does not participate in the cluster and does not host any records for the clustered TDB. Its ip address has been taken over by another node and no services are hosted.
       </para>
       <para>
         Nodes are automatically banned if they are the cause of too many
index a3e3d3deb501c2cdc8581a85ebe369852f1c1de7..002fa82288aea160793e9fde9e11492f6a535926 100644 (file)
            This option is used to tell ctdbd to NOT run as a real-time process
            and instead run ctdbd as a normal userspace process.
            This is useful for debugging and when you want to run ctdbd under
-           valgrind or gdb. (You dont want to attach valgrind or gdb to a
+           valgrind or gdb. (You don't want to attach valgrind or gdb to a
            real-time process.)
           </para>
         </listitem>
            </para>
            <para>
            This is only required when using public ip addresses and only when
-           you dont specify the interface explicitly in /etc/ctdb/public_addresses or when you are using --single-public-ip.
+           you don't specify the interface explicitly in /etc/ctdb/public_addresses or when you are using --single-public-ip.
           </para>
           <para>
          If you omit this argument when using public addresses or single public ip, ctdb will not be able to send out Gratious ARPs correctly or be able to kill tcp connections correctly which will lead to application failures. 
     eventually become banned from the cluster.
     This controls how long the culprit node will be banned from the cluster
     before it is allowed to try to join the cluster again.
-    Dont set to small. A node gets banned for a reason and it is usually due
+    Don't set to small. A node gets banned for a reason and it is usually due
     to real problems with the node.
     </para>
     </refsect2>
     <refsect2><title>EnableBans</title>
     <para>Default: 1</para>
     <para>
-    When set to 0, this disables BANNING completely in the cluster and thus nodes can not get banned, even it they break. Dont set to 0.
+    When set to 0, this disables BANNING completely in the cluster and thus nodes can not get banned, even it they break. Don't set to 0.
     </para>
     </refsect2>
     <refsect2><title>DeterministicIPs</title>