Николай Бараненко:
> Уязвимостей безопасности приклада
Уязвимость в приложении уже предполагает, что злоумышленник имеет те же права, что и приложение. Если приложение может читать свои данные в БД, то сделать это сможет и зломумышленник.
> Уязвимостей БД
Вам известны случаи в истории, когда данные сливались через уязвимости в БД, а не легитимным чтением данных с имеющейся учётки приложения?
В обоих случаях не имеет значения, где размещена БД. Если злоумышленник попал на сервер через приложение, то у него будет доступ к данным этого приложения независимо от того, где размещена БД - локально или отдельно.
Отличный способ эффективно утилизировать оба сервера.
Если совсем заморочиться и позволяют свободные ресурсы, можно на обоих сделать сайт отказоустойчивым.
Николай Бараненко: Не имеет значения, где обновляется БД - и там и там будет временной простой, пока инфраструктура не предполагает высокую доступность.
Не имеет значения, куда восстанавливать БД из бэкапа - на тот же сервер, или на выделенный.
> Ну и фактор управления безопасностью.
В чём разница с размещением на том же сервере?
Александр Черных: Даже средние проекты отлично живут с приложением+БД на борту, если правильно подобрать ресурсы в зависимости от потребления, чтобы оба умещались.
Александр Черных:
На малых проектах приложение не отнимает RAM у базы данных.
Мониторить можно любой сервер, любую службу, любой процесс, и не только Munin-ом, поэтому приобретать отдельный сервер под БД ради более простого мониторинга (при том, что на самом деле мониторить нужно приложение, а не ОС вокруг) расточительно.
automatik:
nginx запускается от имени www-data, поэтому всё, что сможет сделать взломщик веб-приложения (если допустить, что в нём есть дыра) - это погулять по папкам в пределах доступа www-data.
БД сливают не от её присутствия локально на сервере, а от имеющихся прав к данным.
Если БД-учётка сайта имеет чтение данных, не имеет значения, где размещён сервер - локально или на отдельном оборудовании. Чтение до этих данных всё равно есть, и взломщик их всё-равно прочитает.
Чтобы не допускать сливания данных вообще всех сайтов через один единственный, надо не физически разделять сервер БД, а логически отделять права доступа между учётками для сайтов, чтобы каждый сайт мог читать только свои таблицы.
По сути, aptitude - это оболочка для apt-get.
А apt-get - это облочка для dpkg.
apt-get создавался, как прослойка, которая будет управляться через что-то более высокоуровневое и юзерфрендное (aptitude, synaptic).
Но на практике, многие, всё-равно, по привычке/из удобства/из скорости пользуются apt-get. В конце-концов, в большинстве случаев все манипуляции сводятся к install/update/upgrade, что с apt-get и так делать несложно.
aptitude старается думать за Вас.
apt-get исходит из того, что Вы знаете, что делаете.
aptitude в некоторых ситуациях может лучше автоматически обработать конфликты, хотя ситуаций, где между aptitude и apt-get будет разница в поведении, очень мало. Поэтому некоторые считают, что "aptitude не нужен".
liks: Лишь отталкиваюсь от постановки задачи.
То, что начинающему Linuxоиду воспользоваться virt-manager будет проще, чем запускать виртуалки с терминала, я понимаю. =)
virt-manager, кстати, прекрасно работает по сети, даже если на сервере нет desktop-environment.
