Nginx के लिए conf.d निर्देशिका बनाम उपलब्ध साइटों के लिए अलग-अलग उपयोग क्या है

Question

मेरे पास linux का उपयोग करने का कुछ अनुभव है लेकिन nginx का उपयोग करने वाला कोई नहीं है। मुझे एक एप्लिकेशन सर्वर के लिए लोड-बैलेंसिंग विकल्पों पर शोध करने का काम सौंपा गया है।

मैं apt-nginx स्थापित करने के लिए इस्तेमाल किया है और सब ठीक लगता है।

मेरे पास दो सवाल है।

साइट-उपलब्ध फ़ोल्डर और conf.d फ़ोल्डर के बीच अंतर क्या है। उन दोनों फ़ोल्डरों को nginx के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन सेटअप में शामिल किया गया था। ट्यूटोरियल दोनों का उपयोग करते हैं। वे किस लिए हैं और सबसे अच्छा अभ्यास क्या है?

साइट-सक्षम फ़ोल्डर किसके लिए उपयोग किया जाता है? मैं इसे कैसे इस्तेमाल करूं?

डिफ़ॉल्ट कॉन्फ़िगरेशन www-डेटा उपयोगकर्ता को संदर्भित करता है? क्या मुझे वह उपयोगकर्ता बनाना है? मैं उस उपयोगकर्ता को nginx चलाने की अधिकतम अनुमति कैसे दे सकता हूं?

Comments

प्रश्न पूछते समय स्कोप रेंगने से बचने की कोशिश करें; www-dataएक अलग विषय है। अधिकांश ऑपरेटिंग सिस्टम कम अनुमतियों के साथ एक अलग उपयोगकर्ता को परिभाषित करते हैं जो प्रक्रिया को 80 के रूप में रूट करने के लिए बाइंड करने के बाद चला सकते हैं। यह विन्यास फाइल में परिभाषित है। वहां से बुनियादी सुरक्षा प्रथाओं को लागू करें; उपयोगकर्ता को कुछ भी लिखने की अनुमति न दें वेबसर्वर को लिखने की आवश्यकता नहीं होनी चाहिए, अन्य उपयोगकर्ताओं को फ़ाइलों को लिखने की अनुमति न दें जब तक कि यह जानबूझकर न हो।

— एंड्रयू बी

Answer 1

साइटें- * फ़ोल्डर द्वारा प्रबंधित nginx_ensiteऔर nginx_dissite। अपाचे httpd उपयोगकर्ताओं के लिए जो इसे एक खोज के साथ पाते हैं, समकक्ष a2ensite/ है a2dissite।

sites-availableफ़ोल्डर संग्रहीत करने के लिए है सब अपने vhost विन्यास की, या नहीं, वे वर्तमान में सक्षम रहे हैं।

sites-enabledफ़ोल्डर साइटों से उपलब्ध फ़ोल्डर में फ़ाइलें करने के लिए सिमलिंक शामिल हैं। यह आपको सिम्लेक्स को हटाकर vhosts को चुनिंदा रूप से अक्षम करने की अनुमति देता है।

conf.dकाम करता है, लेकिन आपको कुछ चीज़ों को फ़ोल्डर से बाहर करना होगा, इसे हटाना होगा, या कुछ को अक्षम करने की आवश्यकता होने पर उसमें बदलाव करना होगा। साइट्स- * फोल्डर एब्सट्रैक्ट चीजों को थोड़ा और व्यवस्थित बनाता है और आपको उन्हें अलग-अलग समर्थन स्क्रिप्ट के साथ प्रबंधित करने की अनुमति देता है।

(जब तक आप मेरे जैसे नहीं हैं, और कई डेबियन एडिंस में से एक हैं, जो स्क्रिप्ट के बारे में नहीं जानते हुए सीधे सिम्बलिंक्स को प्रबंधित करते हैं ...)

Comments

क्या मुझे कुछ गड़बड़ लगी? अधोगति को नहीं समझ रहा है।

— एंड्रयू बी

मैं उत्सुक हूँ कि यह नगीने में बनाया गया है? मैंने मैन्युअल रूप से github.com/perusio/nginx_ensite

— lfender6445

यह ध्यान रखना महत्वपूर्ण है कि sites-available|sites-enabledएक डेबियन-इसम है और ऐसा कुछ नहीं है जो नगीनेक्स या अपाचे करते हैं। यह शायद अतीत में काफी उपयोगी था, लेकिन इसकी उपयोगिता कुछ हद तक कॉन्फ़िगरेशन प्रबंधन और कंटेनरों में सीमित है।

— माइकल हैम्पटन

क्या आप टिप्पणी कर सकते हैं कि विन्यास प्रबंधन और कंटेनर साइटों की उपयोगिता को कैसे सीमित करते हैं?

— कार्तिक वी

