CloudLinux - Блог CloudLinux - Проблемы, вызванные последним обновлением KernelCare, и что мы сделаем, чтобы это никогда не повторилось
RSS

Проблемы, вызванные последним обновлением KernelCare, и что мы сделаем, чтобы это никогда не повторилось

Проблемы, вызванные последним обновлением KernelCare, и что мы сделаем, чтобы это никогда не повторилось

ОБНОВЛЕНИЕ: Мар 30 - хронологический часовой пояс 10am. Канал 24h был обновлен с той же проблемой из-за того, что техник неправильно удалил задание «at». Это было исправлено в ближайшее время, но некоторые системы были затронуты.

Мы хотим извиниться за инцидент KernelCare, который вчера затронул некоторых наших клиентов. К сожалению, ошибка в патче POSIX ACL для CVE-2016-7097 не была обнаружена нашей тестовой системой.

Мы потратили всю прошлую ночь, чтобы исправить проблему и повторно выпустить исправления, чтобы устранить локальную уязвимость повышения привилегий CVE-2017-2647.

Чтобы избежать этих инцидентов в будущем, мы реализуем следующее:

В настоящее время наша тестовая система использует ряд синтетических тестов и запускает ее в течение часов 4 для каждого ядра. Набор тестов состоит из тестов LTP, а также нашего собственного набора тестов. Ясно, что у этих тестов есть ограничения, но мы планируем добавить xfstests, avocado и другие синтетические тестовые наборы в наш тестовый процесс. Мы также планируем добавить общие рабочие нагрузки в наш набор тестов.

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

Таким образом, мы восстанавливаем систему развертывания следующим образом:

  • Мы модифицируем клиентский скрипт (kcarectl) для обнаружения и уведомления о том, был ли сервер исправлен успешно и не вызвал сбой в 1, 2, 5, 15 и 60 минутах временного интервала.
  • Мы будем выпускать отдельные исправления для каждой версии ядра / версии ядра с задержкой между каждой версией, начиная с наименее популярных ядер.

Наша система развертывания автоматически проверит, были ли какие-либо проблемы с развертыванием, и в тех редких случаях она немедленно прекратит развертывание новых патчей и откатит ту, которая уже была развернута.

Цель состоит в том, чтобы как можно скорее остановить процесс развертывания, часто после первого сбоя, так что недавно выпущенный патч никогда не вырвал бы больше одного или двух серверов из всех серверов, которые запускают KernelCare, во всех наших клиентов.

Этот процесс развертывания исправлений с автоматической проверкой безопасности может занять до 12 часов, чтобы добраться до всех серверов 100,000 +, на которых работает KernelCare, но мы считаем, что это правильное решение, поскольку оно гарантирует, что ни один клиент никогда не столкнется с широко распространенными проблемами после выпуска. исправления когда-либо снова, и что затронутые многократные клиенты были бы делом прошлого.

По нашим оценкам, для внедрения новой системы развертывания потребуется около месяца. До тех пор вы можете использовать задержанный канал, который гарантирует, что ваши серверы получат патчи 24 часов после релиза.

Чтобы реализовать задержанный канал, добавьте PREFIX = 24h в /etc/sysconfig/kcare/kcare.conf

Это только начало работы, которую мы придумали в течение ночи, думая об этом инциденте, который затронул некоторых наших клиентов. Мы относимся к этому очень серьезно. Это наш первый такой серьезный инцидент с момента запуска KernelCare почти 3 лет назад, и мы будем принимать все меры предосторожности, чтобы убедиться, что это наш последний. Мы продолжим выяснять, как мы можем предотвратить такие проблемы в будущем и внедрить их один за другим. Это означает перераспределение значительных ресурсов для разработки из других проектов и инвестиции в новые способы тестирования, развертывания, автоматизации и сбора отзывов для продукта.

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

Еще раз, примите наши самые искренние извинения и будьте уверены, что у нас есть план предотвратить это снова.

Игорь Селецкий,
Генеральный директор CloudLinux

