On Fri, 2013-11-01 at 17:25 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Fri, 2013-11-01 at 16:30 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > On Fri, 2013-11-01 at 15:03 -0500, Serge Hallyn wrote: > > > > > Quoting Michael H. Warfield (m...@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 | 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
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
