[lxc-devel] [PATCH] oracle template: use @LOCALSTATEDIR@ instead of hardcoded /var for lock dir

2012-12-06 Thread Dwight Engen

Signed-off-by: Dwight Engen 
---
 templates/lxc-oracle.in |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/templates/lxc-oracle.in b/templates/lxc-oracle.in
index 243f0e4..eadee3a 100644
--- a/templates/lxc-oracle.in
+++ b/templates/lxc-oracle.in
@@ -337,7 +337,7 @@ container_rootfs_create()
 fi
 done
 
-mkdir -p /var/lock/subsys/
+mkdir -p @LOCALSTATEDIR@/lock/subsys/
 (
 flock -x 200
 if [ $? -ne 0 ]; then
@@ -433,7 +433,7 @@ container_rootfs_create()
 echo "Rebuilding rpm database"
 rm -f $container_rootfs/var/lib/rpm/__db*
 chroot $container_rootfs rpm --rebuilddb >/dev/null 2>&1
-) 200>/var/lock/subsys/lxc-oracle-$name
+) 200>@LOCALSTATEDIR@/lock/subsys/lxc-oracle-$name
 }
 
 usage()
-- 
1.7.1


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] [PATCH 2/4] lxc-archlinux: Don't hardcode /var/lib/lxc in help

2012-12-06 Thread Stéphane Graber
On 12/06/2012 12:07 AM, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
>> Signed-off-by: Stéphane Graber 
>> ---
>>  templates/lxc-archlinux.in | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/templates/lxc-archlinux.in b/templates/lxc-archlinux.in
>> index 5db5b85..cf274d4 100644
>> --- a/templates/lxc-archlinux.in
>> +++ b/templates/lxc-archlinux.in
>> @@ -375,7 +375,7 @@ usage:
>>  Mandatory args:
>>-n,--name container name, used to as an identifier for that 
>> container from now on
>>  Optional args:
>> -  -p,--path path to where the container rootfs will be created, 
>> defaults to /var/lib/lxc. The container config will go under /var/lib/lxc in 
>> that case
>> +  -p,--path path to where the container rootfs will be created, 
>> defaults to $default_path. The container config will go under $default_path 
>> in that case
> 
> ok but default_path is hardcoded to /var/lib/lxc ?  (At least in the tree
> I have here)

It's set to @LXCPATH@ in staging.

> Still, of course
> 
> Acked-by: Serge E. Hallyn 

Thanks, pushed.

> since at least now it can be 'fixed' in one place.
> 
>>-P,--packages preinstall additional packages, comma-separated list
>>-h,--help print this help
>>  EOF
>> -- 
>> 1.8.0
>>
>>
>> --
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> ___
>> Lxc-devel mailing list
>> Lxc-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lxc-devel


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] [PATCH 3/4] templates: Consistent use of locking

2012-12-06 Thread Stéphane Graber
On 12/06/2012 12:14 AM, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
>> Move to per-template lock (except for oracle that's per-container).
>> Also ensure that the path used for the lock is relative to LOCALSTATEDIR.
>>
>> Signed-off-by: Stéphane Graber 
> 
> I believe a few conversions to LOCALSTATEDIR were missed in mkdirs,
> namely in lxc-altlinux.in, lxc-debian.in, lxc-fedora.in, lxc-opensuse.in,
> and lxc-ubuntu-cloud.in.

staging looks fine at the moment:
stgraber@castiana:~/data/code/lxc/stgraber-lxc-git$ grep -r mkdir
templates/ | grep var
templates/lxc-archlinux.in:mkdir -p "${rootfs_path}/var/lib/pacman/sync"
templates/lxc-fedora.in:mkdir -p $INSTALL_ROOT/var/lib/rpm
templates/lxc-ubuntu.in:mkdir -p -m0755 /var/run/sshd
templates/lxc-oracle.in:mkdir -p $container_rootfs/var/lib/rpm
templates/lxc-altlinux.in:mkdir -p $INSTALL_ROOT/var/lib/rpm


> With those added:
> 
> Acked-by: Serge E. Hallyn 

Thanks, pushed.

>> ---
>>  templates/lxc-altlinux.in | 4 ++--
>>  templates/lxc-debian.in   | 4 ++--
>>  templates/lxc-fedora.in   | 4 ++--
>>  templates/lxc-lenny.in| 4 ++--
>>  templates/lxc-opensuse.in | 4 ++--
>>  templates/lxc-oracle.in   | 4 ++--
>>  templates/lxc-ubuntu-cloud.in | 2 +-
>>  templates/lxc-ubuntu.in   | 4 ++--
>>  8 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/templates/lxc-altlinux.in b/templates/lxc-altlinux.in
>> index eab473c..fac545c 100644
>> --- a/templates/lxc-altlinux.in
>> +++ b/templates/lxc-altlinux.in
>> @@ -228,7 +228,7 @@ install_altlinux()
> 
> This has a mkdir /var/lock/subsys at line 199
> 
>>  return 1
>>  fi
>>  return 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-altlinux
>>  
>>  return $?
>>  }
>> @@ -325,7 +325,7 @@ clean()
>>  echo -n "Purging the download cache for ALTLinux-$release..."
>>  rm --preserve-root --one-file-system -rf $cache && echo "Done." || 
>> exit 1
>>  exit 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-altlinux
>>  }
>>  
>>  usage()
>> diff --git a/templates/lxc-debian.in b/templates/lxc-debian.in
>> index 6b5f2f9..7bbc46b 100644
>> --- a/templates/lxc-debian.in
>> +++ b/templates/lxc-debian.in
>> @@ -191,7 +191,7 @@ install_debian()
> 
> this has mkdir at line 167
> 
>>  
>>  return 0
>>  
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-debian
>>  
>>  return $?
>>  }
>> @@ -261,7 +261,7 @@ clean()
>>  rm --preserve-root --one-file-system -rf $cache && echo "Done." || 
>> exit 1
>>  exit 0
>>  
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-debian
>>  }
>>  
>>  usage()
>> diff --git a/templates/lxc-fedora.in b/templates/lxc-fedora.in
>> index bc4b264..366e776 100644
>> --- a/templates/lxc-fedora.in
>> +++ b/templates/lxc-fedora.in
>> @@ -233,7 +233,7 @@ install_fedora()
> 
> mkdir at line 203
> 
>>  fi
>>  
>>  return 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-fedora
>>  
>>  return $?
>>  }
>> @@ -301,7 +301,7 @@ clean()
>>  echo -n "Purging the download cache for Fedora-$release..."
>>  rm --preserve-root --one-file-system -rf $cache && echo "Done." || 
>> exit 1
>>  exit 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-fedora
>>  }
>>  
>>  usage()
>> diff --git a/templates/lxc-lenny.in b/templates/lxc-lenny.in
>> index afc9321..cb93853 100644
>> --- a/templates/lxc-lenny.in
>> +++ b/templates/lxc-lenny.in
>> @@ -166,7 +166,7 @@ install_debian()
>>  return 1
>>  fi
>>  return 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-lenny
>>  
>>  return $?
>>  }
>> @@ -234,7 +234,7 @@ clean()
>>  echo -n "Purging the download cache..."
>>  rm --preserve-root --one-file-system -rf $cache && echo "Done." || 
>> exit 1
>>  exit 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-lenny
>>  }
>>  
>>  usage()
>> diff --git a/templates/lxc-opensuse.in b/templates/lxc-opensuse.in
>> index e0f8e00..65fb7b0 100644
>> --- a/templates/lxc-opensuse.in
>> +++ b/templates/lxc-opensuse.in
>> @@ -242,7 +242,7 @@ install_opensuse()
> 
> mkdir at line 218
> 
>>  fi
>>  
>>  return 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-opensuse
>>  
>>  return $?
>>  }
>> @@ -314,7 +314,7 @@ clean()
>>  echo -n "Purging the download cache..."
>>  rm --preserve-root --one-file-system -rf $cache && echo "Done." || 
>> exit 1
>>  exit 0
>> -) 200>@LOCALSTATEDIR@/lock/subsys/lxc
>> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-open