Исходный выпуск Imunify360 2.0-13
Проблемы, вызванные последним обновлением KernelCare

Комментарии 15

Здравствуйте,

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

Таким образом, мы можем зайти на ваш сервер и посмотреть, какие исправления доступны для каждого сервера.
Таким образом, мы можем решить в графическом интерфейсе установить последние исправления для серверов 1,2 и 3.
Затем мы запускаем систему, например, для 24h и видим, все ли в порядке.
После этого мы можем установить всю другую систему с одним и тем же патчем из графического интерфейса.

Это было бы хорошо. Таким образом, клиенты (мы) имеют больше контроля над тем, что пропатчено, и у нас нет сбоев на всех серверах одновременно, как вчера.

Спасибо

Здравствуйте, у вас должна быть система, где мы можем управлять нашими серверами. Таким образом, мы можем изменить все наши серверы на ручное обновление вместо автоматического исправления. Таким образом, мы можем зайти на ваш сервер и посмотреть, какие исправления доступны для каждого сервера. Таким образом, мы можем решить в графическом интерфейсе установить последние исправления для серверов 1,2 и 3. Затем мы запускаем систему, например, для 24h и видим, все ли в порядке. После этого мы можем установить всю другую систему с одним и тем же патчем из графического интерфейса. Это было бы хорошо. Таким образом, клиенты (мы) больше контролируем то, что исправлено, и у нас нет отключений на всех серверах в то же время, что и вчера. благодаря

Спасибо за предложение. Мы будем осуществлять такой глобальный контроль.
Прямо сейчас это можно сделать с помощью файла конфигурации и настроек AUTO_UPDATE. http://docs.kernelcare.com/index.html?config_options.htm
Тем не менее, теперь я ясно вижу, что это нужно делать лучше.

Спасибо за предложение. Мы будем осуществлять такой глобальный контроль. Прямо сейчас это можно сделать, используя конфигурационный файл и настройки AUTO_UPDATE http://docs.kernelcare.com/index.html?config_options.htm Тем не менее, теперь я ясно вижу, что это нужно делать лучше.

Здравствуйте

мы не довольны вашим видом общения!
Мы узнали о сбоях сервера и не сообщили вам, что мы должны перезапускать только серверы.

ПОЧЕМУ ВЫ НЕ ОТПРАВЛЯЕТЕ ПОЧТУ, КОГДА ВЫ ОБЕСПЕЧИВАЕТЕ ОБ ЭТОМ СВОИХ ЗАКАЗЧИКОВ?

У нас было много работы, офлайн-услуги, отмены контрактов. Из-за вашей некомпетентности. Самые большие проблемы на вашей стороне:
Вы не отправили своих клиентов по почте. Это не выход в нашу индустрию!

Это более важно сделать партию на WHD?

Привет, мы не рады, что вы общаетесь! Мы узнали о сбоях сервера и не сообщили вам, что мы должны перезапускать только серверы. ПОЧЕМУ ВЫ НЕ ОТПРАВЛЯТЬ ЭЛЕКТРОННУЮ ПОЧТУ, ГДЕ ВЫ ИНФОРМИТЕ ВАШИ КЛИЕНТЫ ОБ ЭТОМ? У нас было много работы, офлайн-услуги, отмены контрактов. Из-за вашей некомпетентности. Самые большие проблемы на вашей стороне: вы не отправили своих клиентов по почте. Это не выход в нашу индустрию! Это более важно сделать партию на WHD?

Я хочу лично извиниться за это. Это было предложено в течение первых полутора часов одним из членов нашей команды, но я решил не участвовать в кучей неправильных причин. У нас нет хорошего списка рассылки для этого, ни правильного инструмента, чтобы сделать это на месте, и мы не знали, на кого повлияли ... неправильные причины.
Сначала мы не осознавали, что это было настолько широко распространено, и к тому времени, когда мы это сделали - мы уже откатили все назад - и работали над выяснением того, что произошло / почему и как это решить. Ситуация была для нас настолько новой - что мы (я лично) облажались.

