[DONE] wml://security/2012/dsa-2452.wml

2018-03-31 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- ../../english/security/2012/dsa-2452.wml  2017-11-01 10:11:10.339845257 
+0500
+++ 2012/dsa-2452.wml   2018-04-01 10:54:05.939764507 +0500
@@ -1,54 +1,54 @@
- -insecure default configuration
+#use wml::debian::translation-check translation="1.2" mindelta="1"
+небезопасные настройки по 
умолчанию
 
- -Niels Heinen noticed a security issue with the default Apache
- -configuration on Debian if certain scripting modules like mod_php or
- -mod_rivet are installed. The problem arises because the directory
- -/usr/share/doc, which is mapped to the URL /doc, may contain example
- -scripts that can be executed by requests to this URL. Although access
- -to the URL /doc is restricted to connections from localhost, this still
- -creates security issues in two specific configurations:
+Нильс Найнен заметил проблему 
безопасности с настройками Apache
+по умолчанию в системах Debian в случае, если 
установлены определённые модули
+поддержки языков сценариев, такие как mod_php 
или mod_rivet. Проблема возникает из-за
+того, что каталог /usr/share/doc, который 
отображается в URL /doc, может содержать пример
+сценариев, которые могут быть выполнены 
путём отправки запросов по этому URL. Хотя 
доступ
+к URL /doc ограничивается соединениями с 
локального узла, это всё равно
+создаёт проблема безопасности при двух 
указанных конкретных настройках:
 
 
 
- -if some front-end server on the same host forwards connections to an
- -apache2 backend server on the localhost address, or
+если внешний сервер на том же узле 
перенаправляет подключения на
+внутренний сервер apache2 по адресу 
локального узла, либо
 
 
- -if the machine running apache2 is also used for web browsing.
+если машина, на которой запущен apache2, также 
используется и для просмотра веб-страниц в 
Интернете.
 
 
 
- -Systems not meeting one of these two conditions are not known to be
- -vulnerable. The actual security impact depends on which packages (and
- -accordingly which example scripts) are installed on the system.
- -Possible issues include cross site scripting, code execution, or
- -leakage of sensitive data.
- -
- -This updates removes the problematic configuration sections from the
- -files /etc/apache2/sites-available/default and .../default-ssl. When
- -upgrading, you should not blindly allow dpkg to replace those files,
- -though. Rather you should merge the changes, namely the removal of the
- -Alias /doc "/usr/share/doc" line and the related Directory
- -"/usr/share/doc/" block, into your versions of these config files.
- -You may also want to check if you have copied these sections to any
- -additional virtual host configurations.
- -
- -For the stable distribution (squeeze), this problem has been fixed in
- -version 2.2.16-6+squeeze7.
- -
- -For the testing distribution (wheezy), this problem will be fixed in
- -version 2.2.22-4.
+Неизвестно, подвержены ли указанной 
уязвимости системы, не удовлетворяющие
+одному из приведённых условий. 
Фактическое влияние на безопасность 
системы зависит от того,
+какие пакеты (соответственно, и какие 
примеры сценариев) установлены в системе.
+Среди возможных проблем можно назвать 
межсайтовый сцриптинг, выполнение кода и
+утечку чувствительных данных.
+
+Данное обновление удаляет проблемные 
разделы настройки из
+файлов /etc/apache2/sites-available/default и .../default-ssl. При
+обновлении вам не следует вслепую 
разрешать dpkg заменить указанные файлы.
+Скорее вам следует слить изменения, в 
частности, удаление строки
+Alias /doc "/usr/share/doc" и связанный с ней блок 
Directory
+"/usr/share/doc/" с вашими версиями этих 
файлов настройки.
+Кроме того, вам может потребоваться 
проверить, были ли указанные разделы 
скопированы в
+какие-либо

Re: Нюансы взаимодействия ZFS

2018-03-31 Пенетрантность artiom 