Re: [lxc-devel] [PATCH] oracle template: use @LOCALSTATEDIR@ instead of hardcoded /var for lock dir

2012-12-06 Thread Stéphane Graber
On 12/06/2012 09:19 AM, Dwight Engen wrote:
> 
> Signed-off-by: Dwight Engen 

Thanks but I already proposed that yesterday and it landed a few minutes
ago :)

> ---
>  templates/lxc-oracle.in |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/templates/lxc-oracle.in b/templates/lxc-oracle.in
> index 243f0e4..eadee3a 100644
> --- a/templates/lxc-oracle.in
> +++ b/templates/lxc-oracle.in
> @@ -337,7 +337,7 @@ container_rootfs_create()
>  fi
>  done
>  
> -mkdir -p /var/lock/subsys/
> +mkdir -p @LOCALSTATEDIR@/lock/subsys/
>  (
>  flock -x 200
>  if [ $? -ne 0 ]; then
> @@ -433,7 +433,7 @@ container_rootfs_create()
>  echo "Rebuilding rpm database"
>  rm -f $container_rootfs/var/lib/rpm/__db*
>  chroot $container_rootfs rpm --rebuilddb >/dev/null 2>&1
> -) 200>/var/lock/subsys/lxc-oracle-$name
> +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-oracle-$name
>  }
>  
>  usage()
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] [PATCH] oracle template: use @LOCALSTATEDIR@ instead of hardcoded /var for lock dir

2012-12-06 Thread Dwight Engen
On Thu, 06 Dec 2012 09:42:47 -0500
Stéphane Graber  wrote:

> On 12/06/2012 09:19 AM, Dwight Engen wrote:
> > 
> > Signed-off-by: Dwight Engen 
> 
> Thanks but I already proposed that yesterday and it landed a few
> minutes ago :)

Sounds good. I just did a pull and didn't see it in there, which is why
I sent it. Long as it got in there somehow :) Thanks.

> > ---
> >  templates/lxc-oracle.in |4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/templates/lxc-oracle.in b/templates/lxc-oracle.in
> > index 243f0e4..eadee3a 100644
> > --- a/templates/lxc-oracle.in
> > +++ b/templates/lxc-oracle.in
> > @@ -337,7 +337,7 @@ container_rootfs_create()
> >  fi
> >  done
> >  
> > -mkdir -p /var/lock/subsys/
> > +mkdir -p @LOCALSTATEDIR@/lock/subsys/
> >  (
> >  flock -x 200
> >  if [ $? -ne 0 ]; then
> > @@ -433,7 +433,7 @@ container_rootfs_create()
> >  echo "Rebuilding rpm database"
> >  rm -f $container_rootfs/var/lib/rpm/__db*
> >  chroot $container_rootfs rpm --rebuilddb >/dev/null 2>&1
> > -) 200>/var/lock/subsys/lxc-oracle-$name
> > +) 200>@LOCALSTATEDIR@/lock/subsys/lxc-oracle-$name
> >  }
> >  
> >  usage()
> > 
> 
> 


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


[lxc-devel] [PATCH] lxc.spec: add openssl and rsync as Required since both are used in lxc-clone

2012-12-06 Thread Dwight Engen
Signed-off-by: Dwight Engen 
---
 lxc.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lxc.spec.in b/lxc.spec.in
index 094c34d..51997b5 100644
--- a/lxc.spec.in
+++ b/lxc.spec.in
@@ -29,7 +29,7 @@ Summary: %{name} : Linux Container
 Group: Applications/System
 License: LGPL
 BuildRoot: %{_tmppath}/%{name}-%{version}-build
-Requires: libcap
+Requires: libcap openssl rsync
 BuildRequires: libcap libcap-devel docbook2X
 
 %description
-- 
1.7.11.7



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


[lxc-devel] [PATCH RFC] Enable use of user namespaces in containers

2012-12-06 Thread Serge Hallyn
The rootfs will need to be chowned to the mapped userids, which can
be done with the /usr/bin/uidmapshift tool shipped with the nsexec
package in ppa:serge-hallyn/userns-natty.
The container config supports new entries of the form:
 lxc.id_map = U 10 0 1
 lxc.id_map = G 10 0 1
meaning map 'virtual' uids (in the container) 0-1 to uids
10-11 on the host, and same for gids.  So long as there are
mappings specified in the container config, then CONFIG_NEWUSER will
be used when the container is cloned.  This means that container
setup is no longer done with root privilege on the host, only root
privilege in the container.  Therefore cgroup setup is moved from the
init task to the monitor task.

To use this patchset, you currently need to either use the raring
kernel at ppa:serge-hallyn/usern-natty, or build your own kernel
from either git://kernel.ubuntu.com/serge/quantal-userns.git branch
master-next.dec3.userns or branch userns-always-map-user-v76 at
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
plus a patch enabling tmpfs mounts in userns.

You also need to chown the files in the container rootfs into the
mapped range.  There is a utility at
https://code.launchpad.net/~serge-hallyn/+junk/nsexec to do this.
uidmapshift does the chowning, while the container-userns-convert
script nicely wraps that program.  So I simply