В любом случае - мы были не готовы. Мы думали, что чего-то подобного никогда не произойдет - и у нас не было плана.
Сейчас мы планируем провести вероятные события, и он также будет включать план коммуникаций.

Так что, я очень сожалею об этом - и я не позволю этому повториться:

PS: WHD требует довольно много энергии, и я пошел на вечеринку WHD, но я пошел к ней, зная, что затронуты только два клиента, и что мы отбросили все патчи - и другие люди не должны быть затронуты. Мы не понимали, что проблема была большой / затронутой несколькими клиентами. Я предупреждал о поддержке этой проблемы и сказал им немедленно связаться со мной, если есть другие сообщения. Как только я узнал о втором клиенте, я покинул вечеринку и вместе с другими членами компании, над которыми мы работали, чтобы решить эту проблему.

Я хочу лично извиниться за это. Это было предложено в течение первых полутора часов одним из членов нашей команды, но я решил не участвовать в кучей неправильных причин. У нас нет хорошего списка рассылки для этого, ни правильного инструмента, чтобы сделать это на месте, и мы не знали, на кого повлияли ... неправильные причины. Сначала мы не понимали, что это так широко распространено, и к тому времени, когда мы это сделали, мы уже откинули все - и работали над выяснением того, что произошло / почему и как его решить. Ситуация для нас была настолько новой - что мы (я лично) прищурились. В любом случае - мы были не готовы. Мы думали, что чего-то подобного никогда не произойдет - и у нас не было плана. Сейчас мы планируем провести вероятные события, и он также будет включать план коммуникаций. Так что, я очень сожалею об этом - и я не позволю этому повториться: PS: WHD требует довольно много энергии, и я пошел на вечеринку WHD, но я пошел к нему, зная, что затронуты только два клиента и что мы отбросили все патчи - и другие люди не должны быть затронуты. Мы не понимали, что проблема была большой / затронутой несколькими клиентами. Я предупреждал о поддержке этой проблемы и сказал им немедленно связаться со мной, если есть другие сообщения. Как только я узнал о втором клиенте, я покинул вечеринку и вместе с другими членами компании, над которыми мы работали, чтобы решить эту проблему.

Мы все люди. Ошибки могут и будут происходить всегда.

Речь идет не о проблемах, а о том, как компания реагирует на это. И я должен сказать, что команда KernelCare проделала большую работу с «aftermatch» этой проблемы.

Мы все люди. Ошибки могут и всегда случаться. Речь идет не о проблемах, а о том, как компания реагирует на это. И я должен сказать, что команда KernelCare проделала большую работу с «aftermatch» этой проблемы. :)

Да, были все люди, но это не правильно, так сказать, они сделали хороший матч на всех.
мы несколько раз спрашивали, что мы должны делать. Ничто не возвращается.
У нас было большое время простоя более тысячи клиентов, долгая ночь.

Такая служба должна проходить под специальным помощником людей, которые знают, что они делают. Wé расположены в Германии, а не в США, что означает, что безопасность данных, профессиональная работа очень важны. Я удивлен, как легко ядро ​​может столкнуться с узлами, я бы не подумал об этой ситуации: Kernelcare получил взломать, и хакер может контролировать наши узлы.

НЕТ GO в этой отрасли. @CEO: Как проф. ЭТО, вы ДОЛЖНЫ думать обо всех, и что может быть в любом случае. Для меня это слишком легко. Наш уровень - это предприятие. Не кухонный хост или подобный.

WHD для детей и промышленности низкого уровня. Пожалуйста, проснись! Эта ситуация очень плохая для репутации. В Германии ваше положение очень плохое!

