У меня есть сервер CentOS 6, который находится в производстве и на самом деле размещает несколько сайтов. Теперь мне нужно установить Redmine, работающий на Ruby. Репозиторий remi / ephel дает мне Ruby 1.8.7, но я хотел бы использовать самую последнюю версию (1.9). Проблема в том, что я должен скомпилировать и установить его сам, загрузив исходники и все другие dev-пакеты, необходимые для работы гемов, например mysql-devel для адаптера mysql2. Плохая практика - устанавливать dev-пакеты на производственную машину? Можно ли поставить под угрозу безопасность? Должен ли я придерживаться пакетов по умолчанию, предоставляемых репозиториями?
Лучше бы остаться в системе управления пакетами от вендора.
Тем не менее, если вам требуется более свежая версия программного обеспечения, по крайней мере, попробуйте использовать пакеты вместо установки через make; make build.
Для Ruby 1.9.3 кто-то создал файл спецификации:
https://github.com/imeyer/ruby-1.9.3-rpm
Вы должны иметь возможность использовать это для создания RPM для Ruby 1.9.3 и устанавливать таким образом. По крайней мере, это упростит обновление (т. Е. rpm -Uhv ruby-1.9.3 вместо того make; make install). Вы по-прежнему будете нести ответственность за создание новых пакетов Ruby 1.9 для себя по мере выхода обновлений, конечно.
В общем, существует иерархия предпочтений для установки программного обеспечения.
Программное обеспечение предоставлено репозиториями поставщика. В этом случае вы будете использовать удобную и удобную систему управления для установки и обновления пакетов, поддерживаемых поставщиком (например, yum, apt-get).
Программное обеспечение, предоставляемое через сторонние репозитории. Здесь должна быть мини-иерархия, где у вас есть репозитории с хорошей репутацией (например, EPEL для CentOS), до репозиториев с меньшей репутацией (например, PPA какого-то парня на Ubuntu; я не говорю, что люди пытаются установить трояны через PPA, более того, это обычно что-то, предоставляемое кем-то, кто может не поддерживать пакеты или не искать проблемы совместимости).
Программное обеспечение, устанавливаемое с помощью пакетов, которые вы создаете самостоятельно. Это то место, где упадет файл спецификации, упомянутый ранее. Вы обернете процесс сборки в систему пакетов вашего дистрибутива, чтобы упростить установку и обновление (например, rpm -eвместо того, чтобы искать файлы с загадочными именами через / usr / local). Вы возьмете на себя ответственность за создание новых пакетов по мере появления обновлений.
Программное обеспечение устанавливается без управления пакетами. Это классика wget software.tgz ; tar xzvf software.tgz ; cd software ; ./configure ; make ; make install. Как правило, вы будете разбрасывать файлы по всему / usr / local; может быть трудно получить информацию о программном обеспечении (т.е. вы можете просто запустить rpm -q или rpm -ql), и удалить его будет сложно. Это должно быть крайней мерой.
Я думаю, что где-то около 3-х rvm метод, упомянутый Алексом. На самом деле этого нет в системных пакетах, но есть среда, окружающая установку Ruby. В Ruby в контексте RVM драгоценные камни, связанные с этим конкретным Ruby, будут установлены через gem install и управляется также в определенной структуре, хотя и не в системе управления пакетами ОС.
Если у вас нет требования использовать более позднюю версию, то использование «официальной» версии обычно считается «хорошим делом». Исправления безопасности переносятся в официальные пакеты, и вы можете воспользоваться обновлением диспетчера пакетов и разрешением зависимостей.
Как только вы выйдете за рамки вышеперечисленного, все может стать довольно грязным.
Это вопрос личного мнения, однако я никогда не устанавливаю пакеты напрямую из исходного кода на производственную машину. Это значительно усложняет применение обновлений безопасности в будущем. Я параноик в отношении потенциального компромисса в будущем.
Я склоняюсь к тому, чтобы по возможности использовать встроенные пакеты и при необходимости отслеживать дополнительные RPM из внешних источников. Если я не могу найти нужную мне версию, я сам встраиваю пакет в RPM на устройстве разработчика и развертываю этот новый RPM в производственной среде. Не элегантно, но функционально.
Я всегда использую RVM для создания и управления средами Ruby, RVM кажется предпочтительным способом установки Ruby для многих Rubyists. Пакеты, предоставляемые разработчиками Debian и CentOS, просто не соответствуют скорости. Кроме того, RVM может создавать изолированные виртуальные среды, подобные Python virtualenv.