Capistrano + thin + nginx с пользователем не разрешено sudo howto? - PullRequest
2 голосов
/ 01 октября 2008

У меня есть такой сценарий, который я хочу использовать capistrano для развертывания моего приложения ruby ​​on rails:

  1. Веб-приложение находится на тонком кластере с файлом конфигурации, хранящимся в / etc / thin. также скрипт инициализации находится в /etc/init.d/thin, поэтому он запускается автоматически всякий раз, когда мой сервер нуждается в перезагрузке
  2. Также nginx выполняется так же (как демон сценариев инициализации)
  3. Чтобы убедиться, что если кто-то взломал мой веб-сервер, я не хочу, чтобы он делал что-то слишком ужасное, поэтому веб-пользователю не разрешено sudo.
  4. Thin и nginx работают как веб-пользователь для обеспечения такой безопасности

Теперь, когда мне нужно выполнить развертывание, мне нужно, чтобы файлы были установлены в / home / webuser / railsapps / helloworld, и мне нужен сценарий cap, который перезапускает мой тонкий файл. Я хочу, чтобы все файлы принадлежали веб-пользователю, поэтому основной пользователь скрипта cap работает как веб-пользователь. Теперь проблема возникает, когда я хочу перезапустить тонкий демон, потому что webuser не может sudo.

Я думаю, возможно ли вызвать два отдельных сеанса - веб-пользователь для развертывания файла, а затем специальный sudoer для перезапуска демона. Может ли кто-нибудь дать мне пример сценария по этому вопросу?

Ответы [ 5 ]

4 голосов
/ 01 октября 2008

Возможно, это не то, что вам нужно, но вы можете сделать что-то подобное в файле sudoers:

someuser ALL=NOPASSWD: /etc/init.d/apache2

, что позволяет пользователю запускать /etc/init.d/apache2

Если вы попытаетесь сделать что-то еще:

$ sudo ls
[sudo] password for someuser: 
Sorry, user someuser is not allowed to execute '/bin/ls' as root on ...
1 голос
/ 12 октября 2008

почему бы не использовать sudo для процедуры развертывания, а затем выбрать команду -R в RAILS_ROOT? Вы можете попросить Capistrano сменить владельца до наложения псевдонима на текущий.

0 голосов
/ 17 июня 2011

Только что заметил, что вы не позволяете пользователю sudo :-) Ну, этот ответ поможет другим:

Немного опоздал на вечеринку, но я только что сделал это:

namespace :deploy do
  desc "Start the Thin processes"
    task :start do
      run "cd #{current_path} && bundle exec sudo thin start -C /etc/thin/dankit.yml"
    end

    desc "Stop the Thin processes"
    task :stop do
      run "cd #{current_path} && bundle exec sudo thin stop -C /etc/thin/dankit.yml"
    end

    desc "Restart the Thin processes"
    task :restart do
      run "cd #{current_path} && bundle exec sudo thin restart -C /etc/thin/dankit.yml"
    end

end

Добавление sudo к bundle exec sudo thin start works.

0 голосов
/ 19 июля 2009

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

Единственный раз, когда вы отклеитесь, это когда вам придется редактировать содержимое / etc / thin. Предполагая, что вы используете псевдонимы для битов thin.yml вашего веб-пользователя, это произойдет только тогда, когда вы захотите добавить / удалить программу. Когда это происходит, возможно, стоит просто добавить / удалить псевдоним вручную.

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

0 голосов
/ 04 октября 2008

Альтернативой этому будет запуск nginx от имени обычного пользователя, скажем, на порту 8080, а затем использование IPTables для перенаправления запросов с порта 80 на порт 8080 из памяти

iptables -A PREROUTING -t tcp -m tcp -p 80 -j DNAT --dport 8080

Отправит все пакеты, предназначенные для порта 80, на порт 8080, который может быть связан как обычный пользователь.

...