31.03.2018 11:33, Eugene Berdnikov пишет:
> On Sat, Mar 31, 2018 at 12:07:23AM +0300, artiom wrote:
>>> Теперь вопросы:
>>>
>> Отвечу на свои же вопросы.
>>
>>> - Как желательно располагать ZFS разделы относительно разделов LUKS?
>>>   Сейчас ОС на ZFS, который на LUKS.
>>>   И это правильно, чтобы не усложнять.
>>>   Но здесь не важна производительность.
>>>   А как располагать swap и slog: поверх LUKS или наоборот (как в мануале)?
>>
>> - Прямое копирование на диск блоками по 4 MB: 185 MB/s (dsync: 136 MB/s)
>> - LUKS раздел с поддержкой команд AES-NI: 184 MB/s (dsync: 135 MB/s)
>> - ZFS volume = 170 MB/s (dsync: 50 MB/s).
>> - LUKS on ZFS volume = 274 MB/s (dsync: 38 MB/s).
>> - ZFS on LUKS = 187 MB/s (dsync: 50 MB/s)
> 
>  Третий вариант явно выбивается по цифрам из стройного ряда, что
>  наводит на мысли о какой-то ошибке или опечатке.
> 
Четвёртый. И там действительно скачет, не ясно почему (точнее, почти
ясно: кэширование, но oflag=direct не помогает).
Именно поэтому стоит смотреть на то, что в скобках: dsync.

>  Да и странно, как чистый zfs может оказаться медленнее, чем он же над LUKS.
>  Видимо, статистическая ошибка измерений сравнима со вторым знаком
>  в этих числах, либо присутствует какая-то систематика.
>  
Если смотреть на измеренное с dsync, то меня не сильно удивляет.
Я подобную картинку где-то видел: ZFS дя некоторых операций много
тормознее, чем ext4, а ext4 где-то даже бьёт xfs.
Стоит заметить, что в данном случае SLOG не выносился на SSD.

>>> - Как организовывать шифрованный пул?
>>>   Опять, тот же вопрос: LUKS->ZFS или ZFS->LUKS?
>>>   Если ZFS->LUKS, то не придётся ли мне сделать ZFS->LUKS->ZFS,
>>>   чтобы использовать все возможности ZFS в пуле?
>>> - Имеет ли смысл делать /boot на ZFS? Т.е., создавать для него
>>> зеркальный пул?
>>>
>>
>> Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS
>> pool лучше поверх LUKS, а не наоборот.
>> LUKS почти не вносит оверхед.
> 
>  Не следил за "заверениями экспертов", но, по-моему, очевидно, что
>  шифрование выгоднее делать на уровне, который ниже всех кэшей.
>  Независимо от того, какой оверхед это шифрование вносит.
> 
Да не так и очевидно.

Re: Системы управления сервером?

2018-03-31 Пенетрантность Artem Chuprina 
artiom -> debian-russian@lists.debian.org  @ Sat, 31 Mar 2018 14:18:00 +0300:

 >>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
 >> человек
 >>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >>  >>  >> 
 >>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, 
 >> код
 >>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >>  >>  >> 
 >>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
 >>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать 
 >> коммиты
 >>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >>  >>  >> 
 >>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем 
 >> случае,
 >>  >>  > любым web интерфейсом), и код не проходит в репозиторий без 
 >> одобрения.
 >>  >> 
 >>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
 >>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
 >>  >> происходит.
 >>  >> 
 >>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
 >>  > практики.
 >> 
 >> Собственно, системы управления версиями придуманы ровно для этой
 >> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
 >> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
 >> если оно оказалось неудачным.
 >> 
 >> А чтобы неудачное изменение не долетело до заказчика, существует
 >> релизный цикл.  И ревью его необходимости не отменяет.
 >> 
 > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
 > репозитория, на которую уже понакоммитили и заложили функционал.

Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
трудоемко было потом починить. Так и не починили, кстати. Причем по
крайней мере два первых ревью (два разных человека, входивших в разное
время в проект, внимательно читали этот код) она тоже успешно
проскочила.

Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
находится тысяча первый ревьюер, который таки замечает багу и делает
эксплойт.

