/Etc/apt/source.list.d के ऊपर /etc/apt/source.list पर क्या लाभ है

Question

मुझे पता है कि यह सवाल पहले भी पूछा जा चुका है, लेकिन मैं इसका जवाब स्वीकार नहीं करता, "आप स्पष्ट रूप से कस्टम परिवर्धन देख सकते हैं"। जब मैं पीपा जोड़ता हूं (जो मैंने वर्षों में नहीं किया है), तो मैंने "एंटर" लेबल वाले अपने कीबोर्ड पर एक कुंजी मारा जो मुझे नई प्रविष्टि से पहले एक खाली लाइन जोड़ने की अनुमति देता है (मैं एक व्याख्यात्मक टिप्पणी भी जोड़ूंगा, लेकिन मैं एक हूं तकनीक लेखक, इसलिए ....)। मुझे अपना sources.confस्वच्छ और साफ-सुथरा पसंद है ।

/etc/apt/sources.d

इसका मतलब है कि मेरे पास सिर्फ एक के बजाय पार्स करने के लिए आधा दर्जन फाइलें हैं।

AFAIK, वहाँ है "बिल्कुल" एक कॉन्फ़िगरेशन फ़ाइल बनाम 6 में होने का कोई फायदा नहीं है (तर्क के लिए, शायद आपके पास 3 या 2 है, कोई फर्क नहीं पड़ता ... 1 अभी भी 2 धड़कता है)।

क्या कोई कृपया तर्कसंगत लाभ उठा सकता है, "आप स्पष्ट रूप से कस्टम परिवर्धन देख सकते हैं" एक गरीब व्यक्ति का बहाना है।

मुझे जोड़ना होगा, मैं परिवर्तन से प्यार करता हूं, हालांकि, केवल जब परिवर्तन द्वारा पेश किए गए लाभ हैं।

पहली प्रतिक्रिया के बाद संपादित करें:

यह नई स्थापनाओं की अनुमति देता है जिनके लिए अपने स्वयं के रिपॉज की आवश्यकता होती है, ताकि यह सुनिश्चित करने के लिए कि वह डुप्लिकेट प्रविष्टियों को नहीं जोड़ रहा है, एक फ्लैट फ़ाइल की खोज न हो।

अब, उन्हें एक फ्लैट फ़ाइल के बजाय डूप के लिए एक निर्देशिका खोजना होगा। जब तक वे मानते हैं कि व्यवस्थापक चीजों को नहीं बदलते हैं ...

यह एक सिस्टम प्रशासक को आसानी से निष्क्रिय करने (नाम बदलने के द्वारा) या एक अखंड फाइल को संपादित किए बिना एक रिपॉजिटरी सेट को हटाने (हटाने के द्वारा) की अनुमति देता है।

व्यवस्थापक को नाम बदलने के लिए उपयुक्त फ़ाइल ढूंढने के लिए निर्देशिका को grep करना होगा, इससे पहले, वह One फ़ाइल खोजेगा और एक पंक्ति, एक वन-लाइनर "लगभग" किसी भी व्यवस्थापक के लिए टिप्पणी करेगा।

यह संकुल अनुरक्षक को असंबंधित रिपॉजिटरी के लिए अनजाने में कॉन्फ़िगरेशन बदलने के बारे में चिंता किए बिना रिपॉजिटरी स्थानों को अपडेट करने के लिए एक साधारण कमांड देने की अनुमति देता है।

मुझे यह समझ में नहीं आ रहा है, मैं "ग्रहण" पैकेज अनुरक्षक को अपने भंडार का URL जानता हूं। फिर, sedएक फ़ाइल के बजाय एक निर्देशिका के लिए है।

Comments

टिप्पणी और प्रश्न संपादन जल्दी से "सवाल का जवाब देने की कोशिश" से "समस्या के अस्तित्व के बारे में शेख़ी" करने के लिए बह गए हैं। उपयोगी टिप्पणियां पहले से ही स्वीकृत उत्तर में दिखाई देती हैं

