On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber <stgra...@ubuntu.com> wrote: > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: >> Hey Stéphane, >> >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber <stgra...@ubuntu.com> wrote: >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: >> >> On Mon, 13 Jan 2014 20:56:23 -0500 >> >> Stéphane Graber <stgra...@ubuntu.com> wrote: >> >> >> >> [...] >> >> > >> >> > Yeah, I did a few last-minute changes. >> >> > >> >> > fstab is no longer required (only copied over if it's there). >> >> > >> >> > If the expiry file is messing, it's simply assumed that the container >> >> > won't expire. >> >> >> >> Nice, that makes sense. >> >> >> >> [...] >> >> > Now for Oracle, I guess it depends what's most useful for your users. >> >> > >> >> > Is there actually still a demand for 4.x? I thought at least RHEL 4.x >> >> > went out of support last year. >> >> > >> >> > In any case, I suspect that starting with the latest of each supported >> >> > release on i386 and amd64 is probably a good start. >> >> > We can then expand that to include popular minor releases, possibly >> >> > the last few 6.x? >> >> >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and >> >> we'll see how it goes from there. >> >> >> >> > > One question I have on this is that the rootfs (at least that the >> >> > > Oracle template makes, not sure about others) isn't quite right >> >> > > since the host name will have already been injected into config >> >> > > files (for example /etc/hosts), but lxc-download wants to template >> >> > > them itself. Should we add a switch to the distro template so it >> >> > > knows when its being called to create a rootfs for lxc-download to >> >> > > put LXC_NAME in there instead the --name it was passed? >> >> > >> >> > So currently my build script (Jenkins job) will call the template >> >> > with: >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs >> >> > - --path=/build-lxc/container/LXC_NAME >> >> > - --name=LXC_NAME >> >> >> >> Oh yeah, doh! Clever, that should make it work fine. >> >> >> >> [...] >> >> > > I have not tried from a normal user account yet. Is it basically >> >> > > that you expect the template to be run by a normal user, but be >> >> > > running in a userns? Can you describe how mapped_uid is supposed to >> >> > > be set? Thanks! >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate >> >> > Yeah, lxc-create basically does all the magic we need there. >> >> > When run as a user, it'll run the template in a userns mapped with the >> >> > container's range. >> >> > >> >> > $mapped_uid appears to be set to the uid in the userns which maps back >> >> > to the user's own uid outside of it and makes it possible to chown >> >> > files back to the actual user. >> >> >> >> So I had to dig into the source to see how I could get this to work, >> >> and tried passing a line like: >> >> >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n >> >> ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server >> >> lxchttp/lxc-images --no-validate >> >> >> >> where /home/dengen/ct/dengen_id_map.conf just has: >> >> lxc.id_map = u 0 100000 10000 >> >> lxc.id_map = g 0 100000 10000 >> >> >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't >> >> work because lxc.spec is still installing lxc-create (and a lot more) >> >> setuid, so the geteuid() check in create_run_template() isn't firing. >> >> So my question is: which lxc binaries are supposed to be installed >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead >> >> and fixup lxc.spec. Thanks. >> > >> > Oh, wow, I didn't realize some distros were still installing anything >> > setuid these days, especially after we drop lxc-setuid and lxc-setcap >> > from the upstream tree. >> > >> > So anyway, nowadays, the recommendation is for only lxc-user-nic to be >> > setuid, everything else should always run as the user. When run as root, >> > you'll end up with system containers, when run as a user, you'll get an >> > unprivileged container. >> >> Should I expect [1] to work on saucy with trusty kernel? Here is what >> I'm getting >> >> [caglar@oOo:~] ./unprivileged.sh >> Creating unpriv with dir >> Using image from local cache >> Unpacking the rootfs >> chown: invalid user: ‘-f’ > > What shell is providing /bin/sh on your system? > > I confirmed that chown had a -f argument on both busybox, dash and bash, > but apparently you're using something else. > > Anyway, I'll fix that particular failure by using a good old || true then.
I'm using bash but I think problem is not the -f parameter but wrong LXC_MAPPED_UID value. Printing the LXC_MAPPED_UID via if [ -n "$LXC_MAPPED_UID" ] && [ "$LXC_MAPPED_UID" != "-1" ]; then echo "***" $LXC_MAPPED_UID "***" chown $LXC_MAPPED_UID -f $LXC_PATH/config $LXC_PATH/fstab || true fi shows this [caglar@oOo:~] ./unprivileged.sh Creating unpriv with dir Using image from local cache Unpacking the rootfs *** -- *** chown: invalid user: ‘-f’ --- You just created an Ubuntu container (release=saucy, arch=amd64). The default username/password is: ubuntu / ubuntu To gain root privileges, please use sudo. >> >> --- >> You just created an Ubuntu container (release=saucy, arch=amd64). >> The default username/password is: ubuntu / ubuntu >> To gain root privileges, please use sudo. >> Starting/Attaching/Stopping to unpriv >> lxc-start: command get_cgroup failed to receive response >> lxc-attach: failed to get the init pid >> unpriv is not running >> Destroying unpriv > > The rest of the failure is coming from you not having the proper > cgroupfs setup. Try something like: > > for controller in /sys/fs/cgroup; do > sudo mkdir -p $controller/$USER/lxc > sudo chown -R $USER $controller/$USER > echo $$ > $controller/$USER/lxc/tasks > done > > This assumes that the top level clone_children and use_hierarchy are set > to 1 prior to doing this. > > It's unfortunately a bit painful to setup by hand everytime but > cgmanager should fix that once it lands. Ah right, will try with this. >> >> [caglar@oOo:~] grep ERROR unpriv.log >> lxc-start 1389751901.034 ERROR lxc_cgroup - Permission denied >> - Could not create cgroup /unpriv >> lxc-start 1389751901.034 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/hugetlb//lxc >> lxc-start 1389751901.035 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/hugetlb/ >> lxc-start 1389751901.035 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event//lxc >> lxc-start 1389751901.035 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/ >> lxc-start 1389751901.035 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio//lxc >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/ >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer//lxc >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/ >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/devices//lxc >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/ >> lxc-start 1389751901.036 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/memory//lxc >> lxc-start 1389751901.037 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/memory/ >> lxc-start 1389751901.037 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuacct//lxc >> lxc-start 1389751901.037 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuacct/ >> lxc-start 1389751901.037 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu//lxc >> lxc-start 1389751901.037 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu/ >> lxc-start 1389751901.038 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset//lxc >> lxc-start 1389751901.038 ERROR lxc_cgroup - Permission denied >> - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/ >> lxc-start 1389751901.038 ERROR lxc_start - failed to create >> cgroups for 'unpriv' >> lxc-start 1389751901.038 ERROR lxc_start - failed to spawn 'unpriv' >> lxc-start 1389751901.039 ERROR lxc_commands - command >> get_cgroup failed to receive response >> >> [1] https://gist.github.com/caglar10ur/8429502 >> >> > -- >> > Stéphane Graber >> > Ubuntu developer >> > http://www.ubuntu.com >> > >> > _______________________________________________ >> > lxc-devel mailing list >> > lxc-devel@lists.linuxcontainers.org >> > http://lists.linuxcontainers.org/listinfo/lxc-devel >> > >> >> >> >> -- >> S.Çağlar Onur <cag...@10ur.org> >> _______________________________________________ >> lxc-devel mailing list >> lxc-devel@lists.linuxcontainers.org >> http://lists.linuxcontainers.org/listinfo/lxc-devel > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > > _______________________________________________ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel > -- S.Çağlar Onur <cag...@10ur.org> _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel