Supervisor: Impossible de spécifier le propriétaire du fichier journal ou les autorisations

Apparemment, le problème est qu'en mode AUTO, les fichiers journaux sont créés avec mkstemp, qui a des permissions très restrictives par défaut. Si vous spécifiez explicitement le fichier journal stdout/stderr, les fichiers journaux sont créés avec les autorisations attendues.

J'ai spécifié explicitement les fichiers stdout/stderr, ils utilisent toujours l'utilisateur root plutôt que celui spécifié dans la configuration du programme.

Idem ici, et l'umask est toujours x77 donc les fichiers journaux sont créés par root avec 600 et ne sont pas lisibles par les autres, c'est un problème pour moi

J'ai en supervisord.conf :

[supervisord]
logfile=/var/log/supervisord/supervisord.log
user=supervisor
umask=022

et en conf.d/foo.conf :

stdout_logfile=/var/log/supervisord/%(program_name)s-stdout.log
stderr_logfile=/var/log/supervisord/%(program_name)s-stderr.log

Le répertoire /var/log/supervisord est présent et appartient à supervisor . Cela se traduit par 3 fichiers journaux :

-rw-r--r-- 1 supervisor supervisor   0 2013-02-20 19:26 foo-stderr.log
-rw-r--r-- 1 supervisor supervisor  82 2013-02-20 19:29 foo-stdout.log
-rw-r--r-- 1 supervisor supervisor 649 2013-02-20 19:29 supervisord.log

Pas pour moi, j'ai essayé cela dans la section [supervisord] et dans chaque fichier conf.d/* pour chaque processus à lancer, sans succès, superviseurd continue de créer des fichiers journaux avec 600 perms. Cela semble fonctionner pour le fichier journal principal superviseurd.log, qui semble respecter mon paramètre umask