sudo lxc-create -t ubuntu -n r1
sudo container-userns-convert r1 20

will create a container which is shifted so uid 0 in the container
is uid 20 on the host.

TODO: when doing setuid(0), need to only do that if 0 is one of the
ids we map to.  Similarly, when dropping capabilities, need to only
not do that if 0 is one of the ids we map to.

Signed-off-by: Serge Hallyn 
---
 src/lxc/conf.c|  141 +
 src/lxc/conf.h|   26 ++
 src/lxc/confile.c |   60 +++
 src/lxc/start.c   |   35 +
 4 files changed, 253 insertions(+), 9 deletions(-)

diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 79d96d7..1a619d0 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -1221,7 +1221,7 @@ static int setup_kmsg(const struct lxc_rootfs *rootfs,
return 0;
 }
 
-static int setup_cgroup(const char *name, struct lxc_list *cgroups)
+int setup_cgroup(const char *name, struct lxc_list *cgroups)
 {
struct lxc_list *iterator;
struct lxc_cgroup *cg;
@@ -1882,6 +1882,7 @@ struct lxc_conf *lxc_conf_init(void)
lxc_list_init(&new->network);
lxc_list_init(&new->mount_list);
lxc_list_init(&new->caps);
+   lxc_list_init(&new->id_map);
for (i=0; ihooks[i]);
 #if HAVE_APPARMOR
@@ -2256,6 +2257,44 @@ int lxc_assign_network(struct lxc_list *network, pid_t 
pid)
return 0;
 }
 
+int add_id_mapping(enum idtype idtype, pid_t pid, uid_t host_start, uid_t 
ns_start, int range)
+{
+char path[PATH_MAX];
+int ret;
+FILE *f;
+
+ret = snprintf(path, PATH_MAX, "/proc/%d/%cid_map", pid, idtype == 
ID_TYPE_UID ? 'u' : 'g');
+if (ret < 0 || ret >= PATH_MAX) {
+fprintf(stderr, "%s: path name too long", __func__);
+return -E2BIG;
+}
+f = fopen(path, "w");
+if (!f) {
+perror("open");
+return -EINVAL;
+}
+ret = fprintf(f, "%d %d %d", ns_start, host_start, range);
+if (ret < 0)
+perror("write");
+fclose(f);
+return ret < 0 ? ret : 0;
+}
+
+int lxc_map_ids(struct lxc_list *idmap, pid_t pid)
+{
+   struct lxc_list *iterator;
+   struct id_map *map;
+   int ret = 0;
+
+   lxc_list_for_each(iterator, idmap) {
+   map = iterator->elem;
+   ret = add_id_mapping(map->idtype, pid, map->hostid, map->nsid, 
map->range);
+   if (ret)
+   break;
+   }
+   return ret;
+}
+
 int lxc_find_gateway_addresses(struct lxc_handler *handler)
 {
struct lxc_list *network = &handler->conf->network;
@@ -2364,6 +2403,93 @@ void lxc_delete_tty(struct lxc_tty_info *tty_info)
tty_info->nbtty = 0;
 }
 