@Kthikvee बिंदु यह है कि आजकल सर्वर अक्सर एपेमेरिकल कंटेनरों के रूप में दिखाई देते हैं जो केवल एक ही वेबसाइट / सेवा की सेवा करते हैं, इसलिए इसे nginx.confबिना किसी नुकसान के पठनीयता में शामिल किया जा सकता है। यह कुछ साल पहले के दृष्टिकोण के विपरीत है जब सर्वर सामान्य रूप से दसियों वेबसाइटों को संग्रहीत करेगा।

— अदाम्जी जू

Answer 2

मैं पिछले उत्तरों में जोड़ना चाहूंगा कि सबसे महत्वपूर्ण यह नहीं है कि आप निर्देशिकाओं को कैसे बुलाते हैं (हालांकि यह एक बहुत ही उपयोगी सम्मेलन है), लेकिन आप वास्तव में क्या डालते हैं nginx.conf। उदाहरण विन्यास:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

यहां इस्तेमाल केवल निर्देश शामिल है , इसलिए जैसे conf.d/और के बीच कोई आंतरिक अंतर नहीं है sites-enabled/।

उपरोक्त दस्तावेज से:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

इसलिए, मूल प्रश्न का उत्तर देने के लिए: कोई आंतरिक अंतर नहीं है, और आप उनका उपयोग सबसे अच्छे तरीके से कर सकते हैं, अन्य उत्तरों से सलाह याद रखना। और कृपया, 'सही' उत्तर चुनना न भूलें।

Comments

ठीक है, sites-enabledकुछ हद तक कुछ ditribution द्वारा आविष्कार किया गया है, चारों ओर एक कष्टप्रद मध्यवर्ती करता है fuzzing। आधिकारिक स्रोत से नगीने को पकड़ो : आपको एक अप-टू-डेट उत्पाद मिलेगा, साथ ही इस कॉन्फ़िगरेशन बकवास / नरक से छुटकारा मिलेगा।

— बर्नार्ड रॉसैट

यह बताता है कि आधिकारिक नेग्नेक्स प्रलेखन पर इस नाम सम्मेलन का एक भी संदर्भ क्यों नहीं है। यह एक थर्ड पार्टी प्रोजेक्ट है! github.com/perusio/nginx_ensite

— AxeEffect

Answer 3

आमतौर पर, sites-enabledफ़ोल्डर का उपयोग वर्चुअल होस्ट परिभाषाओं के conf.dलिए किया जाता है , जबकि वैश्विक सर्वर कॉन्फ़िगरेशन के लिए उपयोग किया जाता है। यदि आप कई वेब साइटों का समर्थन कर रहे हैं - यानी, वर्चुअल होस्ट - तो हर एक की अपनी फ़ाइल मिलती है, इसलिए आप फ़ाइलों को अंदर और बाहर ले जाकर sites-enabled(या बनाने और निकालने के लिए) बहुत आसानी से सक्षम और अक्षम कर सकते हैं , जो संभवतः है एक बेहतर विचार)।

conf.dमॉड्यूल लोड करने, लॉग फ़ाइलों और अन्य चीजों के लिए उपयोग करें जो किसी एकल वर्चुअल होस्ट के लिए विशिष्ट नहीं हैं।

डिफ़ॉल्ट कॉन्फ़िगरेशन www-डेटा उपयोगकर्ता को संदर्भित करता है? क्या मुझे वह उपयोगकर्ता बनाना है?

आपके पास एक नॉन-रूट उपयोगकर्ता के रूप में नगनेक्स होना चाहिए। यह कुछ मामलों में नामित है www-data, लेकिन आप इसे अपनी इच्छानुसार कुछ भी नाम दे सकते हैं।

मैं उस उपयोगकर्ता को nginx चलाने की अधिकतम अनुमति कैसे दे सकता हूं?

मैं इस प्रश्न के उत्तर से कम निश्चित हूं (मैं इस समय nginx नहीं चल रहा हूं), लेकिन अगर यह अपाचे की तरह कुछ भी है तो उत्तर यह है कि www-dataउपयोगकर्ता को केवल किसी भी स्थिर फ़ाइलों को पढ़ने की अनुमति है (और पढ़ें + निर्देशिकाओं पर अमल करें) ) जो आप सेवारत हैं, या CGI लिपियों जैसी चीजों पर अनुमतियों को पढ़ने / निष्पादित करने, और कहीं भी कोई अनुमति नहीं देते हैं।

Comments

वैध शेल रिकॉर्ड को हटाकर इस उपयोगकर्ता के लिए लॉगिन क्षमता को अक्षम करने के कारण वेब सर्वर चलाने के लिए एक समर्पित उपयोगकर्ता होना भी महत्वपूर्ण है।

— ड्यूकलाइन

