Запуск супервизора с правами root или нет?

Supervisor работает на версии 3.0:

pip freeze | grep supervisor
supervisor==3.0

При запуске supervisord из командной строки:

sudo $VIRTENV/supervisord --nodaemon --configuration $PATH_TO_CONFIG/supervisord.conf

Я получаю эту ошибку:

2013-11-11 23:30:50,205 CRIT Supervisor running as root (no user in config file)

Но я не могу запустить supervisord без sudo, он жалуется:

Error: Cannot open an HTTP server: socket.error reported errno.EACCES (13)

Как правильно с этим бороться?

(Я получаю ту же ошибку, если запускаю его как root, но устанавливаю user = foobar в разделе [supervisord] в supervisord.conf)

Обновление: вот мой supervisord.conf

[unix_http_server]
file = /opt/run/supervisord.sock

[inet_http_server]
port = 9001
username = foobar
password = foobar

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisord]
logfile = /opt/logs/supervisord.log
loglevel = debug
pidfile = /opt/run/supervisord.pid

[supervisorctl]

[program:foo1]
user = foobar
autostart = True
autorestart = True
command = foo1
stdout_logfile = /opt/logs/foo1.stdout.log
stderr_logfile = /opt/logs/foo1.stderr.log
stdout_logfile_maxbytes = 10MB
stderr_logfile_maxbytes = 10MB

[program:foo2]
user = foobar
autostart = true
autorestart = true
command = foo2
priority = 100
stdout_logfile_backups = 0
stderr_logfile_backups = 0
stdout_logfile_maxbytes = 10MB
stderr_logfile_maxbytes = 10MB
stdout_logfile = /opt/logs/foo2.stdout.log
stderr_logfile = /opt/logs/foo2.stderr.log

python supervisord startup
person kev    schedule 11.11.2013    source источник
comment
Вы уверены, что хотите запустить еще одну копию демона supervisord вместо запуска supervisorctl или что-то в этом роде? Что именно вы пытаетесь сделать здесь?   -  person abarnert    schedule 12.11.2013
comment
Я не пытаюсь запустить несколько копий супервизора, только одну. Как я уже писал, я в замешательстве. Запуск супервизора с правами root дает мне CRIT, но я не могу запустить его с правами root.   -  person kev    schedule 12.11.2013
comment
Это работает, когда вы удаляете раздел [inet_http_server]?   -  person pors    schedule 19.02.2014
comment
Мне интересно то же самое. В документе нет ясности по этому поводу, и, увидев ошибку CRIT, я также задаюсь вопросом, не лучше ли запустить супервизора с пользователем-супервизором, созданным для этой цели. Что ты в итоге сделал? Спасибо.   -  person Michael    schedule 09.10.2014
comment
TL;DR установить user=root в supervisord.conf. (Объяснение)   -  person Kyan    schedule 30.11.2017

Ответы (5)


arrow_upward
27
arrow_downward

Supervisord переключается на учетную запись пользователя UNIX перед любой обработкой.

Вам нужно указать, какую учетную запись пользователя он должен использовать, запустить демон от имени пользователя root, но указать пользователя в файле конфигурации.

Пример:

[program:myprogram]
command=gunicorn --worker-class socketio.sgunicorn.GeventSocketIOWorker app.wsgi:application -b 127.0.0.1:8000
directory=/opt/myprogram
user=user1
autostart=true
autorestart=true
redirect_stderr=True

Посетите http://supervisord.org/configuration.html#program-x-section-values для получения дополнительной информации

person Jan Vorcak    schedule 11.11.2013
comment
Я делаю это сейчас, но он все еще говорит, что CRIT Supervisor работает от имени пользователя root (нет пользователя в файле конфигурации) при запуске supervisord. - person kev; 12.11.2013
comment
@ user1252307: Вы действительно указали пользователя в файле конфигурации, как в примере с java? Потому что сообщение об ошибке, кажется, говорит, что вы этого не сделали. (Может быть, вы поместили его не в тот раздел или сделали глупую опечатку?) - person abarnert; 12.11.2013
comment
Я только что дважды проверил конфиг выше (я заменил имена программ) - person kev; 12.11.2013

arrow_upward
14
arrow_downward

Когда вы запускаете супервизор как root, вам нужно указать пользователя, к которому супервизор должен перейти из соображений безопасности.

