Как грамотно настроить автоматические обновления на боевом Ubuntu Server?

Уже пару лет являюсь обладателем и админом (начинающим) нескольких боевых веб-серверов под управлением debian и ubuntu. Крутятся на них обычные вещи вроде nginx, apache, unicorn, mysql, postgresql.
До chef/puppet я еще не дорос, поэтому все делаю ручками по ssh. Проблема в том, что каждый раз, когда я пишу aptitude update, я вижу какую-то нереальную цифру с количеством предлагаемых к обновлению пакетов и каждый раз не знаю что с этим делать.
С одной стороны, страшно делать upgrade, потому что что-то где-то может сломаться из-за обновления пакета до новой major версии. Еще ситуация осложняется тем, что среди серверов есть VPSки, где нельзя обновлять ядро, потому что оно собрано хостером с модулем xen.
С другой же стороны, в голове сидит паранойя, что в любом из тех же apache, ssh или mysql в любой момент может вылезти что-то страшное, наподобие недавнего heartbleed.

Собственно, вопрос к знатокам: как правильно обновлять пакеты на debian-based сервере, чтобы ничего не ломалось?
А еще лучше так: как правильно настроить автоматические обновления на debian-based сервере, чтобы об этом можно было спокойно забыть до выхода следующей LTSки?

P.S. До кучи, приветствуются рекомендации и ссылки по настройке прочих вещей на сервере (например iptables), которые тоже необходимо "настроить и забыть".
  • Вопрос задан
  • 8463 просмотра
Решения вопроса 1
1. По опыту скажу что на production-серверах обновление лучше делать вручную, если нету зеркального сервера для тестов. Периодичность обновления советую раз в 15-20 дней. Разумеется, в случае экстренных проблем с безопасностью типа heartbleed, как ты упомянул, обновлять надо сразу, при выпуске заплаток.
2. Если не осиливаешь пока chef и puppet почитай про Ansible. У него порог вхождения существенно ниже чем у вышеупомянутых и поддерживать его в дальнейшем намного проще, а по функционалу, если честно, он не уступает.
3. Общие советы.
  1. Отключи не используемые службы (rpcbind, nfscommon) к примеру
  2. Заблокируй не используемых пользователей, проверь не имеют ли системные пользователи паролей (в /etc/shadow наличие хеша во втором поле, если имеют а доступ им не нужен ставь '!')
  3. Желательно включить ssh авторизацию только по ключам, включить опцию AllowUsers со списком пользователей которым авторизироваться разрешено. Отключить авторизацию по ssh root и создать системного пользователя с оболочкой sh, без всяких привилегий. Его занести в AllowUsers, при логине выполнять /bin/su - с полным путем.
  4. По возможности все используемые службы контролировать TCP Wrappers (/etc/hosts.{allow,deny})
  5. Установить библиотеку snoopy (snoopy logger) - очень подробное логирование запускаемых процессов.
  6. Соответственно настроить rsyslog/syslog-ng и перенаправлять логи желательно на сторонний сервер. Для логов есть различные веб-морды с различными отчетами и сортировками.
  7. Для контроля версий конфигурационных файлов советую использовать git в /etc либо выносить под различные службы в отдельные репозитарии и, конечно, настроить правильно .gitignore. Тут же присмотрись к подсистеме событий файловой системе inotify и отличному демону incron. Он пригодиться может не только в этом пункте, с ним можно много интересных вещей контролировать.
  8. По возможности настраивай все службы и сервисы в chroot окружении.
  9. Iptables. Можно на нем, а можно к примеру на ipset настраивать правила. Тут все просто. Лучше сначала создай скрипт на тестовой машине. Политики по умолчанию - deny all, а дальше разрешаешь что нужно. Конкретно что то посоветовать не имеет смысла если ты как обезьянка начнешь копировать без понимания. Есть отличная литература по iptables. А дальше ищи в интернете iptables tips, примеры настройки iptables и вникай что там делают и для чего. Но не перемудри. Понимай что пакеты пробегают по всем цепочкам правил. Это нагрузно. Задумайся об использовании ipset.
    Всякие fail2ban-ы советовать не буду. Слишком спорно и не нужно если ты правильно отстроишь любой сервис работающий поверх netfilter. Так же многие хостинги из коробки имеют защиту от DDOS и брута на уровне своего железа типа ASA-к и тд.
    Периодически делай срезы tcpdump-ом (особенно в подозрительных ситуациях) и анализируй wireshark-ом.
  10. Постоянные бэкапы, хоть rsync, fsbackup, unison, bacula и тд - выбор большой


Вообще это далеко не все, но "настроить и забыть" на production-сервере плохая идея.
Подключай мониторинг.

Для этого могу посоветовать 4 системы (это лично мои приоритеты, но их оочень много).
Zabbix, Nagios, Sensu, Cacti

Хорошим вариантом будет установка zabbix_agent-а не сервер и удаленный мониторинг с другого сервера. Настроишь свои скрипты + анализ логов syslog и вот уже залог достаточно устойчивой и на мой взгляд хорошо защищенной системы.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
edinorog
@edinorog
Троллей не кормить!
С никсами .. только для себя работаю. Сервисы под ними не держу. Но тебе в любом случае поможет пару советов.
0. Своевременность
1. Тестовая машина
2. Временной фактор
3. Единообразие
4. Квалификация

Любые телодвижения начинаются с первого пункта. Желательно копии работающей машины. После обновления машина остается работать и наблюдаешь за ее самочувствием. Если всё прошло норм ... накатывает обновления на все!!! машины. Не нужно мудрить что-то. Иначе потом заипешься. Ну и последний этап. Всегда что-то вылезет! Тут уже приходится городить костыли или работать на живую. Чтоб исправить что-то что ты не планировал. И ВСЁ ЭТО НУЖНО ДЕЛАТЬ СВОЕВРЕМЕННО!!! А не ждать до последнего.

примечание ... иногда легче мигрировать сервером на другую виртуалку чем подбирать сопли на старой.
Ответ написан
merryjane
@merryjane
Системный администратор
Автоматическое обновление наверное никак.

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

Теперь посмотрим на реальный мир. При наличие кучи серверов на которых крутятся разные проекты - это все из области фантастики. Так как разные проекты - это разный код. В одном проекте используются одни вещи, в другом другие. При смене мажорной версии может что-нибудь оказаться deprecated и не запуститься при рестарте сервиса, если вообще Ваш проект работает с новой версией. Также надо отказаться от пакетов уставленных через make install\checkinstall на самом сервере.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы