Supervisor: تعذر تحديد مالك ملف السجل أو الأذونات

من الواضح أن المشكلة تكمن في أنه في الوضع التلقائي يتم إنشاء ملفات السجل باستخدام mkstemp ، والتي لها حدود مقيدة للغاية بشكل افتراضي. إذا قمت بتحديد ملف سجل stdout / stderr بشكل صريح ، يتم إنشاء ملفات السجل بالأذونات المتوقعة.

لقد حددت ملفات stdout / stderr صراحة ، ما زالوا يستخدمون المستخدم الجذر بدلاً من المستخدم المحدد في البرنامج conf.

نفس الشيء هنا ، و umask هو دائمًا x77 ، لذا يتم إنشاء ملفات السجل بواسطة الجذر باستخدام 600 ولا يمكن قراءتها من قبل الآخرين ، فهذه مشكلة بالنسبة لي

لدي في supervisord.conf :

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

conf.d/foo.conf :

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

الدليل /var/log/supervisord موجود ويملكه supervisor . ينتج عن هذا 3 ملفات سجل:

-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

ليس بالنسبة لي ، لقد جربت هذا في قسم [المشرف] وفي كل ملف conf.d / * لكل عملية يتم تشغيلها ، وبدون نجاح ، يستمر المشرف في إنشاء ملفات السجل بـ 600 تجوُّل. يبدو أنه يعمل مع ملف السجل الرئيسي supervisord.log رغم ذلك ، والذي يبدو أنه يكرِّم معلمة umask الخاصة بي

لدي مشكلة مماثلة. لقد قمت بتعيين umask 000 على مستوى SV والعملية ، ومع ذلك يتم إنشاء جميع ملفات السجل بقناع 022.
(أنا لا أستخدم الوضع التلقائي)
(لدي أيضًا مشكلة في ملف سجل المشرف)

ذات صلة: # 312 ، طلب خيار لتعيين مالك السجل.

أي قرار لهذا؟

يا مشرف.

مجرد مستخدم آخر يبحث عن نفس الشيء بالضبط!

تعيين user=<user> على برنامج supervisord يعمل بالنسبة لي ... يتم إخفاء جميع السجلات لهذا المستخدم بواسطة المشرف.

+1 من فضلك - هذه صفقة كبيرة جدًا

كنا نكافح أيضًا مع هذا. يتضمن الحل البديل الذي توصلنا إليه إنشاء جميع ملفات السجل مسبقًا كجزء من عملية النشر قبل إعادة تشغيل supervisord . في الأساس نقوم بتشغيل أمر grep | awk | xargs (touch ; chown; chmod) ضد تكوينات المشرف. يعمل هذا بشكل جيد طالما أن السجلات لا تدور ، وهو ما نادرًا ما يحدث.

سيكون محل تقدير على الرغم من أجمل حل. ؛)

+1
كما ذكر gkertai ، يتعين علينا أيضًا القيام بالكثير من التزويد والتحقق المزدوج في عملية النشر الخاصة بنا حتى نتمكن من استخدام المشرف (مثل الإنشاء المسبق لملفات السجل بأذونات صحيحة) ، وهذا أمر مرهق حقًا. يتضمن ذلك الحاجة إلى التأكد من وجود أدلة ملف السجل الرئيسي (https://github.com/Supervisor/supervisor/issues/120) ، فقط حتى يبدأ المشرف في تشغيل أي شيء ، أو عدم إنهاء مجموعة من العمليات معها. تعجبني حقًا فكرة المشرف ، وأكره فكرة الاضطرار إلى الحفاظ على البرامج النصية المبتدئة أو المبتدئة ، لكن استخدام المشرف في بيئة الإنتاج حتى الآن لم يثبت أنه يمكن الاعتماد عليه كما نرغب. من شأن المعالجة الأنظف لملفات السجل أن تقطع شوطًا طويلاً ، وتحظى بتقدير كبير ، خاصةً إنشاء دليل ملف السجل الرئيسي (لا أستطيع أن أفهم عدم إنشاء أدلة سجل البرنامج ، لكنني أشعر بصدق أن دليل السجل الرئيسي للمشرف نفسه يجب أن يكون هو مسؤولية). على الأقل أشعر أنه يجب أن يعود إلى موقع السجل الافتراضي الذي من المتوقع أن يكون متاحًا دائمًا (على سبيل المثال /tmp/supervisord.log ) بحيث يمكن الوصول بسهولة إلى رسائل التحذير حول عدم وجود دليل السجل المطلوب

بالنسبة لي ، كان الحل الأفضل هو تغيير Umask في عملية الوالدين:

#!/usr/bin/env bash

umask 0000
supervisord -c supervisord.conf

سترث العملية الفرعية Umask للعملية الأم ، ونتيجة لذلك ستتمتع جميع الملفات التي سيتم إنشاؤها بالأذونات الجيدة:

يمكنك أيضًا تعيين umask باستخدام الخيار umask= في قسم [supervisord ] من ملف التكوين.

sidnei هل يجب أن يكون هناك chmod بعد mkstemp هنا ؟

مشكلة مماثلة هنا ، مجنون لم يتم التعامل مع هذا بعد

[البرنامج: test1]
المستخدم = user1
stdout_logfile = user1.log

يبدأ التطبيق بشكل صحيح باسم user1 ولكنه ينشئ user1.log كجذر
بدلاً من المستخدم 1 ، يبدو هذا خطأ أكثر منه تحسين

و +1 مني.
يبدو أنه خطأ ، حيث لا أتوقع أنه إذا حددت مستخدمًا في البرنامج: سيتم إنشاء ملفات سجلات القسم x من الجذر.

يا له من متعة إجراء 1+ لقضية عمرها 3 سنوات لم يتم حلها.

:بكاء:

+1

نعم من فضلك! +1

+1 - حدث تدوير للسجل وقلبت مجموعة من الخدمات مع وجود أخطاء في الأذونات على مقابض ملفات السجل .. ومن المؤكد أن ملفات السجل الجديدة اللامعة مملوكة للجذر. مفاجأة سيئة!

+1

+1

إنه لأمر محزن أن نرى الكثير من الناس يلجأون إلى الحلول البديلة الخرقاء. يتعامل nginx مع هذا الأمر جيدًا حقًا.
+1

: '(

: +1:

+1

+1. لا أعتقد أن أي شخص سوف يصلحها على الإطلاق.

coleplx احتفظ + 1ing. إذا لم يتم إصلاح ذلك ، فسننشئ على الأقل مجتمعًا لطيفًا هنا ^ _ ^

+1

+1

أهلا يا أصدقاء،
يمكنك تشغيل الأمر الخاص بك على النحو التالي:

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

وقم بإزالة هذه العلامات:

redirect_stderr
stderr_logfile
stdout_logfile

BahmaniAlireza : بالتأكيد نستطيع. ولكن بعد ذلك سنفتقد هذه الميزات الجيدة ... :(
stderr_logfile_maxbytes
stderr_logfile_backups
stderr_capture_maxbytes

+1

+1

+1

متى سيتم اصلاح هذا؟؟؟؟

متى سيتم اصلاح هذا؟؟؟؟

عندما يزعج شخصًا ما بما فيه الكفاية بحيث لا يعمل حوله خارجيًا و
يقدمون العلاقات العامة ... :)

+1

+1

لقد وجدت أن استخدام setgid يبدو طريقة جيدة للحصول على بعض الوظائف التي نريد رؤيتها من معلمة umask (غير وظيفية) في المشرف. في حالتي ، كنت بحاجة إلى سجلات من البرامج التي يديرها المشرف لتكون مرئية لمجمع السجلات ، لذلك استخدمت setgid لتحقيق ذلك: مثل هذا:
chmod u=rwx,go=rx,a+s /var/log/myapplogs/

ثم في تكوينات المشرف ، كان علي فقط تعيين ملف السجل ، المستخدم ، ملف pidfile ، stdout_logfile ، stdout_events_enabled (صحيح) ، stderr_logfile ، stderr_events_enabled (صحيح) ، إلخ.

إعداد العينة: https://gist.github.com/jpsandiego/a7927d14fc23efc0eae049d1466656b0

لكل شخص يترك تعليقات منفصلة لـ 1+ وعلامة الإعجاب وما إلى ذلك: FUCK OFF.

على محمل الجد ، يعد قسم المشكلات أداة مطور ، وكل ما تفعله هو إزعاج المطورين (والبقية منا) عن طريق إرسال رسائل غير مرغوب فيها إلينا جميعًا برسالتك غير المجدية. أنا حقًا لا أفهم لماذا من الضروري أن تدرسك على هذه الحقيقة الأساسية للآداب. إذا لم يكن لديك أي شيء مفيد تضيفه ، فما عليك سوى إبداء الإعجاب بالمشكلة والمضي قدمًا.

(آسف للجميع على هذا البريد العشوائي ، لكن هذه المشكلة خرجت عن نطاق السيطرة.)

"لكل من يترك تعليقات منفصلة لـ 1+ وعلامة الإعجاب وما إلى ذلك"
...
"إذا لم يكن لديك أي شيء مفيد تضيفه ، فما عليك سوى إبداء الإعجاب بالمشكلة والمضي قدمًا."

فقط من أجل FUCK OFF مرة أخرى - تمت إضافة ردود الفعل (وهي الإبهام الذي تشير إليه) في مارس من عام 2016. https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and -تعليقات

هذا ما يقرب من أربع سنوات بعد بدء هذه المشكلة. قبل تلك اللحظة (وسألاحظ أنني لم ألاحظ في الواقع تمت إضافة الميزة بعد) ، كانت الطريقة الصحيحة والوحيدة لإبداء الإعجاب بالمشكلة هي التعليق.

إذا كنت لا تحب تصويت الناس ، فأغلق القضية. إنه مفتوح ، لذلك من المفترض أن فريق التطوير مهتم بهذا - ونحن المستخدمين الذين نعرب عن اهتمامنا به ما زلنا نهتم أيضًا.

إذا كنت تمثل فريق التطوير وتشعر أنه لن يتم حله أبدًا ، فاذكر ذلك وأغلقه. إذا لم تقم بإلغاء الاشتراك. :)

لذا ، تبا.

بالفعل.

رايان تبا

في 10/1/17 17:18 كتب ديفيد رايستريك:
>

"لكل من يترك تعليقات منفصلة لـ 1+ وعلامة الإعجاب وما إلى ذلك"
...
"إذا لم يكن لديك أي شيء مفيد تضيفه ، فكل ما عليك هو إبداء الإعجاب بالمشكلة و
المضي قدما ".

فقط للابتلاع مرة أخرى - ردود الفعل (التي هي إبهامك
في اشارة الى) في مارس من عام 2016.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

هذا ما يقرب من أربع سنوات بعد بدء هذه المشكلة. قبل ذلك
لحظة من الزمن (وسألاحظ أنني في الواقع لم ألاحظ
تمت إضافة الميزة حتى الآن) الطريقة الصحيحة والوحيدة لإبداء الإعجاب بالمشكلة
كان تعليق.

إذا كنت لا تحب تصويت الناس ، فأغلق القضية. إنه مفتوح ، لذا
يفترض أن فريق التطوير مهتم بهذا - ونحن
المستخدمين الذين أبدوا اهتمامًا به لا يزالون مهتمين أيضًا.

إذا كنت تمثل فريق التطوير وتشعر أنه ليس كذلك
شيء سيتم حله في أي وقت ، دولة ذلك وإغلاقه.

لذا ، تبا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-271686060 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAzKDJ3bty9ezBMMR8ObCeV_8hIazqPTks5rQ-edgaJpZM4AA4dF .

+1

+1

+1

+1

في 17/12/01/17 06:31 ، كتب يوجين إيفانوف:
>

+1

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-272115994 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAzKDKMUhFVHCN1C03WXOSUsuRSmv48Tks5rRfMMgaJpZM4AA4dF .

مرحبًا بالجميع ، أولاً وقبل كل شيء ، أنا لا أوافق على أن تكون عدوانيًا عند التحدث في المنتديات ، لأي سبب من الأسباب ، فنحن جميعًا نستحق الاحترام ومن الواضح أنه لا أحد هنا يعني أي ضرر ولكن أظهر أن هذه القضية تؤثر على العديد من الأشخاص. ومع ذلك ، لدى @ keen99 نقطة صحيحة ، لقد اشتركت في هذا العدد منذ فترة ، وفي كل مرة أتلقى إشعارًا أتساءل "رائع ، هل لدينا أي أخبار صحيحة عن ذلك؟" ولكن بعد ذلك قمت بفتحه ووجدت +1 😞.

من خلال النقر على "اشتراك" وإعطاء إبهامًا على التعليق الأول للمسألة ، في رأيي طريقة أكثر إنتاجية لإظهار الاهتمام ، حيث إنها طريقة أكثر وضوحًا لعدد الأشخاص الذين يعانون من نفس المشكلة.

ومع ذلك ، فإن تنفيذ +1 s لن يجعل المشرفين على المشروع يذهبون بشكل أسرع مع المشكلة لأن لدينا بالفعل العديد من +1s وهذا لم يتم إصلاحه (من الواضح أنهم ليسوا مضطرين إلى ذلك ، أي شخص يتأثر بشدة له الحرية في فتح طلب سحب كما هو الحال مع أي برمجيات مفتوحة المصدر). لكن في رأيي ، يزعج هذا العديد من المشتركين دون سبب وجيه حقيقي ولا فائدة.