А обычно бага либо легко правится, либо быстро замечается. В идеале и
то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
реализации фичи, но так бывает не всегда :)

 >>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - 
 >> не
 >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >>  >>  >> 
 >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
 >> лучше
 >>  >>  > ли - не допустить?
 >>  >>  > Какая практика?
 >>  >>  > В чём нехорошесть данной идеи?
 >>  >> 
 >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >>  >> будет изменен, проходит время.
 >>  > Как минус, так и плюс.
 >> 
 >> В течение этого времени в системе присутствуют и старые, и новые баги.
 >> Где плюс?
 >> 
 > Нет, присутствуют только старые баги, которые уже известны, проверены и
 > одеты в пиджак, так что стали напоминать фичи.

В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
поверх них уже идет работа.

И не факт, кстати, что старые баги известны. Мы можем говорить о ревью,
например, фикса свеженаступленной грабли. Она, может, в коде и пару лет
уже, но важный заказчик наступил на нее только сегодня, а до него просто
никому не приходило в голову проделать именно эту последовательность
действий.

 > А тут новые баги, которые успеют сломать тестирование, например, в
 > результате чего могут не пройти другие тесты и т.п..
 > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
 > однако есть факты на практике).

На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
если тест сломался, то багу надо чинить. Если бага сломала сразу много
тестов, починка приоритетна, и все дела.

 >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 >>  > ждать ответов автора (который в этом время уже над другим работает), к
 >>  > тому же, ревьюверов бывает несколько.
 >> 
 >> Я про прерывания не процесса ревью, а про прерывания процесса своей
 >> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
 >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
 >> заменит контекст своей задачи.  После ревью придется снова грузить свой.
 >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
 >> часа каждая перегрузка, а их тут две.
 > Ну час - это явный перебор.

Это значит, у тебя все задачи простые.

 > А отрыв на 15 минут - не критично: вы же не соревновательным
 > программированием занимаетесь, надеюсь?

Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.

 > Иногда вообще полезно от задачи оторваться, бывает.

В моем опыте оторваться от задачи полезно, а вот заменять

[DONE] wml://security/2011/dsa-2297.wml

2018-03-31 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- ../../english/security/2011/dsa-2297.wml  2017-11-01 10:11:10.275841084 
+0500
+++ 2011/dsa-2297.wml   2018-03-31 21:42:43.168148254 +0500
@@ -1,58 +1,58 @@
- -several vulnerabilities
+#use wml::debian::translation-check translation="1.2" mindelta="1"
+несколько уязвимостей
 
 
- -Several vulnerabilities have been discovered in Icedove, an unbranded
- -version of the Thunderbird mail/news client.
+В Icedove, безбрендовой версии почтового и 
новостного клиента Thunderbird, было
+обнаружено несколько уязвимостей.
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2011-0084;>CVE-2011-0084
 
- -   regenrecht discovered that incorrect pointer handling in the SVG
- -   processing code could lead to the execution of arbitrary code.
+   regenrecht обнаружил, что неправильная 
работа с указателями в коде для
+   обработки SVG может приводить к 
выполнению произвольного кода.
 
 https://security-tracker.debian.org/tracker/CVE-2011-2378;>CVE-2011-2378
 
- -   regenrecht discovered that incorrect memory management in DOM
- -   processing could lead to the execution of arbitrary code.
+   regenrecht обнаружил, что неправильное 
управление памятью в коде для
+   обработки DOM может приводить к 
выполнению произвольного кода.
 
 https://security-tracker.debian.org/tracker/CVE-2011-2981;>CVE-2011-2981
 
- -   moz_bug_r_a_4 discovered a Chrome privilege escalation
- -   vulnerability in the event handler code.
+   moz_bug_r_a_4 обнаружил повышений 
привилегий Chrome
+   в коде обработчика событий.
 
 https://security-tracker.debian.org/tracker/CVE-2011-2982;>CVE-2011-2982
 
- -   Gary Kwong, Igor Bukanov, Nils and Bob Clary discovered memory
- -   corruption bugs, which may lead to the execution of arbitrary 
code.
+   Гари Квон, Игорь Буканов, Нильс и Боб 
Клэри обнаружили ошибки с повреждением 
содержимого
+   памяти, которые могут приводить к 
выполнению произвольного кода.
 
 https://security-tracker.debian.org/tracker/CVE-2011-2983;>CVE-2011-2983
 
