Как создать пользовательские cgroups с systemd

Я использую непривилегированные lxcконтейнеры в Arch Linux. Вот основные сведения о системе:

[chb@conventiont ~]$ uname -a
Linux conventiont 3.17.4-Chb #1 SMP PREEMPT Fri Nov 28 12:39:54 UTC 2014 x86_64 GNU/Linux

Это кастомное / скомпилированное ядро ​​с user namespace enabled:

[chb@conventiont ~]$ lxc-checkconfig 
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

[chb@conventiont ~]$ systemctl --version
systemd 217
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN 

К сожалению, systemdне очень хорошо в lxcнастоящее время. Особенно cgroupsпохоже, что настройка для пользователя без полномочий root работает не очень хорошо, или я просто слишком незнаком, как это сделать. lxcконтейнер будет запускаться только в непривилегированном режиме, когда он может создать необходимые группы в /sys/fs/cgroup/XXX/*. Это, однако, невозможно, lxcпотому что systemdмонтирует rootиерархию cgroup в /sys/fs/cgroup/*. Обходной путь, кажется, должен сделать следующее:

for d in /sys/fs/cgroup/*; do
        f=$(basename $d)
        echo "looking at $f"
        if [ "$f" = "cpuset" ]; then
                echo 1 | sudo tee -a $d/cgroup.clone_children;
        elif [ "$f" = "memory" ]; then
                echo 1 | sudo tee -a $d/memory.use_hierarchy;
        fi
        sudo mkdir -p $d/$USER
        sudo chown -R $USER $d/$USER
        echo $$ > $d/$USER/tasks
done

Этот код создает соответствующие cgroupкаталоги в cgroupиерархии для непривилегированного пользователя. Однако происходит то, чего я не понимаю. Перед выполнением вышеупомянутого я увижу это:

[chb@conventiont ~]$ cat /proc/self/cgroup 
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpu,cpuacct:/
2:cpuset:/
1:name=systemd:/user.slice/user-1000.slice/session-c1.scope

После выполнения вышеупомянутого кода, который я вижу в оболочке, я запустил его:

[chb@conventiont ~]$ cat /proc/self/cgroup 
8:blkio:/chb
7:net_cls:/chb
6:freezer:/chb
5:devices:/chb
4:memory:/chb
3:cpu,cpuacct:/chb
2:cpuset:/chb
1:name=systemd:/chb

Но в любой другой оболочке я все еще вижу:

[chb@conventiont ~]$ cat /proc/self/cgroup 
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpu,cpuacct:/
2:cpuset:/
1:name=systemd:/user.slice/user-1000.slice/session-c1.scope

Следовательно, я могу запустить свой непривилегированный lxcконтейнер в оболочке, в которой я выполнил код, упомянутый выше, но ни в каком другом.

1. Может кто-нибудь объяснить это поведение?

2. Кто-то нашел лучший способ установить требуемый cgroupsс текущей версией systemd( >= 217)?

Лучшее и более безопасное решение - установить cgmanagerи запустить его systemctl start cgmanager(в systemdдистрибутиве на основе). Вы можете сделать так, чтобы ваш rootпользователь, или если у вас есть sudoправа на хосте, создал cgroupsдля вашего непривилегированного пользователя во всех контроллерах:

sudo cgm create all $USER
sudo cgm chown all $USER $(id -u $USER) $(id -g $USER)

После того, как они были созданы для вашего непривилегированного пользователя, она / он может переместить процессы, к которым он имеет доступ, в свой cgroupдля каждого контроллера, используя:

cgm movepid all $USER $PPID

Безопаснее, быстрее, надежнее, чем сценарий оболочки, который я написал.

Ручное решение:

Ответить 1.

for d in /sys/fs/cgroup/*; do
        f=$(basename $d)
        echo "looking at $f"
        if [ "$f" = "cpuset" ]; then
                echo 1 | sudo tee -a $d/cgroup.clone_children;
        elif [ "$f" = "memory" ]; then
                echo 1 | sudo tee -a $d/memory.use_hierarchy;
        fi
        sudo mkdir -p $d/$USER
        sudo chown -R $USER $d/$USER
        echo $$ > $d/$USER/tasks
done

Я не знал о том, что происходит именно тогда , когда я писал этот сценарий , но читает это и экспериментируя немного помог мне понять , что происходит. То, что я в основном делаю в этом сценарии, - это создание нового cgroupсеанса для текущего, о userчем я уже говорил выше. Когда я запускаю эти команды в текущем shellили запускаю их в сценарии и делаю так, чтобы они оценивались в текущем, shellа не в subshell(через . scriptЭто .важно для этого работает!), Я не просто открываю новый сеанс для userно добавьте текущую оболочку как процесс, который выполняется в этой новой группе. Я могу добиться того же эффекта, запустив сценарий в подоболочке, а затем погрузиться в cgroupиерархию chb subcgroupи использоватьecho $$ > tasksдобавить текущую оболочку для каждого члена chb cgroup hierarchy.

Следовательно, когда я запускаю lxcэту текущую оболочку, мой контейнер также становится членом всех элементов, членом chb subcgroupкоторых является текущий shell. То есть мой containerнаследует cgroupстатус моего shell. Это также объясняет, почему он не работает в любой другой оболочке, которая не является частью текущей chb subcgroups.

Я все еще прохожу 2.. Возможно, нам придется подождать либо systemdобновления, либо дальнейших Kernelразработок, чтобы systemdпринять согласованное поведение, но я все равно предпочитаю ручную настройку, поскольку она заставляет вас понимать, что вы делаете.

На самом деле в archlinux это не будет работать, например, с непривилегированным пользователем (рекомендуется при использовании контейнеров unpriv. Lxc). то есть у этого пользователя нет sudo :)

Вместо этого определите группу в /etc/cgconfig.conf, активируйте cgconfig, cgrules (libcgroup в AUR), добавьте также cgrules, сделано .. unpriv. Пользователь также будет иметь такие же права.

В systemd 218 (я не знаю, когда, но, похоже, нужно добавить еще два условия, поскольку они не устанавливаются при создании способом cgconfig):

cat /etc/cgconfig.conf

group lxcadmin {
perm {
    task {
        uid = lxcadmin;
        gid = lxcadmin;
    }
    admin {
        uid = lxcadmin;
        gid = lxcadmin;
    }
}
cpu { }
memory { memory.use_hierarchy = 1; }  
blkio { }
cpuacct { }
cpuset { 
    cgroup.clone_children = 1;
    cpuset.mems = 0;
    cpuset.cpus = 0-3; 
}
devices { }
freezer { }
hugetlb { }
net_cls { }
}

cat /etc/cgrules.conf
lxcadmin        *       lxcadmin/

Предполагая, что пространство имен скомпилировано в ядре.

Это шаблон, процессор может быть в зависимости от того, сколько ядер у вас есть, mem может быть установлена ​​на какое-то фактическое значение и т. Д. И т. Д.

РЕДАКТИРОВАТЬ 2: Наконец, в systemd, если вы хотите использовать автозапуск с таким непривилегированным пользователем, вы можете сделать:

cp /usr/lib/systemd/system/lxc],admin‹\@.service, затем добавьте User = lxcadmin

и включите его для контейнера lxcadmin под названием lolz systemctl enable lxcadmin @ lolz.

Поэтому я столкнулся с той же проблемой, когда пытался заставить LXC непривилегированные контейнеры работать на CentOS 7. Я не хотел их использовать, cgmanagerпотому что не люблю вводить какие-либо дополнительные сервисы, если в этом нет необходимости. Вместо этого я в итоге исправил systemd, используя некоторые исправления из пакета ubuntu и одно специальное исправление для расширения списка контроллеров cgroup. У меня есть источники, необходимые для создания RPM в моей учетной записи GitHub по адресу https://github.com/CtrlC-Root/rpmdist . У меня также есть исправленные версии shadow-utils (для subuids и subgids) и pam (для loginuid). После того, как я установлю эти RPM и настрою пользователя на запуск непривилегированных контейнеров (назначение subuids & subgids, выделение пар веток в lxc-usernet, создание .config / lxc / default.conf и т. Д.), Я могу нормально запускать непривилегированные контейнеры LXC.

РЕДАКТИРОВАТЬ: Другая причина, по которой я не хотел использовать cgmanager, заключается в том, что я не хотел, чтобы мои обычные пользователи вообще использовали sudo. Обычные пользователи должны иметь возможность войти в систему, и все должно "просто работать" из коробки.