नॉलेजबेस · Fantastico
Joomla द्वारा इंस्टॉल किए गए Joomla टेम्पलेट को FTP से संशोधित नहीं कर पा रहे हैं
अंतिम अपडेट 2020-04-05
यह समस्या उन सर्वरों पर आती है जिन पर SuExec/phpSuExec नहीं चल रहा होता। समाधान यह है कि कृपया फ़ाइलें FTP के माध्यम से अपलोड करें और फिर Joomla कॉम्पोनेंट/टेम्पलेट का मैन्युअल इंस्टॉलेशन करें।
इसकी व्याख्या यहाँ की गई है: http://forum.joomla.org/index.php/topic,30796.0.html। कारणों का सार इस प्रकार है, हम उद्धृत करते हैं:
"सबसे पहले... इससे कोई फ़र्क़ नहीं पड़ता कि Joomla की कोर फ़ाइलों का स्वामी आपका यूज़र है या httpd (या nobody, apache, या जो भी apache यूज़र हो)। फ़ाइल का स्वामित्व फ़ाइल बनते समय तय हो जाता है। यह उस यूज़र द्वारा तय होता है जिसके पास फ़ाइलसिस्टम में फ़ाइल बनाने वाली ऑपरेटिंग सिस्टम प्रोसेस का स्वामित्व होता है।
परिदृश्य: आप एक यूज़र के रूप में लॉग इन हैं और अपने पसंदीदा टेक्स्ट एडिटर (उदाहरण के लिए vi) से something.txt नाम की एक नई फ़ाइल बनाते हैं।
चूँकि आप अपने यूज़र के रूप में लॉग इन रहते हुए vi प्रोग्राम चलाते हैं (आगे हम मान लेंगे कि यूज़रनेम USER है), इसलिए फ़ाइलसिस्टम पर something.txt बनाने वाली vi प्रोसेस का स्वामी USER है। इसका अर्थ है कि फ़ाइल something.txt का स्वामी USER होगा।
परिदृश्य: आप FTP का उपयोग करके somethingElse.txt नाम की फ़ाइल अपलोड करते हैं।
चूँकि आपने अपने यूज़रनेम और पासवर्ड से FTP में लॉगिन किया है, इसलिए जिस FTP प्रोसेस पर आप काम कर रहे हैं, वह USER के स्वामित्व में चलने के लिए यूज़र बदल चुकी है। इसलिए जब somethingElse.txt फ़ाइल फ़ाइलसिस्टम पर अपलोड (निर्मित) होती है, तो उसका स्वामी वही होता है जो उसे बनाने वाली प्रोसेस का स्वामी है, यानी USER।
परिदृश्य: आप किसी php स्क्रिप्ट पर एक फ़ाइल अपलोड करते हैं, जो उसे yetSomethingElse.txt के रूप में सेव करती है (php के साथ suexec का उपयोग किए बिना)।
Apache सुरक्षा कारणों से अपनी प्रोसेस एक "विशेष" यूज़र के स्वामित्व में चलाता है, जिसका नाम अक्सर nobody, apache या httpd होता है, या कोई और नाम जो सिस्टम एडमिनिस्ट्रेटर कॉन्फ़िगरेशन फ़ाइल में रख देता है। यहाँ हम मान लेते हैं कि apache यूज़र का नाम httpd है। अब आप अपनी फ़ाइल php स्क्रिप्ट पर अपलोड करते हैं। Php एक apache मॉड्यूल में चल रही है, जो apache प्रोसेस में चल रहा है। अनुमान लगाइए कि उसका स्वामी कौन है? जी हाँ, यूज़र httpd। इसी कारण जब php move_uploaded_file() चलाकर फ़ाइल yetSomethingElse.txt सेव करती है, तो उसका स्वामी यूज़र httpd ही होता है। क्या यह php की कोई बग है? नहीं। क्या यह apache की बग है? नहीं। क्या यह php स्क्रिप्ट की बग है? नहीं। फ़ाइलसिस्टम में स्वामित्व इसी तरह काम करता है।
suexec एक ऐसा सिस्टम है जिसके द्वारा apache यूज़र बदलता है (Switches User) और प्रोसेस को निष्पादित करता है (EXECutes), यह उस यूज़र के आधार पर होता है जो अनुरोधित वर्चुअल होस्ट के document root का स्वामी है। (क्या आपने इसमें SUEXEC पकड़ा?) यह एक ऐसा समाधान है जो कुछ होस्टिंग प्रदाता उपलब्ध कराते हैं, और इसके ज़रिए apache प्रोसेस द्वारा बनाई या बदली गई सभी फ़ाइलें सही यूज़र के स्वामित्व में रहती हैं।
हो सकता है आप सोच रहे हों कि apache ऐसा व्यवहार क्यों करता है। मेरा सुझाव है कि ये सभी प्रश्न इन्हें भेजे जाएँ: http://www.apache.org
संक्षेप में, यह सिस्टम की कोई बग नहीं है, सिस्टम ठीक वैसे ही काम करने के लिए बनाया गया है। क्या इससे आपका काम आसान हो जाता है? नहीं। लेकिन यही इसका स्पष्टीकरण है। इसके कई संभावित विकल्प हैं, जिनमें से एक FTP क्लाइंट लेयर है जिसे मैंने 1.1 के लिए लिखा है।
लुई "
इसकी व्याख्या यहाँ की गई है: http://forum.joomla.org/index.php/topic,30796.0.html। कारणों का सार इस प्रकार है, हम उद्धृत करते हैं:
"सबसे पहले... इससे कोई फ़र्क़ नहीं पड़ता कि Joomla की कोर फ़ाइलों का स्वामी आपका यूज़र है या httpd (या nobody, apache, या जो भी apache यूज़र हो)। फ़ाइल का स्वामित्व फ़ाइल बनते समय तय हो जाता है। यह उस यूज़र द्वारा तय होता है जिसके पास फ़ाइलसिस्टम में फ़ाइल बनाने वाली ऑपरेटिंग सिस्टम प्रोसेस का स्वामित्व होता है।
परिदृश्य: आप एक यूज़र के रूप में लॉग इन हैं और अपने पसंदीदा टेक्स्ट एडिटर (उदाहरण के लिए vi) से something.txt नाम की एक नई फ़ाइल बनाते हैं।
चूँकि आप अपने यूज़र के रूप में लॉग इन रहते हुए vi प्रोग्राम चलाते हैं (आगे हम मान लेंगे कि यूज़रनेम USER है), इसलिए फ़ाइलसिस्टम पर something.txt बनाने वाली vi प्रोसेस का स्वामी USER है। इसका अर्थ है कि फ़ाइल something.txt का स्वामी USER होगा।
परिदृश्य: आप FTP का उपयोग करके somethingElse.txt नाम की फ़ाइल अपलोड करते हैं।
चूँकि आपने अपने यूज़रनेम और पासवर्ड से FTP में लॉगिन किया है, इसलिए जिस FTP प्रोसेस पर आप काम कर रहे हैं, वह USER के स्वामित्व में चलने के लिए यूज़र बदल चुकी है। इसलिए जब somethingElse.txt फ़ाइल फ़ाइलसिस्टम पर अपलोड (निर्मित) होती है, तो उसका स्वामी वही होता है जो उसे बनाने वाली प्रोसेस का स्वामी है, यानी USER।
परिदृश्य: आप किसी php स्क्रिप्ट पर एक फ़ाइल अपलोड करते हैं, जो उसे yetSomethingElse.txt के रूप में सेव करती है (php के साथ suexec का उपयोग किए बिना)।
Apache सुरक्षा कारणों से अपनी प्रोसेस एक "विशेष" यूज़र के स्वामित्व में चलाता है, जिसका नाम अक्सर nobody, apache या httpd होता है, या कोई और नाम जो सिस्टम एडमिनिस्ट्रेटर कॉन्फ़िगरेशन फ़ाइल में रख देता है। यहाँ हम मान लेते हैं कि apache यूज़र का नाम httpd है। अब आप अपनी फ़ाइल php स्क्रिप्ट पर अपलोड करते हैं। Php एक apache मॉड्यूल में चल रही है, जो apache प्रोसेस में चल रहा है। अनुमान लगाइए कि उसका स्वामी कौन है? जी हाँ, यूज़र httpd। इसी कारण जब php move_uploaded_file() चलाकर फ़ाइल yetSomethingElse.txt सेव करती है, तो उसका स्वामी यूज़र httpd ही होता है। क्या यह php की कोई बग है? नहीं। क्या यह apache की बग है? नहीं। क्या यह php स्क्रिप्ट की बग है? नहीं। फ़ाइलसिस्टम में स्वामित्व इसी तरह काम करता है।
suexec एक ऐसा सिस्टम है जिसके द्वारा apache यूज़र बदलता है (Switches User) और प्रोसेस को निष्पादित करता है (EXECutes), यह उस यूज़र के आधार पर होता है जो अनुरोधित वर्चुअल होस्ट के document root का स्वामी है। (क्या आपने इसमें SUEXEC पकड़ा?) यह एक ऐसा समाधान है जो कुछ होस्टिंग प्रदाता उपलब्ध कराते हैं, और इसके ज़रिए apache प्रोसेस द्वारा बनाई या बदली गई सभी फ़ाइलें सही यूज़र के स्वामित्व में रहती हैं।
हो सकता है आप सोच रहे हों कि apache ऐसा व्यवहार क्यों करता है। मेरा सुझाव है कि ये सभी प्रश्न इन्हें भेजे जाएँ: http://www.apache.org
संक्षेप में, यह सिस्टम की कोई बग नहीं है, सिस्टम ठीक वैसे ही काम करने के लिए बनाया गया है। क्या इससे आपका काम आसान हो जाता है? नहीं। लेकिन यही इसका स्पष्टीकरण है। इसके कई संभावित विकल्प हैं, जिनमें से एक FTP क्लाइंट लेयर है जिसे मैंने 1.1 के लिए लिखा है।
लुई "
Tell us what you need
Compare available plans or describe your workload so we can discuss a suitable starting point.