J'ai un problème similaire. J'ai défini un umask 000 au niveau SV et processus, néanmoins tous les fichiers journaux sont créés avec un masque de 022.
(Je n'utilise pas le mode AUTO)
(J'ai aussi le problème pour le fichier journal du superviseur)

Connexe : #312, demandant une option pour définir le propriétaire du journal.

Une résolution à cela?

oh superviseur.

Juste un autre utilisateur recherchant exactement la même chose !

Le réglage user=<user> sur le supervisord fonctionne pour moi... Tous les journaux sont transmis à cet utilisateur par le superviseur.

+1 s'il vous plaît - c'est un gros problème

Nous étions également aux prises avec cela. La solution de contournement que nous avons proposée consiste à pré-créer tous les fichiers journaux dans le cadre de notre processus de déploiement avant le redémarrage supervisord . Fondamentalement, nous exécutons une commande grep | awk | xargs (touch ; chown; chmod) sur les configurations du superviseur. Cela fonctionne bien tant que les journaux ne tournent pas, ce qu'ils font rarement.

Une solution plus agréable serait cependant appréciée. ;)

+1
Comme @gkertai l'a mentionné, nous devons également faire beaucoup de provisionnement et de double-vérification dans notre processus de déploiement pour pouvoir utiliser le superviseur (comme la pré-création de fichiers journaux avec les autorisations correctes), et cela semble vraiment fastidieux. Cela implique de s'assurer que les principaux répertoires de fichiers journaux existent ( https://github.com/Supervisor/supervisor/issues/120 ), juste pour que superviseurd commence même à exécuter quoi que ce soit, ou ne supprime pas un tas de processus avec ça. J'aime vraiment l'idée de Superviseur et je déteste l'idée de devoir maintenir des scripts Upstart ou initd, mais l'utilisation de Superviseur dans un environnement de production jusqu'à présent ne s'est pas avérée aussi fiable que nous le souhaiterions. Une gestion plus propre des fichiers journaux irait très loin et serait très appréciée, _surtout_ la création du répertoire principal des fichiers journaux (je peux comprendre qu'il ne crée pas de répertoires de journaux de programme, mais je pense sincèrement que le répertoire principal des journaux pour superviseurd lui-même devrait être son responsabilité). À tout le moins, j'ai l'impression qu'il devrait revenir à un emplacement de journal par défaut qui devrait toujours être accessible (par exemple /tmp/supervisord.log ) afin que les messages d'avertissement concernant l'absence du répertoire de journal souhaité soient facilement accessibles

Pour moi, la meilleure solution était de changer le umask dans le processus parent :

#!/usr/bin/env bash

umask 0000
supervisord -c supervisord.conf

Le processus enfant héritera de l'umask du processus parent, par conséquent tous les fichiers qui seront créés auront les bonnes permissions :

Vous pouvez également définir le umask en utilisant l'option umask= dans la section [supervisord ] du fichier de configuration.

@sidnei devrait-il y avoir un chmod après mkstemp ici ?

problème similaire ici, fou cela n'a pas encore été traité

[programme : test1]
utilisateur = utilisateur1
stdout_logfile = user1.log

démarre correctement l'application en tant qu'utilisateur1 mais crée user1.log en tant que root
au lieu de user1, cela ressemble plus à un bogue qu'à une amélioration

Et +1 de ma part.
On dirait que c'est un bogue, car je ne m'attends pas à ce que si vous spécifiez l'utilisateur dans la section program:x , les fichiers journaux soient créés à partir de la racine.

oh le plaisir d'attribuer +1 à un problème non résolu de 3 ans.

:cri:

+1

Oui s'il vous plaît! +1

+1 - la rotation des journaux s'est produite et une gamme de services s'est retournée avec des erreurs d'autorisations sur les poignées de fichiers journaux .. et bien sûr, les nouveaux fichiers journaux brillants appartiennent à root. Mauvaise surprise !

+1

+1

Il est triste de voir tant de personnes recourir à des solutions de contournement maladroites. nginx gère cela très bien.
+1

:'(

:+1:

+1

+1. Je pense que personne ne pourra jamais le réparer.

@coleplx garde +1ing. Si ce n'est pas résolu, nous allons au moins créer une belle communauté ici ^_^

+1

+1

Salut les gars,
vous pouvez exécuter votre commande comme suit :

command= bash -c "votre_commande first_param second_param 2> error_file.txt > stdout.txt"

et SUPPRIMER ces balises :

redirect_stderr
stderr_logfile
stdout_logfile

@BahmaniAlireza : bien sûr que nous le pouvons. mais alors ces fonctionnalités supplémentaires nous manqueront... :(
stderr_logfile_maxbytes
stderr_logfile_backups
stderr_capture_maxbytes

+1

+1

+1

Quand est-ce que ça va être réglé ????

Quand est-ce que ça va être réglé ????

quand cela agace suffisamment quelqu'un pour qu'il ne le contourne pas à l'extérieur et
ils soumettent un PR... :)

+1

+1

J'ai trouvé que l'utilisation de setgid semble être une méthode décente pour obtenir certaines des fonctionnalités que nous voulons voir à partir du paramètre umask (non fonctionnel) dans le superviseur. Dans mon cas, j'avais besoin que les journaux des programmes gérés par le superviseur soient visibles pour un agrégateur de journaux, j'ai donc utilisé setgid pour que cela se produise : comme ceci :
chmod u=rwx,go=rx,a+s /var/log/myapplogs/

Ensuite, dans les configs du superviseur, j'ai juste eu à définir logfile, user, pidfile, stdout_logfile, stdout_events_enabled (true), stderr_logfile, stderr_events_enabled (true), etc.

Exemple de configuration : https://gist.github.com/jpsandiego/a7927d14fc23efc0eae049d1466656b0

À tous ceux qui laissent des commentaires séparés pour +1, pouces vers le haut, etc. : FUCK OFF.

Sérieusement, la section des problèmes est un outil de développement, et tout ce que vous faites est d'ennuyer les développeurs (et le reste d'entre nous) en nous spammant tous avec votre message inutile. Je ne comprends vraiment pas pourquoi il est nécessaire de vous enseigner ce fait fondamental de l'étiquette. Si vous n'avez rien d'utile à ajouter, contentez-vous de signaler le problème et passez votre chemin.

(Désolé pour tout le monde pour ce spam, mais ce problème est devenu incontrôlable.)

"À tous ceux qui laissent des commentaires séparés pour +1, pouce levé, etc."
...
"Si vous n'avez rien d'utile à ajouter, contentez-vous de signaler le problème et passez votre chemin."

Juste pour FUCK OFF back - les réactions (qui sont les pouces vers le haut auxquels vous faites référence) ont été ajoutées en mars 2016. https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and -commentaires

C'est presque QUATRE ANS après le début de ce problème. Avant ce moment (et je noterai que je n'avais pas encore remarqué que la fonctionnalité avait été ajoutée), le seul et unique moyen de signaler un problème était un commentaire.