- -   shutdown discovered an information leak in the handling of
+   shutdown обнаружил утечку информации в 
коде обработки
RegExp.input.
 
 https://security-tracker.debian.org/tracker/CVE-2011-2984;>CVE-2011-2984
 
- -   moz_bug_r_a4 discovered a Chrome privilege escalation 
- -   vulnerability.
+   moz_bug_r_a4 обнаружил повышений 
привилегий
+   Chrome.
 
 
 
- -As indicated in the Lenny (oldstable) release notes, security support for
- -the Icedove packages in the oldstable needed to be stopped before the end
- -of the regular Lenny security maintenance life cycle.
- -You are strongly encouraged to upgrade to stable or switch to a different
- -mail client.
+Как указано в информации о выпуске Lenny 
(предыдущий стабильный выпуск) поддержка 
безопасности
+для пакетов Icedove в предыдущем стабильном 
выпуске должна быть прекращена до 
окончания
+обычного цикла поддержки безопасности Lenny.
+Настоятельно рекомендуется выполнить 
обновление до стабильного выпуска или 
перейти на
+использование другого почтового 
клиента.
 
- -For the stable distribution (squeeze), this problem has been fixed in
- -version 3.0.11-1+squeeze4.
+В стабильном выпуске (squeeze) эта проблема 
была исправлена в
+версии 3.0.11-1+squeeze4.
 
- -For the unstable distribution (sid), this problem has been fixed in
- -version 3.1.12-1.
+В нестабильном выпуске (sid) эта проблема 
была исправлена в
+версии 3.1.12-1.
 
- -We recommend that you upgrade your iceweasel packages.
+Рекомендуется обновить пакеты iceweasel.
 
 
 # do not modify the following line
 #include "$(ENGLISHDIR)/security/2011/dsa-2297.data"
- -# $Id: dsa-2297.wml,v 1.2 2014/04/30 07:16:25 pabs Exp $
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAlq/upgACgkQXudu4gIW
0qXdXA//RF3Rcd6cV7S5rnZcjAAGrFWyKUBHD5shtacLSLRPZas/MJXoAjFFabcA
3bVFct4K2eqTdoKSS46gql5UdegwLSdj2EjBGUY3pXZglPH0WlCkJasL1sSBMmd6
oq7YJiHflEmysqVUQ/hOuF8uDZkM5hby/kUakfY23zEWcR0invJlPBWRGqBgfk2O

[DONE] wml://security/2011/dsa-2305.wml

2018-03-31 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- ../../english/security/2011/dsa-2305.wml  2017-11-01 10:11:10.279841345 
+0500
+++ 2011/dsa-2305.wml   2018-03-31 21:32:27.156355140 +0500
@@ -1,49 +1,49 @@
- -denial of service
+#use wml::debian::translation-check translation="1.3" mindelta="1"
+отказ в обслуживании
 
- -Two security issue have been discovered that affect vsftpd, a lightweight,
- -efficient FTP server written for security.
+В vsftpd, упрощённому эффективном 
FTP-сервере, написанном с целью обеспечения
+высокой безопасности, были обнаружены две 
проблемы безопасности.
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2011-2189;>CVE-2011-2189
 
