audit-kernel v7.2
लिनक्स कर्नेल की ऑडिट रिपॉज़िटरी का GitHub मिरर
लिनक्स कर्नेल ऑडिट सबसिस्टम
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
लिनक्स ऑडिट सबसिस्टम एक सुरक्षित लॉगिंग ढाँचा प्रदान करता है जिसका उपयोग सुरक्षा-संबंधी घटनाओं को कैप्चर करने और रिकॉर्ड करने के लिए किया जाता है। इसमें एक कर्नेल घटक होता है जो सिस्टम गतिविधि के आधार पर ऑडिट रिकॉर्ड उत्पन्न करता है, एक यूज़रस्पेस डेमन जो इन रिकॉर्डों को स्थानीय फ़ाइल या दूरस्थ एग्रीगेशन सर्वर पर लॉग करता है, और ऑडिट लॉग निरीक्षण तथा पोस्ट-प्रोसेसिंग के लिए यूज़रस्पेस टूल्स का एक सेट।
मुख्य लिनक्स कर्नेल README निम्नलिखित पते पर पाया जा सकता है: Documentation/admin-guide/README.rst
ऑनलाइन संसाधन
ऑडिट कर्नेल का प्रामाणिक रिपॉज़िटरी kernel.org पर होस्ट की गई है:
- https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
- git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
इसका आधिकारिक रूप से अनुरक्षित GitHub मिरर भी है:
कर्नेल स्रोत शाखाएँ और विकास प्रक्रिया
कर्नेल स्रोत शाखाएँ
विकास प्रक्रिया से जुड़ी चार प्राथमिक git शाखाएँ हैं: stable-X.Y, dev, dev-staging, और next। इन चार प्राथमिक शाखाओं के अतिरिक्त, "working-" उपसर्ग से शुरू होने वाली विषय-विशिष्ट, कार्य-प्रगति वाली शाखाएँ भी हैं; इन शाखाओं को आम तौर पर अनदेखा किया जा सकता है, जब तक कि आप उस विशेष विषय के विकास में शामिल न हों। इन विषय शाखाओं का प्रबंधन कई कारकों के आधार पर भिन्न हो सकता है, लेकिन प्रत्येक शाखा का विवरण अपस्ट्रीम मेलिंग सूची पर प्रासंगिक चर्चा सूत्रों में सूचित किया जाएगा।
stable-X.Y शाखा
stable-X.Y शाखा स्थिर कर्नेल पैच के लिए अभिप्रेत है और यह Linus के X.Y-rc1 टैग, या आवश्यकतानुसार बाद के X.Y.Z स्थिर कर्नेल रिलीज़ टैग पर आधारित है। यदि कर्नेल के रिलीज़ कैंडिडेट चक्र के दौरान गंभीर समस्याएँ पहचानी जाती हैं और एक पैच विकसित किया जाता है, तो वह स्थिर कर्नेल चिह्नन तथा stable-X.Y शाखा में शामिल किए जाने का उम्मीदवार हो सकता है। मुख्य लिनक्स कर्नेल के स्थिर कर्नेल पैच पर दस्तावेज़ में इस बारे में अधिक जानकारी है कि कौन से पैच स्थिर कर्नेल उम्मीदवार हो सकते हैं, और उन पैचों को उचित रूप से कैसे चिह्नित किया जाए; पैच को स्थिर के रूप में चिह्नित करने के गुण-दोष पर अपस्ट्रीम मेलिंग सूची चर्चाओं की भी अपेक्षा की जा सकती है। एक बार जब कोई पैच stable-X.Y शाखा में विलय कर दिया जाता है और next शाखा (next शाखा नोट देखें) में एक-दो दिन बिता लेता है, तो उसे अगले रिलीज़ कैंडिडेट या अंतिम कर्नेल रिलीज़ में विलय के लिए Linus को भेजा जाएगा (इस दस्तावेज़ में पुल रिक्वेस्ट नोट देखें)। यदि पैच को स्थिर के लिए उचित रूप से चिह्नित किया गया है, तो अन्य स्थिर कर्नेल ट्री Linus के ट्री में उपस्थित होते ही पैच को बैकपोर्ट करने का प्रयास करेंगे; अधिक जानकारी के लिए मुख्य लिनक्स कर्नेल दस्तावेज़ देखें।
जब तक विशेष रूप से अनुरोध न किया जाए, डेवलपर्स को अपने पैच stable-X.Y शाखा पर आधारित नहीं करने चाहिए। अपस्ट्रीम में प्रस्तुत पैचों के विलय से उत्पन्न होने वाले किसी भी विलय संघर्ष को अनुरक्षक द्वारा निपटाया जाएगा, हालाँकि चरम मामलों में सहायता और/या अनुरोध किया जा सकता है।
dev शाखा
dev शाखा आगामी मर्ज विंडो को लक्षित करने वाले विकास पैच के लिए अभिप्रेत है, और यह Linus के नवीनतम X.Y-rc1 टैग, या गंभीर बग, विलय संघर्ष या अन्य महत्वपूर्ण समस्याओं से बचने के लिए आवश्यकतानुसार बाद के rc टैग पर आधारित है। यह शाखा प्राथमिक विकास शाखा है जहाँ सामान्य कर्नेल विकास चक्र के दौरान अधिकांश पैच विलय किए जाते हैं। dev शाखा में विलय किए गए पैच next शाखा (next शाखा नोट देखें) में उपस्थित रहेंगे और अगली मर्ज विंडो के दौरान Linus को भेजे जाएँगे।
डेवलपर्स को अपने स्वयं के विकास कार्य के लिए dev शाखा को एक स्थिर आधार के रूप में उपयोग करना चाहिए; केवल चरम परिस्थितियों में ही X.Y-rc चक्र के दौरान dev शाखा को रीबेस किया जाएगा, और किसी भी विलय संघर्ष को हल करने की जिम्मेदारी अनुरक्षक की होगी, हालाँकि चरम मामलों में सहायता और/या अनुरोध किया जा सकता है।
dev-staging शाखा
dev-staging शाखा उन विकास पैचों के लिए अभिप्रेत है जो किसी विशिष्ट मर्ज विंडो को लक्षित नहीं करते हैं। dev-staging शाखा मुख्य dev शाखा के लिए एक स्टेजिंग क्षेत्र के रूप में मौजूद है, और इसलिए इसका उपयोग अप्रत्याशित होगा और आवश्यकतानुसार इसे रीबेस किया जाएगा। dev-staging शाखा में विलय किए गए पैच भविष्य में किसी बिंदु पर प्राथमिक dev शाखा में अपना रास्ता खोज लेने चाहिए, हालाँकि इसकी गारंटी नहीं है।
जब तक विशेष रूप से अनुरोध न किया जाए, डेवलपर्स को dev-staging शाखा को किसी भी विकास कार्य के आधार के रूप में उपयोग नहीं करना चाहिए।
next शाखा
next शाखा एक समग्र शाखा है जो नवीनतम stable-X.Y और dev शाखाओं को उसी क्रम में विलय करके बनाई गई है। next शाखा का मुख्य उद्देश्य linux-next एकीकरण परीक्षण के लिए एक एकल शाखा प्रदान करना है जिसमें घटक शाखाओं के सभी कमिट शामिल हों। जब भी किसी एक घटक शाखा में परिवर्तन होगा, next शाखा को अद्यतन किया जाएगा, लेकिन linux-next टीम की इच्छाओं के साथ सहयोग करने के लिए यह मर्ज विंडो के दौरान स्थिर रहेगी।
यद्यपि डेवलपर्स विकास के आधार के रूप में next शाखा का उपयोग कर सकते हैं, dev शाखा संभवतः अधिक उपयुक्त और स्थिर आधार होगी।
कर्नेल विकास प्रक्रिया
जब Linus अपस्ट्रीम कर्नेल मर्ज विंडो को बंद कर देता है, तो वर्तमान कर्नेल रिलीज़ कैंडिडेट से जुड़ी stable-X.Y शाखा, dev शाखा, और संभावित रूप से dev-staging शाखा (dev-staging शाखा नोट देखें) को Linus के ट्री में नवीनतम vX.Y-rc1 टैग से मेल खाने के लिए रीसेट किया जाएगा। इन शाखाओं से बनी एक समग्र शाखा के रूप में next शाखा को परिणामस्वरूप अद्यतन किया जाएगा।
कर्नेल मर्ज विंडो के बंद होने से शुरू होने वाले और टैग किए गए कर्नेल रिलीज़ के साथ समाप्त होने वाले विकास चक्र के दौरान, इस दस्तावेज़ में उनके संबंधित अनुभागों में वर्णित अनुसार पैच stable-X.Y और dev शाखाओं में स्वीकार किए जाएँगे। यद्यपि पैच किसी भी समय stable-X.Y शाखा में स्वीकार किए जाएँगे, विकास चक्र में दो या उससे कम सप्ताह शेष रहने पर महत्वपूर्ण परिवर्तन dev शाखा में स्वीकार किए जाने की संभावना नहीं है; इसका सामान्य अर्थ यह है कि vX.Y-rc6 कर्नेल जारी होने के बाद केवल महत्वपूर्ण बगफिक्स ही स्वीकार किए जाते हैं। इस दौरान next शाखा को घटक शाखाओं में परिवर्तनों के आधार पर आवश्यकतानुसार पुनः उत्पन्न किया जाएगा, और stable-X.Y शाखा में पैचों के लिए आवश्यकतानुसार Linus को पुल रिक्वेस्ट भेजी जाएँगी।
जब Linus अंतिम vX.Y कर्नेल जारी करता है और मर्ज विंडो खुलती है, तो दो चीजें होंगी। पहला, dev शाखा को एक नई stable-X'.Y' शाखा में प्रतिलिपित किया जाएगा, जो आगामी नए कर्नेल रिलीज़ का प्रतिनिधित्व करेगी, और दूसरा, वर्तमान मर्ज विंडो में शामिल करने के लिए इस शाखा से एक पुल रिक्वेस्ट भेजी जाएगी। मर्ज विंडो प्रक्रिया के दौरान dev और next शाखाओं को स्थिर रखा जाना चाहिए, हालाँकि परीक्षण या प्रक्रिया से संबंधित कारणों से कुछ पैच dev-staging में विलय किए जाने की संभावना है।
Linus के लिए पुल रिक्वेस्ट
Linus को पुल रिक्वेस्ट भेजने के लिए, चाहे वह किसी महत्वपूर्ण बगफिक्स के लिए हो या मर्ज विंडो के भाग के रूप में, एक हस्ताक्षरित git टैग बनाया जाना चाहिए जो पुल रिक्वेस्ट बिंदु की ओर इंगित करे। टैग का नाम "{subsystem}-pr-{date}" प्रारूप का उपयोग करके रखा जाना चाहिए और इसे निम्नलिखित git कमांड के साथ उत्पन्न किया जा सकता है:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
हस्ताक्षरित टैग बन जाने के बाद, इसे पुल रिक्वेस्ट के आधार के रूप में उपयोग किया जाना चाहिए।
यूज़रस्पेस टूल्स और परीक्षण सूट
ऑडिट यूज़रस्पेस टूल्स और परीक्षण सूट GitHub द्वारा होस्ट किए गए हैं: