Supervisor: Erreur de permission refusée lors de l'utilisation de superviseurctl

+1

J'ai également ce problème sur Ubuntu 12.04 lors de l'installation du superviseur 3.0a8-1.1 via le gestionnaire de packages système. Je crée un programme simple comme dans le tutoriel : http://supervisord.org/running.html#adding -a-program

J'ai chown'ed le propriétaire de /tmp/supervisor.sock et j'ai résolu ce problème.

dans votre superviseur.conf, vous pouvez faire quelque chose comme ce qui suit

il suffit de le rendre accessible en écriture à tous

[unix_http_server]
file=/tmp/supervisor.sock   ; (the path to the socket file)
chmod=0766                 ; socket file mode (default 0700)

controll qui possède réellement le fichier

[unix_http_server]
file=/tmp/supervisor.sock   ; (the path to the socket file)
chmod=0760                 ; socket file mode (default 0700)
chown=myuser:group       ; socket file uid:gid owner

ce dernier ne suis pas sûr car je n'ai pas testé et je ne comprends pas complètement le comportement ici. Je m'en fiche aussi parce que ça n'a pas l'air très sûr :

[unix_http_server]
file=/tmp/supervisor.sock   ; (the path to the socket file)
chmod=0700                ; socket file mode (default 0700)
username=root              ; (default is no username (open server))
password=yourrootpassword               ; (default is no password (open server))

Je n'ai eu ce problème que si je n'étais pas connecté en tant que root. Donc, un sudo superviseur normal résoudrait le problème

Sommes-nous censés utiliser supervisorctl avec sudo ?

rencontrez-le aussi!

Alors que beaucoup de nos lecteurs s'en sortiront en exécutant à nouveau la commande avec sudo et en réussissant, il existe un meilleur moyen! L'erreur d'autorisation provient des autorisations d'accès au fichier socket de superviseur, qui par défaut appartient à root et n'est pas accessible en écriture par d'autres utilisateurs. Nous pouvons faire en sorte que le superviseur chown et chmod le fichier à un utilisateur ou à un groupe particulier au démarrage, en accordant à l'utilisateur ou au groupe l'autorisation d'arrêter et de démarrer les services que nous avons configurés sans nécessiter sudo.

Créons un groupe, ajoutons-nous à celui-ci en procédant comme suit

superviseur groupadd
usermod -a -G superviseur

Après vous être déconnecté/connecté (afin que la nouvelle appartenance au groupe prenne effet), modifiez le fichier de configuration supervisé (/etc/supervisor/supervisor.conf) pour que la section unix_http_server se présente comme suit

[unix_http_server]
file=/var/run/supervisor.sock ; (le chemin du fichier socket)
chmod=0770 ; mode de fichier socket (par défaut 0700)
chown= root:superviseur

Notez que nous avons chmod le fichier en 0770 (inscriptible par le propriétaire et le groupe) et chiffré le fichier en root:supervisor , ce qui permettra aux membres du groupe de superviseurs d'appeler superviseurctl. Il faut redémarrer le superviseur une dernière fois

superviseurctl recharger

ou

redémarrage du superviseur de service sudo

RÉF :

https://bixly.com/blog/supervisord-or-how-i-learned-to-stop-worrying-and-um-use-supervisord/

^ Fonctionne à merveille !

N'oubliez pas d'ajouter votre nom d'utilisateur à la commande usermod, cependant.

usermod -a <your-username> -G supervisor

Pour les personnes comme moi qui débutent sur Linux, vous pouvez obtenir votre nom d'utilisateur actuel avec whoami

^ Fonctionne à merveille !

N'oubliez pas d'ajouter votre nom d'utilisateur à la commande usermod, cependant.

usermod -a <your-username> -G supervisor

Pour les personnes comme moi qui débutent sur Linux, vous pouvez obtenir votre nom d'utilisateur actuel avec whoami

et pour aws linux ami
usermod -a -G superviseur ec2-user (ou votre nom d'utilisateur)

Pour quelqu'un qui ne parvient toujours pas à utiliser superviseurctl sans autorisation root, vous pouvez vérifier l'autorisation du répertoire qui contient le fichier sock :
ls -ld /var/run/supervisor/
si vous ne pouvez pas accéder à ce répertoire, vous devez utiliser chown ou chmod comme suit :
chown user:group /var/run/supervisor/
ou
chmod 777 /var/run/supervisor/

Pour moi, cela a aidé à déplacer le socket de /var/run/supervisord/supervisord.sock à quelque chose comme /tmp/supervisord.sock et à changer les autorisations en 766 .

Même après avoir modifié la configuration pour ajuster les autorisations de fichier, le dossier /var/run/supervisord/ n'était toujours pas accessible aux utilisateurs non privilégiés.

[unix_http_server]
;file=/var/run/supervisord/supervisord.sock  ; default value
file=/tmp/supervisord.sock
chmod=0766

[supervisorctl]
;serverurl=unix:///var/run/supervisord/supervisord.sock  ; default value
serverurl=unix:///tmp/supervisord.sock