Merge pull request #42 from martin-a-brown/master

another batch of validation improvements in all DocBook XML 4.x documents

LDP/guide/docbook/EVMSUG/create-snapshot.xml

@@ -419,11 +419,11 @@ all but the desired snapshot must be deleted before rollback can take place.
 <listitem><para>Select 
 <menuchoice><guimenu>Actions</guimenu>
 <guimenuitem>Other</guimenuitem>
-<guimenuitem>Storage Object Tasks</guimenuitem>.
-</menuchoice> </para></listitem>
+<guimenuitem>Storage Object Tasks</guimenuitem>
+</menuchoice>.</para></listitem>
 <listitem><para>Select the object "snap."</para></listitem>
 <listitem><para>Click or activate <guibutton>Next</guibutton>.</para></listitem>
-<listitem><para>Select <guibutton>Rollback</guibutton></para>.</listitem>
+<listitem><para>Select <guibutton>Rollback</guibutton>.</para></listitem>
 <listitem><para>Click or activate <guibutton>Next</guibutton>.</para></listitem>
 <listitem><para>Click or activate <guibutton>Rollback</guibutton> on the action panel.
 </para></listitem>

LDP/guide/docbook/Intro-Linux/chap11.xml

@@ -2,6 +2,7 @@
 <chapter id="chap_11"><title>Sound and Video</title>
 <abstract>
 <para>This chapter addresses the following tasks (briefly, as the field of sound and video is very wide):</para>
+<para>
 <itemizedlist>
 <listitem><para>Sound card configuration</para></listitem>
 <listitem><para>Playing CDs, copying CDs, </para></listitem>
@@ -10,6 +11,7 @@
 <listitem><para>Video and television</para></listitem>
 <listitem><para>Recording sound</para></listitem>
 </itemizedlist>
+</para>
 </abstract>
 <sect1 id="sect_11_01"><title>Audio Basics</title>
 <sect2 id="sect_11_01_01"><title>Installation</title>

LDP/guide/docbook/Intro-Linux/chap3.xml

@@ -695,7 +695,7 @@ Diskquotas for user pierre (uid 501): none
 
 <sect2 id="sect_03_02_06"><title>The most common variable files</title>
 
-<para>In the <filename>/var<indexterm><primary>var</primary></indexterm></filename> directory we find a set of directories for storing specific non-constant data (as opposed to the ls program or the system configuration files, which change relatively infrequently or never at all).  All files that change frequently<indexterm>variable files<primary></primary><secondary>overview</secondary></indexterm>, such as log files, mailboxes, lock files, spoolers etc. are kept in a subdirectory of <filename>/var</filename>.</para>
+<para>In the <filename>/var<indexterm><primary>var</primary></indexterm></filename> directory we find a set of directories for storing specific non-constant data (as opposed to the ls program or the system configuration files, which change relatively infrequently or never at all).  All files that change frequently<indexterm><primary>variable files</primary><secondary>overview</secondary></indexterm>, such as log files, mailboxes, lock files, spoolers etc. are kept in a subdirectory of <filename>/var</filename>.</para>
 <para>As a security measure these files are usually kept in separate parts from the main system files, so we can keep a close eye on them and set stricter permissions where necessary.  A lot of these files also need more permissions than usual, like <filename>/var/tmp<indexterm><primary>tmp</primary></indexterm></filename>, which needs to be writable for everyone.  A lot of user activity might be expected here, which might even be generated by anonymous Internet users connected to your system.  This is one reason why the <filename>/var</filename> directory<indexterm><primary>partitions</primary><secondary>var partition</secondary></indexterm>, including all its subdirectories, is usually on a separate partition.  This way, there is for instance no risk that a mail bomb, for instance, fills up the rest of the file system, containing more important data such as your programs and configuration files.</para>
 <note><title>/var/tmp and /tmp</title>
 <para>Files in <filename>/tmp<indexterm><primary>temporary files</primary></indexterm></filename> can be deleted without notice, by regular system tasks or because of a system reboot.  On some (customized) systems, also <filename>/var/tmp</filename> might behave unpredictably.  Nevertheless, since this is not the case by default, we advise to use the <filename>/var/tmp</filename> directory for saving temporary files.  When in doubt, check with your system administrator.  If you manage your own system, you can be reasonably sure that this is a safe place if you did not consciously change settings on <filename>/var/tmp</filename> (as root, a normal user can not do this).</para>

LDP/guide/docbook/Intro-Linux/chap4.xml

@@ -310,7 +310,7 @@ passwd is /usr/bin/passwd
 -r-s--x--x    1 root     root    13476 Aug  7 06:03 /usr/bin/passwd*
 </screen>
 <para>When called, the <command>passwd</command> command will run using the access permissions<indexterm><primary>file permissions</primary><secondary>SUID</secondary></indexterm> of <emphasis>root</emphasis>, thus enabling a common user to edit the password file which is owned by the system admin.</para>