- -It was discovered that Linux kernels  2.6.35 are considerably 
slower in
- -releasing than in the creation of network namespaces.  As a result of 
this
- -and because vsftpd is using this feature as a security enhancement to
- -provide network isolation for connections, it is possible to cause denial
- -of service conditions due to excessive memory allocations by the kernel.
- -This is technically no vsftpd flaw, but a kernel issue.  However, this
- -feature has legitimate use cases and backporting the specific kernel 
patch
- -is too intrusive.  Additionally, a local attacker requires the 
CAP_SYS_ADMIN
- -capability to abuse this functionality.  Therefore, as a fix, a kernel
- -version check has been added to vsftpd in order to disable this feature
- -for kernels  2.6.35.
+Было обнаружено, что ядра Linux  2.6.35 
значительно медленнее при выполнении
+освобождения сетевых пространств имён, 
чем при их создании. В результате этого,
+а также потому, что vsftpd использует 
указанную возможность для улучшения 
безопасности
+с целью предоставления сетевой изоляции 
для соединений, можно вызвать отказ в 
обслуживании
+из-за выделения ядром чрезмерного 
количества памяти.
+Технически это не является ошибкой в 
vsftpd, это проблема ядра. Тем не менее, данная
+функциональность имеет вполне 
легитимные сценарии использования, а 
обратный перенос заплаты
+ядра является чересчур сложным. Кроме 
того, локальному злоумышленнику требуются 
права на
+CAP_SYS_ADMIN для использования указанной 
функциональности. Следовательно, для 
исправления
+проблемы в vsftpd была добавлена 
специальная проверка версии ядра, чтобы 
данная
+функциональность отключалась для ядер 
 2.6.35.
 
 https://security-tracker.debian.org/tracker/CVE-2011-0762;>CVE-2011-0762
 
- -Maksymilian Arciemowicz discovered that vsftpd is incorrectly handling
- -certain glob expressions in STAT commands.  This allows a remote 
authenticated
- -attacker to conduct denial of service attacks (excessive CPU and process
- -slot exhaustion) via crafted STAT commands.
+Максимилиан Арцемович обнаружил, что 
vsftpd неправильно обрабатывает
+определённые маски в командах STAT. Это 
позволяет удалённому аутентифицированному
+злоумышленнику вызывать отказ в 
обслуживании (чрезмерное потребление 
ресурсов ЦП
+и памяти) с помощью специально 
сформированных STAT-команд.
 
 
 
- -For the oldstable distribution (lenny), this problem has been fixed in
- -version 2.0.7-1+lenny1.
+В предыдущем стабильном выпуске (lenny) эта 
проблема была исправлена в
+версии 2.0.7-1+lenny1.
 
- -For the stable distribution (squeeze), this problem has been fixed in
- -version 2.3.2-3+squeeze2.  Please note that 
+В стабильном выпуске (squeeze) эта проблема 
была исправлена в
+версии 2.3.2-3+squeeze2. Обратите внимание, что
 https://security-tracker.debian.org/tracker/CVE-2011-2189;>\
- -CVE-2011-2189 does not affect the lenny version.
+CVE-2011-2189 не касается версии в lenny.
 
- -For the testing distribution (wheezy),

Re: Системы управления сервером?

2018-03-31 Пенетрантность artiom 
>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
> человек
>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
>  >>  >>  >> 
>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
>  >>  >> 
>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
>  >>  >> 
>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
>  >>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
>  >> 
>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
>  >> происходит.
>  >> 
>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
>  > практики.
> 
> Собственно, системы управления версиями придуманы ровно для этой
> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
> если оно оказалось неудачным.
> 
> А чтобы неудачное изменение не долетело до заказчика, существует
> релизный цикл.  И ревью его необходимости не отменяет.
> 
Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
репозитория, на которую уже понакоммитили и заложили функционал.

>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
>  >>  >> 
>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
>  >>  > ли - не допустить?
>  >>  > Какая практика?
>  >>  > В чём нехорошесть данной идеи?
>  >> 
>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
>  >> будет изменен, проходит время.
>  > Как минус, так и плюс.
> 
> В течение этого времени в системе присутствуют и старые, и новые баги.
> Где плюс?
> 
Нет, присутствуют только старые баги, которые уже известны, проверены и
одеты в пиджак, так что стали напоминать фичи.
А тут новые баги, которые успеют сломать тестирование, например, в
результате чего могут не пройти другие тесты и т.п..
На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
однако есть факты на практике).


