Как грамотно настроить автоматические обновления на боевом 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), которые тоже необходимо "настроить и забыть". 

 1. По опыту скажу что на production-серверах обновление *лучше делать вручную*, если нету зеркального сервера для тестов. Периодичность обновления советую раз в 15-20 дней. Разумеется, в случае экстренных проблем с безопасностью типа heartbleed, как ты упомянул, обновлять надо сразу, при выпуске заплаток.   

2. Если не осиливаешь пока chef и puppet почитай про [**Ansible**](http://habrahabr.ru/search/?target_type=posts&q=Ansible&order_by=relevance). У него порог вхождения существенно ниже чем у вышеупомянутых и поддерживать его в дальнейшем намного проще, а по функционалу, если честно, он не уступает.   

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](http://www.opennet.ru/docs/RUS/iptables/). А дальше ищи в интернете iptables tips, примеры настройки iptables и вникай что там делают и для чего. Но не перемудри. Понимай что пакеты пробегают по всем цепочкам правил. Это нагрузно. Задумайся об использовании ipset.   

Всякие fail2ban-ы советовать не буду. Слишком спорно и не нужно если ты правильно отстроишь любой сервис работающий поверх netfilter. Так же многие хостинги из коробки имеют защиту от DDOS и брута на уровне своего железа типа ASA-к и тд.   

Периодически делай срезы tcpdump-ом (особенно в подозрительных ситуациях) и анализируй wireshark-ом.
10. Постоянные бэкапы, хоть rsync, fsbackup, unison, bacula и тд - выбор большой

  
  

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

Подключай мониторинг.   
  

Для этого могу посоветовать 4 системы (это лично мои приоритеты, но их [оочень много](http://toster.ru/answer?answer_id=308173#answers_list)).   
**Zabbix, Nagios, Sensu, Cacti**  
  

Хорошим вариантом будет установка zabbix\_agent-а не сервер и удаленный мониторинг с другого сервера. Настроишь свои скрипты + анализ логов syslog и вот уже залог достаточно устойчивой и на мой взгляд хорошо защищенной системы. 

 С никсами .. только для себя работаю. Сервисы под ними не держу. Но тебе в любом случае поможет пару советов.  

0. Своевременность  

1. Тестовая машина  

2. Временной фактор   

3. Единообразие  

4. Квалификация  
  

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

примечание ... иногда легче мигрировать сервером на другую виртуалку чем подбирать сопли на старой. 

 Автоматическое обновление наверное никак.  
  

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

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

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