[lxc-devel] [PATCH] fix errors when using docbook2man
Dwight Engen
dwight.engen at oracle.com
Fri Oct 4 17:46:05 UTC 2013
docbook2man picks up some errors that docbook2x does not, fixing them
isn't harmful to docbook2x. The only real change is adding <para> and
<citerefentry> tags.
Signed-off-by: Dwight Engen <dwight.engen at oracle.com>
---
doc/lxc.conf.sgml.in | 156 +++++++++++++++++++++++++++++----------------------
1 file changed, 88 insertions(+), 68 deletions(-)
diff --git a/doc/lxc.conf.sgml.in b/doc/lxc.conf.sgml.in
index dd68d48..ac3e377 100644
--- a/doc/lxc.conf.sgml.in
+++ b/doc/lxc.conf.sgml.in
@@ -668,81 +668,101 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
</para>
<itemizedlist>
<listitem>
- <option>proc:mixed</option> (or <option>proc</option>):
- mount <filename>/proc</filename> as read-write, but
- remount <filename>/proc/sys</filename> and
- <filename>/proc/sysrq-trigger</filename> read-only
- for security / container isolation purposes.
+ <para>
+ <option>proc:mixed</option> (or <option>proc</option>):
+ mount <filename>/proc</filename> as read-write, but
+ remount <filename>/proc/sys</filename> and
+ <filename>/proc/sysrq-trigger</filename> read-only
+ for security / container isolation purposes.
+ </para>
</listitem>
<listitem>
- <option>proc:rw</option>: mount
- <filename>/proc</filename> as read-write
+ <para>
+ <option>proc:rw</option>: mount
+ <filename>/proc</filename> as read-write
+ </para>
</listitem>
<listitem>
- <option>sys:ro</option> (or <option>sys</option>):
- mount <filename>/sys</filename> as read-only
- for security / container isolation purposes.
+ <para>
+ <option>sys:ro</option> (or <option>sys</option>):
+ mount <filename>/sys</filename> as read-only
+ for security / container isolation purposes.
+ </para>
</listitem>
<listitem>
- <option>sys:rw</option>: mount
- <filename>/sys</filename> as read-write
+ <para>
+ <option>sys:rw</option>: mount
+ <filename>/sys</filename> as read-write
+ </para>
</listitem>
<listitem>
- <option>cgroup:mixed</option> (or
- <option>cgroup</option>):
- mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
- create directories for all hierarchies to which
- the container is added, create subdirectories
- there with the name of the cgroup, and bind-mount
- the container's own cgroup into that directory.
- The container will be able to write to its own
- cgroup directory, but not the parents, since they
- will be remounted read-only
+ <para>
+ <option>cgroup:mixed</option> (or
+ <option>cgroup</option>):
+ mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
+ create directories for all hierarchies to which
+ the container is added, create subdirectories
+ there with the name of the cgroup, and bind-mount
+ the container's own cgroup into that directory.
+ The container will be able to write to its own
+ cgroup directory, but not the parents, since they
+ will be remounted read-only
+ </para>
</listitem>
<listitem>
- <option>cgroup:ro</option>: similar to
- <option>cgroup:mixed</option>, but everything will
+ <para>
+ <option>cgroup:ro</option>: similar to
+ <option>cgroup:mixed</option>, but everything will
be mounted read-only.
+ </para>
</listitem>
<listitem>
- <option>cgroup:rw</option>: similar to
- <option>cgroup:mixed</option>, but everything will
- be mounted read-write. Note that the paths leading
- up to the container's own cgroup will be writable,
- but will not be a cgroup filesystem but just part
- of the tmpfs of <filename>/sys/fs/cgroup</filename>
+ <para>
+ <option>cgroup:rw</option>: similar to
+ <option>cgroup:mixed</option>, but everything will
+ be mounted read-write. Note that the paths leading
+ up to the container's own cgroup will be writable,
+ but will not be a cgroup filesystem but just part
+ of the tmpfs of <filename>/sys/fs/cgroup</filename>
+ </para>
</listitem>
<listitem>
- <option>cgroup-full:mixed</option> (or
- <option>cgroup-full</option>):
- mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
- create directories for all hierarchies to which
- the container is added, bind-mount the hierarchies
- from the host to the container and make everything
- read-only except the container's own cgroup. Note
- that compared to <option>cgroup</option>, where
- all paths leading up to the container's own cgroup
- are just simple directories in the underlying
- tmpfs, here
- <filename>/sys/fs/cgroup/$hierarchy</filename>
- will contain the host's full cgroup hierarchy,
- albeit read-only outside the container's own cgroup.
- This may leak quite a bit of information into the
- container.
+ <para>
+ <option>cgroup-full:mixed</option> (or
+ <option>cgroup-full</option>):
+ mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
+ create directories for all hierarchies to which
+ the container is added, bind-mount the hierarchies
+ from the host to the container and make everything
+ read-only except the container's own cgroup. Note
+ that compared to <option>cgroup</option>, where
+ all paths leading up to the container's own cgroup
+ are just simple directories in the underlying
+ tmpfs, here
+ <filename>/sys/fs/cgroup/$hierarchy</filename>
+ will contain the host's full cgroup hierarchy,
+ albeit read-only outside the container's own cgroup.
+ This may leak quite a bit of information into the
+ container.
+ </para>
</listitem>
<listitem>
- <option>cgroup-full:ro</option>: similar to
- <option>cgroup-full:mixed</option>, but everything
- will be mounted read-only.
+ <para>
+ <option>cgroup-full:ro</option>: similar to
+ <option>cgroup-full:mixed</option>, but everything
+ will be mounted read-only.
+ </para>
</listitem>
<listitem>
- <option>cgroup-full:rw</option>: similar to
- <option>cgroup-full:mixed</option>, but everything
- will be mounted read-write. Note that in this case,
- the container may escape its own cgroup. (Note also
- that if the container has CAP_SYS_ADMIN support
- and can mount the cgroup filesystem itself, it may
- do so anyway.)
+ <para>
+ <option>cgroup-full:rw</option>: similar to
+ <option>cgroup-full:mixed</option>, but everything
+ will be mounted read-write. Note that in this case,
+ the container may escape its own cgroup. (Note also
+ that if the container has CAP_SYS_ADMIN support
+ and can mount the cgroup filesystem itself, it may
+ do so anyway.)
+ </para>
</listitem>
</itemizedlist>
<para>
@@ -1001,20 +1021,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
as command line arguments and through environment variables.
The arguments are:
<itemizedlist>
- <listitem> Container name. </listitem>
- <listitem> Section (always 'lxc'). </listitem>
- <listitem> The hook type (i.e. 'clone' or 'pre-mount'). </listitem>
- <listitem> Additional arguments In the
+ <listitem><para> Container name. </para></listitem>
+ <listitem><para> Section (always 'lxc'). </para></listitem>
+ <listitem><para> The hook type (i.e. 'clone' or 'pre-mount'). </para></listitem>
+ <listitem><para> Additional arguments In the
case of the clone hook, any extra arguments passed to
- lxc-clone will appear as further arguments to the hook. </listitem>
+ lxc-clone will appear as further arguments to the hook. </para></listitem>
</itemizedlist>
The following environment variables are set:
<itemizedlist>
- <listitem> LXC_NAME: is the container's name. </listitem>
- <listitem> LXC_ROOTFS_MOUNT: the path to the mounted root filesystem. </listitem>
- <listitem> LXC_CONFIG_FILE: the path to the container configuration file. </listitem>
- <listitem> LXC_SRC_NAME: in the case of the clone hook, this is the original container's name. </listitem>
- <listitem> LXC_ROOTFS_PATH: this is the lxc.rootfs entry for the container. Note this is likely not where the mounted rootfs is to be found, use LXC_ROOTFS_MOUNT for that. </listitem>
+ <listitem><para> LXC_NAME: is the container's name. </para></listitem>
+ <listitem><para> LXC_ROOTFS_MOUNT: the path to the mounted root filesystem. </para></listitem>
+ <listitem><para> LXC_CONFIG_FILE: the path to the container configuration file. </para></listitem>
+ <listitem><para> LXC_SRC_NAME: in the case of the clone hook, this is the original container's name. </para></listitem>
+ <listitem><para> LXC_ROOTFS_PATH: this is the lxc.rootfs entry for the container. Note this is likely not where the mounted rootfs is to be found, use LXC_ROOTFS_MOUNT for that. </para></listitem>
</itemizedlist>
</para>
<para>
@@ -1121,8 +1141,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
<listitem>
<para>
A hook to be run when the container is cloned to a new one.
- See <refentrytitle><command>lxc-clone</command></refentrytitle>
- <manvolnum>1</manvolnum> for more information.
+ See <citerefentry><refentrytitle><command>lxc-clone</command></refentrytitle>
+ <manvolnum>1</manvolnum></citerefentry> for more information.
</para>
</listitem>
</varlistentry>
--
1.8.1.4
More information about the lxc-devel
mailing list