Capistrano использует sudo даже с set: use_sudo, false

Я не хочу использовать sudo ни для одной из моих удаленно выполняемых команд через Capistrano. В частности, когда я запускаю cap deploy:setup, меня спрашивают пароль sudo во время первой mkdir команды. Я добавил set :use_sudo, false в свой файл deploy.rb, но это не имело значения.

Я начал с довольно полного файла deploy.rb, но сократил его, как только у меня начались проблемы. Вот моя минимальная версия, которая все еще показывает use_sudo несоблюдение:

# App Definitions

set :domain, '[server-ip]'
role :app, domain
role :web, domain
role :db, domain, :primary => true

set :user, "my_app"
set :use_sudo, false

task :sudo_test do
  run "#{try_sudo} whoami"
end

запуск cap sudo_test приводит к тому, что мне предлагается ввести пароль sudo. Что мне здесь не хватает (кроме волос, которые я уже вытащил)?

Выводы Google

https://groups.google.com/forum/?fromgroups#!topic/capistrano/QNYnvW8obrg < / а>

Тема с похожей проблемой. Никаких выводов / решений в ветке не отмечено.


sudo ruby-on-rails-3 capistrano rvm-capistrano
person YWCA Hello    schedule 25.05.2012    source источник
comment
что это за #{try_sudo} бит? а что если вынуть?   -  person sbeam    schedule 26.05.2012
comment
#{try_sudo} следует выполнить sudoize команду, если для :use_sudo установлено значение false. Я включил его в sudo_test, потому что задачи capistrano rails, вероятно, также используют его, и, вероятно, откуда возникла проблема.   -  person YWCA Hello    schedule 26.05.2012
comment
Мы используем sudo -i ‹cmd› в нашем файле deploy.rb.   -  person yeowzir    schedule 26.05.2012
comment
и это тоже: sudo 'aptitude install -y rsync'   -  person yeowzir    schedule 26.05.2012
comment
Как упоминалось выше, первоначальная причина сообщения заключается в том, что cap deploy:setup пытается использовать sudo, когда я этого не хочу. cap deploy:setup - это готовый рецепт; Я не собираюсь его модифицировать. Скорее мне нужно определить, почему опция :use_sudo не работает.   -  person YWCA Hello    schedule 27.05.2012
comment
Вы уверены, что он запрашивает пароль sudo, а не пароль SSH? Я попробовал вашу настройку, и она запрашивает мой пароль SSH.   -  person Jeroen Rosenberg    schedule 05.06.2012
comment
@JeroenRosenberg Вы видите это, потому что не настроили аутентификацию по ключу ssh. Моя связана с sudo.   -  person YWCA Hello    schedule 07.06.2012

Ответы (2)


arrow_upward
12
arrow_downward

Для всех, кто сталкивается с этой проблемой и такой же дурак, как я. Убедитесь, что вы не цитируете ложь. Я имел:

set :use_sudo, "false"

и когда я переключил его на

set :use_sudo, false

большинство вещей начало работать так, как я ожидал. Как указывает YWCA Hello, все еще есть команды, которые игнорируют параметр use_sudo. Однако не забудьте установить его правильно.

person Dan Green    schedule 08.03.2013
comment
В качестве объяснения (без чтения соответствующей части кода capistrano): false - истинное значение в рубине. Ложны только ноль и ложь. Любое другое значение, в т.ч. 0,, [], считаются истинными. Таким образом, установка: use_sudo на false аналогична установке: use_sudo на true. - person Pascal; 22.04.2014

arrow_upward
5
arrow_downward

По-видимому, невозможно отключить функциональность sudo с некоторыми задачами capistrano. Предполагается, что непривилегированный пользователь на сервере не должен иметь возможность выполнять определенные задачи.

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

Вот ссылка на ответ на мой первоначальный вопрос:

https://github.com/capistrano/capistrano/issues/211#issuecomment-7667467

person YWCA Hello    schedule 13.08.2012
comment
: use_sudo, false работал у меня с mkdir (с использованием deploy: setup) - person vish; 09.07.2013