> 'आपके पास नॉन-रूट उपयोगकर्ता के रूप में चलने वाला नग्नेक्स होना चाहिए' - क्या आप इसके बारे में अधिक विस्तार से बता सकते हैं?

— lfender6445

एक अनपेक्षित उपयोगकर्ता के रूप में चलाना नुकसान से युक्त होने का एक तरीका है जो दूरस्थ समझौता से उत्पन्न हो सकता है। यदि आप एक वेबसर्वर के रूप में चला रहे हैं rootऔर किसी प्रकार का एक दूरस्थ समझौता है, तो हमलावर को तुरंत सिस्टम तक पूरी पहुंच है। जब एक अनपेक्षित उपयोगकर्ता के रूप में चल रहा है, तो प्रशासनिक पहुंच केवल स्थानीय शोषण के कुछ प्रकार के संयोजन में उपलब्ध होगी।

— लार्क्स

Answer 4

क्या चल रहा है?

आप डेबियन या उबंटू का उपयोग कर रहे होंगे, क्योंकि बुराई sites-available / sites-enabledतर्क nginx के अपस्ट्रीम पैकेजिंग http://nginx.org/packages/ से उपयोग नहीं किया गया है ।

या तो मामले में, दोनों को मानक includeनिर्देश की मदद से कॉन्फ़िगरेशन कन्वेंशन के रूप में लागू किया जाता है /etc/nginx/nginx.conf।

यहाँ /etc/nginx/nginx.confnginx.org से nginx के आधिकारिक अपस्ट्रीम पैकेज से एक स्निपेट दिया गया है:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

यहाँ /etc/nginx/nginx.confडेबियन / उबंटू से एक स्निपेट दिया गया है :

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

तो, एनजीआईएनएक्स के दृष्टिकोण से, केवल अंतर यह होगा कि फाइलों को conf.dजल्दी से संसाधित किया जा सकता है, और, जैसे कि, यदि आपके पास कॉन्फ़िगरेशन हैं जो चुपचाप एक-दूसरे के साथ संघर्ष करते हैं, तो उन conf.dलोगों में से उन पर पूर्ववर्ती हो सकता है sites-enabled।

---

बेस्ट प्रैक्टिस है conf.d।

आपको /etc/nginx/conf.dएक मानक सम्मेलन के रूप में उपयोग करना चाहिए , और कहीं भी काम करना चाहिए।

यदि आपको किसी साइट को निष्क्रिय करने की आवश्यकता है, तो बस नाम बदलने के लिए अब .confप्रत्यय नहीं है, बहुत आसान, सरल और त्रुटि-प्रूफ:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

या किसी साइट को सक्षम करने के लिए विपरीत :

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

---

बचें sites-availableऔर sites-enabledहर कीमत पर।

मैं पूरी तरह से उपयोग करने का कोई कारण नहीं देखता sites-available/ sites-enabled:

• कुछ लोगों ने उल्लेख किया है nginx_ensiteऔर nginx_dissiteलिपियों - इन लिपियों के नाम इस पराजय के बाकी हिस्सों की तुलना में भी बदतर हैं - लेकिन ये स्क्रिप्ट भी कहीं नहीं पाए जाते हैं - वे nginxडेबियन में पैकेज से अनुपस्थित हैं (और शायद उबंटू में भी) , और अपने स्वयं के पैकेज में मौजूद नहीं है, या तो, साथ ही, क्या आपको वास्तव में दो निर्देशिकाओं के बीच फ़ाइलों को स्थानांतरित करने और / या लिंक करने के लिए एक पूरे गैर-मानक तृतीय-पक्ष स्क्रिप्ट की आवश्यकता है?

• और यदि आप लिपियों का उपयोग नहीं कर रहे हैं (जो वास्तव में, ऊपर के अनुसार एक स्मार्ट विकल्प है), तो इस बात का मुद्दा आता है कि आप साइटों का प्रबंधन कैसे करते हैं:

  • आप से सांकेतिक लिंक बना सकता हूँ sites-availableकरने के लिए sites-enabled?
  • फ़ाइलों की प्रतिलिपि बनाएँ?
  • फ़ाइलों को स्थानांतरित करें?
  • फ़ाइलों को जगह में संपादित करें sites-enabled?

उपरोक्त कुछ मामूली मुद्दों से निपटने के लिए लग सकता है, जब तक कि कई लोग सिस्टम का प्रबंधन शुरू नहीं करते हैं, या जब तक आप एक त्वरित निर्णय नहीं लेते हैं, केवल लाइन के नीचे महीनों या वर्षों के बारे में भूलने के लिए…

जो हमें लाता है:

• क्या किसी फ़ाइल को निकालना सुरक्षित है sites-enabled? क्या यह सॉफ्ट लिंक है? एक कड़ी? या विन्यास की एकमात्र प्रति? विन्यास नरक का एक प्रमुख उदाहरण।

