У меня был некоторый успех в этом - если не с контейнером lxc, то мне удалось заставить его работать для частного пространства имен монтирования. Поскольку lxc построен на базовых пространствах имен linux, которые я также использовал, я не вижу причин, почему это не должно работать у вас.
В первую очередь я настроил пространство имен следующим образом:
sudo unshare -m sh -c '
mount -ttmpfs none /tmp
echo x > /tmp/mytmp
findmnt -o+PROPAGATION /tmp
echo "$$"
cd /tmp
exec "$0" -i
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/tmp tmpfs tmpfs rw private
/tmp none tmpfs rw,relatime private
29384
$
... и получил интерактивную оболочку. Следующее, что я сделал в отдельной терминальной сессии...
sudo sh -c ' { cd /dev/fd/0 ; mkdir mnt
ls -l; cat mytmp
} 3<$0/ns/mnt <$0/29384/cwd
' /proc/29384
drwxr-xr-x 2 root root 40 Jan 4 02:52 mnt
-rw-r--r-- 1 root root 2 Jan 4 02:38 mytmp
x
... что было очень обнадеживающе!
Но я не смог выполнить монтирование - каждый раз, когда я пытался смонтировать
родительский ns каталог поверх одного из дочерних ns, он терпел неудачу. Некоторые исследования показывают, что это сделано специально (в частности: см. предостережения в man 7 user_namespaces
относительно флагов PROPAGATION). Что сработало, так это (в новом пространстве имен):
sudo unshare --propagation slave -m sh -c '
mount -ttmpfs none /tmp; cd /tmp
exec "$0" -i'
А затем в сессии родительского пространства имен...
sudo mount --bind / /mnt
sudo mount --bind / /tmp
sudo mount --bind /tmp /mnt/img/tmp
Теперь вышеописанное работает в первом случае, но не во втором. Поскольку дочернее ns не распространяет изменения fs вверх, родительское не повлияет на изменения, внесенные в его представление fs. И так как у дочернего ns есть собственное монтирование на /tmp
, все, что делает родитель, не имеет значения. Однако, если существует некоторая общая иерархия и дочерний ns настроен на получение изменений файловой системы, то он будет видеть изменения, которые родитель распространяет вниз.
В дочернем ns после выполнения вышеуказанного...
ls /tmp /mnt /mnt/tmp
/mnt:
bin dev etc lib mnt proc run srv tmp var
boot esp home lib64 opt root sbin sys usr
/mnt/tmp:
serverauth.FT3Z6IFyWW
systemd-private-...systemd-timesyncd.service-YUkVU6
/tmp:
И так, я полагаю, чтобы ответить на вопрос - да, я считаю, что это возможно. Но я также уверен, что вам потребуется организовать это заранее.
yum repolist enabled -v
содержит эту информацию (настроенный metadata_expire и время последнего обновления метаданных) и красивый вывод.
[root@localhost ~]# yum repolist enabled -v | grep 'Repo-name\|expire'
Repo-name : CentOS-7 - Base
Repo-expire : 21,600 second(s) (last: Wed Mar 8 19:01:59 2017)
Repo-name : CentOS-7 - Extras
Repo-expire : 21,600 second(s) (last: Wed Mar 8 19:02:00 2017)
Repo-name : CentOS-7 - Updates
Repo-expire : 21,600 second(s) (last: Wed Mar 8 19:02:01 2017)
Проверка времени изменения файла cachecookie - еще один способ узнать время последнего обновления метаданных. Это выполняется очень быстро, но путь кэша yum может не совпадать между дистрибутивами / основными.
[root@localhost ~]# stat -c %y /var/cache/yum/x86_64/7/base/cachecookie
2017-03-08 19:01:59.650838052 +0000