Si vous n'aimez pas que les gens votent pour, FERMEZ LE PROBLÈME. C'est ouvert, donc on peut supposer que l'équipe de développement s'y intéresse - et nous, les utilisateurs qui expriment de l'intérêt, nous en soucions toujours aussi.

Si vous représentez l'équipe de développement et estimez que ce n'est pas quelque chose qui sera jamais résolu, alors dites-le et fermez-le. Si vous ne le faites pas, désabonnez-vous. :)

Alors, BAISEZ-VOUS.

En effet.

Ryan va te faire foutre

Le 10/01/17 17:18, david raistrick a écrit :
>

"À tous ceux qui laissent des commentaires séparés pour +1, pouce levé, etc."
...
"Si vous n'avez rien d'utile à ajouter, contentez-vous de signaler le problème et
avancer."

Juste pour FUCK OFF back - réactions (ce qui est le pouce levé que vous êtes
faisant référence) ont été ajoutés en mars 2016.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

C'est presque QUATRE ANS après le début de ce problème. Avant cela
moment dans le temps (et je noterai qu'en fait je n'avais pas remarqué le
fonctionnalité a encore été ajoutée) la bonne et la seule façon de signaler un problème
était un commentaire.

Si vous n'aimez pas que les gens votent pour, FERMEZ LE PROBLÈME. C'est ouvert donc
l'équipe de développement est probablement intéressée par cela - et nous, les
les utilisateurs qui expriment leur intérêt s'en soucient toujours aussi.

Si vous représentez l'équipe de développement et estimez que ce n'est pas
quelque chose qui ne sera jamais résolu, déclarez-le et fermez-le.

Alors, BAISEZ-VOUS.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-271686060 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAzKDJ3bty9ezBMMR8ObCeV_8hIazqPTks5rQ-edgaJpZM4AA4dF .

+1

+1

+1

+1

Le 12/01/17 06:31, Eugen Ivanov a écrit :
>

+1

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-272115994 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAzKDKMUhFVHCN1C03WXOSUsuRSmv48Tks5rRfMMgaJpZM4AA4dF .

Salut tout le monde, tout d'abord, je n'approuve pas d'être agressif quand on parle sur des forums, pour quelque raison que ce soit, car nous méritons tous le respect et il est évident que personne ici ne veut de mal, mais montrez que ce problème touche beaucoup de gens. Cependant, @keen99 a un argument valable, je me suis abonné à ce numéro il y a quelque temps et chaque fois que je reçois une notification, je me demande "wow, avons-nous des nouvelles valables à ce sujet?" mais ensuite je l'ouvre et trouve un +1 😞 .

En appuyant sur s'abonner et en donnant un coup de pouce au premier commentaire du problème, c'est à mon avis un moyen plus productif de montrer son intérêt, car c'est beaucoup plus visuel pour savoir combien de personnes ont le même problème.

