Различия

Здесь показаны различия между двумя версиями данной страницы.

--- wiki:руководство_по_ubuntu_server:виртуализация:lxc [2012/10/27 09:52]
[Пакет lxcguest]
+++ wiki:руководство_по_ubuntu_server:виртуализация:lxc [2014/05/15 13:56] (текущий)
[Настройка основной системы]
@@ Строка 54: / Строка 54: @@
 **LXC** сохраняет информацию контейнеров и корневую файловую систему (с резервным хранилищем по умолчанию) в **/var/lib/lxc**. Также шаблоны создания контейнеров предпочитают хранить закешированную информацию по дистрибутивам в **/var/cache/lxc**.
-Если вы хотите использовать для **/var** иную файловую систему, вы можете смонтировать в этот каталог другую файловую систему большего объема. Если у вас есть диск, предназначенный для этих целей, вы можете просто смонтировать его в **/var/lib/lxc**. Если вы предпочитаете использовать другое расположение, такое как /srv, вы можете примонтировать его к этому каталогу или создать символическую ссылку. Например, если /srv является большой смонтированной файловой системой, создайте два каталога и символьные ссылки на них:
+Дефолтный путь, называемый **lxcpath**, может быть переопределён в командной строке ключом **-P** или навсегда через **lxcpath = /новый/путь** в **/etc/lxc/lxc.conf**
+Если вы переопределяете **lxcpath**, то каталог снимков **snap** добавляется к **lxcpath** и магическим образом за ним следует. Кэш шаблонов, к сожалению, жёстко вшит и не просто его сменить.
+Но можно всё сделать через символические ссылки. Например, если /srv является большой смонтированной файловой системой, создайте каталог и символьную ссылку на него:
 <code>
-sudo mkdir /srv/lxclib /srv/lxccache
+sudo mkdir /srv/lxccache
-sudo rm -rf /var/lib/lxc /var/cache/lxc
+sudo rm -rf /var/cache/lxc
-sudo ln -s /srv/lxclib /var/lib/lxc
 sudo ln -s /srv/lxccache /var/cache/lxc
 </code>
 или, используя монтирование:
 <code>
-sudo mkdir /srv/lxclib /srv/lxccache
+sudo mkdir /srv/lxccache
 sudo sed -i '$a \
-/srv/lxclib /var/lib/lxc    none defaults,bind 0 0 \
 /srv/lxccache /var/cache/lxc none defaults,bind 0 0' /etc/fstab
 sudo mount -a
@@ Строка 79: / Строка 79: @@
 Если основная система имеет **/var**, размеченный как **btrfs**, средства администрирования LXC распознают это и автоматически будут использовать для клонирования контейнеров снимки btrfs.
+===ZFS===
+Подобно **btrfs**, использование **zfs** позволит применять возможности, но уже **ZFS**: подтом (subvolume) для контейнера, быстрое создание снимков и клонов, более эффективное использование места на диске за счёт дедупликации.
 ===Apparmor===
-LXC поставляется с профилем Apparmor, предназначенным для защиты основной системы от случайного неправильного использования привилегий внутри контейнера. Нпример, контейнер не должен иметь возможности писать в каталог /proc/sysrq-trigger или менять большинство файлов в каталоге /sys.
+LXC поставляется с профилем Apparmor, предназначенным для защиты основной системы от случайного неправильного использования привилегий внутри контейнера. Например, контейнер не должен иметь возможности писать в каталог /proc/sysrq-trigger или менять большинство файлов в каталоге /sys.
 Профиль **usr.bin.lxc-start** используется при запуске **lxc-start**. Этот профиль в основном предотвращает монтирование **lxc-start** новых файловых систем вне корневой файловой системы контейнера. Перед инициализацией контейнера LXC запрашивает переключение на профиль контейнера. По умолчанию используется профиль **lxc-container-default**, определенный в **/etc/apparmor.d/lxc/lxc-default**. Этот профиль запрещает контейнеру доступ к многим опасным каталогам и монтирование большинства файловых систем.
@@ Строка 198: / Строка 201: @@
 ===Клонирование===
-Для быстрой подготовки к работе вы можете решить изменить canonical контейнер в соответствии с вашими требованиями и затем сделать множество его копий. Это можно осуществить с помощью программы lxc-clone. Дан существующий контейнер с именем C1, новый контейнер C2 мможет быть создан:
+Для быстрой подготовки к работе вы можете решить изменить canonical контейнер в соответствии с вашими требованиями и затем сделать множество его копий. Это можно осуществить с помощью программы lxc-clone. Дан существующий контейнер с именем C1, новый контейнер C2 может быть создан:
 <code>sudo lxc-clone -o C1 -n C2</code>
@@ Строка 491: / Строка 494: @@
 ====Безопасность====
-A namespace maps ids to resources. By not providing a container any id with which to reference a resource, the resource can be protected. This is the basis of some of the security afforded to container users. For instance, IPC namespaces are completely isolated. Other namespaces, however, have various leaks which allow privilege to be inappropriately exerted from a container into another container or to the host.
+Пространство имен сопоставляет идентификаторы с ресурсами. Чтобы не предоставлять доступ контейнерам к любым идентификаторам (id) , указывающим на ресурсы, ресурсы должны быть защищены. Это является основой некоторой безопасности, предоставляемой пользователям контейнеров. Например, пространство имен IPC (взаимодействия между процессами) полностью изолировано. Однако другие пространства имен имеют различные уязвимости, которые позволяют получать неправильно предоставленные привилегии из одного контейнера в другой или в основную систему.
-By default, LXC containers are started under a Apparmor policy to restrict some actions. However, while stronger security is a goal for future releases, in 12.04 LTS the goal of the Apparmor policy is not to stop malicious actions but rather to stop accidental harm of the host by the guest.
+По умолчанию LXC контейнеры запускаются под управлением политики Apparmor для ограничения некоторых действий. Несмотря на то, что более строгая безопасность является задачей следующих редакций, в 12.04 LTS задачей политики Apparmor является не прекращение злонамеренных действий, а предупреждения случайных повреждений основной системы из гостевой.
-See the LXC security wiki page for more, uptodate information.
+Смотрите [[http://wiki.ubuntu.com/LxcSecurity|LxcSecurity wiki]] страницу для дополнительной актуальной информации.
 ===Используемые системные вызовы===
-It is a core container feature that containers share a kernel with the host. Therefore, if the kernel contains any exploitable system calls, the container can exploit these as well. Once the container controls the kernel it can fully control any resource known to the host.
+Возможность совместного использования ядра системы контейнерами является базовой особенностью. Поэтому, если ядро содержит некоторые потенциально опасные вызовы, контейнеры также могут их использовать. Как только контейнер сможет контролировать ядро системы, он сможет полностью управлять любыми ресурсами, доступными основной системе.
 ====Ссылки====
-    The DeveloperWorks article LXC: Linux container tools was an early introduction to the use of containers.
+  ~~ Статья в DeveloperWorks [[https://www.ibm.com/developerworks/linux/library/l-lxc-containers/|LXC: Linux container tools]] является введением в использование контейнеров.
+  ~~ [[http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html|The Secure Containers Cookbook]] демонстрирует использование модулей безопасности с целью сделать контейнеры более безопасными.
-    The Secure Containers Cookbook demonstrated the use of security modules to make containers more secure.
+  ~~ Страницы руководств могут быть найдены по данным ссылкам:
+    ~~ [[http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html|capabilities]].
-    Manual pages referenced above can be found at:
+    ~~ [[http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html|lxc.conf]].
+  ~~ Основное развитие проекта LXC на [[http://lxc.sf.net/|Sourceforge]].
-    capabilities
+  ~~ Проблемы безопасности приведены и обсуждаются на странице [[http://wiki.ubuntu.com/LxcSecurity|LxcSecurity wiki]].
-    lxc.conf
+  ~~ Для дополнительной информации по пространствам имен в Linux смотрите: [[http://dl.acm.org/citation.cfm?id=1400097.1400109&coll=DL&dl=GUIDE&CFID=133158545&CFTOKEN=80778967|S.Bhattiprolu, E.W.Biederman, S.E.Hallyn, and D.Lezcano. Virtual Servers and Checkpoint/Restart in Mainstream Linux. SIGOPS Operating Systems Review, 42(5), 2008]].
+  ~~ Стефан Грабер (Stéphane Graber), в предверии выхода 20 февраля 2014 года релиза LXC 1.0, опубликовал цикл статей о Linux Containers. [[https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/|LXC 1.0: Blog post series]] ([[http://vasilisc.com/lxc-1-0-blog-post-series|перевод]]).
-    The upstream LXC project is hosted at Sourceforge.
-    LXC security issues are listed and discussed at the LXC Security wiki page
-    For more on namespaces in Linux, see: S. Bhattiprolu, E. W. Biederman, S. E. Hallyn, and D. Lezcano. Virtual Servers and Check- point/Restart in Mainstream Linux. SIGOPS Op- erating Systems Review, 42(5), 2008.
 ----
@@ Строка 524: / Строка 521: @@
 [[wiki:руководство_по_ubuntu_server:виртуализация:ubuntu_cloud|<-назад]] |
 [[wiki:руководство_по_ubuntu_server:кластеризация|далее->]]</style>

LXC Сравнение версий

Различия