سؤال لماذا لا تعمل مهام cron التي تم إنشاؤها بواسطة WWW-DATA؟


لدي Ubuntu 14 ، وأريد إنشاء بعض وظائف cron باستخدام كود PHP الخاص بي.

حاليا ، أنا أفعل شيء من هذا القبيل crontab -u www-data، ومن رمز PHP لدي القدرة على الكتابة في crontab.

إذا فعلت crontab -u www-data -e أستطيع أن أرى أن هناك بعض الأوامر ، لكن لا يتم تنفيذ هذه الأوامر ، وإن قمت بإضافة نفس الأوامر إليها crontab -e (بدون تحديد المستخدم) ، يتم تشغيلها بنجاح.

ملفات كرون لها أيضا إلزامي خط جديد في النهاية.

TL، DR: كيف يمكنني جعل وظائف العمل كرون إنشاؤها من قبل المستخدم www-data عمل؟

تحرير: 1

حل:  انقر لمعرفة الحل


1
2018-02-03 17:49


الأصل


هل يمكنك مشاركة المزيد عن دخول crontab؟ تذكر أن cron يحتاج عادة إلى اسم المسار الكامل لبرنامج نصي أو أمر وإلا سيتم تجاهله. يمكنك أيضًا إعادة توجيه الإخراج إلى ملف سجل. وفي ملفات سجل النظام الخاصة بك يمكنك البحث عن "cron" وربما العثور على أخطاء. - albert j
أنا فقط لاحظ أن مستخدم www-data غير نشط ، لأن في الداخل /var/spool/crons/crontab أستطيع أن أرى www-data ملف. ويجب أن يعمل كما www-data المستعمل. لذلك لا بد لي من اعطاء www-data حقوق الجذر للمستخدم؟ أو ما تنصح به؟ - Umair
لا! لا تستخدم www-data لأي شيء آخر بخلاف خادم الويب من فضلك. استخدم حساب (مستخدم) محلي أو حتى حساب مخصص لمهام cron فقط. لا تعبث مع اباتشي الافتراضية ومقاييس الأمن لينكس ؛-) - Rinzwind


الأجوبة:


سيدير ​​Cron عناصر www.data. يمكنك التحقق من ذلك باستخدام هذا الاختبار البسيط:

$ sudo crontab -u www-data -e

أضف هذا الإدخال:

* * * * * date >> /tmp/date.out

الآن فحص الإخراج مع:

$ tail -f /tmp/date.out

بعد أن تقوم بذلك للتأكد من عمل crontab ، يمكنك عمل النصوص البرمجية الفعلية التي تريد تشغيلها.

المستخدم www-data بينما لا يكون لديك نفس المسار الذي تتبعه ، فإن الكثير من الأوامر التي تعمل من حسابك لن تعمل من www-data المستخدم إلا إذا قمت بتعيين مسار هذا البرنامج النصي بشكل خاص. يحتوي المسار الافتراضي للبيانات www-data على: PATH=/usr/bin:/bin

يمكنك القيام بذلك عن طريق تصدير قائمة المسارات الخاصة بك ، ثم وضعها في قائمة مسار للبرنامج النصي.

يمكنك القيام بذلك من خلال:

$ echo $PATH > ~/mypath.txt

الآن إلحاق نص ~ / mypath.txt بأعلى النص البرمجي الخاص بك على النحو التالي:

النص البرمجي الخاص بك:

#!/bin/bash

export PATH=$PATH:/home/users/l/j/ljames/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
# rest of your script code here.

يمكنك ضبط المسار عن طريق إزالة بعض العناصر الواضحة التي لن تستخدمها كما هو الحال في المثال الخاص بي:

/home/users/l/j/ljames/bin
/usr/games
/usr/local/games
/snap/bin

سيترك هذا سطر المسار مع البرنامج النصي مع:

#!/bin/bash

export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# ... rest of your script code here

تشغيل PHP النصي في كرون

البرنامج النصي اختبار php (/home/users/l/j/ljames/test.php)

#!/usr/bin/php

<?php
        $string=`date`;
        print "Output from PHP script: $string";
?>

دخول phon crontab

* * * * * php /home/users/l/j/ljames/test.php >> /tmp/date.out

يمكنك فحص الإخراج باستخدام:

$ tail -f /tmp/date.out
Output from PHP script: Fri Feb  3 14:46:01 EST 2017

Output from PHP script: Fri Feb  3 14:47:01 EST 2017

Output from PHP script: Fri Feb  3 14:48:01 EST 2017

يتحقق المخرج من أن crontab سيدير ​​نصوص php الخاصة بك.  فإنه يدل على أن الجاني هو البرنامج النصي الفعلي ، والتي يجب أن يتم تصحيحه لتعمل بشكل صحيح خارج كرون أولا. الجاني المحتمل سيكون قائمة المسار من البيئة.

ملحوظة:
يتم تشغيل sytsem مع البرامج النصية لخادم الويب كمستخدم www-data سيكون أكثر أمنا مما لو كانوا اهرب مثل أنت أو الجذر. إذا كانوا مثلك ، فسيكون للبرنامج النصي حق الوصول إلى كل ما لديك إمكانية الوصول إليه وإذا كان خادم الويب الخاص بك قد تم اختراقه ، فربما يكون لديه حق الوصول إلى الجذر مع sudo. وجود البرامج النصية خادم الويب الخاص بك اهرب مثل  www-data، لن يتمكن الخادم المخترق من الوصول إلى خادمك. والتي ، في حالة النسخ الاحتياطي ، سيكون من الأسهل إصلاحها بدلاً من التعامل مع الخادم بأكمله.


3
2018-02-03 18:23



يمكنني رؤية التواريخ المضافة /tmp/date.out - Umair
تاريخ هو أمر موجود في مسار المتاحة ل www-data. بنفس الطريقة التي تعمل بها /bin/date يمكن تشغيل أي شيء آخر إما في قائمة المسار أو يتم توفيره بواسطة مسار كامل. يمكنك اختبار البرنامج النصي الخاص بك فقط عن طريق تقييد قائمتك السابقة فقط /usr/bin و /bin. إذا كنت تستطيع تشغيل البرنامج النصي ، ثم www-data يجب أن يكون قادرا على تشغيلها أيضا. يمكنك تقييد البحث عن المسار إلى هذين المسارين فقط مع: PATH=/usr/bin:/bin. ستصبح الأوامر التي يمكنك تشغيلها محدودة للغاية في ذلك الوقت. يمكنك استعادة المسار الافتراضي الخاص بك الخروج طرفية النافذة وبدء تشغيلها. - L. D. James
أنا لست كثيرًا من خبراء لينكس ، لكن دعني أخبرك ، الأمر ببساطة php path/to/script/script.php >> path/to/script/log.log ... يعني أنني أقوم بتشغيل نص PHP فقط ... ويعمل PHP تحته www-data المستخدم ، لذلك لا ينبغي تشغيل هذا البرنامج النصي؟ - Umair
هل يعمل البرنامج النصي بشكل صحيح من سطر الأوامر؟ كما أنها تعمل من commanline باسم www-data؟ إذا كان يحتوي على بعض المكونات التي يتم استدعاؤها خارج /usr/bin أو /bin، سوف تفشل في تشغيل www-data دون إضافة ذلك إلى مسار البرنامج النصي. إذا قمت باختباره من سطر الأوامر وفشل في تشغيله في مجمع bash باستخدام المسار ، أضف الخطوات التي قدمتها في الإجابة. - L. D. James
بالمناسبة ، ننظر إلى ملحوظة إلحاق جوابي. أنا أفهم التحذيرات من المستخدم حول الأمان. لكن الأمان في تحديد من يقوم بتشغيل البرنامج النصي. عندما يعمل تحت الوصول الصارم من www-data ستحصل على أكبر قدر من الأمان ، بدلاً من استخدام حسابات أخرى قد يكون لها مزيد من الوصول إلى اختراق النظام الخاص بك. - L. D. James


هذا لأنه ، تقليديا (ولأسباب أمنية جيدة جدا) ، و www-data لا يُسمح للمستخدم بإجراء أي شيء بخلاف عرض الويب. لا تسجيلات الدخول ، لا وظائف كرون ، ندى.

$ getent passwd www-data
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

إعادة التفكير في تدفق عملك ، لا تحاول تشغيل الأشياء www-data.


2
2018-02-03 18:17



فعلا www-data يمكن تشغيل الأوامر. تتضمن العديد من خدمات الويب عمليات تقوم بتشغيل أوامر لتهيئة المواقع والمهام الأخرى. الأمان هو المستخدم والملفات والأذونات. لا يمكن لبيانات www-data تغيير الملفات في دليلك أو في أي مكان آخر بدون إذن. يجب على المستخدم إعطاء الإذن على وجه التحديد لإجراء تغييرات لهذه الملفات من خلال إتاحتها على وجه التحديد للبيانات www. وبالتالي ، فإن الملفات والمساحات المتاحة لـ www-data هي صفحات الويب والدلائل نفسها أو بشكل افتراضي /tmp. - L. D. James
waltinator ما سوف تفعله الأوامر الخاصة بك؟ يرجى توضيح؟ لن يكون لها أي تأثير مع خادم أباتشي. لا يهم ، أنا لا أريد أن العبث خادم العميل: P. - Umair


لقد وجدت الحل. راجعت cronlogs عن طريق الدخول

sudo grep CRON /var/log/syslog

ورأيت الرسالة “(CRON) info (No MTA installed, discarding output)”

هذا يعني أنني اضطررت إلى البريد المثبت.

لذلك ركضت sudo apt-get install postfix والآن كل شيء يعمل.


0
2018-02-04 14:28



كان هذا هو الجواب الذي كان يشير إلى المشكلة. كان الحل ، كما هو مذكور في إجابتي ، هو تشغيل التطبيق من المحطة الطرفية وتصحيحه. سيظهر الخطأ عند تشغيله من المحطة. يعمل كرون. كان القرار لإضافة تطبيق العمل إلى crontab. - L. D. James
هذا الأمر كان يعمل بشكل جيد من المحطة باستخدام -u www-data ... كانت المشكلة الوحيدة التي لم يتم تثبيت الارسال. لذلك كان cron يرمي التحذير (النصي كان يعمل بشكل جيد ، ربما لم يتم كتابة الإخراج إلى ذلك الملف.) - Umair