Да, все люди, но это не так, так что скажем, они отлично справились. мы несколько раз спрашивали, что мы должны делать. Ничто не возвращается. У нас было большое время простоя более тысячи клиентов, долгая ночь. Такая служба должна проходить под специальным помощником людей, которые знают, что они делают. Wé расположены в Германии, а не в США, что означает, что безопасность данных, профессиональная работа очень важны. Я удивлен, как легко ядро ​​может столкнуться с узлами, я бы не подумал об этой ситуации: Kernelcare получил взломать, и хакер может контролировать наши узлы. НЕТ GO в этой отрасли. @CEO: Как проф. ЭТО, вы ДОЛЖНЫ думать обо всех, и что может быть в любом случае. Для меня это слишком легко. Наш уровень - это предприятие. Не кухонный хост или подобный. WHD предназначен для детей и индустрии низкого уровня. Пожалуйста, проснись! Эта ситуация очень плохо для репутации. В Германии ваше положение очень плохое!

«Wé расположены в Германии, а не в США, а это означает, что безопасность данных, профессиональная работа очень важны».

Эй, Ханс, вы пытаетесь понять, что профессионализм и безопасность данных не то, чем американцы стремятся или находят важными? Вы должны пересмотреть оскорбление всей страны за ошибку одной компании, особенно после того, как мы спасли вашу задницу один раз, и вам придется сделать это снова, как только этот нечестивый дьявол Меркель заставит вас стать халифатом.

«Wé расположены в Германии, а не в США, а это означает, что безопасность данных, профессиональная работа очень важны». Эй, Ханс, вы пытаетесь понять, что профессионализм и безопасность данных не то, чем американцы стремятся или находят важными? Вы должны пересмотреть оскорбление всей страны за ошибку одной компании, особенно после того, как мы спасли вашу задницу один раз, и вам придется сделать это снова, как только этот нечестивый дьявол Меркель заставит вас стать халифатом.

Эта проблема слишком сильно ударила по нам, но Игорь делает хорошее общение и не пытается скрыть проблемы. Я считаю, что он заслуживает доверия, честно и сочувственно. Он серьезно относится к этой проблеме и хочет предпринять шаги, чтобы это не повторилось.
Но в противном случае (я очень уважаю его, так что вы общаетесь так открыто!) Согласно вашему обновлению, это произошло снова, что, конечно же, разрушает первое повторное доверие.

Как DJPRMF уже сказал, люди делают ошибки. Конечно, этого не должно быть, но это случается. Теперь важно, что вы делаете в будущем, чтобы предотвратить это. Ваши планы звучат законно и разумно.

В моем случае у меня тоже есть хуго ущерб (также на финансовом уровне), и я провел всю ночь и день, чтобы вернуть все. Но это не помогает, когда плачет, как «The A» - это просто не будет иметь никакого эффекта. Kernelcare очень помогает, и наша команда разработчиков сэкономила много времени в прошлом.

Эта проблема слишком сильно ударила по нам, но Игорь делает хорошее общение и не пытается скрыть проблемы. Я считаю, что он заслуживает доверия, честно и сочувственно. Он серьезно относится к этой проблеме и хочет предпринять шаги, чтобы это не повторилось. Но в противном случае (я очень уважаю его, так что вы общаетесь так открыто!) Согласно вашему обновлению, это произошло снова, что, конечно же, разрушает первое повторное доверие. Поскольку DJPRMF уже сказал, люди делают ошибки. Конечно, этого не должно быть, но это случается. Теперь важно, что вы делаете в будущем, чтобы предотвратить это. Ваши планы звучат законно и разумно. В моем случае у меня тоже есть хуго ущерб (также на финансовом уровне), и я провел всю ночь и день, чтобы вернуть все. Но это не помогает, когда плачет, как «The A» - это просто не будет иметь никакого эффекта. Kernelcare очень помогает, и наша команда разработчиков сэкономила много времени в прошлом.

Потому что это Игорь, я не сомневаюсь, что это приведет к чему-то гораздо лучшему. Cloudlinux, по-моему, не допустил много ошибок, и ошибки рано или поздно будут связаны с людьми.

Я думаю, вам стоит подумать о добавлении опции поддержки уровня предприятия, кажется, что у вас есть по крайней мере один клиент для этого. Не жертвуйте той большой поддержкой, которую вы предоставляете другим из нас.

WHD может быть для менее крупных компаний, но я полагаю, что большинство клиентов cloudlinux, вероятно, вписываются в группу, посещающую WHD.