Из документов руководителя (http://supervisord.org/configuration.html):

user
If supervisord is run as the root user, switch users to this UNIX user account before doing any meaningful processing. 
This value has no effect if supervisord is not run as root.

Поместите это в свой файл conf:

[supervisord]
user=nobody

Пользователь должен быть пользователем, который существует, но не имеет разрешений sudo (никто не может работать).

person Rylan    schedule 26.02.2014
comment
Это помешало супервизору сохранить в файл журнала, для которого требовались разрешения корневого уровня. - person nu everest; 26.05.2014
comment
В качестве альтернативы вы можете использовать logfile=/path/to/logfile, чтобы указать каталог для сохранения файла журнала и убедиться, что пользователь, к которому вы переходите, имеет разрешение на запись в этот каталог. Вам также не нужно обращаться к никому, вы можете перейти к ubuntu или аналогичному пользователю. - person Rylan; 27.05.2014
comment
Вы можете изменить разрешение для каталога журнала, и оно останется. Но сценарий init.d продолжает перезаписывать владельца /var/run/supervisord на root, из-за чего supervisord не запускается при запуске из сценария init.d (по крайней мере, в OpenSUSE). - person Artem Russakovskii; 14.09.2017
comment
А, /usr/lib/tmpfiles.d/supervisord.conf отвечает за создание каталога. Меняем там пользователя с root на none. D /run/supervisord 0700 nobody nobody - person Artem Russakovskii; 14.09.2017
comment
Привет, Рилан, можешь объяснить, почему у пользователя не должно быть разрешений sudo? Я установил user=nobody, а затем получил ошибку, например, супервизор: не удалось установить значение 0: невозможно отказаться от привилегий как пользователя без полномочий root. - person Jialin Zou; 02.07.2018
comment
Привет @JialinZou, вы бы предпочли, чтобы у пользователя не было разрешений sudo, потому что это уменьшает вашу поверхность атаки. Если супервизор работает от имени пользователя root, злоумышленник может захватить вашу систему, если супервизор скомпрометирован. Возможно, этого никогда не произойдет, но эмпирическое правило для систем UNIX состоит в том, чтобы по возможности избегать запуска чего-либо от имени пользователя root именно по этой причине. Ошибка, которую вы видите, связана с тем, что вы не запускаете супервизора с правами root (используя sudo). Если вы не запускаете супервизор как root, вам не нужна строка user=nobody и ее следует удалить. - person Rylan; 10.07.2018

arrow_upward
12
arrow_downward

Что касается меня, я получил эту ошибку при работе от имени пользователя без полномочий root:

Error: Cannot open an HTTP server: socket.error reported errno.EACCES (13)

Это исчезло после того, как я выбрал каталог, содержащий файл sock для этого пользователя.

В твоем случае:

[unix_http_server]
file = /opt/run/supervisord.sock

Либо chown username /opt/run/, либо укажите файл в другой каталог, принадлежащий пользователю.

Я узнал об этом подходе по этой ссылке.

Кроме того, мои системные администраторы установили сценарий init.d, который я написал. Сценарий init.d запускается от имени пользователя root, но сценарий может запустить supervisord на myuser с помощью этой команды:

SUPERVISORD=/path/to/supervisord
PIDFILE=/path/to/supervisord.pid
OPTIONS='-c /path/to/supervisord.conf'
daemon --pidfile=$PIDFILE --user=myuser $SUPERVISORD $OPTIONS
person Matthew Moisen    schedule 20.01.2016

arrow_upward
12
arrow_downward

Ты получил:

Насколько я понимаю, вы получили это сообщение CRIT, которое вас беспокоит:

CRIT Supervisor работает от имени пользователя root (в файле конфигурации нет пользователя)

Слова в скобках - подсказка. Это сообщение указывает на то, что вы, возможно, непреднамеренно запускаете Supervisor от имени пользователя root.

Сделай это:

Итак, решение довольно простое: сообщите супервизору, что вы делаете это намеренно.
(in /etc/supervisor/supervisord.conf)

[supervisord]
user = root

Когда вы запускаете Supervisord от имени root, он устанавливает uid для назначенного вами пользователя, то есть root. (#308)

Не важно:

Хотя теперь вы можете получить это сообщение:

CRIT Установите uid для пользователя 0

Не беспокойтесь, это сообщение должно быть уровня INFO, а не уровня CRIT. (#693)

person Kyan    schedule 30.11.2017

arrow_upward
0
arrow_downward

Моя среда:

Усадьба+ларавель ubuntu18 LTS

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

1. Запуск супервизора должен использовать root

пример:

vagrant@homestead:~$ sudo supervisord -c /etc/supervisord.conf
vagrant@homestead:~$ ps -aux|grep supervisord
root     12145  0.0  0.8  71144 16744 ?        Ss   07:20   0:00 /usr/bin/python /usr/bin/supervisord -c /etc/supervisord.conf

вы можете убить всю обработку супервизора и перезапустить

2. Старайтесь не использовать задание root run.

Конфигурация моей работы /etc/supervisor/conf.d/lara*.conf, пользователь бродяга

конфигурация моей работы

chown файл журнала в vagrant, связанный с файлом supervisor.conf

конфигурация моего руководителя

потом

запустить supervisorctl status использовать vagrant

выполнение задания

person zzr    schedule 10.09.2020