[lxc-devel] [linuxcontainers.org/master] Russian translation

Tue Aug 23 18:00:23 UTC 2016

A non-text attachment was scrubbed...
Name: not available
Type: text/x-mailbox
Size: 316 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20160823/8f0b629c/attachment.bin>
-------------- next part --------------
From b37aef3312557ae8f15d22b6e1cedefa008dca78 Mon Sep 17 00:00:00 2001
From: Alexander Georgievskiy <galeksandrp at gmail.com>
Date: Tue, 23 Aug 2016 20:56:19 +0300
Subject: [PATCH] Russian translation

---
 content/cgmanager/introduction.ru.md | 57 ++++++++++++++++++++++++++++++++++++
 content/lxc/security.ru.md           | 18 ++++++------
 2 files changed, 66 insertions(+), 9 deletions(-)
 create mode 100644 content/cgmanager/introduction.ru.md

diff --git a/content/cgmanager/introduction.ru.md b/content/cgmanager/introduction.ru.md
new file mode 100644
index 0000000..74b6dab
--- /dev/null
+++ b/content/cgmanager/introduction.ru.md
@@ -0,0 +1,57 @@
+# Что такое CGManager?
+
+CGManager это основной привилегированный демон, управляющий всеми вашими cgroups для вас  
+с помощью простого API D-Bus. Он спроектирован для работы с вложенными контейнерами LXC  
+но также допускает непривилегированные запросы включающие разрешение пользовательских пространств имен UIDs/GIDs.
+
+# Компоненты
+## cgmanager
+Этот демон запускается на хосте, монтирует cgroupfs в отдельное монтируемое  
+пространство имен (так что оно недоступно с хоста), привязывает /sys/fs/cgroup/cgmanager/sock  
+для входящих запросов D-Bus и обычно обслуживает всех клиентов, запущенных на хосте.
+
+cgmanager принимает одновременно запросы аутентификации с использованием D-Bus + данных аутентификации SCM  
+используемых для трансляции uid, gid и pid по пространствам имен или с использованием  
+"неаутентифицированных" (снабженных только начальным ucred) D-Bus для запросов с уровня хоста.
+
+## cgproxy
+Вы можете увидеть этот демон запущенным в двух случаях. На хосте если ваше ядро старее 3.8  
+(не имеет поддержки связывания pidns) или в контейнерах (где запущен только cgproxy).
+
+cgproxy сам не изменяет конфигурацию cgroup но, как показывает его имя,  
+проксирует запросы к основному процессу cgmanager.
+
+Требуется, чтобы процесс мог сообщатся с /sys/fs/cgroup/cgmanager/sock  
+через straight D-Bus (например используя dbus-send).
+
+cgproxy получает ucred из запроса и посылает аутентифицированный запрос SCM в  
+настоящий сокет cgmanager, посылая аргументы в структурах ucred, так что они правильно  
+транслируется в каком-либо cgmanager в поддерживаемое пространство имен хоста.
+
+## cgm
+Простая утилита командной строки связывается с сервисом D-Bus и позволяет вам  
+выполнять привычные операции cgroup из командной строки.
+
+# Коммуникационный протокол
+Как сказано выше, cgmanager и cgproxy используют D-Bus. Внешним клиентам  
+рекомендуется (но не cgproxy) использовать стандартный D-Bus API  
+и не пытаться использовать протокол SCM creds это не требуется и можно легко ошибиться.
+
+Вместо этого, просто считайте что используя /sys/fs/cgroup/cgmanager/sock вы поступаете правильно.
+
+cgmanager API доступен только через отдельный сокет D-Bus, cgmanager сам не присоединяется  
+к системной шине, так что запущенный демон dbus не требуется для cgmanager/cgproxy.
+
+Вы можете узнать больше о D-Bus API [здесь](/cgmanager/dbus-api/).
+
+# Лицензирование
+CGManager это свободное программное обеспечение, большая часть исходного кода выпущена на условиях лицензии GNU LGPLv2.1+,  
+некоторые бинарные файлы выпущены под лицензией GNU GPLv2.
+
+Основная лицензия проекта GNU LGPLv2.1+.
+
+# Поддержка
+Поддержка стабильного релиза полагается на дистрибутивы Linux  
+и их вклад в продвижение исправлений стабильности и обновлений безопасности.
+
+Коммерческая поддержка CGManager на выпусках Ubuntu LTS может быть получена от [Canonical Ltd](http://www.canonical.com).
diff --git a/content/lxc/security.ru.md b/content/lxc/security.ru.md
index 6b0936a..49f64d8 100644
--- a/content/lxc/security.ru.md
+++ b/content/lxc/security.ru.md
@@ -1,4 +1,4 @@
-# Introduction
+# Введение
 Контейнеры LXC могут быть двух типов:
 
  - Привилегированные контейнеры
@@ -8,14 +8,14 @@
 только в окружениях, в которых непривилегированные контейнеры недоступны и когда вы доверяете
 пользователю контейнера root доступ к хосту.
 
-Вторые были добавлены в LXC 1.0 (февраль 2014) и требуют относительон свежее  
+Вторые были добавлены в LXC 1.0 (февраль 2014) и требуют относительно свежее  
 ядро (3.13 и выше). Положительная сторона в том, что мы считаем такие контейнеры безопасными для root так что  
 пока вы отслеживаете все проблемы безопасности ядра, такие контейнеры безопасны.
 
 
 Так как привилегированные контейнеры считаются небезопасными, мы обычно не считаем новые
 эксплоиты выхода из контейнера проблемами безопасности, достойными CVE и быстрого исправления. Мы тем не менее пытаемся уменьшить эти  
-проблемы защищая от случайного повреждения хоста.
+проблемы защищая хост от случайного повреждения.
 
 # Привилегированные контейнеры
 Привилегированным контейнером считается любой контейнер в котором uid 0 соотносится с uid 0 хоста.  
@@ -36,12 +36,12 @@
 Некоторые невозможно заблокировать, так как это потребует отключения стольких ключевых возможностей ядра, что весь контейнер станет абсолютно непригодным к использованию.
 
 # Непривилегированные контейнеры
-Непривилегированные контейнер безопасны как задумано. uid 0 контейнера соответствует непривилегированному пользователю снаружи контейнера  
+Непривилегированные контейнеры безопасны как задумано. uid 0 контейнера соответствует непривилегированному пользователю снаружи контейнера  
 и имеет расширенные права только на свои ресурсы.
 
 С таким контейнером, использование SELinux, AppArmor, Seccomp и capabilities для защиты не является необходимым.  
 LXC будет по прежнему использовать их для добавления дополнительного уровня защиты который может быть полезным в случае  
-проблемы безопасности ядра but the security model isn't enforced by them.
+проблемы безопасности ядра, но защита обеспечивается не только ими.
 
 Для обеспечения работы непривилегированных контейнеров, LXC взаимодействует с 3 частями кода setuid:
 
@@ -65,10 +65,10 @@ LXC не пытается предотвратить DoS атаки по умо
 
 ## Ограничения Cgroup
 LXC наследует ограничения cgroup от своего родителя, на моем дистрибутиве Linux, реальных ограничений не установлено.  
-В результате, пользователь в контейнере может довольно легоко DoS запуском fork бомбы,  
+В результате, пользователь в контейнере может довольно легко DoS запуском fork бомбы,  
 использовав всю системную память или создавая сетевые интерфейсы пока у ядра не кончится память.
 
-This can be mitigated by either задав необходимые элементы конфигурации lxc.cgroup (память, cpu и pids)  
+Это можно предотвратить задав необходимые элементы конфигурации lxc.cgroup (память, cpu и pids)  
 или удостоверившись что родительский пользователь помещен в надлежащим образом настроенную cgroups во время входа.
 
 ## Пользовательские ограничения
@@ -81,9 +81,9 @@ This can be mitigated by either задав необходимые элемент
 Это значит что если два контейнера имеют одинаковые или перекрывающиеся связи id, с общим uid ядра, тогда они также разделяют ограничения,  
 означая что пользователь в первом контейнере может может успешно DoS того же пользователя в другом контейнере.
 
-Для предотвращения этого, недоверенные пользователи или контейнеры untrusted users or containers должны иметь абсолютно разные связи id (в идеале из 65536 uids и gids каждый).
+Для предотвращения этого, недоверенные пользователи или контейнеры должны иметь абсолютно разные связи id (в идеале из 65536 uids и gids каждый).
 
-## Shared network bridges
+## Общие сетевые мосты
 LXC устанавливает базовую level 2 связь для своих контейнеров. Для удобства он также предоставляет один мост по умолчанию для системы.
 
 Так как контейнер подключенный к мосту может передавать любой level 2 трафик какой захочет, он может успешно совершать MAC или IP spoofing на мосту.
