Семён Воронов

1. Upstart, (хоть и переходят на systemd, но пока upstart)
2. AppArmor (Дополнительная логика безопасности, иногда приводящая к не предсказуемым результатам так же как и SELinux)
3. По достаточно большому опыту менее стабильна и более непредсказуема чем Debian
4. Изменение расположения многих каталогов и конфигурационных файлов без необходимости
5. Наплевательское отношение на многие идеологии и стандарты
6. Много лишней логики и сомнительного функционала. Достаточно поставить логирование системных вызовов и ужаснуться от того, что без вашего ведома в Ubuntu происходит.

В целом заслуживает такое же место для существования как и другие дистрибутивы, правда вклад не такой большой как у RH в сообщество. Шатволд тянет одеяло на себя, RH на себя и по тому что сейчас происходит становится ясно что невидимый бой проигран. Systemd, разрабатываемая RH с Поттерингом воцарит на большинстве популуярных дистрибутивов линукс. (Debian, CentOS, Suse, Fedora, ArchLinux... и от них образованные). Другая часть дистрибутивов уже имеет плотную поддержку systemd (Gentoo к примеру). А если немного озадачиться и посмотреть что из себя сейчас представляет systemd и какие планы интеграции у них в дальнейшем - становится все на свои места, кто тут главный :) Дебиан перелезает на systemd, Шатволду ничего не осталось как развести руками и объявить что и убунта будет полностью менять свою систему инициализации на systemd.

Что в virtualenv сложного? Так же устанавливаешь virtualenv на сервер той версии какой нужен python. Дальше все очень тривиально и просто.

# Убедись что он 2ой версии
apt-cache show python-virtualenv
# Устанавливаешь virtualenv  
apt-get install python-virtualenv  
# Создаешь новый проект, установленные в системы либы не тянешь
virtualenv --no-site-packages project
# Активируешь виртуальное окружение
# Все. Теперь команда pip будет устанавливать все пакеты в твое окружение а не системное
. ./project/bin/activate
# Устанавливаешь Django   
pip install django

Если же по каким то причинам не хочешь виртуального окружения, то поставь версию pip-а в систему под питон нужный тебе:

$ apt-cache search virtualenv
python-pip - alternative Python package installer
python3-pip - alternative Python package installer - Python 3 version of the package

И обращаться к нему уже будешь pip, pip3

Как дополнение: в Debian и Ubuntu есть механизм выбора приоритетов. Все что он делает - переключает ссылку на нужные версии софта.
Делается это по средством команды update-alternatives

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 и вот уже залог достаточно устойчивой и на мой взгляд хорошо защищенной системы.