+/*
+ * given a host uid, return the ns uid if it is mapped.
+ * if it is not mapped, return the original host id.
+ */
+static int shiftid(struct lxc_conf *c, int uid, enum idtype w)
+{
+   struct lxc_list *iterator;
+   struct id_map *map;
+   int low, high;
+
+   lxc_list_for_each(iterator, &c->id_map) {
+   map = iterator->elem;
+   if (map->idtype != w)
+   continue;
+
+   low = map->nsid;
+   high = map->nsid + map->range;
+   if (uid < low || uid >= high)
+   continue;
+
+   return uid - low + map->hostid;
+   }
+
+   return uid;
+}
+
+/*
+ * Take a pathname for a file created on the host, and map the uid and gid
+ * into the contain

Re: [lxc-devel] [PATCH] lxc.spec: add openssl and rsync as Required since both are used in lxc-clone

2012-12-06 Thread Stéphane Graber
On 12/06/2012 09:58 AM, Dwight Engen wrote:
> Signed-off-by: Dwight Engen 

Acked-by: Stéphane Graber 

And pushed to staging. Thanks

> ---
>  lxc.spec.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lxc.spec.in b/lxc.spec.in
> index 094c34d..51997b5 100644
> --- a/lxc.spec.in
> +++ b/lxc.spec.in
> @@ -29,7 +29,7 @@ Summary: %{name} : Linux Container
>  Group: Applications/System
>  License: LGPL
>  BuildRoot: %{_tmppath}/%{name}-%{version}-build
> -Requires: libcap
> +Requires: libcap openssl rsync
>  BuildRequires: libcap libcap-devel docbook2X
>  
>  %description
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] LXC 0.9.alpha1

2012-12-06 Thread Michael H. Warfield
On Wed, 2012-12-05 at 11:54 -0500, Stéphane Graber wrote:
> Hello,

> After discussing this briefly with Daniel, I wanted to make all of you
> aware that we are currently planning on sending a pull request of the
> staging branch on the 10th of December (next Monday).

> This pull request will very likely contain everything that's currently
> in the staging branch and is intended to become 0.9.alpha1.

> I'd therefore recommend everyone tests the current staging branch and
> sends any remaining bugfixes to the mailing list as soon as possible.

> Also, if a change you sent to the mailing-list hasn't been applied yet,
> it's very likely because I missed it as according to my mail client,
> there's no outstanding patch to review. In such case, please reply to
> this e-mail with a reference to your change and I'll make sure it's
> reviewed before I send the pull request.

Notes in building on Fedora 17...

*) Manual configure and build:

configure --help lists --enable-apparmor as an option but does not list
--disable-apparmor.  The default is enabled and the --disable-apparmor
has to be used to build on Fedora without AppArmor.

Sort of cosmetic since most of us building by hand know to invert the
sense of that enable but I think that help listing could use some
touching up.

*) Building rpms using the lxc.spec file in the package...

With the existing lxc.spec file, rpmbuild blows up on Fedora 17 with
this:

-- 
checking for docbook2man... yes
checking sys/apparmor.h usability... no
checking sys/apparmor.h presence... no
checking for sys/apparmor.h... no
configure: error: You must install the AppArmor development package in
order to compile lxc
error: Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
-- 

So it looks like --disable-apparmor needs to be added to the lxc.spec.in
file around line 65 (lxc-spec line 66):

PATH=$PATH:/usr/sbin:/sbin %configure $args --disable-apparmor
--disable-rpath

Even after that, I run into this problem building an rpm:

Fedora rpmbuild is also NOT liking this:

%{_bindir}/*
%attr(4111,root,root) %{_bindir}/lxc-attach
%attr(4111,root,root) %{_bindir}/lxc-create
%attr(4111,root,root) %{_bindir}/lxc-clone
%attr(4111,root,root) %{_bindir}/lxc-shutdown
%attr(4111,root,root) %{_bindir}/lxc-start
%attr(4111,root,root) %{_bindir}/lxc-netstat
%attr(4111,root,root) %{_bindir}/lxc-unshare
%attr(4111,root,root) %{_bindir}/lxc-execute
%attr(4111,root,root) %{_bindir}/lxc-checkpoint
%attr(4111,root,root) %{_bindir}/lxc-restart

Results in this...

RPM build errors:
File listed twice: /usr/bin/lxc-attach
File listed twice: /usr/bin/lxc-checkpoint
File listed twice: /usr/bin/lxc-clone
File listed twice: /usr/bin/lxc-create
File listed twice: /usr/bin/lxc-execute
File listed twice: /usr/bin/lxc-netstat
File listed twice: /usr/bin/lxc-restart
File listed twice: /usr/bin/lxc-shutdown
File listed twice: /usr/bin/lxc-start
File listed twice: /usr/bin/lxc-unshare

I had to comment out the "%{_bindir}/*" line.  That's probably not right
but I'm not sure how to resolve the dups due to the wildcard statement.

Also got a /usr/local/var/lib/lxc in there at line 100 that's
"@LXCPATH@".  That doesn't look right.  Shouldn't that have ended
up /var/lib/lxc without the "/usr/local" part?  Shouldn't that be using
the rpm macros there too?

After making those corrections, I was able to build rpms for F17 and I'm
starting testing from them now.

> Thanks

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!


signature.asc
Description: This is a digitally signed message part
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] LXC 0.9.alpha1

2012-12-06 Thread Michael H. Warfield
Deep down below...  A correction...

On Thu, 2012-12-06 at 11:57 -0500, Michael H. Warfield wrote:
> On Wed, 2012-12-05 at 11:54 -0500, Stéphane Graber wrote:
> > Hello,
> 
> > After discussing this briefly with Daniel, I wanted to make all of you
> > aware that we are currently planning on sending a pull request of the
> > staging branch on the 10th of December (next Monday).
> 
> > This pull request will very likely contain everything that's currently
> > in the staging branch and is intended to become 0.9.alpha1.
> 
> > I'd therefore recommend everyone tests the current staging branch and
> > sends any remaining bugfixes to the mailing list as soon as possible.
> 
> > Also, if a change you sent to the mailing-list hasn't been applied yet,
> > it's very likely because I missed it as according to my mail client,
> > there's no outstanding patch to review. In such case, please reply to
> > this e-mail with a reference to your change and I'll make sure it's
> > reviewed before I send the pull request.
> 
> Notes in building on Fedora 17...
> 
> *) Manual configure and build:
> 
> configure --help lists --enable-apparmor as an option but does not list
> --disable-apparmor.  The default is enabled and the --disable-apparmor
> has to be used to build on Fedora without AppArmor.
> 
> Sort of cosmetic since most of us building by hand know to invert the
> sense of that enable but I think that help listing could use some
> touching up.
> 
> *) Building rpms using the lxc.spec file in the package...
> 
> With the existing lxc.spec file, rpmbuild blows up on Fedora 17 with
> this:
> 
> -- 
> checking for docbook2man... yes
> checking sys/apparmor.h usability... no
> checking sys/apparmor.h presence... no
> checking for sys/apparmor.h... no
> configure: error: You must install the AppArmor development package in
> order to compile lxc
> error: Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> 
> 
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> -- 
> 
> So it looks like --disable-apparmor needs to be added to the lxc.spec.in
> file around line 65 (lxc-spec line 66):
> 
> PATH=$PATH:/usr/sbin:/sbin %configure $args --disable-apparmor
> --disable-rpath
> 
> Even after that, I run into this problem building an rpm:
> 
> Fedora rpmbuild is also NOT liking this:
> 
> %{_bindir}/*
> %attr(4111,root,root) %{_bindir}/lxc-attach
> %attr(4111,root,root) %{_bindir}/lxc-create
> %attr(4111,root,root) %{_bindir}/lxc-clone
> %attr(4111,root,root) %{_bindir}/lxc-shutdown
> %attr(4111,root,root) %{_bindir}/lxc-start
> %attr(4111,root,root) %{_bindir}/lxc-netstat
> %attr(4111,root,root) %{_bindir}/lxc-unshare
> %attr(4111,root,root) %{_bindir}/lxc-execute
> %attr(4111,root,root) %{_bindir}/lxc-checkpoint
> %attr(4111,root,root) %{_bindir}/lxc-restart
> 
> Results in this...
> 
> RPM build errors:
> File listed twice: /usr/bin/lxc-attach
> File listed twice: /usr/bin/lxc-checkpoint
> File listed twice: /usr/bin/lxc-clone
> File listed twice: /usr/bin/lxc-create
> File listed twice: /usr/bin/lxc-execute
> File listed twice: /usr/bin/lxc-netstat
> File listed twice: /usr/bin/lxc-restart
> File listed twice: /usr/bin/lxc-shutdown
> File listed twice: /usr/bin/lxc-start
> File listed twice: /usr/bin/lxc-unshare
> 
> I had to comment out the "%{_bindir}/*" line.  That's probably not right
> but I'm not sure how to resolve the dups due to the wildcard statement.

Yeah, that was a bad move.  That resulted in things like lxc-ls not
being packaged.  My bad.  So we want all those explicitly listed to be
SUID to root?  We may have to list every binary individually in order to
avoid the duplicate warnings but it turns out they're not fatal anyways
(the failure at that point had been caused the problem below not the
duplicates above).

> Also got a /usr/local/var/lib/lxc in there at line 100 that's
> "@LXCPATH@".  That doesn't look right.  Shouldn't that have ended
> up /var/lib/lxc without the "/usr/local" part?  Shouldn't that be using
> the rpm macros there too?
> 
> After making those corrections, I was able to build rpms for F17 and I'm
> starting testing from them now.
> 
> > Thanks
> 
> Regards,
> Mike

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!


signature.asc
Description: This is a digitally signed message part
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d__

Re: [lxc-devel] LXC 0.9.alpha1

2012-12-06 Thread Dwight Engen
On Thu, 06 Dec 2012 12:30:18 -0500
"Michael H. Warfield"  wrote:

> Deep down below...  A correction...
> 
> On Thu, 2012-12-06 at 11:57 -0500, Michael H. Warfield wrote:
> > On Wed, 2012-12-05 at 11:54 -0500, Stéphane Graber wrote:
> > > Hello,
> > 
> > > After discussing this briefly with Daniel, I wanted to make all
> > > of you aware that we are currently planning on sending a pull
> > > request of the staging branch on the 10th of December (next
> > > Monday).
> > 
> > > This pull request will very likely contain everything that's
> > > currently in the staging branch and is intended to become
> > > 0.9.alpha1.
> > 
> > > I'd therefore recommend everyone tests the current staging branch
> > > and sends any remaining bugfixes to the mailing list as soon as
> > > possible.
> > 
> > > Also, if a change you sent to the mailing-list hasn't been
> > > applied yet, it's very likely because I missed it as according to
> > > my mail client, there's no outstanding patch to review. In such
> > > case, please reply to this e-mail with a reference to your change
> > > and I'll make sure it's reviewed before I send the pull request.
> > 
> > Notes in building on Fedora 17...
> > 
> > *) Manual configure and build:
> > 
> > configure --help lists --enable-apparmor as an option but does not
> > list --disable-apparmor.  The default is enabled and the
> > --disable-apparmor has to be used to build on Fedora without
> > AppArmor.
> > 
> > Sort of cosmetic since most of us building by hand know to invert
> > the sense of that enable but I think that help listing could use
> > some touching up.

Hi, I'm building on Fedora 17 too for some testing. I've noticed this
once in a while, even though there are configure checks which should
check for sys/apparmor.h. I haven't been able to track down why it
sometimes doesn't work, it is a bit annoying when the autodetect
doesn't work :(


> > *) Building rpms using the lxc.spec file in the package...
> > 
> > With the existing lxc.spec file, rpmbuild blows up on Fedora 17 with
> > this:
> > 
> > -- 
> > checking for docbook2man... yes
> > checking sys/apparmor.h usability... no
> > checking sys/apparmor.h presence... no
> > checking for sys/apparmor.h... no
> > configure: error: You must install the AppArmor development package
> > in order to compile lxc
> > error: Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> > 
> > 
> > RPM build errors:
> > Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> > -- 
> > 
> > So it looks like --disable-apparmor needs to be added to the
> > lxc.spec.in file around line 65 (lxc-spec line 66):
> > 
> > PATH=$PATH:/usr/sbin:/sbin %configure $args --disable-apparmor
> > --disable-rpath
> > 
> > Even after that, I run into this problem building an rpm:
> > 
> > Fedora rpmbuild is also NOT liking this:
> > 
> > %{_bindir}/*
> > %attr(4111,root,root) %{_bindir}/lxc-attach
> > %attr(4111,root,root) %{_bindir}/lxc-create
> > %attr(4111,root,root) %{_bindir}/lxc-clone
> > %attr(4111,root,root) %{_bindir}/lxc-shutdown
> > %attr(4111,root,root) %{_bindir}/lxc-start
> > %attr(4111,root,root) %{_bindir}/lxc-netstat
> > %attr(4111,root,root) %{_bindir}/lxc-unshare
> > %attr(4111,root,root) %{_bindir}/lxc-execute
> > %attr(4111,root,root) %{_bindir}/lxc-checkpoint
> > %attr(4111,root,root) %{_bindir}/lxc-restart
> > 
> > Results in this...
> > 
> > RPM build errors:
> > File listed twice: /usr/bin/lxc-attach
> > File listed twice: /usr/bin/lxc-checkpoint
> > File listed twice: /usr/bin/lxc-clone
> > File listed twice: /usr/bin/lxc-create
> > File listed twice: /usr/bin/lxc-execute
> > File listed twice: /usr/bin/lxc-netstat
> > File listed twice: /usr/bin/lxc-restart
> > File listed twice: /usr/bin/lxc-shutdown
> > File listed twice: /usr/bin/lxc-start
> > File listed twice: /usr/bin/lxc-unshare
> > 
> > I had to comment out the "%{_bindir}/*" line.  That's probably not
> > right but I'm not sure how to resolve the dups due to the wildcard
> > statement.
> 
> Yeah, that was a bad move.  That resulted in things like lxc-ls not
> being packaged.  My bad.  So we want all those explicitly listed to be
> SUID to root?  We may have to list every binary individually in order
> to avoid the duplicate warnings but it turns out they're not fatal
> anyways (the failure at that point had been caused the problem below
> not the duplicates above).

Yeah, the duplicates are just warnings, but we probably should fix it by
listing the files individually instead of using the glob.

> > Also got a /usr/local/var/lib/lxc in there at line 100 that's
> > "@LXCPATH@".  That doesn't look right.  Shouldn't that have ended
> > up /var/lib/lxc without the "/usr/local" part?  Shouldn't that be
> > using the rpm macros there too?

When you run ./configure, you have to pass the same options rpmbuild
will to make sure LXCPATH gets expanded right.

> > After making those corrections, I was able to build rpms for F17
> > and I'm starting 

Re: [lxc-devel] LXC 0.9.alpha1

2012-12-06 Thread Michael H. Warfield
On Thu, 2012-12-06 at 12:46 -0500, Dwight Engen wrote:
> On Thu, 06 Dec 2012 12:30:18 -0500
> "Michael H. Warfield"  wrote:



> Yeah, the duplicates are just warnings, but we probably should fix it by
> listing the files individually instead of using the glob.
> 
> > > Also got a /usr/local/var/lib/lxc in there at line 100 that's
> > > "@LXCPATH@".  That doesn't look right.  Shouldn't that have ended
> > > up /var/lib/lxc without the "/usr/local" part?  Shouldn't that be
> > > using the rpm macros there too?

> When you run ./configure, you have to pass the same options rpmbuild
> will to make sure LXCPATH gets expanded right.

Yeah, problem is that it's blowing in the rpmbuild.  So something isn't
getting passed right in the spec file.

Looks like that line in the spec file should have been this...

%{_localstatedir}/lib/lxc

Instead of this (like I set it)...

/var/lib/lxc

And certainly not this...

/usr/local/var/lib/lxc

Not sure where the breakage was but I'm guess the line in lxc.spec.in at
line 65 is the culprit...

-- 
%{_libdir}/%{name}
@LXCPATH@
%{_localstatedir}/cache/lxc
-- 

Maybe should have been...

-- 
%{_libdir}/%{name}
%{_localstatedir}/var/lxc
%{_localstatedir}/cache/lxc
-- 

There may be a more appropriate macro for /var/lib but I'm not sure of
it.

> > > After making those corrections, I was able to build rpms for F17
> > > and I'm starting testing from them now.

My test system is running right now with the prealpha git code installed
from rpms I built from stage with those corrections.  I have F14, F15,
and F17 containers as well as CentOS 5 and 6 containers.  All seem
content.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!


signature.asc
Description: This is a digitally signed message part
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] LXC 0.9.alpha1

2012-12-06 Thread Dwight Engen
On Thu, 6 Dec 2012 12:46:28 -0500
Dwight Engen  wrote:

> On Thu, 06 Dec 2012 12:30:18 -0500
> "Michael H. Warfield"  wrote:
> 
> > Deep down below...  A correction...
> > 
> > On Thu, 2012-12-06 at 11:57 -0500, Michael H. Warfield wrote:
> > > On Wed, 2012-12-05 at 11:54 -0500, Stéphane Graber wrote:
> > > > Hello,
> > > 
> > > > After discussing this briefly with Daniel, I wanted to make all
> > > > of you aware that we are currently planning on sending a pull
> > > > request of the staging branch on the 10th of December (next
> > > > Monday).
> > > 
> > > > This pull request will very likely contain everything that's
> > > > currently in the staging branch and is intended to become
> > > > 0.9.alpha1.
> > > 
> > > > I'd therefore recommend everyone tests the current staging
> > > > branch and sends any remaining bugfixes to the mailing list as
> > > > soon as possible.
> > > 
> > > > Also, if a change you sent to the mailing-list hasn't been
> > > > applied yet, it's very likely because I missed it as according
> > > > to my mail client, there's no outstanding patch to review. In
> > > > such case, please reply to this e-mail with a reference to your
> > > > change and I'll make sure it's reviewed before I send the pull
> > > > request.
> > > 
> > > Notes in building on Fedora 17...
> > > 
> > > *) Manual configure and build:
> > > 
> > > configure --help lists --enable-apparmor as an option but does not
> > > list --disable-apparmor.  The default is enabled and the
> > > --disable-apparmor has to be used to build on Fedora without
> > > AppArmor.
> > > 
> > > Sort of cosmetic since most of us building by hand know to invert
> > > the sense of that enable but I think that help listing could use
> > > some touching up.
> 
> Hi, I'm building on Fedora 17 too for some testing. I've noticed this
> once in a while, even though there are configure checks which should
> check for sys/apparmor.h. I haven't been able to track down why it
> sometimes doesn't work, it is a bit annoying when the autodetect
> doesn't work :(
> 
> 
> > > *) Building rpms using the lxc.spec file in the package...
> > > 
> > > With the existing lxc.spec file, rpmbuild blows up on Fedora 17
> > > with this:
> > > 
> > > -- 
> > > checking for docbook2man... yes
> > > checking sys/apparmor.h usability... no
> > > checking sys/apparmor.h presence... no
> > > checking for sys/apparmor.h... no
> > > configure: error: You must install the AppArmor development
> > > package in order to compile lxc
> > > error: Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> > > 
> > > 
> > > RPM build errors:
> > > Bad exit status from /var/tmp/rpm-tmp.8VlE1L (%build)
> > > -- 
> > > 
> > > So it looks like --disable-apparmor needs to be added to the
> > > lxc.spec.in file around line 65 (lxc-spec line 66):
> > > 
> > > PATH=$PATH:/usr/sbin:/sbin %configure $args --disable-apparmor
> > > --disable-rpath
> > > 
> > > Even after that, I run into this problem building an rpm:
> > > 
> > > Fedora rpmbuild is also NOT liking this:
> > > 
> > > %{_bindir}/*
> > > %attr(4111,root,root) %{_bindir}/lxc-attach
> > > %attr(4111,root,root) %{_bindir}/lxc-create
> > > %attr(4111,root,root) %{_bindir}/lxc-clone
> > > %attr(4111,root,root) %{_bindir}/lxc-shutdown
> > > %attr(4111,root,root) %{_bindir}/lxc-start
> > > %attr(4111,root,root) %{_bindir}/lxc-netstat
> > > %attr(4111,root,root) %{_bindir}/lxc-unshare
> > > %attr(4111,root,root) %{_bindir}/lxc-execute
> > > %attr(4111,root,root) %{_bindir}/lxc-checkpoint
> > > %attr(4111,root,root) %{_bindir}/lxc-restart
> > > 
> > > Results in this...
> > > 
> > > RPM build errors:
> > > File listed twice: /usr/bin/lxc-attach
> > > File listed twice: /usr/bin/lxc-checkpoint
> > > File listed twice: /usr/bin/lxc-clone
> > > File listed twice: /usr/bin/lxc-create
> > > File listed twice: /usr/bin/lxc-execute
> > > File listed twice: /usr/bin/lxc-netstat
> > > File listed twice: /usr/bin/lxc-restart
> > > File listed twice: /usr/bin/lxc-shutdown
> > > File listed twice: /usr/bin/lxc-start
> > > File listed twice: /usr/bin/lxc-unshare
> > > 
> > > I had to comment out the "%{_bindir}/*" line.  That's probably not
> > > right but I'm not sure how to resolve the dups due to the wildcard
> > > statement.
> > 
> > Yeah, that was a bad move.  That resulted in things like lxc-ls not
> > being packaged.  My bad.  So we want all those explicitly listed to
> > be SUID to root?  We may have to list every binary individually in
> > order to avoid the duplicate warnings but it turns out they're not
> > fatal anyways (the failure at that point had been caused the
> > problem below not the duplicates above).
> 
> Yeah, the duplicates are just warnings, but we probably should fix it
> by listing the files individually instead of using the glob.
> 
> > > Also got a /usr/local/var/lib/lxc in there at line 100 that's
> > > "@LXCPATH@".  That doesn't look right.  Shouldn't that have ended
> > > up /va

[lxc-devel] [PATCH] assume LXCPATH took on default localstatedir based value in configure

2012-12-06 Thread Dwight Engen
On Thu, 06 Dec 2012 13:10:09 -0500
"Michael H. Warfield"  wrote:

> On Thu, 2012-12-06 at 12:46 -0500, Dwight Engen wrote:
> > On Thu, 06 Dec 2012 12:30:18 -0500
> > "Michael H. Warfield"  wrote:
> 
> 
> 
> > Yeah, the duplicates are just warnings, but we probably should fix
> > it by listing the files individually instead of using the glob.
> > 
> > > > Also got a /usr/local/var/lib/lxc in there at line 100 that's
> > > > "@LXCPATH@".  That doesn't look right.  Shouldn't that have
> > > > ended up /var/lib/lxc without the "/usr/local" part?  Shouldn't
> > > > that be using the rpm macros there too?
> 
> > When you run ./configure, you have to pass the same options rpmbuild
> > will to make sure LXCPATH gets expanded right.
> 
> Yeah, problem is that it's blowing in the rpmbuild.  So something
> isn't getting passed right in the spec file.
> 
> Looks like that line in the spec file should have been this...
> 
> %{_localstatedir}/lib/lxc
> 
> Instead of this (like I set it)...
> 
> /var/lib/lxc
> 
> And certainly not this...
> 
> /usr/local/var/lib/lxc
> 
> Not sure where the breakage was but I'm guess the line in lxc.spec.in
> at line 65 is the culprit...

I think this is pretty much what you're suggesting (correct based
on current options passed by spec to configure):

--

Signed-off-by: Dwight Engen 
---
 lxc.spec.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lxc.spec.in b/lxc.spec.in
index 51997b5..c7470b8 100644
--- a/lxc.spec.in
+++ b/lxc.spec.in
@@ -97,8 +97,7 @@ rm -rf %{buildroot}
 %defattr(-,root,root)
 %{_libdir}/*.so.*
 %{_libdir}/%{name}
-@LXCPATH@
-%{_localstatedir}/cache/lxc
+%{_localstatedir}/*
 %attr(4555,root,root) %{_libexecdir}/%{name}/lxc-init
 
 %files devel
-- 
1.7.11.7


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel


Re: [lxc-devel] [PATCH RFC] Enable use of user namespaces in containers

2012-12-06 Thread Stéphane Graber
On 12/06/2012 10:02 AM, Serge Hallyn wrote:
> The rootfs will need to be chowned to the mapped userids, which can
> be done with the /usr/bin/uidmapshift tool shipped with the nsexec
> package in ppa:serge-hallyn/userns-natty.
> The container config supports new entries of the form:
>  lxc.id_map = U 10 0 1
>  lxc.id_map = G 10 0 1
> meaning map 'virtual' uids (in the container) 0-1 to uids
> 10-11 on the host, and same for gids.  So long as there are
> mappings specified in the container config, then CONFIG_NEWUSER will
> be used when the container is cloned.  This means that container
> setup is no longer done with root privilege on the host, only root
> privilege in the container.  Therefore cgroup setup is moved from the
> init task to the monitor task.
> 
> To use this patchset, you currently need to either use the raring
> kernel at ppa:serge-hallyn/usern-natty, or build your own kernel
> from either git://kernel.ubuntu.com/serge/quantal-userns.git branch
> master-next.dec3.userns or branch userns-always-map-user-v76 at
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> plus a patch enabling tmpfs mounts in userns.
> 
> You also need to chown the files in the container rootfs into the
> mapped range.  There is a utility at
> https://code.launchpad.net/~serge-hallyn/+junk/nsexec to do this.
> uidmapshift does the chowning, while the container-userns-convert
> script nicely wraps that program.  So I simply
> 
>   sudo lxc-create -t ubuntu -n r1
>   sudo container-userns-convert r1 20
> 
> will create a container which is shifted so uid 0 in the container
> is uid 20 on the host.
> 
> TODO: when doing setuid(0), need to only do that if 0 is one of the
> ids we map to.  Similarly, when dropping capabilities, need to only
> not do that if 0 is one of the ids we map to.
> 
> Signed-off-by: Serge Hallyn 

Nice, the code is much simpler than I expected.

I only read through pretty briefly and left a few comments, mostly
questions and cosmetics than problems with the code itself.

I'm also wondering, what's the state of lxc-attach wrt user namespaces?
does it need any updating too?

> ---
>  src/lxc/conf.c|  141 
> +
>  src/lxc/conf.h|   26 ++
>  src/lxc/confile.c |   60 +++
>  src/lxc/start.c   |   35 +
>  4 files changed, 253 insertions(+), 9 deletions(-)
> 
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 79d96d7..1a619d0 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -1221,7 +1221,7 @@ static int setup_kmsg(const struct lxc_rootfs *rootfs,
>   return 0;
>  }
>  
> -static int setup_cgroup(const char *name, struct lxc_list *cgroups)
> +int setup_cgroup(const char *name, struct lxc_list *cgroups)

Why the change?

>  {
>   struct lxc_list *iterator;
>   struct lxc_cgroup *cg;
> @@ -1882,6 +1882,7 @@ struct lxc_conf *lxc_conf_init(void)
>   lxc_list_init(&new->network);
>   lxc_list_init(&new->mount_list);
>   lxc_list_init(&new->caps);
> + lxc_list_init(&new->id_map);
>   for (i=0; i   lxc_list_init(&new->hooks[i]);
>  #if HAVE_APPARMOR
> @@ -2256,6 +2257,44 @@ int lxc_assign_network(struct lxc_list *network, pid_t 
> pid)
>   return 0;
>  }
>  
> +int add_id_mapping(enum idtype idtype, pid_t pid, uid_t host_start, uid_t 
> ns_start, int range)
> +{
> +char path[PATH_MAX];
> +int ret;
> +FILE *f;
> +
> +ret = snprintf(path, PATH_MAX, "/proc/%d/%cid_map", pid, idtype == 
> ID_TYPE_UID ? 'u' : 'g');
> +if (ret < 0 || ret >= PATH_MAX) {
> +fprintf(stderr, "%s: path name too long", __func__);
> +return -E2BIG;
> +}
> +f = fopen(path, "w");
> +if (!f) {
> +perror("open");
> +return -EINVAL;
> +}
> +ret = fprintf(f, "%d %d %d", ns_start, host_start, range);
> +if (ret < 0)
> +perror("write");
> +fclose(f);
> +return ret < 0 ? ret : 0;
> +}
> +
> +int lxc_map_ids(struct lxc_list *idmap, pid_t pid)
> +{
> + struct lxc_list *iterator;
> + struct id_map *map;
> + int ret = 0;
> +
> + lxc_list_for_each(iterator, idmap) {
> + map = iterator->elem;
> + ret = add_id_mapping(map->idtype, pid, map->hostid, map->nsid, 
> map->range);
> + if (ret)
> + break;
> + }
> + return ret;
> +}
> +
>  int lxc_find_gateway_addresses(struct lxc_handler *handler)
>  {
>   struct lxc_list *network = &handler->conf->network;
> @@ -2364,6 +2403,93 @@ void lxc_delete_tty(struct lxc_tty_info *tty_info)
>   tty_info->nbtty = 0;
>  }
>  
> +/*
> + * given a host uid, return the ns uid if it is mapped.
> + * if it is not mapped, return the original host id.
> + */
> +static int shiftid(struct lxc_conf *c, int uid, enum idtype w)
> +{
> + struc

[lxc-devel] [PATCH 1/1] api: add set_cgroup_item and get_cgroup_item (to c api)

2012-12-06 Thread Serge Hallyn
set_cgroup_item takes a pointer to a running container, a cgroup subsystem
name, and a char *value and it mimicks
'lxc-cgroup -n containername subsys value'
get_cgroup_item takes a pointer to a running container, a a cgroup
subsystem name, a destination value * and the length of the value being
sent in, and returns the length of what was read from the cgroup file.
If a 0 len is passed in, then the length of the file is returned.  So
you can do

len = c->get_cgroup_item(c, "devices.list", NULL, 0);
v = malloc(len+1);
ret = c->get_cgroup_item(c, "devices.list", v, len);

to read the whole file.

This patch also disables the lxc-init part of the startone test, which
was failing because lxc-init has been moved due to multiarch issues.
The test is salvagable, but saving it was beyond this effort.

Signed-off-by: Serge Hallyn 
---
 src/lxc/cgroup.c   |   20 ++-
 src/lxc/lxccontainer.c |   52 
 src/lxc/lxccontainer.h |9 +
 src/tests/startone.c   |   47 +++
 4 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 532d638..b6c948b 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -789,6 +789,13 @@ out:
return ret;
 }
 
