fix building docs

Commit 69fe23ff added checking for the older docbook2man back into
configure, but this breaks building the docs on at least Oracle Linux and
Fedora when docbook2X is not installed as docbook2man will be found but the
docs don't actually build with that tool.

This change makes it so the docs can be built with either the older
docbook2man or the newer 2X tools by using configure to set the dtd
string to an appropriate value depending on use of docbook2man or
db2x_docbook2man.

Also fixed a small error in lxc-destroy.sgml.in that was noticed
by the old tools.

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Create log file in lxcpath for non-system containers

On Fri, 26 Apr 2013 10:18:12 -0500
Serge Hallyn <serge.hallyn@ubuntu.com> wrote:

> Quoting Dwight Engen (dwight.engen@oracle.com):
> > On Fri, 26 Apr 2013 09:37:49 -0500
> > Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> >
> > > Quoting Dwight Engen (dwight.engen@oracle.com):
> > > > Using lxc configured with --enable-configpath-log, and
> > > > specifying a path to the lxc commands with -P, the log file
> > > > path is generated with a basename of LOGPATH instead of the
> > > > lxcpath. This means for example if you do
> > > >
> > > > lxc-start -P /tmp/containers -n test01 -l INFO
> > > >
> > > > your log file will be
> > > >
> > > > /var/lib/lxc/test01/test01.log
> > > >
> > > > I was expecting the log to be /tmp/containers/test01/test01.log.
> > > > This is particularly confusing if you also have test01 on the
> > > > regular lxcpath. The patch below changes the log file path to be
> > > > based on lxcpath rather than LOGPATH when lxc is configured with
> > > > --enable-configpath-log.
> > > >
> > > > I think that even in the normal non --enable-configpath-log case
> > > > we should consider using lxcpath as the base and not having
> > > > LOGPATH at all, as attempting to create the log files
> > > > in /var/log is not going to work for regular users on their own
> > > > lxcpath. If we want that, I'll update the patch to do that as
> > > > well.
> > >
> > >
> > > Perhaps we should do:
> > >
> > > 	1. If lxcpath == default_lxc_path(), then first choice is
> > > 	   LOGPATH, second is lxcpath/container.log
> > > 	2. when opening, if first choice fails, use second choice
> > > 	   if there is any.
> > >
> > > That way 'system' containers will go to /var/log/lxc, as I think
> > > they should.  Custom-lxcpath containers should never go
> > > to /var/log/lxc, since their names could be dups of containers in
> > > default_lxc_path(). And if the system is a weird one where
> > > default_lxc_path is set up so that an unprivileged user can use
> > > it, then we should log into $lxcpath.
> >
> > That sounds good to me. So these rules would apply in both the
> > regular and --enable-configpath-log cases.

I updated the patch to try to open the log file according to the
choices given above. Along the way I cleaned up log.c a bit, making
some things static, grouping external interfaces together, etc...
Hopefully that doesn't add too much noise.

> > > (Note this patch will trivially conflict with my new lxc_clone.c
> > > causing it to fail to build - unfortunate result of timing)
> >
> > Yeah unfortunately this touches every lxc_log_init() caller. I can
> > work on the above logic and re-submit after your new lxc_clone
> > stuff goes in.
>
> No no, I'll just need to remember to update mine.  Don't hold up on
> mine, this is just the nature of such collaboration  :)
>
> > Did you have any thoughts on the XXX what to pass in for lxcpath in
> > lxc_init? Right now it just falls back to LOGPATH.
>
> No - that's a weird one, since lxc_init runs in the container.  If
> there were only system containers I'd say always use LOGPATH.
> However there are people (apparently :) who use container sharing the
> host's rootfs...
>
> lxc-execute does know the lxcpath.  Perhaps we can simply have
> src/lxc/execute.c:execute_start() look at handler->conf to see if a
> rootfs is set.  If rootfs is NOT set, then pass lxcpath along to
> lxc-init.  Then lxc-init can mostly do the same as the others?  (It
> doesn't use src/lxc/arguments.c, so you'd have to add lxcpath to
> options[] in lxc-init.c)

So I did this, only to realize that lxc-init is passing "none" for the
file anyway, so it currently doesn't intend to log. This makes me
think that passing NULL for lxcpath is the right thing to do in
this patch. If you want me to make it so lxc-init can log, I can do
that but I think it should be in a different change :)

--

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
implement backend drivers and container clone API (v3)

1. commonize waitpid users to use a single helper.  We frequently want
to run something in a clean namespace, or fork off a script.  This
lets us keep the function doing fork:(1)exec(2)waitpid simpler.

2. start a blockdev backend implementation.  This will be used for
mounting, copying, and snapshotting container filesystems.

3. implement btrfs, lvm, directory, and overlayfs backends.

4. For overlayfs, support a new lxc.rootfs format of
'bdevtype:<extra>'.  This means you can now use overlayfs-based
containers without using lxc-start-ephemeral, by using
lxc.rootfs = overlayfs:/readonly-dir:writeable-dir

5. add a set of simple clone testcases

6. Write a new lxc_clone.c based on api clone.

Still to do (there's more, but off top of my head):

1. support zfs, aufs
2. have clone handle other mount entries (right now it only clones
the rootfs)
3. python, lua, and go bindings (not me :)
4. lxc-destroy: if lvm backing store, check for snapshots of it.
   (what about directories which have overlayfs clones?)

Changes since v2:
	Initialize random generator when picking new macaddr (reported
	  by caglar@10ur.org)
	Fix wrong use of bitmask flags
	On copy-clone of btrfs, create a subvolume
	lxc_clone.c: respect the command line usage of the old script
	lxc-clone(1): update documentation
	Refuse to try changing backing stores expect to overlayfs, as
	  it is not implemented (yet) anyway.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

Conflicts:
	src/lxc/utils.h
implement zfs bdev and clone

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Several backing store improvements

allow copy clones from other bdevs

for lvm and zfs, as we don't yet support passing options, only default
VG of 'lxc' and default zfsroot of 'tank' are supported when converting
another backing store type.

refuse deletion of container which has lvm or zfs snapshots.
	Note that since a zfs clone must be made from a zfs snapshot,
	which is made from the original zfs fs, even after we
	lxc-destroy the snapshotted container we still must manually
	remove the snapshot.  This can be handled automatically, by
	looking for snapshots where c1 is the original, c2 is the clone,
	tank/c2 no longer exists, but tank/c1@c2 does.  We can then
	remove tank/c1@c2 and feel free to remove tank/c1.  This patch
	does NOT do that yet.

Make sure not to return when we're a forked child.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
allow site-wide customization of zfsroot and lvm vg

/etc/lxc/lxc.conf can contain

	zfsroot = custom1
	lvm_vg = vg0

(Otherwise the defaults are 'lxc' for lvm_vg, and 'lxc' for zfsroot)

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
add vg and zfsroot options to lxc.functions and use in lxc-create

also make sure to drop spaces between = and variable in lxc.conf

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
introduce lxc_config

It's a tiny program (exported through the api) wrapping the util.c
helpers for reading /etc/lxc/lxc.conf variables, and replaces
the kludgy shell duplication in lxc.functions.in

Changelog: Apr 30: address feedback from Dwight
	(exit error on failure, and use 'lxcpath' as name, not
	'default_path').

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Dwight Engen <dwight.engen@oracle.com>