linux-audit/audit-kernelمرآة GitHub لمستودع التدقيق الخاص بنواة لينكس
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
يوفر نظام التدقيق (Audit) في لينكس إطار عمل آمن لتسجيل الأحداث، يُستخدم لالتقاط وتسجيل الأحداث ذات الصلة بالأمان. ويتكوّن من مكوّن داخل النواة يُنشئ سجلات تدقيق بناءً على نشاط النظام، وبرنامج خفي في مساحة المستخدم يسجّل هذه السجلات في ملف محلي أو على خادم تجميع بعيد، ومجموعة من أدوات مساحة المستخدم لفحص سجلات التدقيق ومعالجتها لاحقًا.
يمكن العثور على ملف README الرئيسي لنواة لينكس في Documentation/admin-guide/README.rst
المستودع الرسمي لنواة التدقيق مستضاف على kernel.org:
هناك أيضًا مرآة رسمية على GitHub تتم صيانتها:
هناك أربعة فروع git رئيسية مرتبطة بعملية التطوير: stable-X.Y وdev وdev-staging وnext. بالإضافة إلى هذه الفروع الأربعة الرئيسية، توجد أيضًا فروع مخصصة لموضوعات محددة وقيد العمل تبدأ ببادئة "working-"؛ ويمكن عمومًا تجاهل هذه الفروع ما لم تكن مشاركًا في تطوير ذلك الموضوع تحديدًا. قد تختلف إدارة هذه الفروع المواضيعية تبعًا لعدد من العوامل، لكن تفاصيل كل فرع سيتم الإعلان عنها في سلاسل النقاش ذات الصلة على القائمة البريدية للمنبع (upstream).
فرع stable-X.Y مخصص لتصحيحات النواة المستقرة ويستند إلى وسم X.Y-rc1 الخاص بـ Linus، أو إلى وسم إصدار نواة مستقرة X.Y.Z لاحق عند الحاجة. إذا تم تحديد مشاكل خطيرة وتم تطوير تصحيح خلال دورة المرشح للإصدار (release candidate) للنواة، فقد يكون مرشحًا لوضع علامة النواة المستقرة وإدراجه في فرع stable-X.Y. تحتوي وثائق نواة لينكس الرئيسية حول تصحيحات النواة المستقرة على مزيد من المعلومات حول التصحيحات التي قد تكون مرشحة للنواة المستقرة، وكيفية وضع العلامات المناسبة على تلك التصحيحات؛ كما يمكن توقّع مناقشات على القائمة البريدية للمنبع حول مزايا وضع علامة التصحيح على أنه مستقر. بمجرد دمج التصحيح في فرع stable-X.Y وقضائه يومًا أو يومين في فرع next (انظر ملاحظات فرع next)، سيتم إرساله إلى Linus لدمجه في المرشح التالي للإصدار أو الإصدار النهائي للنواة (انظر الملاحظات حول طلبات السحب في هذا المستند). إذا تم وضع علامة مناسبة على التصحيح ليكون مستقرًا، فستحاول أشجار النواة المستقرة الأخرى نقل التصحيح (backport) بمجرد وجوده في شجرة Linus، راجع وثائق نواة لينكس الرئيسية لمزيد من التفاصيل.
ما لم يُطلب ذلك تحديدًا، يجب على المطوّرين ألا يعتمدوا تصحيحاتهم على فرع stable-X.Y. سيتم التعامل مع أي تعارضات دمج ناتجة عن دمج التصحيحات المقدمة إلى المنبع من قِبل المشرف، على الرغم من أنه قد يُطلب المساعدة في الحالات القصوى.
فرع dev مخصص لتصحيحات التطوير التي تستهدف نافذة الدمج القادمة، ويستند إلى أحدث وسم X.Y-rc1 الخاص بـ Linus، أو وسم rc لاحق عند الحاجة لتجنب الأخطاء الخطيرة أو تعارضات الدمج أو غيرها من المشكلات المهمة. هذا الفرع هو فرع التطوير الأساسي حيث يتم دمج غالبية التصحيحات خلال دورة تطوير النواة العادية. التصحيحات المدمجة في فرع dev ستكون موجودة في فرع next (انظر ملاحظات فرع next) وستُرسل إلى Linus خلال نافذة الدمج التالية.
يجب على المطوّرين استخدام فرع dev كأساس مستقر لأعمالهم التطويرية الخاصة، ولن يُعاد تأسيس (rebase) فرع dev أثناء دورة X.Y-rc إلا في ظروف قصوى، وسيكون المشرف مسؤولًا عن حل أي تعارضات دمج، على الرغم من أنه قد يُطلب المساعدة في الحالات القصوى.
فرع dev-staging مخصص لتصحيحات التطوير التي لا تستهدف نافذة دمج محددة. يوجد فرع dev-staging كمنطقة تجهيز لفرع dev الرئيسي، وبالتالي سيكون استخدامه غير متوقع وسيتم إعادة تأسيسه عند الحاجة. التصحيحات المدمجة في فرع dev-staging يجب أن تجد طريقها إلى فرع dev الأساسي في وقت ما في المستقبل، على الرغم من أن ذلك غير مضمون.
ما لم يُطلب ذلك تحديدًا، يجب على المطوّرين ألا يستخدموا فرع dev-staging كأساس لأي عمل تطويري.
فرع next هو فرع مركّب يتم بناؤه بدمج أحدث فرعي stable-X.Y وdev بهذا الترتيب. يتمثل التركيز الرئيسي لفرع next في توفير فرع واحد لاختبار تكامل linux-next يحتوي على جميع الالتزامات من الفروع المكوِّنة. سيتم تحديث فرع next كلما حدث تغيير في أي من الفروع المكوِّنة، لكنه سيبقى مجمّدًا خلال نافذة الدمج وذلك لمواكبة رغبات فريق linux-next.
بينما يمكن للمطوّرين استخدام فرع next كأساس للتطوير، فمن المرجح أن يكون فرع dev أساسًا أكثر ملاءمة واستقرارًا.
بعد أن يغلق Linus نافذة دمج النواة في المنبع، سيتم إعادة تعيين فرع stable-X.Y المرتبط بمرشح الإصدار الحالي للنواة، وفرع dev، وربما فرع dev-staging (انظر ملاحظات فرع dev-staging) لتطابق أحدث وسم vX.Y-rc1 في شجرة Linus. وسيتم تحديث فرع next، كفرع مركّب يتكوّن من هذه الفروع، نتيجةً لذلك.
خلال دورة التطوير التي تبدأ بإغلاق نافذة دمج النواة وتنتهي بإصدار النواة الموسوم، سيتم قبول التصحيحات في فرعي stable-X.Y وdev كما هو موصوف في القسمين الخاصين بهما في هذا المستند. بينما سيتم قبول التصحيحات في فرع stable-X.Y في أي وقت، فمن المرجح ألا تُقبل التغييرات المهمة في فرع dev عندما تبقى أسبوعان أو أقل على انتهاء دورة التطوير؛ وهذا يعني عادةً أنه لا تُقبل سوى إصلاحات الأخطاء الحرجة بمجرد إصدار نواة vX.Y-rc6. خلال هذا الوقت، سيتم إعادة إنشاء فرع next عند الحاجة بناءً على التغييرات في الفروع المكوِّنة، وستُرسل طلبات السحب إلى Linus عند الحاجة للتصحيحات الموجودة في فرع stable-X.Y.
بمجرد أن يصدر Linus نواة vX.Y النهائية وتُفتح نافذة الدمج، سيحدث أمران. الأول هو أن فرع dev سيُنسخ إلى فرع stable-X'.Y' جديد، ليمثّل إصدار النواة القادم الجديد، والثاني هو أنه سيتم إرسال طلب سحب من هذا الفرع لإدراجه في نافذة الدمج الحالية. خلال عملية نافذة الدمج، يجب أن يبقى فرعا dev وnext مجمّدين، على الرغم من وجود احتمال لدمج بعض التصحيحات في dev-staging لأسباب متعلقة بالاختبار أو بالعملية.
من أجل إرسال طلب سحب إلى Linus، سواء لإصلاح خطأ حرج أو كجزء من نافذة الدمج، يجب إنشاء وسم git موقّع يشير إلى نقطة طلب السحب. يجب تسمية الوسم باستخدام تنسيق "{subsystem}-pr-{date}" ويمكن إنشاؤه باستخدام أمر git التالي:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
بمجرد إنشاء الوسم الموقّع، يجب استخدامه كأساس لطلب السحب.
أدوات التدقيق في مساحة المستخدم ومجموعات الاختبار مستضافة على GitHub: