रूट क्रोन जॉब स्क्रिप्ट को ठीक से चलाने के लिए 'सुडो' की आवश्यकता क्यों है?

Question

मैं अपने रास्पबेरी पाई पर इस सरल स्क्रिप्ट को ऑटो अपडेट पर चला रहा हूं ताकि मैं इसके बारे में भूल सकूं। यह एक लॉग भी रखता है जो कहता है कि क्या अपडेट सफल था। स्क्रिप्ट अद्यतन है। श:

#!/bin/bash
echo "Update starts on: $(date)" >> /home/pi/update.log
 if apt-get update && apt-get upgrade -y; then
    echo "update successful $(date)"  >> /home/pi/update.log
 else
    echo "Couldn't update $(date)" >> /home/pi/update.log
 fi

मैंने इस स्क्रिप्ट को रूट क्रॉस्टैब के साथ जोड़ दिया sudo crontab -eऔर क्रोनजोब को हर दिन सुबह 6 बजे चलाने के लिए तैयार किया

0 6 * * * /home/pi/update.sh

मुझे पता है कि यह कुछ हद तक काम करता है क्योंकि sudo ./update.shशेल में चलने से मैन्युअल रूप से कमांड चलता है और लॉग में "सफल" प्रविष्टि छोड़ देता है। दूसरी ओर, जब क्रॉस्टैब से भाग गया, तो मुझे हमेशा "अपडेट नहीं कर सका" प्रविष्टि मिलती है। यदि यह मायने रखता है, तो "pi" उपयोगकर्ता द्वारा "update.sh" स्क्रिप्ट बनाई गई थी और मैंने निष्पादन अनुमतियाँ देने के अलावा कभी भी अनुमतियाँ नहीं बदलीं।

मैंने उसी समस्या के बारे में एक और प्रश्न पढ़ा और उस व्यक्ति ने इसे sudoकमांड के सामने रखकर हल किया । वह मानते हैं कि यह अजीब है क्योंकि इसे पहले ही रूट द्वारा निष्पादित किया जा रहा है, लेकिन कहते हैं कि यह काम करता है। मैंने जोड़ने का प्रयास किया sudoऔर सत्यापित किया कि यह वास्तव में अब काम करता है।

क्या किसी को पता है यह क्यों होता है? sudoअगर यह पहले से ही जड़ है तो इसकी आवश्यकता क्यों है ?

Comments

के संभावित डुप्लिकेट जब क्रॉन से चलाने क्यों इस स्क्रिप्ट विफल, लेकिन जब मैन्युअल रूप से चलाने के काम करता है करता है?

— निफले

मैंने वह पोस्ट पढ़ी और इसने एक व्यावहारिक समाधान दिया, लेकिन मुझे नहीं लगता कि इसने वास्तविक उत्तर दिया, न कि मुझे वैसे भी समझ में आया। मैंने उस प्रश्न को प्रतिबिंबित करने के लिए पुनःप्रकाशित किया।

— 25

सुडो और शुद्ध जड़ के लिए पर्यावरण आवश्यक रूप से समान नहीं हैं। envरूट के रूप में टाइप करने की कोशिश करें और फिर sudo envपरिणामों की तुलना करें।

— निफले

यह विंडोज यूएसी की तरह है जो प्रशासक के रूप में लॉग इन है। हालाँकि आप व्यवस्थापक के रूप में लॉग इन हैं लेकिन आप अभी भी एक सामान्य उपयोगकर्ता हैं। एक सिस्टम फ़ंक्शन चलाने के लिए आपको एक व्यवस्थापक टोकन के लिए "पूछना" पड़ता है जो आपको कार्य करने की क्षमता देता है। यह लिनक्स के लिए समान है (जहां, मेरा मानना ​​है, विचार उत्पन्न हुआ) क्योंकि यह उपयोगकर्ता को गलती से ऐसा कुछ करने से रोकता है जो संभावित रूप से एक सिस्टम को बर्बाद कर सकता है।

— किन्युकस

क्या विफल apt-getकमांड किसी भी त्रुटि की रिपोर्ट करता है ? चूंकि आप इसके आउटपुट को रीडायरेक्ट नहीं कर रहे हैं, इसलिए इसे रूट के मेल के रूप में भेजा जाएगा।

— बरमार

Answer 1

क्रोन एक विशेष शेल से कमांड चलाता है, उपयोगकर्ता या रूट शेल से अलग होता है। इस शेल में उपयोगकर्ताओं के समान पैठ चर की पहुंच नहीं है। इसलिए, जब एक स्क्रिप्ट को क्रोन जॉब के रूप में चलाया जाता है, तो दो विकल्प होते हैं:

A. स्क्रिप्ट में प्रत्येक कमांड के लिए पूर्ण पथ निर्दिष्ट करें (यानी योग्यता के लिए पूर्ण पथ- क्रॉन को यह नहीं पता है कि "एप्ट-गेट" कहां खोजना है)

B. छोटी चाल मैं उपयोग करते हैं- क्रोन जॉब लाइन लिखते समय, यहां तक ​​कि ROOT crontab में, स्क्रिप्ट पथ से पहले sudo को जोड़ते हैं। यह क्रोन शेल के बजाय रूट शेल से स्क्रिप्ट को चलाने में क्रोन को धोखा देगा, जो इसे सभी रूट के पैठ चर तक पहुंच देगा।

Answer 2

ऐसा इसलिए है क्योंकि क्रोन आपके अप्रभावित उपयोगकर्ता के रूप में चल रहा है, और apt-getकमांड को चलाने के लिए रूट (उर्फ प्रशासन) के विशेषाधिकारों की आवश्यकता होती है।

एक विकल्प इस कमांड को rootयूजर के क्रैस्टैब के तहत चलाने के लिए है :

sudo -i
<type user password>
crontab -e

पहला कमांड आपके पूरे शेल को रूट करने के लिए बढ़ाता है और यह भी - महत्वपूर्ण रूप से - आपको रूट के पर्यावरण तक पहुंच प्रदान करता है, न कि केवल एक कमांड के रूप में आपके उपयोगकर्ता को उन्नत विशेषाधिकार के साथ।

दूसरा कमांड रूट क्रॉस्टैब को संपादित करेगा, आपका अपना नहीं।