Также любопытно, что другие комментаторы, на уровне предприятий, хотели бы видеть в ответ от Игоря. Для моих целей ответ был в порядке.

Поскольку это Игорь, я не сомневаюсь, что это приведет к чему-то гораздо лучшему. Cloudlinux, на мой взгляд, не сделал много ошибок, и ошибки неизбежно произойдут, рано или поздно люди будут вовлечены. Я думаю, вы должны рассмотреть возможность добавления поддержки уровня предприятия, кажется, у вас есть по крайней мере один клиент для этого. Не жертвуйте той великой поддержкой, которую вы оказываете остальным из нас. :) WHD может быть для небольших компаний, но я думаю, что большая часть клиентов cloudlinux, вероятно, вписывается в группу участников WHD. Также любопытно, что другие комментаторы на уровне предприятия хотели бы видеть в ответе Игоря. Для моих собственных целей ответ был в порядке.

Спасибо, Игорь за сообщение в блоге и вашу очень честную оценку ситуации.

В конце концов, это происходит. Для каждого поставщика услуг важно, чтобы KernelCare оценивал риски для своих систем автоматических обновлений, будь то из дистрибутива вверх, ядровой помощи, панели управления или тому подобного. Это, безусловно, первый раз в 3 годах, когда я слышал о каких-либо проблемах с KernelCare, и в то время я вспоминаю множество примеров cPanel, Plesk, отложенных обновлений RHN и тому подобного.

Ошибки случаются. Период. Если у вас есть система, которая требует абсолютной целостности, отложите обновления и выполните пакетирование вручную после собственного внутреннего тестирования. Кроме того, есть смягчающие функции, которые любой может применить, которые могли бы предотвратить панику из-за жесткой блокировки, просто установив соответствующие значения sysctl для принудительной перезагрузки при панике.

например: sysctl.conf
# перезагрузиться при панике после 90
kernel.panic = 90

Мы с нетерпением ждем продолжения использования kernelcare в будущем. Будьте очень внимательными людьми, что есть два игрока во всех экосистемах Linux, предоставляющих эту услугу - ksplice и kernelcare. Только один из них находится под значимым активным обслуживанием с быстрым переворачиванием патчей для 0days, kernelcare.

Будем поддерживать и конструктивно, да, мы платим за услугу, но на нас лежит ответственность за то, чтобы пользователи также помогали в улучшении продукта благодаря содержательной обратной связи.

Спасибо Игорь!

Спасибо, Игорь за сообщение в блоге и вашу очень честную оценку ситуации. В конце концов, это происходит. Для каждого поставщика услуг важно, чтобы KernelCare оценивал риски для своих систем автоматических обновлений, будь то из дистрибутива вверх, ядровой помощи, панели управления или тому подобного. Это, безусловно, первый раз в 3 годах, когда я слышал о каких-либо проблемах с KernelCare, и в то время я вспоминаю множество примеров cPanel, Plesk, отложенных обновлений RHN и тому подобного. Ошибки случаются. Период. Если у вас есть система, требующая абсолютной целостности, задержите ваши обновления и вручную выпустите их после собственного внутреннего тестирования. Кроме того, существуют смягчающие функции, которые могут применить любые, которые предотвратили бы жесткие блокировки, просто установив соответствующие значения sysctl для принудительной перезагрузки при панике. например: sysctl.conf # перезагрузка при панике после 90s kernel.panic = 90 Мы с нетерпением ждем продолжения использования kernelcare в будущем. Будьте очень внимательными людьми, что есть два игрока во всех экосистемах Linux, предоставляющих эту услугу - ksplice и kernelcare. Только один из них находится под значимым активным обслуживанием с быстрым переворачиванием патчей для 0days, kernelcare. Будем поддерживать и конструктивно, да, мы платим за услугу, но на нас лежит ответственность за то, чтобы пользователи также помогали в улучшении продукта благодаря содержательной обратной связи. Спасибо, Игорь!
Уже зарегистрирован? ВОЙТИ
гость
Среда, 13 ноября 2019

Защитный код изображение