+/*
+ * If you pass in NULL value or 0 len, then you are asking for the size
+ * of the file.  Note that we can't get the file size quickly through stat
+ * or lseek.  Therefore if you pass in len > 0 but less than the file size,
+ * your only indication will be that the return value will be equal to the
+ * passed-in ret.  We will not return the actual full file size.
+ */
 int lxc_cgroup_get(const char *name, const char *filename,
   char *value, size_t len)
 {
@@ -813,7 +820,18 @@ int lxc_cgroup_get(const char *name, const char *filename,
return -1;
}
 
-   ret = read(fd, value, len);
+if (!len || !value) {
+char buf[100];
+int count = 0;
+while ((ret = read(fd, buf, 100)) > 0)
+count += ret;
+if (ret >= 0)
+ret = count;
+} else {
+memset(value, 0, len);
+ret = read(fd, value, len);
+}
+
if (ret < 0)
ERROR("read %s : %s", path, strerror(errno));
 
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index d25b848..1345ab5 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -163,6 +163,13 @@ static const char *lxcapi_state(struct lxc_container *c)
return ret;
 }
 
+static bool is_stopped_nolock(struct lxc_container *c)
+{
+   lxc_state_t s;
+   s = lxc_getstate(c->name);
+   return (s == STOPPED);
+}
+
 static bool lxcapi_is_running(struct lxc_container *c)
 {
const char *s;
@@ -850,6 +857,49 @@ static char *lxcapi_config_file_name(struct lxc_container 
*c)
return strdup(c->configfile);
 }
 