— माइकल मिरोज़ेक

Answer 1

तकनीकी स्तर पर, कुछ बड़े और लोकप्रिय सिस्टम इन्फ़ॉर्मेशन टूल में इन परिवर्तनों को संभालने वाले व्यक्ति के रूप में, मूल रूप से यह इस के लिए नीचे आता है:

सूत्रों के लिए।

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

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

सूत्रों के लिए

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Google Chrome देवों ने Google Chrome स्रोतों की उपस्थिति के लिए जाँच नहीं की, सटीक फ़ाइल नाम पर भरोसा करते हुए उनका Chrome पैकेज मौजूद होगा। अन्य सभी मामलों में, वे source.list.d में एक नई फ़ाइल बनाएंगे, जैसा कि वे चाहते थे।

यह देखने के लिए कि आपके पास कौन से स्रोत हैं, ज़ाहिर है, यह इतना सुंदर नहीं है, क्योंकि आपको पढ़ने और बनाए रखने में आसानी नहीं हो सकती है:

cat /etc/sources.list

तो यह मूल रूप से स्वचालित अपडेट के उद्देश्य से किया गया था, और उपयोगकर्ताओं को आप जो भी बता सकते हैं, उसे आसान एकल कमांड प्रदान करने के लिए। उपयोगकर्ताओं के लिए, इसका मतलब है कि उन्हें 1 फ़ाइल के बजाय कई फ़ाइलों को पढ़ना है, यह देखने के लिए कि क्या उनके पास रेपो जोड़ा गया है, और उपयुक्त के लिए, इसका मतलब है कि उन्हें एक फ़ाइल के बजाय कई फ़ाइलों को पढ़ना होगा।

चूंकि वास्तविक दुनिया में, यदि आप यह अच्छी तरह से करने जा रहे थे, तो आपको सभी फाइलों के खिलाफ चेक का समर्थन करना होगा, चाहे वे किसी भी नाम के हों, और फिर परीक्षण करें कि क्या कार्रवाई की जानी चाहिए या नहीं।

हालाँकि, यदि आप इसे अच्छी तरह से करने नहीं जा रहे हैं, तो आप चेक को यह देखने के लिए अनदेखा कर देंगे कि क्या आइटम स्रोतों में कहीं है, और फ़ाइल नाम के लिए जाँच करें। मेरा मानना ​​है कि सबसे अधिक स्वचालित सामान क्या करता है, लेकिन अंत में, मुझे बस सब कुछ जांचना था, इसलिए मैं इसे सूचीबद्ध कर सकता हूं और अगर कोई उन फ़ाइलों में से एक पर आधारित है, तो केवल वास्तविक परिणाम इसे और अधिक जटिल बना रहा था।

थोक संपादन

कई सर्वरों को चलाने के लिए, मुझे केवल एक रात के काम की स्क्रिप्ट पर प्रलोभन दिया जाएगा जो /etc/apt/sources.list.d/ के माध्यम से लूप करता है और यह सुनिश्चित करने के लिए पहले चेक करता है कि आइटम source.list में पहले से ही नहीं है, फिर अगर यह नहीं, तो उस आइटम को source.list में जोड़ें। source.list.d फ़ाइल को हटा दें, और यदि पहले से source.list में है, तो केवल source.list.d फ़ाइल को हटा दें

चूंकि सादगी और रखरखाव में आसानी से परे केवल स्रोतों का उपयोग करने के लिए कोई नकारात्मक है। कुछ ऐसा जोड़ना एक बुरा विचार नहीं हो सकता है, विशेष रूप से sys व्यवस्थापक द्वारा रचनात्मक यादृच्छिक क्रियाएं दी गई हैं।

जैसा कि ऊपर टिप्पणी में कहा गया है, inxi -r बड़े करीने से सक्रिय प्रतिनिधि प्रति फ़ाइल प्रिंट करेगा, लेकिन निश्चित रूप से उन्हें संपादित या परिवर्तित नहीं करेगा, इसलिए यह केवल आधा समाधान होगा। यदि यह कई वितरण है, तो यह सीखने का एक दर्द है कि प्रत्येक यह कैसे करता है, यह सुनिश्चित करने के लिए है, और यादृच्छिकता निश्चित रूप से अपवाद के बजाय नियम है।

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— terdon