Cela dit, faire des +1 n'accélérera pas les responsables du projet car nous avons déjà beaucoup +1s et cela n'a pas été corrigé (évidemment, ils n'ont pas à , celui qui est profondément affecté est libre d'ouvrir une pull request comme avec n'importe quel OSS). Mais à mon avis, cela dérange de nombreux abonnés sans véritable raison et sans en retirer aucun avantage.

J'ai frappé ceci et je ne sais probablement pas ce que je fais, mais setgid et définir umask dans [supervisord] et dans le script init n'ont pas fait l'affaire. Je vais probablement utiliser la valeur syslog magique pour les paramètres du fichier journal :
stdout_logfile=syslog stderr_logfile=syslog
Et démêler les choses à partir de là. Ce n'est pas la première (et je doute de la dernière) fois que j'ai personnellement résolu des problèmes d'autorisations pour l'agrégation de journaux en utilisant simplement syslog. Fonctionne bien !

+1

Nous utilisons un superviseur sur nos machines pour surveiller et contrôler les processus. Nous aimerions améliorer la sécurité de nos instances et avons remarqué qu'il n'est pas possible de changer facilement les permissions des fichiers journaux. Voici les autres problèmes pertinents :

https://github.com/Supervisor/supervisor/issues/114
https://github.com/Supervisor/supervisor/issues/107

Quelqu'un travaille-t-il sur ces problèmes ou sur des problèmes connexes ?

Qu'en est-il d'avoir un champ de configuration global distinct appelé stdout_log_user et stdout_log_permissions (de même pour stderr_* ) qui permettrait à l'utilisateur de spécifier à qui appartiennent les journaux (par exemple, seulement root ) et avec quelles autorisations (par exemple, 0o600 ) ?

Vous pouvez également avoir ces champs dans les sections du programme pour remplacer le champ global si nécessaire.

Si personne ne travaille sur ce problème, notre équipe de Parquery AG se fera un plaisir de vous aider et de faire une demande d'extraction. Veuillez me faire savoir quelles seraient les prochaines étapes.

@mristin Je suggérerais de soumettre un PR et d'utiliser votre propre fork jusqu'à ce qu'il soit fusionné ici .. ce qui peut prendre un certain temps car il semble que ce projet souffre d'un manque de contributeurs actifs (pas de pointage du doigt, je n'ai pas il est temps de se lancer et de contribuer non plus, malheureusement !).

@lukeburden , merci, nous le ferons.

Certains des utilisateurs intéressés par la fonctionnalité pourraient-ils rapidement confirmer que notre proposition leur conviendrait ?

@mristin qui ferait l'affaire dans mon cas. J'utiliserais les paramètres au niveau du programme pour m'assurer, lorsque la rotation des journaux se produit sur mon processus de céleri, que les nouveaux fichiers journaux appartiennent au bon utilisateur celery et que les permissions sont appropriées. Pour le moment, le superviseur crée les nouveaux fichiers journaux en tant que root, puis le processus de céleri ne peut pas écrire dans le nouveau fichier journal.

Ma seule pensée supplémentaire est que ce pourrait être une bonne idée d'avoir un paramètre permettant également de spécifier le groupe? Cela peut être important pour la configuration de certaines personnes.

@mristin qui ferait l'affaire pour moi aussi.

Je peux également vous aider à le tester si vous en avez besoin.

Je sais que c'est vieux, mais j'avais du mal à faire en sorte que le superviseur ne fasse PAS tourner les journaux, et apparemment, à un moment donné, le nom de configuration du paramètre qui désactive cette option est passé de "logfile_maxbytes" à "stdout_logfile_maxbytes".

Ce que j'ai trouvé pour contourner le changement des autorisations de fichier journal à la racine, c'est que la désactivation de la rotation des journaux des superviseurs et l'utilisation de logrotate ont fait l'affaire. Cependant, si les fichiers grandissent assez vite, logrotate se déclenchera en raison de la taille du fichier.

Peut-être que cela aide quelqu'un.

Salut tout le monde,

J'ai trouvé cette réponse sur ce sujet : http://supervisor-users.10397.x6.nabble.com/Supervisor-users-Changing-owner-of-log-files-td4945286.html

En créant le fichier journal avec l'utilisateur souhaité (comme celui qui possède le processus enfant superviseur), la propriété est conservée pendant le processus superviseur.

J'espère que cela pourra aider!

Meilleures salutations et restez en sécurité!

@keen99 +1