Назад | Перейти на главную страницу

Последствия установки исходного кода в «нестандартный» каталог

Я сам компилирую и устанавливаю множество программ из исходников. Поскольку у меня есть рабочая установка apache + PHP, но я хотел бы попробовать Nginx + PHP-FPM, я хотел бы установить их в нестандартных местах, таких как / nginx и / php-fpm

Помимо исполняемых файлов, не находящихся в PATH (но это можно решить), какие еще проблемы или последствия могут быть?

Основные недостатки ручной компиляции в пользовательские места можно разделить на те, которые возникают в результате ручной компиляции, и те, которые возникают при хранении в пользовательских местах.

Среди недостатков ручной компиляции я считаю:

  1. Это кошмар обслуживания, так как вам постоянно приходится перекомпилировать из исходников, когда выпускается обновление безопасности;
  2. Это кошмар двойного обслуживания, так как вам нужно постоянно следить за форумами, списками рассылки, веб-сайтами и (в наши дни) IRC-каналами для каждой части программного обеспечения, которое вы скомпилировали, чтобы вы могли узнавать об обновлениях по мере их выпуска и выносить суждение по каждому из них, когда вы о нем узнаете, нужно ли вам это конкретное обновление;
  3. Это кошмар стабильности. RH (и другие поставщики дистрибутивов серверного класса) придерживаются политики не увеличивать количество версий внутри стабильной основной версии ОС. Вместо этого они переносят только необходимые исправления (в основном, безопасности, но не всегда) в выпущенную версию, так что вы не будете постоянно бороться со старыми файлами конфигурации, которые становятся синтаксически недействительными, хранящимися базами данных, требующими применения исправлений схемы, и так далее, с каждым новый выпуск, который вы решили взять на вооружение.

Среди недостатков нестандартных локаций я считаю:

  1. Это усложняет обслуживание системы, поскольку любой новый администратор должен сначала раскрыть лабиринт, в котором находится текущее системное программное обеспечение;
  2. Это увеличивает вероятность того, что некоторые из них не смогут получить резервную копию (вам необходимо постоянно обновлять свои политики, чтобы включать новые каталоги);
  3. Если вы не будете осторожны со своим ./configures, он оставляет файлы конфигурации разбросанными по всей FS (например, /nginx/etc/nginx.conf, /php-fm/etc/php-fm.ini) вместо того, чтобы все они были централизованы в /etc. Это может затруднить управление изменениями.

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