+static bool lxcapi_set_cgroup_item(struct lxc_container *c, const char 
*subsys, const char *value)
+{
+   int ret;
+   bool b = false;
+
+   if (!c)
+   return false;
+
+   if (lxclock(c->privlock, 0))
+   return false;
+
+   if (is_stopped_nolock(c))
+   goto err;
+
+   ret = lxc_cgroup_set(c->name, subsys, value);
+   if (!ret)
+   b = true;
+err:
+   lxcunlock(c->privlock);
+   return b;
+}
+
+static int lxcapi_get_cgroup_item(struct lxc_container *c, const char *subsys, 
char *retv, int inlen)
+{
+   int ret = -1;
+
+   if (!c || !c->lxc_conf)
+   return -1;
+
+   if (lxclock(c->privlock, 0))
+   return -1;
+
+   if (is_stopped_nolock(c))
+   goto out;
+
+   ret = lxc_cgroup_get(c->name, subsys, retv, inlen);
+
+out:
+   lxcunlock(c->privlock);
+   return ret;
+}
+
+
 struct lxc_container *lxc_container_new(const char *name)
 {
struct lxc_container *c;
@@ -920,6 +970,8 @@ struct lxc_container *lxc_container_new(const char *name)
c->shutdown = lxcapi_shutdown;
c->clear_config_item = lxcapi_clear_config_item;
c->get_config_item = lxcapi_get_config_item;
+   c->get_cgroup_item = lxcapi_get_cgroup_item;
+   c->set_cgroup_item = lxcapi_set_cgroup_item;
 
/* we'll allow the caller to update these later */
if (lxc_log_init(NULL, NULL, "lxc_container", 0)) {
diff --git a/src/lxc/lxccontainer.h b/src/lxc/lxccontainer.h
index 9c9296c..a6fdb2b 100644
--- a/src/lxc/lxccontainer.h
+++ b/src/lxc/lxccontainer.h
@@ -48,6 +48,15 @@ struct lxc_container {
 * the length which was our would be printed. */
int (*get_config_item)(struct lxc_container *c, const char *key, char 
*retv, int inlen);
int (*get_keys)(struct lxc_container *c, const char *key, char *retv, 
int inlen);
+   /*
+* get_cgroup_item returns the number of bytes read, or an error (<0).
+* If retv

Re: [lxc-devel] [PATCH RFC] Enable use of user namespaces in containers

2012-12-06 Thread Serge Hallyn
Quoting Stéphane Graber (stgra...@ubuntu.com):
...
> I'm also wondering, what's the state of lxc-attach wrt user namespaces?
> does it need any updating too?

I need to check that still - I'm not sure.

> > @@ -1221,7 +1221,7 @@ static int setup_kmsg(const struct lxc_rootfs *rootfs,
> > return 0;
> >  }
> >  
> > -static int setup_cgroup(const char *name, struct lxc_list *cgroups)
> > +int setup_cgroup(const char *name, struct lxc_list *cgroups)
> 
> Why the change?

Because setup_cgroup now has to be done by the parent in start.c.  When
not starting a new user namespace, the child task has a period of time
after the clone(CLONE_NEWNS|...) where it is still root and able to
set up cgroups.  But when doing clone(CLONE_NEWUSER) then it immediately
is unable to do so, so we now have the parent do it after it knows
the child has been cloned.

> > -   if (setup_caps(&lxc_conf->caps)) {
> > -   ERROR("failed to drop capabilities");
> > -   return -1;
> > +   if (lxc_list_empty(&lxc_conf->id_map)) {
> > +   if (setup_caps(&lxc_conf->caps)) {
> > +   ERROR("failed to drop capabilities");
> > +   return -1;
> > +   }
> > }
> 
> Why can't we drop capabilities in a user namespace?

We can, but we don't need to.  Root in the new namespace can run with
all capabilities since the capabilities are targeted to resources owned
by the container{

-serge

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel