Capistrano, пользователь Unix, разрешения

Question

Я не очень понимаю, какая модель учетных записей / разрешений Unix предназначена для Capistrano.

Допустим, у меня есть приложение для рельсов под названием Widget, и я буду развертывать его вместе с пассажиром.В общем, до-capistrano, я хочу, чтобы весь каталог ./widget принадлежал пользователю с именем 'widget'.И тогда по умолчанию пассажир по умолчанию запускает процесс приложения как пользовательский «виджет», потому что пассажир запускается как пользователь, которому принадлежит файл.

И весь смысл в том, что учетная запись «виджета» имеет довольно ограниченные разрешения, верно?Поскольку веб-приложение будет работать под этой учетной записью?

Поэтому, поскольку я хочу, чтобы файлы принадлежали «виджету», я говорю cap

set: user, "widget"

Но теперь, когда я запускаю «cap deploy: setup», он хочет «sudo» из этой учетной записи.Ни при каких обстоятельствах учетная запись «виджета» не получает привилегий sudo, весь смысл заключается в том, чтобы держать эту учетную запись ограниченной привилегии.

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

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

Используйте одну учетную запись Unix для установки, но затем есть кепка, как-то "прикованная" к чему-то другому?Использовать одну учетную запись Unix, но сделать что-то не-cap (puppet?) Достаточно для настройки, чтобы учетной записи не требовалось sudo для начала работы?Какие?Чего мне не хватает?

Answer 1

Вы можете избежать головной боли, используя Passenger чаще всего с Nginx в качестве веб-сервера.

Затем для перезапуска веб-служб непривилегированный пользователь Widget создает файл по своему пути, и Passenger автоматически перезапускает Nginx, когда обнаруживает, что этот файл присутствует.

Это включается через следующее в вашем config / deploy.rb:

пространство имен: deploy do задача: начать делать; конец задача: перестать делать; конец задача: перезапустить,: role =>: приложение,: кроме => {: no_release => true} сделать запустите "touch # {File.join (current_path, 'tmp', 'restart.txt')}" конец конец

Что касается других привилегированных задач для администрирования MySQL / DB, ваш database.yml предоставляет учетные данные, необходимые для обработки задач миграции рейка.

Так что на самом деле единственный раз, когда вам понадобится что-то более привилегированное, будет установка всей системы обновлений gems, ruby ​​или rails, но многое зависит от того, как была настроена / установлена ​​ваша производственная среда.

С учетом Passenger + Nginx и отдельных учетных данных для БД вы можете отключить sudo и посмотреть, не возникнут ли какие-либо ошибки во время процесса развертывания Capistrano, а затем получить их оттуда.