[lxc-devel] [Not A Patch] [POC] Proof of concept code for using devtmpfs for autodev and more...

[Michael H. Warfield]

On Fri, 2013-11-01 at 17:25 -0500, Serge Hallyn wrote: 
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > On Fri, 2013-11-01 at 16:30 -0500, Serge Hallyn wrote: 
> > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > On Fri, 2013-11-01 at 15:03 -0500, Serge Hallyn wrote: 
> > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > > > The only place that's being used is in creating a symlink...
> > > > > > 
> > > > > > /dev/.lxc/$name -> /dev/.lxc/$pathhash
> > > > > > 
> > > > > > I use it for the same reason you wanted the extra bind mounts to
> > > > > > $lxcpath/$lxcname.dev.  In your case, you wanted to see the dev mappings
> > > > > 
> > > > > Oh - gotcha.  Well in that case I'd say just create your own unique
> > > > > $name.$index.  that should be enough info.

Hmmm...  I sort of like that idea of $name.{something}.  Specifically, I
like the idea of "$name.$(hash $lxcpath/$name)".  It's a little
redundant but, you specifically said, a name is unique within a given
lxcpath and that has a certain elegance to it compaired to merely
hashing the rootfs.  I changed that so it's now /dev/.lxc/$name.$(hash
$lxcpath/$name).

> > > > > Oh now unprivileged container creation of course will not be able
> > > > > to do this as I won't be able to create /dev/.lxc/anything as uid
> > > > > 1000.
> > > > 
> > > > Oh, we're going to have to look into that then.  We're doing other
> > > > privileged operations like the bind mounts...  Hmmm...  It may have to
> > 
> > > bind mounts are ok.  we can do this in a private mntns.  That's how
> > > I currently get around our inability to mknod in a userns - I
> > > bind mount devices from the host into the container's /dev.

Oh boy was that a clue.  Any mounts I do in that area of code is not
showing up on the host.  I had to change some logic to fit your bill
there.  You were asking for some bind mounts back
into /dev/.lxc/{container_dev} but that doesn't work from the host view.
It'll have to be symlinks (which are easy and don't clutter up the mount
tables) or it will have done somewhere else.

> > Ok...  How are you handling the creation of objects under $lxc_path
> > then?  Obviously, I haven't been paying much attention to the unpriv
> > user angle of things here.  Is it like many of the other virt systems
> > where the user needs to be part of a particular group?  Could we do
> > something similar?

> No.  I mkdir /home/serge/lxcbase and do

> 	lxc-create -t tarball -n b1 -P /home/serge/lxcbase -f /home/serge/lxc.conf -- -T /home/serge/ubuntu.tgz

> (tarball is a special template that just extracts the given tarball.
> I'm working on a patch to not need to do that, but I've been very
> distracted by other issues)

> So the key is the "-P" which specifies that the container lives in a
> directory which I own.

Bingo.  That whole key was really what I needed...

> Ok, so really to get this to work I first need to:

> 1.  cat > /home/serge/lxc.conf << EOF
> lxc.network.type = veth
> lxc.network.link = lxcbr0
> lxc.network.flags = up
> lxc.id_map = u 0 100000 10000
> lxc.id_map = g 0 100000 10000
> EOF

> 2. sudo usermod -v 100000-200000 -w 100000-200000 serge

> And then if I want to actually start the container (since I specified a
> nic) I need to

> 3. cat >> /etc/lxc/lxc-usernet  << EOF
> serge veth lxcbr0 2
> EOF

I think I can address all of this now and a couple of other issues.
More to follow, shortly.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at 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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131109/5ef97ce1/attachment.pgp>