-<para>SGID modes on a file don't occur nearly as frequently as SUID, because SGID often involves the creation of extra groups.  In some cases, however, we have to go through this trouble in order to build an elegant solution (don't worry about this too much -  the necessary groups are usually created upon installation).  This is the case for the <command>write<indexterm><primary>write</primary>4dwx<secondary></secondary></indexterm></command> and <command>wall<indexterm><primary>wall</primary></indexterm></command> programs, which are used to send messages to other users' terminals<indexterm><primary>terminal</primary><secondary>send a message</secondary></indexterm> (ttys).  The <command>write</command> command writes a message to a single user, while <command>wall</command> writes to all connected users.</para>
+<para>SGID modes on a file don't occur nearly as frequently as SUID, because SGID often involves the creation of extra groups.  In some cases, however, we have to go through this trouble in order to build an elegant solution (don't worry about this too much -  the necessary groups are usually created upon installation).  This is the case for the <command>write<indexterm><primary>write</primary><secondary>4dwx</secondary></indexterm></command> and <command>wall<indexterm><primary>wall</primary></indexterm></command> programs, which are used to send messages to other users' terminals<indexterm><primary>terminal</primary><secondary>send a message</secondary></indexterm> (ttys).  The <command>write</command> command writes a message to a single user, while <command>wall</command> writes to all connected users.</para>
 <para>Sending text to another user's terminal or graphical display is normally not allowed.  In order to bypass this problem, a group has been created, which owns all terminal devices.  When the <command>write</command> and <command>wall</command> commands are granted SGID permissions, the commands will run using the access rights as applicable to this group, <emphasis>tty</emphasis> in the example.  Since this group has write access to the destination terminal, also a user having no permissions to use that terminal in any way can send messages to it.</para>
 <para>In the example below, user <emphasis>joe</emphasis> first finds out on which terminal his correspondent is connected, using the <command>who</command> command.  Then he sends her a message using the <command>write</command> command.  Also illustrated are the access rights on the <command>write</command> program and on the terminals occupied by the receiving user: it is clear that others than the user owner have no permissions<indexterm><primary>file permissions</primary><secondary>SGID</secondary></indexterm> on the device, except for the group owner, which can write to it.</para>
 <screen>

LDP/guide/docbook/Intro-Linux/chap5.xml

@@ -306,8 +306,8 @@ My boss
 <listitem><para><cmdsynopsis><command>grep <parameter>root</parameter> <filename>/etc/passwd /etc/nofiles</filename> &gt; <filename>grepresults</filename></command></cmdsynopsis></para></listitem>
 <listitem><para><cmdsynopsis><command>/etc/init.d/sshd <parameter>start</parameter> &gt; <filename>/var/tmp/output</filename></command></cmdsynopsis></para></listitem>
 <listitem><para><cmdsynopsis><command>/etc/init.d/crond <parameter>start</parameter> &gt; <filename>/var/tmp/output</filename> 2&gt;&amp;1</command></cmdsynopsis></para></listitem>
-<para>Now check your results by issuing the commands again, now redirecting standardoutput to the file <filename>/var/tmp/output</filename> and standard error to the file <filename>/var/tmp/error</filename>.</para>
 </itemizedlist>
+<para>Now check your results by issuing the commands again, now redirecting standardoutput to the file <filename>/var/tmp/output</filename> and standard error to the file <filename>/var/tmp/error</filename>.</para>
 
 </listitem>
 <listitem><para>How many processes are you currently running?</para></listitem>

LDP/guide/docbook/Linux-Dictionary/Linux-Dictionary.xml

@@ -1,6 +1,6 @@
 <?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"[
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[
 <!ENTITY About-the-Author SYSTEM "About-the-Author.xml">
 <!ENTITY Contributors SYSTEM "Contributors.xml">
 <!ENTITY Disclaimer   SYSTEM "Disclaimer.xml">

LDP/guide/docbook/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3.xml

@@ -1,5 +1,5 @@
 <?xml version='1.0' encoding="iso-8859-1" standalone='no'?>
-<!DOCTYPE article PUBLIC '-//OASIS//DTD DocBook XML V4.1.2//EN' 
+<!DOCTYPE book PUBLIC '-//OASIS//DTD DocBook XML V4.1.2//EN' 
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
 
 <book><!-- <?dbhtml filename="coverpage.html"?> -->

LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml

@@ -125,10 +125,11 @@ some minor fixes</revremark></revision>
 </articleinfo>
 
 <abstract>
+<para>
 <indexterm>
 <primary>CVS Best Practices</primary>
 </indexterm>
-<para>This article explores some of the best practices that can be adopted
+This article explores some of the best practices that can be adopted
 while using CVS as the configuration management tool in your software
 projects.
 </para>
@@ -1072,17 +1073,22 @@ The bug fix team will check out using the command line
 will update, verify a successful build and commit their changes to the bug
 fix branch using the command line
 </para>
+<para>
 <command>
 cvs update -R -r release_1_0_patches {module name}
 </command>
+</para>
 
 <para>The team should perform a build at this point to verify that the
 update did not break any code on the branch.  Once the build is successful,
-the branch should be committed back into the repository.  </para>
+the branch should be committed back into the repository.
+</para>
 
+<para>
 <command>
 cvs commit -R -r release_1_0_patches {module name}
 </command>
+</para>
 
 <para><xref linkend="section2-bebo" /> : On a daily basis, each developer
 will check in code to &CVSAB; and to ensure sanity of code, daily builds on