• किन साइटों को अक्षम किया गया है? (के साथ conf.d, बस फ़ाइलों के लिए एक उलटा खोज करते हैं .conf- के साथ समाप्त नहीं find /etc/nginx/conf.d -not -name "*.conf", या उपयोग करें grep -v।)

न केवल उपरोक्त सभी, बल्कि includeडेबियन / उबंटू द्वारा उपयोग किए जाने वाले विशिष्ट निर्देश पर भी ध्यान दें - /etc/nginx/sites-enabled/*- इसके लिए कोई फ़ाइल नाम प्रत्यय निर्दिष्ट sites-enabledनहीं किया गया है conf.d।

• क्या इसका मतलब यह है कि अगर एक दिन आप जल्दी से एक फ़ाइल या दो के भीतर संपादित करना तय है /etc/nginx/sites-enabledआपकी, और emacsएक बैकअप फ़ाइल बनाता है की तरह default~है, तो, अचानक, तुम दोनों है defaultऔर default~के रूप में सक्रिय विन्यास, जो इस्तेमाल किया निर्देशों निर्भर करता है, यहां तक कि देना नहीं कर सकते हैं शामिल आप किसी भी चेतावनी, और जगह लेने के लिए एक लंबे समय तक डिबगिंग सत्र का कारण। (हां, मेरे साथ ऐसा हुआ; यह एक हैकथॉन के दौरान था, और मैं पूरी तरह से हैरान था कि मेरा आत्मविश्वास क्यों काम कर रहा था।)

इस प्रकार, मुझे विश्वास है कि sites-enabledशुद्ध बुराई है!

Comments

उपरोक्त सभी के अलावा, जाहिरा तौर पर, गलत सिम्बलिंक बनाना भी बहुत आम है! stackoverflow.com/a/14107803/1122270 बस मामले में आपको नहीं लगता sites-enabledथा कि यह काफी बुरा था!

— cnst

या, कभी-कभी, ऐसा हो सकता है कि कोई व्यक्ति फ़ाइलों को संपादित करने का निर्णय लेता है sites-enabled, फिर भी कोई अन्य व्यक्ति इसे हटाकर इसे अक्षम करने का निर्णय लेता है, संभवतः यह सोचकर कि यह केवल एक सिम्लिंक था, इसके लिए नॅन्गैक्स हीप की मेमोरी डंप की आवश्यकता होती है, जो कि गोपनीय फाइल को पुनर्प्राप्त करने के लिए होती है। stackoverflow.com/q/45852224/1122270

— cnst

मैं के बारे में दावे से सहमत नहीं है sites-availableऔर sites-enabled; 'लाइव' पिकअप डायरेक्टरी के बाहर कॉन्फिग फाइल्स तैयार करने में सक्षम होना जरूरी है जैसे कि अगर नग्नेक्स को फिर से लोड किया गया या रीस्टार्ट किया गया तो यह आंशिक कॉन्फिग फाइल्स को नहीं उठाएगा। यह उन फ़ाइलों को रखने के लिए भी उपयोगी हो सकता है जो अब सक्रिय उपयोग में नहीं हैं। यदि आप पहली बार में nginx का प्रबंधन करने के लिए पर्याप्त अनुभव का अनुभव करते हैं, तो सीमलिंक बनाना कोई विशेष मुश्किल काम नहीं है।

— BE77Y

@ BE77Y आप अधिक जटिल दृष्टिकोण अपना रहे हैं। प्रोग्रामिंग में, इसे अप्रयुक्त कोड को पूरी तरह से हटाने के लिए सबसे अच्छा अभ्यास माना जाता है, न कि इसे अक्षम या टिप्पणी करना; मुझे कोई कारण नहीं दिखता है कि देवओप्स को अलग क्यों होना चाहिए - यदि किसी कॉन्फ़िगरेशन की अब आवश्यकता नहीं है, तो इसे हटा दें (यह आपके सीसीएस में अभी भी मौजूद होना चाहिए)। आंशिक गोपनीय फ़ाइलों के साथ समान - आप उन्हें सक्षम क्यों संपादित करेंगे और आपकी पीठ के पीछे nginx पुनः लोड किया जाएगा? ( USR1, जो लॉग को फिर से खोलता है, फिर से लोड नहीं करता है।) मुझे आपकी सहानुभूति "अनुभव" टिप्पणियों को गलत तरीके से मिली है - समस्या एक सुसंगतता का मामला है, जिसका अनुभव के साथ बहुत कम संबंध है।

— cnst 22'17

यह स्पष्ट है कि क) यह इस चर्चा के लिए उपयुक्त माध्यम नहीं है और शायद इससे भी महत्वपूर्ण बात यह है कि ख) यह किसी भी मामले में फलहीन होने की संभावना है। और कोई बहस नहीं चाहिए।

— BE77Y