So after some expmeriments, this is what I have: http://goo.gl/7p3nUI - create c7 container, e.g. lxc-create -n c7v -t download -B zfs --zfsroot rpool/lxc -- -d centos -r 7 -a amd64
- edit config file. See "config" on that gdrive link, look for "Manual additions" - place script/systemd_create_cgroup in the correct path (whatever you use the config file), chmod 700 - start the container. This is similar with what I did for fedora20, on https://lists.linuxcontainers.org/pipermail/lxc-users/2014-May/007069.html What works that previously doesn't: - lxc-console - default apparmor container profile (so, for example, you can't mess up host's cgroup allocation) - default lxc.cap.drop (although you might want to remove sys_nice if you have apps that depend on it) - rsyslogd now always start correctly (previously there could be stale PIDs on /var/run) What still does NOT work: unpriviledged container I tried backporting F22's systemd-218 plus ubuntu vivid's changes (RPMS and SPECS folder), but it wasn't enough to run unpriviledged container. It should be reasonably safer than allow-the-container-to-do-anything approach previously needed for c7. -- Fajar On Fri, Feb 6, 2015 at 9:35 PM, CDR <vene...@gmail.com> wrote: > Thanks. > I love Ubuntu as a host for LXC. I just got addicted to systemctl and > writing *.service files. It is much more sophisticated than the older way of > starting and stopping applications. > > On Fri, Feb 6, 2015 at 8:40 AM, Fajar A. Nugraha <l...@fajar.net> wrote: >> >> On Fri, Feb 6, 2015 at 8:15 PM, CDR <vene...@gmail.com> wrote: >> > Thanks for the response. >> > I disable selinux and a apparmor routinely. My containers are just a way >> > to >> > separate applications, there are no users accessing them, nothing bad >> > can >> > happen. >> > So basically you are saying that there is no way to run Centos 7 under >> > an >> > Ubuntu host. >> >> No. What I'm saying is when you use c7 container (and possible most >> newer-systemd-based distros) under ubuntu host: >> - you can't use lxc-console >> - root on your container can mess up the host >> >> It shouldn't really matter for your use case, since "lxc-attach" works >> just fine (you DO know about lxc-attach?), and you don't really care >> about user access anyway. >> >> This should improve in the future as debian/ubuntu is also moving >> towards systemd (lxcfs is supposed to help), however currently the >> required level of support/integration is just not there yet. >> >> Since your main use case is "separate applications", docker might be a >> better candidate. And when you use c7-based docker container under c7 >> host, you might even get better protection since they integrate >> selinux. >> _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users