Комментарии 53
Это, конечно, крутая штука. Но совершенно бессмысленная, если фикс сложнее полутора строк кода и связан со структурами ядра, а не с фиксом какой-либо проверки.
Иными словами, KernelCare НЕ обновляет ядро до новой версии (то есть если в новом появился новый функционал или сильно исправлен старый), то вы НЕ получите все это. Максимум, что Вы получите — фикс связанный с безопасностью но тоже далеко не во всех случаях.
Также это может вызвать проблемы с последующей отладкой дампов таких патченых ядер например силами kdump.
Иными словами, KernelCare НЕ обновляет ядро до новой версии (то есть если в новом появился новый функционал или сильно исправлен старый), то вы НЕ получите все это. Максимум, что Вы получите — фикс связанный с безопасностью но тоже далеко не во всех случаях.
Также это может вызвать проблемы с последующей отладкой дампов таких патченых ядер например силами kdump.
Всё верно. Но и usecase подобных инструментов совсем иной. Представьте у вас крутится суперважная бизнескритикал БД. Она крутится вот уже год, никакое ПО и настройки там не меняются, все отлажено. И тут обнаруживается критичный баг в используемом ядре- маленький, но очень вредный, способный заставить ядро «паниковать». Что делать, обновляться с простоем? Вот тут то вам и пригодится KernelCare или иной подобный инструмент.
Как раз критический баг, от которого ядро будет паниковать оно вряд ли исправит, ибо скорее всего тут понадобятся большие фиксы. Но в целом, да, это актуально особенно на серверах, где пользователи имеют локальный доступ, так как локальные уязвимости находят чуть ли не каждый день.
Суперкритикал БД может нехило подфризиться, пока обновляются вызовы. Даже если там обновление kgraft-подобное, все равно тормоза могут быть неприемлемо большими. На мой взгляд, все эти пляски могут быть применимы только как дальшейшее уменьшение даунтайма при апгрейде ядра, с бонусом в виде поднятых в память кешей, для критичных вещей существует HA/state replication :)
А почему «суперважная бизнескритикал БД» не работает в кластере? Usecase вами представленный больше на костыль походит, все конечно ИМХО.
Почти ни одна из доступных открытых баз данных не кластеризуется. Даже oracle клстеризуется с кучей ограничений и условий. Да и легендарный VmWare для кластеризованных VPS (полностью реплицированные и работающие на двух узлах) такие огранчиения накладывает, что становится сомнительна целесообразность такого.
ИМХО:
Обычно на сервере ведь не нужны новые возможности ядра, он расчитывается изначально на выполнение конкретных задач на стабильной основе, соответственно кроме обновлений безопасности потребностей нет. Если же вы хотите новый фичи ядра сразу на продакт выкатывать с клиентами, то это как минимум неправильно. Лучше развернуть новый сервер с новыми возможностями и мигрировать, но если это критичный сервис, если же нет, то можно и ребутнуться ведь…
Обычно на сервере ведь не нужны новые возможности ядра, он расчитывается изначально на выполнение конкретных задач на стабильной основе, соответственно кроме обновлений безопасности потребностей нет. Если же вы хотите новый фичи ядра сразу на продакт выкатывать с клиентами, то это как минимум неправильно. Лучше развернуть новый сервер с новыми возможностями и мигрировать, но если это критичный сервис, если же нет, то можно и ребутнуться ведь…
На самом деле проще ребутнутся с kexec, это сокращает время ребута раз в 5-20 в зависимости от железа и сводит его к почти минимуму. А еще с помощью виртуальной магии из патча openvz можно сохранить страничный кэш в прогретом состоянии :)
Не спорю, вариатов полно, но для шаред-хостинга, для которого и позиционируется CloudLinux, подход с KernelCare вполне оптимален.
kexec кончено очень крут, и делает больше — и делает лучше. Всё же новое ядро. KernelCare не для всех. Но kexec это явно не проще чем сервис который поставил и забыл, и даже не задумываешься когда это сделает. Он себе где то на фоне калупается, без какой либо помощи админов.
вот сейчас как раз пример когда kexec не поможет. Ядер новых от CentOS и RHEL ещё просто нет. А мы уже закрыли уязвимость. Ну это такой, довольно редкий пример.
www.cloudlinux.com/blog/clnews/kernelcare-cve20143153.php
www.cloudlinux.com/blog/clnews/kernelcare-cve20143153.php
Вы совершенно правы — это не для полного обновления ядра, а для устранения проблем с безопасностью и критических багов.
Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)
Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)
Игорь, очень рад видеть Вас здесь! :) Спасибо за комментарии, очень полезная информация. Есть ли у Вас планы реализации критичных к стабильности фиксов для OpenVZ? Там тоже много фич не связанных с безопасностью, но легко заваливающих серверы в определенных условиях. Будь у Вас такая фишка, мы бы с радостью купили подписку на сотни машин, ибо их (ядер) обновление — задача крайне долгая и сложная :)
Есть, мы обсуждаем это с Parallels & OpenVZ командами. Мы хотим чтоб они нам давали патчи которые они считают 'критичными', и мы их тоже будем вставлять. Но пока это в стадии обсуждения/рассуждения. Нам в этом очень важно партнёрство с вендорами, ибо без них нам очень трудно понять что важно, а что нет.
Да, это было бы офигенное партнерство! Надеюсь, оно будет не только для PCS, но и для открытого OpenVZ.
Игорь, а реально ли получить по KernelCare пару критичных фиксов стабильности OpenVZ имеющих место в ядрах 1-2 релиза назад?
В частности отсюда wiki.openvz.org/Download/kernel/rhel6-testing/042stab090.2 вот этот «fix for netconsole over bonding (PSBM-26668, RH #1095252, possibly #2231, #2338)». Уверен, он очень простой, но растет аж с RHEL (и не факт, что там исправлен).
А также отсюда openvz.org/Download/kernel/rhel6/042stab088.4 вот этот «ms ext4: fix online resize with a non-standard blocks per group setting (#2911, PSBM-24924)».
Также очень хотелось бы более-менее подробную информацию об организации наложения патчей, чтобы быть совсем совсем уверенными в том, что в очередном апгрейде не придет rm -rf.
Кроме этого, у нас есть большой интерес в предоставлении подобной услуги клиентам (тысячи выделенных машин), но тут есть нюансы, которые нужно обсуждать уже отдельно.
В частности отсюда wiki.openvz.org/Download/kernel/rhel6-testing/042stab090.2 вот этот «fix for netconsole over bonding (PSBM-26668, RH #1095252, possibly #2231, #2338)». Уверен, он очень простой, но растет аж с RHEL (и не факт, что там исправлен).
А также отсюда openvz.org/Download/kernel/rhel6/042stab088.4 вот этот «ms ext4: fix online resize with a non-standard blocks per group setting (#2911, PSBM-24924)».
Также очень хотелось бы более-менее подробную информацию об организации наложения патчей, чтобы быть совсем совсем уверенными в том, что в очередном апгрейде не придет rm -rf.
Кроме этого, у нас есть большой интерес в предоставлении подобной услуги клиентам (тысячи выделенных машин), но тут есть нюансы, которые нужно обсуждать уже отдельно.
Поставил плюс просто за картинку :). Очень жизненно :).
А что касается обновления ядра «на лету», ИМХО, обычно оно всё-таки неоправданно и слишком рискованно :). Программы, работающие на серверах, не должны быть единственным источником данных, поэтому временный downtime одного из серверов не должен приводить к отказу в обслуживании. Поэтому maintanenance перезагрузка сервера на момент обновления ядра, ИМХО, это нормально и терпимо даже в супер-highload-enterprise-production системах.
А что касается обновления ядра «на лету», ИМХО, обычно оно всё-таки неоправданно и слишком рискованно :). Программы, работающие на серверах, не должны быть единственным источником данных, поэтому временный downtime одного из серверов не должен приводить к отказу в обслуживании. Поэтому maintanenance перезагрузка сервера на момент обновления ядра, ИМХО, это нормально и терпимо даже в супер-highload-enterprise-production системах.
Исходинки поделки есть? Если нет — сразу в топку.
НЛО прилетело и опубликовало эту надпись здесь
По этим исходникам можно сказать, что в них нет ничего, что раскрывало бы суть того, что они делают.
И забано доверять свои сервера за 3 бакса в месяц конторе, которая потом может запросто быть поломана и вот у нас ботнет из тучи серверов.
И забано доверять свои сервера за 3 бакса в месяц конторе, которая потом может запросто быть поломана и вот у нас ботнет из тучи серверов.
пока мы не готовы открыть всё — ибо строим на этом коммерческий сервис, и не хотим лишних конкурентов.
Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
Patch Level 9 applied
Это очень энтерпрайзно, конечно, но вопрос есть: какие все-таки ограничения у продукта? Какого рода патчи он не сможет применить?
И еще, если говорить о «бизнес-критичных» серверах, то есть такие вопросы:
— Как перед применением отревьюить список патчей?
— Как откатить последний примененный банч патчей?
— История применения патчей?
— Возможна ли периодическиая проверка без фактического обновления, только нотификация?
Как-то так, наверно
— их можно увидеть на patches.kernelcare.com нажмите на ядро, там будет что патчается, и какими патчами.
— мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
— там система такая что старые патчи сносятся, новые накладываются, каждый раз.
— проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com
Спасибо за вопросы — очень классные.
— мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
— там система такая что старые патчи сносятся, новые накладываются, каждый раз.
— проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com
Спасибо за вопросы — очень классные.
Ага, понял. Пара мнений:
1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)
1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)
1. Там всё что есть для каждого ядра. Что мы пока не делаем, это не разделяем, что в этот раз «CVE-2222», а в прошлый CVE-2232. Сейчас над этим работаем.
2. Хорошая идея, и очень просто сделать. Добавим.
3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
2. Хорошая идея, и очень просто сделать. Добавим.
3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
А есть какая-либо защита и rollback на лету, если не важно по какой причине (невозможной и тд) но патч не хочет накладываться?
Конечно, часто бывает что ядро в критической секции и мы просто не можем наложить в этот момент патч, мы это узнаём ждём, пробуем ещё раз пару раз… если за пол минуты не находим, вылетаем с ошибкой (но это редко)
Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
Нет, речь идёт о любой ошибке в модуле, или стечении обстоятельств, или криптомагии, когда сигнатура ядра та же, хеш тот же, а ядро другое.
Или конфликт двух патчилок (или какие-либо модули, модифицирующие ядро, либо еще чего) — проверка накладываемости патча успешно прошла, вы накладываете свой патч и внезапно нарываетесь на то, что код который патчите не тот.
будет ли откат уже наложенной части, перезапишется патч поверх без проверок, или будет упс ожиданный?
Или конфликт двух патчилок (или какие-либо модули, модифицирующие ядро, либо еще чего) — проверка накладываемости патча успешно прошла, вы накладываете свой патч и внезапно нарываетесь на то, что код который патчите не тот.
будет ли откат уже наложенной части, перезапишется патч поверх без проверок, или будет упс ожиданный?
Нет, такие вещи мы просто не знаем как обнаружат. И конфликт двух патчилок тоже не сможем обнаружить. Например если поставить KernelCare на ядро с ksplice --> можно быть уверенным что ядро крашанётся. С ksplice мы это обнаруживаем в userland программе. Если же какой руткит (а они часто подобным образом меняют код) — и он сменил туже/соседнюю секцию --> то мы этого не увидим, и крашанёмся.
На самом деле интересная идея -> сверять эти куски кода, и ставить патч только если таже сигнатура этих кусков. Я спрошу наших разработчиков. Это на данный момент не критично (ибо не случается), но такая защита не повредит.
На самом деле интересная идея -> сверять эти куски кода, и ставить патч только если таже сигнатура этих кусков. Я спрошу наших разработчиков. Это на данный момент не критично (ибо не случается), но такая защита не повредит.
Кстати, как пример крутой статы по ядрам предлагаю: stats.openvz.org :)
Надеюсь патчи подписаны паблик ключем с последующей проверкой его в ядре? А то теперь руткиты станет ставить еще проще…
Честно говоря, в контексте появления аж ДВУХ ОТКРЫТЫХ (kpatch, kGraft ) средств для реализации той же самой задачи не вижу смысла в Kernel Care в принципе, хотя он работает хорошо (даже на OpenVZ), мы его тестировали и весьма успешно.
Зачем платить, ловить баги закрытого продукта, когда в ближайшее время появятся надежные и стабильные реализации данной задачи от открытых продуктов? А RHEL скорее всего так вообще получит эту функцию в стандартной поставке (ну не зря же они делали kpatch?).
Зачем платить, ловить баги закрытого продукта, когда в ближайшее время появятся надежные и стабильные реализации данной задачи от открытых продуктов? А RHEL скорее всего так вообще получит эту функцию в стандартной поставке (ну не зря же они делали kpatch?).
подозреваю, что на регулярной основе выпуск патчей бесплатно получить сложно.
kGraph не будет работать с текущими ядрами, только со специфично проопатченными. Ну и там очень сыро.
kpatch -> там интересно, но тоже только последние ядра.
Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
kpatch -> там интересно, но тоже только последние ядра.
Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
Игорь, а Вы случайно не хотите написать красивую статью с обзором текущих средств обновления ядра и кратким экскурсом в особенности каждой технологии? Это же бесценная информация :)
Двоякое чувство. С одной стороны хочется, ибо то как мы создаём патчи — это очень интересно, у нас технология сильно улучшена по сравнению с ksplice. Они у нас меньше по размеру, легче 'вырезается' именно нужный бинарный кусок. И при этом куда более точно. И мы видим что пока не SuSe не RHEL так не делают.
И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
Игорь, а сделайте тоже самое, что для ядра, но для user space приложений? Ведь тот же OpenSSL можно было исправить находу даже без ребута приложений, просто поправив в памяти один байт буквально.
Даже если не находу, то универсальное решение умеющее обновлять систему просто через apt/yum (и также не забывающее перезапускать приложения зависящие от данного бинарика, но уже находящиеся в памяти) без привлечения администраторы я бы с чистой совестью выкупил вдвое дороже KernelCare на сотни машинок :)
Даже если не находу, то универсальное решение умеющее обновлять систему просто через apt/yum (и также не забывающее перезапускать приложения зависящие от данного бинарика, но уже находящиеся в памяти) без привлечения администраторы я бы с чистой совестью выкупил вдвое дороже KernelCare на сотни машинок :)
Можно, технология позволяет, вот в полезности у неё куда меньше, ведь тот же:
yum update openssl
service httpd graceful
etc… вообще не даст downtime
ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.
А создавать эти патчи, при всей автоматизации — дорого. Кто то должен их просмотреть, убедится что он ничего не сломает, и его не надо переделывать. Ну или переделать — что вообще трудно, ибо надо иметь специалиста для данного софта.
Собрать, протестировать, подписать, выпустить.
То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
yum update openssl
service httpd graceful
etc… вообще не даст downtime
ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.
А создавать эти патчи, при всей автоматизации — дорого. Кто то должен их просмотреть, убедится что он ничего не сломает, и его не надо переделывать. Ну или переделать — что вообще трудно, ибо надо иметь специалиста для данного софта.
Собрать, протестировать, подписать, выпустить.
То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
Почему не понятна? Вся суть KernelCare (да и других подобных систем) в том, чтобы запатчить ядро (= закрыть потенциальные дыры в системе) как можно быстрее без привлечения системного администратора, отсутствие даунатайма при этом скорее бесплатная приятность, чем самоцель.
Но если задачу апгрейда ядра/слежения за уязвимостями в ядре Вы снимаете с администратора, чем, безусловно, закрываете по моим оценкам где-то 1/5 число потенциальных проблем с безопасность и стабильностью. На практике (чуточку больше ее здесь) взломы через локальные уязвимости — вещь веееесьма экзотическая.
Но вот чтобы закрыть оставшиеся 4/5 требуется лезть в ПО, к счастью, обычно это стандартное системное ПО из репозитариев — nginx, exim, apache, openssl, gnutls, lighttpd и прочие. И если будет возможность их также CareFree обновить/запатчить без привлечения системного администратора — Вы перевернете системное администрирование.
Но если задачу апгрейда ядра/слежения за уязвимостями в ядре Вы снимаете с администратора, чем, безусловно, закрываете по моим оценкам где-то 1/5 число потенциальных проблем с безопасность и стабильностью. На практике (чуточку больше ее здесь) взломы через локальные уязвимости — вещь веееесьма экзотическая.
Но вот чтобы закрыть оставшиеся 4/5 требуется лезть в ПО, к счастью, обычно это стандартное системное ПО из репозитариев — nginx, exim, apache, openssl, gnutls, lighttpd и прочие. И если будет возможность их также CareFree обновить/запатчить без привлечения системного администратора — Вы перевернете системное администрирование.
Кстати, да, очень ждем поддержки Debian 6 и 7. Ну очень очень прямо :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
KernelCare: патчим ядро «на лету»