Answer 2

प्रत्येक रिपॉजिटरी (या रिपॉजिटरी का संग्रह) की अपनी फाइल में होने से इसे हाथ और प्रोग्राम दोनों द्वारा प्रबंधित करना आसान हो जाता है:

• यह नई स्थापनाओं की अनुमति देता है जिनके लिए अपने स्वयं के रिपॉज की आवश्यकता होती है, ताकि यह सुनिश्चित करने के लिए कि वह डुप्लिकेट प्रविष्टियों को नहीं जोड़ रहा है, एक फ्लैट फ़ाइल की खोज न हो।
• यह एक सिस्टम प्रशासक को आसानी से निष्क्रिय करने (नाम बदलने के द्वारा) या एक अखंड फाइल को संपादित किए बिना एक रिपॉजिटरी सेट को हटाने (हटाने के द्वारा) की अनुमति देता है।
• यह संकुल अनुचर को एक साधारण कमांड देने के लिए रिपॉजिटरी स्थानों को अपडेट करने की अनुमति देता है, अनजाने में असंबंधित रिपॉजिटरी के लिए कॉन्फ़िगरेशन को बदलने के बारे में चिंता किए बिना।

Comments

यह स्वीकृत उत्तर से बेहतर है ... मुख्य अवधारणा "स्वामित्व" है। .dडिजाइन स्पष्ट रूप से अलग संस्थाओं के स्वामित्व विन्यास राज्य अलग करती है। एक पैकेज के स्वामित्व में हो सकता है। एक अन्य के माध्यम से स्थापित किया जा सकता है wget ...। एक सिंगल मॉन्स्टर फ़ाइल के साथ, कोई भी स्वचालित या अर्ध-स्वचालित प्रक्रिया "पता" कैसे करती है कि यह किस टुकड़े का मालिक है? यह नहीं है, यही वजह है कि .dडिजाइन बेहतर है।

— निमो

'हाथ से' के बारे में निश्चित नहीं है, लेकिन मैंने ऐसा सालों से नहीं किया है। यह प्रोग्रामेटिक मैनेजमेंट को फायदा पहुंचाता है। कठपुतली जैसे विन्यास प्रबंधन सॉफ्टवेयर का उपयोग करते समय, लाइनों को जोड़ने या हटाने के लिए फ़ाइल को पार्स करने के बजाय, डीआईआर में फ़ाइल को केवल गिराना या हटाना आसान होता है। खासकर तब से जब कई स्वतंत्र मॉड्यूल से एक 'फाइल' संसाधन का प्रबंधन करने से बचा जाता है। मैं इस कारण से ".d" dirs के उबंटू के व्यापक उपयोग की सराहना करता हूं।

— मार्टिज़न हेमेल्स

@MartijnHeemels अगर मैं कर सकता तो मैं आपकी टिप्पणी को सौ बार बढ़ा देता। मेरे लिए व्यक्तिगत रूप से, .dडिज़ाइन के लाभों को तुरंत ध्यान केंद्रित में तड़कने के बाद मैंने एक बार भारी कठपुतली / नमक विन्यास प्रबंधन करना शुरू कर दिया।

— स्मितली

@ मोटे तौर पर, यदि आपके व्यवस्थापक आपको बेवकूफ बनाने की कोशिश करते हैं, तो आपको अधिक भरोसेमंद व्यवस्थापक मिल जाने चाहिए। कॉलिंग जो मैं (या वास्तव में किसी को) लिखता हूं, "बिल्कुल बकवास" है, सबसे अच्छा, अशिष्ट।

— डोपघोटी

ऑप्स के नजरिए से इसकी पुष्टि करते हैं। सम्पूर्ण फाइलों का प्रावधान और स्वामित्व या तो विशिष्ट पैकेजों के द्वारा, या आपके कॉन्फिग मैनेजमेंट सिस्टम के मॉड्यूल्स के द्वारा होता है, जो आपके द्वारा कॉन्फ़िगर किए गए प्रत्येक एप्लिकेशन के लिए मक्खी पर एक पार्सर लिखने की कोशिश करने से ज्यादा साफ-सुथरा होता है। यह केवल उपयुक्त के लिए तुच्छ लग सकता है, लेकिन फिर आपको कई अन्य सिस्टम मिलते हैं जो एक ही रणनीति (लॉगरोट, क्रोन, sysctl, sudoers, rsyslog, modprobe, ... service.d/*फ़ाइलों के लोड को कॉन्फ़िगर कर सकते हैं) का उपयोग कर सकते हैं फ़ाइलों को तैनात करने के बजाय मौजूदा मोड को संशोधित करना। लोग छवि कैशिंग / तुलना के लिए भी बेहतर हैं।

— विराटपुर

Answer 3

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

विशेष रूप से इसलिए कि एक एकल 'फ़ाइल' संसाधन की सामग्री का प्रबंधन करने से बचा जाता है, उदाहरण के लिए: /etc/apt/sources.listकई स्वतंत्र मॉड्यूल से जो कि तीसरे पक्ष द्वारा लिखे गए हैं।

मैं इस विशेष कारण के लिए ".d" dirs के Ubuntu के व्यापक उपयोग की सराहना करता हूं, अर्थात sudoers.d, rsyslog.d, sysctl.d।, cron.d, logrotate.d, आदि।

Answer 4

जैसा कि नीमो ने एक टिप्पणी में बताया, एक निर्देशिका के प्रमुख लाभों में से एक यह है कि यह "स्वामित्व" की धारणा के लिए अनुमति देता है।

आधुनिक लिनक्स वितरण और इंस्टॉलर सभी संकुल के विचार के आसपास आधारित हैं - सॉफ्टवेयर के स्वतंत्र टुकड़े जो जितना संभव हो, परमाणु में जोड़ा और हटाया जा सकता है। जब भी आप dpkg(और इसलिए apt) के साथ एक पैकेज स्थापित करते हैं , तो यह ट्रैक रखता है कि सिस्टम पर कौन सी फाइलें उस इंस्टॉलर द्वारा बनाई गई थीं। पैकेज को अनइंस्टॉल करने से मोटे तौर पर उन फाइलों को हटाने का काम हो सकता है।

वर्तमान में स्वीकार जवाब एक बुरी बात एक गूगल क्रोम संस्थापक मान लिया है कि है कि यह केवल बनाना चाहिए या स्थान यह उम्मीद में एक प्रविष्टि हटाने के लिए, लेकिन स्वचालित कुछ भी भयानक बढ़त मामलों के सभी प्रकार के लिए और सुराग के रूप में यह लेता है; उदाहरण के लिए:

• यदि sources.listइंस्टॉल करते समय लाइन मौजूद है , लेकिन टिप्पणी की गई है, तो क्या इंस्टॉलर को इसे अनइंस्टाल करना चाहिए, या डुप्लिकेट जोड़ना चाहिए?
• यदि अनइंस्टॉलर लाइन को हटा देता है, लेकिन उपयोगकर्ता ने इसके आगे टिप्पणी को जोड़ा या संपादित किया है, तो फ़ाइल को टूटी हुई टिप्पणी के साथ छोड़ दिया जाएगा।
• यदि उपयोगकर्ता ने मैन्युअल रूप से लाइन को जोड़ा है, तो इंस्टॉलर इसे जोड़ने के लिए नहीं जान सकता है; लेकिन अनइंस्टालर कैसे इसे हटाने के लिए नहीं पता होगा?

स्वामित्व के लिए अलग फ़ाइलों की आवश्यकता नहीं है; उदाहरण के लिए, इंस्टॉलर टिप्पणियों के एक ब्लॉक को यह कहते हुए शामिल कर सकता है कि यह लाइनों के एक विशेष सेट का "मालिक" है। उस मामले में, यह हमेशा उस सटीक ब्लॉक के लिए फ़ाइल खोजेगा, उसी रिपॉजिटरी के कुछ अन्य उल्लेख के लिए नहीं।

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

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

Answer 5

यह स्क्रिप्ट्स का सहारा लिए बिना अतिरिक्त स्रोतों को जोड़ने की अनुमति देता है।

उदाहरण के लिए, जब आप Microsoft का Skype पैकेज स्थापित करते हैं, तो skype.com का एक स्रोत अपडेट डाउनलोड करने के लिए स्वचालित रूप से कॉन्फ़िगर हो जाता है; सिस्टम से Skype पैकेज को निकालना भी इस पैकेज स्रोत को फिर से अक्षम करता है।

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

Answer 6

मुझे यकीन नहीं है कि एक अच्छा कारण है - इसके अलावा यह फैशनेबल लगता है। मेरे लिए, यह एक नियम को तोड़ता है कि एक निर्देशिका या तो एक पत्ती या एक नोड होनी चाहिए - अर्थात इसमें केवल फाइलें या निर्देशिकाएं होनी चाहिए, दोनों का मिश्रण नहीं।

मुझे लगता है कि यह फ़ाइलों को छोटा बनाता है, इसलिए पढ़ना आसान है - उदाहरण के लिए सुडो नियमों के मामले में, जो काफी लंबा हो सकता है, इससे एक प्रकार के उपयोगकर्ता के लिए नियमों का मानकीकृत सेट होना आसान हो जाता है (एक डेवलपर कहते हैं ), और अगर यह मशीन पर sudo करने के लिए अनुमति दी जानी चाहिए विन्यास निर्देशिका में जोड़ने; इस प्रकार आपको कम फ़ाइलों को बनाए रखने की आवश्यकता है - केवल देवों के लिए एक फ़ाइल, व्यवस्थापक के लिए, sysops के लिए, आदि, इसके बजाय हर संभव संयोजन के लिए।

वहां, मैंने खुद को प्रतिवाद किया है।

Comments

मैं एक नियम के रूप में "एक निर्देशिका या तो एक पत्ती या एक नोड नहीं होना चाहिए"। एक आकस्मिक उदाहरण के रूप में देखें /var/log। एक साधारण डेमॉन एक एकमात्र फाइल को सीधे अंदर लिख सकता है /var/log/simple.log:। : एक और अधिक जटिल डेमॉन अपनी ही उपनिर्देशिका आवश्यकता हो सकती है /var/log/complex/a.log, /var/log/complex/b.log, /var/log/complex/c.log... कॉन्फ़िगरेशन के साथ इसी तरह के पैटर्न।

— 3

मुझे लगता है कि /var/log/simple/log.1 .2, आदि के रूप में मैं आपको जानकारी देता हूं। SO var लॉग में प्रत्येक लॉग प्रकार के लिए सबडिअर होते हैं, और प्रत्येक सबडिर में एक या कई फाइलें हो सकती हैं। मैं मानता हूं, ऐसे उदाहरण हैं जहां अपवाद वाजिब हैं, लेकिन एक सामान्य नियम के रूप में, यह अच्छा है। मुझे फाइलों के साथ घर निर्देशिकाओं को देखने से नफरत है - सबूत, अव्यवस्था का आईएमओ।

— ग्राहम निकोलस

वहाँ है एक अच्छा कारण है, लेकिन आप एक व्यवस्थापक के रूप में सोचने के लिए इससे पहले कि आप यह समझ की जरूरत है। देखें डोपघोटी का जवाब।

— रीयरियरपोस्ट

खैर, कि मुझे मेरी जगह में डाल दिया, यह नहीं था? जाहिर है मैं एक व्यवस्थापक के रूप में नहीं सोच सकता - या मैं आपसे केवल असहमत हूं।

— ग्राहम निकोल्स