На сколько опасно автоматическое обновление linux-сервера?

Question

[Alex-Vin]

Во всех рекомендациях пишут, что автоматическое обновление linux-серверов не приветствуется.
Главная причина, говорят, что если что-то пойдет не так, то сразу можно исправить.

Какие могут быть реальные варианты проблемного обновления? У кого-то были вообще проблемы с обновлениями? И как вы их исправляли?

Больше года обновляю вручную виртуальный сервер на Debian, ни разу проблем не было.
Есть предложение добавить в крон apt-get update apt-get upgrade.

Поэтому, на сколько рискованно автоматически обновлять сервер?

Answer 1

[s1dney]

И не зря рекомендуют.
Придет мажорное обновление php/nginx/apache или любого другого жизненно важного продакшен-компонента и есть не малая вероятность того, что сервисы прилягут.
Вместе с обновлениями приходят патчи на ядро + хедеры и зависимости, но важный момент в том, что зависимости обновляются в ту же минуту, а новое ядро загрузится только с перезагрузкой, это вызовет неизбежные конфликты, если не сделать перезагрузку (а делать ее нельзя очень часто).
Вообще, по опыту - любые обновления непредсказуемы, можно попасть в неловкую ситуацию даже обновляя какие-то безобидные вещи вроде logrotate.

Comments

[Максим Васильев]

Мажорные обновления в дебиане и убунте не прилетают.

[Максим Васильев]

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

[s1dney]

Под мажорными обновлениями я имел в виду, конечно, не очевидные 2.6 - 2.7, а 1.2.3-19 - 1.2.4-01, такие обновления приходят регулярно.
Впрочем, я видел как ломается код php и от минорного обновления php-fpm в центоси (энтерпрайз самый настоящий). Причина конечно была в самом php коде, а не в пакете. Но это совершенно ничего не меняет.

[Максим Дунаевский]

Известен случай, когда сервера CloudFlare легли из-за ошибки в обновлении, которое автоматически установилось на Debian. Было разбирательство, выплата компенсаций и т.д. С тех пор только manual. От себя рекомендую как полумеру создать виртуальную машину и все обновления проверять сначала на ней. Если после перезагрузки всё OK - обновляю продуктивы, пока всё работает.

[Максим Васильев]

@s1dney извините, но как сисадмин с опытом, не соглашусь.
То, что написано на пхп может сломаться вообще от штатного обновления настроек или изменения IP. Это целиком и полностью относится к врождённой криворукости пхпшников, но никак не к системам пакетов.
На питоне вон умудряются писать библиотеки, совместимые и с 3.x и 2.x версиями, несовместимыми по задумке.

[Максим Васильев]

@dunmaksim известен только один такой случай?

[s1dney]

@qmax Я же явно указал на то, что это ничего не меняет. Говнокод/не говнокод, кого это волнует? Обновления могут поломать продакшен - это факт, с чем вы не хотите соглашаться?

[Максим Васильев]

@s1dney если кривой код стоит на продакшене, значит для него не критично, что он время от времени ломается (от кучи разных причин), и авто обновления не добавят к этому принципиально много падучести.

[s1dney]

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

[Максим Дунаевский]

@qmax вспомнилась одна из новостей на каком-то IT-ресурсе, специального исследования не проводил

[Максим Васильев]

@s1dney для обеспечения работы сисадмин не ставит говнокод на продакшен. либо лезет в него руками и исправляет в любом случае.

[s1dney]

@qmax представил себе ситуацию - нет, это говнокод, ставить не буду, переписывайте
окей

[Максим Васильев]

@s1dney а по-вашему ситуация выделеть под каждый говнокод отдельный сервер, чтобы ничего не трогать и он мог срать вдоволь куданибуть в рут - лучше?

Answer 2

[tgz]

В cron ничего добавлять не надо, есть cron-apt.
security можно накатывать автоматически, остальное по желанию и задачам.