1.1, solardiz (?), 07:23, 25/11/2009 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
"Версия 2.6.18 с патчами ..." - это, хоть и правда, но очень условно. Если размер объединенного патча (10 MB под .bz2) сравним с размером ядра (40 MB под .bz2), какая это теперь версия?.. Номер у нее получается длинный - у нас она сейчас зовется 2.6.18-128.2.1.el5.028stab064.8-owl0.2. Сюда вошел номер версии ядра, от которой Red Hat'овцы fork'нули stable ветку для RHEL5, номер версии RHEL-патчей (трехзначный т.к. у них тоже ветки - эта одна из стабильных, на основе которой Red Hat выпускал официальные обновления RHEL), номер версии OpenVZ-патчей, и номер версии наших патчей (совсем мелких - на данный момент это всего 11 KB под .gz - да, килобайт).
Звучит страшно? А не стоит бояться. Это правда стабильная ветка (ну, по крайней мере в терминах Red Hat и OpenVZ, и относительно cutting-edge 2.6 ядер), включающая back-port'ы security fix'ов (а многие публикуемые сейчас уязвимости ядер 2.6.3x, кстати, в 2.6.18 просто отсутствовали, так что новых back-port'ов требуется и делается меньше, чем сейчас исправляется уязвимостей в 2.6.3x), некоторый security hardening (exec-shield, vm.mmap_min_addr и отвязка его от LSM - в свежих 2.6.3x это тоже есть, в исходном 2.6.18 не было), а также back-port'ы драйверов.
Названные мной 10 MB - это почти исключительно изменения между 2.6.18 и ядром из RHEL5, причем из них большая часть объема - это драйвера. Код OpenVZ - в пределах 10% от размера общего патча. Вот картинка, которая это поясняет:
http://wiki.openvz.org/Image:Kernel-loc-changes-compared-to-rhel5.png
В ближайших планах (вероятно, декабрь) - переход на "2.6.18-164..." (как-бы с RHEL 5.3 на 5.4). В более отдаленных - на OpenVZ-патч на основе ядер из RHEL6, опять же с нашими мелкими патчами сверху, конечно (теми из них, которые еще не войдут в один из upstream'ов - некоторые уже вошли пока мы "разрабатывали").
| |
|
|
|
4.16, solardiz (?), 03:37, 26/11/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>А мне запомнилась его 128 байтовая демка Cross ...
Забавно, что такие вещи вспомнили здесь. Cross была другого участника конкурса. Моя была Highway. Но это не в тему.
А в тему - за Owl "стою" не только я. В частности, значительную часть работы после Owl 2.0 (да и до тоже) проделали Дмитрий Левин (известный также как один из ключевых разработчиков ALT Linux), Михаил Литвак, Дмитрий Хлебников и еще несколько человек (в том числе "не русские", хотя это в большей степени до 2.0). Проект небольшой, команда тоже, но всё же это не я один, и это важно.
| |
|
|
|
3.15, solardiz (?), 03:18, 26/11/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>2.6.18-128.2.1.el5.028stab064.8-owl0.2 -- детская болезнь, такое длинное наименование избыточно. Вполне достаточно 2.6.18-owl-r0648 :-)
Спасибо за мнение. В userland пакетах мы такие длинные "номера" версий не используем, несмотря на то что в ряде случаев там тоже набор патчей из разных источников. В случае с ядром пока так в какой-то степени чтобы подчеркнуть для "новичков" что это далеко не 2.6.18 и сразу "ответить на вопросы" что именно. С другой стороны, я понимаю что все ответы в номер версии или имя файла все равно не уместить... К тому же, 128.2.1 оказывается не совсем верным, т.к. часть более новых Red Hat'овых патчей вошла в owl0.2, фактически доведя версию до 128.7.1, но OpenVZ'овый 064.8 при этом базировался на 128.2.1. Так что да, есть причины отказаться от такой длинной нумерации. Подумаем.
> Кстати, как у вас там с aufs дело обстоит -- используете ли и если да, то какую версию?
Пока не используем. Пока контейнеры на simfs. Может быть, позже, если будет значительный спрос или это (общие файлы и copy-on-write для изменений) всерьез потребуется нам самим или станет стандартной функцией используемого ядра.
| |
|
|
|
|
|
4.7, Alex (??), 12:49, 25/11/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>А есть ли какие-то планы по интеграции SELinux, AppArmor, TOMOYO ? Как
>вы вообще к таким технологиям относитесь и насколько по вашему мода
>по их добавлению в дистрибутивы оправдана ?
>
>Еще было бы интересно услышать ваше мнение по поводу технологий повышения безопасности,
>представленных Google в Chromium OS.
>http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview
>http://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs
С SELinux пока вопрос скорее не к разработчикам Owl, а к разработчикам SELinux и OpenVZ. Так как пока они вместе не работают. Когда OpenVZ войдет целиком в mainstream ядро или хотя бы в RHEL6, можно расчитывать, что оно будет вместе работать. Про AppArmor и TOMOYO не скажу, не смотрел подробно.
| |
|
|
|
|