لقد قمت بضرب هذا وربما لا أعرف ما أفعله ، لكن تعيين الإعداد ووضع umask في [المشرف] وفي النص الأولي لم يفي بالغرض. من المحتمل أن أستخدم قيمة سجل النظام السحرية لإعدادات ملف السجل:
stdout_logfile=syslog stderr_logfile=syslog
وتتجادل الأشياء من هناك. هذه ليست المرة الأولى (وأشك في المرة الأخيرة) التي قمت فيها شخصيًا بحل مشكلات الأذونات لتجميع السجلات باستخدام سجل النظام فقط. يعمل بشكل جيد!

+1

نحن نستخدم مشرفًا على أجهزتنا لمراقبة العمليات والتحكم فيها. نود تحسين أمان مثيلاتنا ولاحظنا أنه لا يمكن بسهولة تغيير أذونات ملفات السجل. فيما يلي القضايا الأخرى ذات الصلة:

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

هل هناك شخص ما يعمل على هذه أو القضايا ذات الصلة؟

ماذا عن وجود حقل تكوين عام منفصل يسمى stdout_log_user و stdout_log_permissions (وبالمثل لـ stderr_* ) والذي من شأنه أن يسمح للمستخدم بتحديد من يملك السجلات (على سبيل المثال ، root فقط 0o600 )؟

يمكنك وضع هذه الحقول في أقسام البرنامج أيضًا لتجاوز الحقل العالمي إذا لزم الأمر.

إذا لم يعمل أحد على حل هذه المشكلة ، فسيكون فريقنا في Parquery AG سعيدًا بتقديم المساعدة وتقديم طلب سحب. يرجى إعلامي بالخطوات التالية.

mristin ، أقترح تقديم عرض عام واستخدام مفترق خاص بك حتى يتم دمجه هنا .. الأمر الذي قد يستغرق بعض الوقت حيث يبدو أن هذا المشروع يعاني من نقص في المساهمين النشطين (وليس توجيه أصابع الاتهام ، لم أحصل على ذلك) حان الوقت للمشاركة والمساهمة أيضًا ، للأسف!).

lukeburden ، شكرًا ، سنفعل ذلك.

هل يمكن لبعض المستخدمين المهتمين بالميزة التأكيد بسرعة على أن اقتراحنا سوف يناسبهم؟

@ كريستين من شأنه أن يفعل الحيلة في حالتي. سأستخدم إعدادات مستوى البرنامج للتأكد عند حدوث دوران السجل في عملية الكرفس الخاصة بي ، أن ملفات السجل الجديدة مملوكة للمستخدم الصحيح celery وأن التصاميم مناسبة. في الوقت الحالي ، يقوم المشرف بإنشاء ملفات السجل الجديدة كجذر ، ومن ثم لا يمكن لعملية الكرفس الكتابة إلى ملف السجل الجديد.

فكرتي الإضافية الوحيدة هي أنه قد تكون فكرة جيدة أن يكون لديك إعداد يسمح بتحديد المجموعة أيضًا؟ قد يكون هذا مهمًا لتكوين بعض الأشخاص.

@ كريستين من شأنه أن يفعل الحيلة بالنسبة لي أيضًا.

يمكنني أيضًا مساعدتك في اختباره إذا كنت بحاجة إلى ذلك.

أعلم أن هذا قديم ، لكنني كنت أواجه صعوبة في جعل المشرف لا يقوم بتدوير السجلات ، وعلى ما يبدو ، في مرحلة ما ، تغير اسم التكوين للإعداد الذي يقوم بإيقاف تشغيله من "logfile_maxbytes" إلى "stdout_logfile_maxbytes".

ما وجدته للالتفاف على تغيير أذونات ملف السجل مرة أخرى إلى الجذر هو أن إيقاف تشغيل دوران سجل المشرفين واستخدام logrotate هو الحيلة. ومع ذلك ، إذا نمت الملفات بسرعة كافية ، فسيتم تشغيل logrotate بسبب حجم الملف.

ربما هذا يساعد شخص ما.

أهلا بكم،

لقد وجدت هذه الإجابة على هذا الموضوع: http://supervisor-users.10397.x6.nabble.com/Supervisor-users-Changing-owner-of-log-files-td4945286.html

من خلال إنشاء ملف السجل مع المستخدم المطلوب (مثل الشخص الذي يمتلك عملية المشرف الفرعية) ، يتم الاحتفاظ بالملكية أثناء عملية المشرف.

امل ان يساعد!

مع أطيب التحيات والبقاء في أمان!

@keen99 +1