>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
>  > ждать ответов автора (который в этом время уже над другим работает), к
>  > тому же, ревьюверов бывает несколько.
> 
> Я про прерывания не процесса ревью, а про прерывания процесса своей
> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
> той задачи, к которой относится просматриваемый код.  Он там неизбежно
> заменит контекст своей задачи.  После ревью придется снова грузить свой.
> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
> часа каждая перегрузка, а их тут две.
Ну час - это явный перебор. А отрыв на 15 минут - не критично: вы же не
соревновательным программированием занимаетесь, надеюсь?
Иногда вообще полезно от задачи оторваться, бывает.
Другое дело, если ревью много. Тогда да, на них забивают.

> 
>  >>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
>  >>  >> там такова, что оно окупается.
>  >>  >> 
>  >>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
>  >>  > привязана задача, после чего проверяются (перед репозиторием).
>  >> 
>  >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
>  >> тормозной путь.
>  >> 
>  > Продукт окупается.
>  > "Тормозной путь", скорее всего, да.
>  > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.
> 
> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
> окупалось?
> 
Запаренные.

>  >> Менталитет программиста тоже интернационален. С менталитетом "кодера по
>  >> обезьяньей работе" хуже, но extreme programming - технология для
>  >> программистов.
>  >> 
>  > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
>  > несколько сложно, и не для всех эта техника подходит.
> 
> А никто не утверждал, что для всех.  А вот русский с китайцем, скорее
> всего, в паре как раз неплохо уживутся.  Только роли будут не
> переменные, а ближе к постоянным.  Китаец кодит, русский следит и
> корректирует.  Характерного китайца не надо подгонять, зато надо
> своевременно тормозить и/или поворачивать.  Тогда он будет выдавать
> качественный продукт, а быстро он его и так будет выдавать.
> 
Что-то динамика развития Китая по отношению к РФ показывает: роли
меняются. :-/

>  >>  >>  > В любом случае, если я такое (чисто теоретически) предложу 
> менеджеру,
>  >>  >>  > он только у виска покрутит. Это же получается, что каждый 
> программист
>  >>  >>  > работает, условно половину

Re: Нюансы взаимодействия ZFS

2018-03-31 Пенетрантность Eugene Berdnikov 
On Sat, Mar 31, 2018 at 12:07:23AM +0300, artiom wrote:
> > Теперь вопросы:
> > 
> Отвечу на свои же вопросы.
> 
> > - Как желательно располагать ZFS разделы относительно разделов LUKS?
> >   Сейчас ОС на ZFS, который на LUKS.
> >   И это правильно, чтобы не усложнять.
> >   Но здесь не важна производительность.
> >   А как располагать swap и slog: поверх LUKS или наоборот (как в мануале)?
> 
> - Прямое копирование на диск блоками по 4 MB: 185 MB/s (dsync: 136 MB/s)
> - LUKS раздел с поддержкой команд AES-NI: 184 MB/s (dsync: 135 MB/s)
> - ZFS volume = 170 MB/s (dsync: 50 MB/s).
> - LUKS on ZFS volume = 274 MB/s (dsync: 38 MB/s).
> - ZFS on LUKS = 187 MB/s (dsync: 50 MB/s)

 Третий вариант явно выбивается по цифрам из стройного ряда, что
 наводит на мысли о какой-то ошибке или опечатке.

 Да и странно, как чистый zfs может оказаться медленнее, чем он же над LUKS.
 Видимо, статистическая ошибка измерений сравнима со вторым знаком
 в этих числах, либо присутствует какая-то систематика.
 
> > - Как организовывать шифрованный пул?
> >   Опять, тот же вопрос: LUKS->ZFS или ZFS->LUKS?
> >   Если ZFS->LUKS, то не придётся ли мне сделать ZFS->LUKS->ZFS,
> >   чтобы использовать все возможности ZFS в пуле?
> > - Имеет ли смысл делать /boot на ZFS? Т.е., создавать для него
> > зеркальный пул?
> > 
> 
> Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS
> pool лучше поверх LUKS, а не наоборот.
> LUKS почти не вносит оверхед.

 Не следил за "заверениями экспертов", но, по-моему, очевидно, что
 шифрование выгоднее делать на уровне, который ниже всех кэшей.
 Независимо от того, какой оверхед это шифрование вносит.
-- 
 Eugene Berdnikov