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 <[email protected]> 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 <[email protected]> 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.
>
> ---
> 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.
>
> [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
> > [email protected]
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> >
>
>
>
> --
> S.Çağlar Onur <[email protected]>
> _______________________________________________
> lxc-devel mailing list
> [email protected]
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
