0 - en to ar-MA translation catalogue (332 entries)

en: Preseeding
ar-MA: تغذية

en: Monitoring
ar-MA: المراقبة

en: Virtualization
ar-MA: الحوسبة الظاهرية

en: Xen
ar-MA: ‏Xen

en: LXC
ar-MA: ‏LXC

en: Advanced Administration
ar-MA: الإدارة المتقدمة

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
ar-MA: يعيد هذا الفصل النظر في بعض القضايا التي ناقشناها سابقاً، لكن من وجهة نظر مختلفة: سوف ندرس تجهيز الأنظمة الكبيرة بدلاً من تجهيز حاسوب مفرد؛ وسوف نتعلم ضبط LVM و RAID يدوياً بدل الضبط الآلي عند التثبيت، حتى نتمكن من تعديل الخيارات التي حددناها سابقاً. أخيراً، سوف نتحدث عن أدوات المراقبة وتقنيات المحاكاة. أي أن هذا الفصل موجَّه لمديري النظم المحترفين أكثر مما يركز على ما يهم الأفراد الذين يديرون شبكة منزلية.

en: RAID and LVM
ar-MA: ‏RAID وLVM

en: RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.
ar-MA: تستخدم تقنيتا LVM و RAID لعزل الحيز التخزيني المتاح لنظام الملفات عن الحيز التخزيني الفيزيائي (الأقراص الصلبة الفعلية أو الأقسام partitions)؛ تحمي تقنية RAID البيانات من خلال التخزين الفائض، بينما تجعل تقنية LVM إدارة البيانات أكثر مرونة واستقلالاً عن السَّعَة الحقيقية للأقراص التي تحميل تلك البيانات. في الحالتين، يعتمد النظام على أجهزة تخزينية جديدة، يمكن استخدامها لإنشاء نظم ملفات أو مساحات الإبدال Swap، دون أن ترتبط بقرص فيزيائي واحد. إن جذور التقنيتين مختلفة كثيرًا، لكن وظائفهما متشابهة نوعًا ما، ولهذا غالبًا ما تذكران معًا.

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
ar-MA: <emphasis>منظور</emphasis> Btrfs يجمع بين LVM وRAID

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
ar-MA: من المزايا التي تستحق الذكر هي إمكانية أخذ لقطة snapshot لشجرة نظام الملفات عند أي لحظة زمنية. هذه اللقطة لا تحجز أي مساحة على القرص، إذا أن البيانات لا تنسخ قبل أن تجرى بعض التغييرات عليها. كما أن نظام الملفات يعالج أيضًا الضغط الشفاف للملفات، وهناك checksums تضمن سلامة كافة البيانات المخزنة.

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
ar-MA: في حال استخدام RAID أو LVM، توفر النواة ملف جهاز تخزيني (كتلي) block device file، يشبه الملفات التي تمثل الأقراص الصلبة أو أقسام الأقراص. عندما يحتاج أحد التطبيقات، أو أحد أجزاء النواة، للوصول إلى كتلة block من جهاز تخزيني من هذا النوع، يعمل النظام الفرعي المناسب (نظام LVM أو RAID) على توجيه هذه الكتلة إلى الطبقة الفيزيائية الموافقة. وحسب إعداد النظام، يمكن أن تُخزَّن هذه الكتلة على قرص فيزيائي واحد أو أكثر، كما أن موقعها الفيزيائي قد لا يرتبط بموقعها ضمن الجهاز المنطقي.

en: Software RAID
ar-MA: ‏Software RAID

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
ar-MA: <emphasis>ثقافة</emphasis> <foreignphrase>Independent</foreignphrase> أو <foreignphrase>inexpensive</foreignphrase>؟

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
ar-MA: يمكن تطبيق RAID باستخدام عتاد خاص (وحدات RAID مدمجة في متحكِّمات SCSI أو SATA) أو برمجيًا (عبر النواة). سواء كان النظام يعتمد على العتاد أو البرمجيات، يستطيع RAID أن يبقى في الخدمة عند عطب أحد الأقراص إذا كان هناك تخزين فائض كاف؛ إذا يمكن للطبقة العليا (التطبيقات) أن تستمر بالوصول إلى البيانات بغض النظر عن العطل. طبعاً، يمكن أن يؤثر ”وضع degraded“ هذا على الأداء، كما أن الفائض التخزيني ينخفض، ما يعني إمكانية خسارة البيانات إذا حصل عطل آخر في الأقراص. ولهذا لا يتم الاعتماد على degraded mode عمليًا إلا خلال المدة اللازمة لاستبدال القرص المعطوب. يستطيع نظام RAID إعادة بناء المعلومات اللازمة للعودة إلى الوضع الآمن بعد تثبيت القرص الجديد. لن تلاحظ البرمجيات أي شيء، أو ربما تشعر ببعض البطء في سرعة الوصول إلى البيانات عندما تكون المصفوفة في الوضع degraded أو أثناء مرحلة إعادة بناء البيانات المفقودة.

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
ar-MA: عندما يعتمد على العتاد لبناء مصفوفات RAID، فغالباً ما يتم إعداد النظام عبر أداة إعداد BIOS، وتعتبر النواة مصفوفة RAID كقرص واحد، يعمل مثل قرص فيزيائي قياسي، إلا أن اسم الجهاز قد يختلف (تبعاً لبرنامج التعريف).

en: We only focus on software RAID in this book.
ar-MA: سوف نركز على RAID البرمجي فقط في هذا الكتاب.

en: Different RAID Levels
ar-MA: مستويات RAID المختلفة

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
ar-MA: في الواقع RAID ليس نظاماً واحداً، بل مجموعة من النظم لكل منها مستوى؛ وتختلف المستويات عن بعضها بالتنظيم وكمية الفائض التي تقدمها. كلما كان الفائض أكبر كلما كان النظام أكثر مقاومة للأعطال، ذلك لأن النظام سيبقى في الخدمة مع المزيد من الأقراص المعطوبة. الناحية السلبية هي أن المساحة التخزينية المتاحة للاستعمال تصغر؛ وذلك بسبب الحاجة لأقراص أكثر لتخزين الكمية نفسها من البيانات.

en: Linear RAID
ar-MA: ‏Linear RAID

en: RAID-0
ar-MA: ‏RAID-0

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
ar-MA: لا يقدم هذا المستوى أية فائض أيضًا، لكن الأقراص لا تتقاطر خلف بعضها بشكل بسيط: بل تقسم إلى شرائط <emphasis>stripes</emphasis>، ويتم تخزين أجزاء القرص الظاهري على الشرائط بشكل متناوب بين الأقراص الفيزيائية. في نظام RAID-0 ذو قرصين، مثلًا، تُخَزَّن الأجزاء الزوجية من القرص الظاهري على القرص الفيزيائي الأول، والأجزاء الفردية على القرص الفيزيائي الثاني.

en: RAID-1
ar-MA: ‏RAID-1

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
ar-MA: يعرف هذا المستوى أيضًا باسم ”RAID mirroring“، وهو الأبسط والأكثر انتشاراً. يعتمد هذا المستوى –في شكله المعياري– على قرصين فيزيائيين لهما السعة ذاتها، ويعطي قرصًا منطقيًا له نفس السعة أيضًا. تخزن البيانات نفسها على القرصين، ولذلك كان ”mirror“ هو الاسم الثاني لهذا المستوى. إذا تعطّل أحد القرصين، تبقى البيانات متوفرة على الآخر. يمكن طبعاً إعداد RAID-1 على أكثر من قرصين بالنسبة للبيانات الهامة جدًا، لكن هذا سيزيد نسبة الكلفة للمساحة التخزينية.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
ar-MA: <emphasis>ملاحظة</emphasis> سعة الأقراص وسعة العنقود

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
ar-MA: إذا تم إعداد قرصين من سعتين مختلفتين في مرآة RAID-1، لن يستخدم القرص الأكبر بشكل كامل، لأنه سيحوي نفس البيانات التي يحويها القرص الأصغر فقط. أي أن المساحة المتوفرة للاستخدام في قرص RAID-1 الناتج ستطابق سعة أصغر قرص في المصفوفة. هذا القانون ينطبق على مستويات RAID اللاحقة أيضًا، رغم أن الفائض مخزن بأسلوب مختلف.

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
ar-MA: لذلك كان مهماً أن تجمع الأقراص ذات السعات المتساوية أو المتقاربة جدًا عند إعداد مصفوفات RAID (ما عدا RAID-0 و Linear RAID)، حتى تتجنب الهدر في الموارد.

en: <emphasis>NOTE</emphasis> Spare disks
ar-MA: <emphasis>ملاحظة</emphasis> الأقراص الاحتياطية

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
ar-MA: يمكن إضافة أقراص أكثر مما هو مطلوب للمصفوفة في مستويات RAID التي تحتوي على فائض. يمكن استخدام الأقراص الإضافية كبديل عندما يتعطّل أحد الأقراص الرئيسية. مثلًا، في حالة تطبيق مرآة بقرصين مع قرص احتياطي واحد، سوف تعيد النواة بناء المرآة تلقائيًا (وفوريًا) باستخدام القرص الاحتياطي إذا تعطّل أحد القرصين الرئيسيين. يمكن اعتماد هذا الأسلوب كخط أمان إضافي للبيانات الحساسة.

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
ar-MA: قد يتساءل المرء عن سبب تفضيل هذا الأسلوب على إعداد مرآة بثلاثة أقراص ببساطة. إن ميزة إعداد ”القرص الاحتياطي“ هي إمكانية مشاركة القرص الاحتياطي بين عدة مصفوفات RAID. يمكن مثلًا، إعداد ثلاثة مصفوفات RAID-1، مع ضمان حماية الفائض حتى في حال تعطل أحد الأقراص باستخدام سبعة أقراص فقط (ثلاثة أزواج واحتياطي واحد)، بدلاً من تسعة أقراص كنا سنحتاجها لإعداد ثلاثة مرايا ثلاثية.

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
ar-MA: بالرغم من ارتفاع كلفة هذا المستوى (نظراً لأن المساحة التخزينية المتاحة تساوي نصف المساحة الفيزيائية في أحسن الأحوال)، إلا أنه استخدامه منتشر عملياً. فهم هذا المستوى بسيط، وهو يؤدي عملية نسخ احتياطي بسيطة جدًا: بما أن القرصين يخزنان المحتوى نفسه، يمكن فصل أحدهما مؤقتًا دون التأثير على عمل النظام. غالبًا ما يكون أداء الأقراص عند القراءة مرتفعاً، لأن النواة تستطيع قراءة نصف البيانات من كل قرص على التوازي، في حين لا ينخفض الأداء كثيراً عند الكتابة. تبقى البيانات متاحة في مصفوفة RAID-1 ذات N قرص، حتى في حال تعطل N-1 قرص.

en: RAID-4
ar-MA: ‏RAID-4

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
ar-MA: هذا المستوى من RAID غير منتشر كثيراً. يستخدم هذا المستوى N قرص لتخزين البيانات المفيدة، وقرص إضافي لتخزين معلومات فائضة. إذا تعطل القرص الإضافي، يستطيع النظام إعادة بناء محتوياته اعتمادًا على الأقراص الأخرى. أما إذا تعطل أحد أقراص المعلومات فيستخدم النظام الأقراص المتبقية منها (N-1 قرص) مع القرص الإضافي (قرص الازدواجية – ‎“parity” disk) لإعادة بناء البيانات المفقودة.

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
ar-MA: إن كلفة RAID-4 ليست مرتفعة جداً بما أن الزيادة في الكلفة هي 1 إلى N كما أنه تأثيره على سرعة القراءة غير ملحوظ، لكن أداء الكتابة ينخفض. من ناحية أخرى، عند كل عملية كتابة على أحد أقراص المعلومات يجب الكتابة على قرص الازدواجية أيضًا، ما قد يؤدي لتقصير عمره بشكل كبير. تبقى البيانات في مصفوفة RAID-4 بأمان في حال عطب قرص واحد (من المصفوفة كلها ذات N+1 قرص).

en: RAID-5
ar-MA: ‏RAID-5

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
ar-MA: يعالج المستوى RAID-5 مشكلة اللاتناظر التي يعاني منها RAID-4: حيث تنتشر معلومات الازدواجية على جميع الأقراص في مصفوفة N+1، ولا يوجد دور محدد لأي قرص منها.

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
ar-MA: أداء القراءة والكتابة مطابق لأداء RAID-4. كما أن النظام هنا أيضًا يتحمل تعطل قرص واحد فقط (من أصل N+1 قرص).

en: RAID-6
ar-MA: ‏RAID-6

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
ar-MA: يمكن اعتبار RAID-6 كامتداد للمستوى RAID-5، إذ أن كل سلسلة مؤلفة من N كتلة تحتاج إلى كتلتين فائضتين، وكل سلسلة من N+2 كتلة تنتشر على N+2 قرص.

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
ar-MA: كلفة هذا المستوى أعلى بقليل من المستويين السابقين، لكنه يزيد مستوى الأمان إذا يستطيع العمل حتى لو تعطل قرصين (من أصل N+2) دون تأثر البيانات. الجانب السلبي هو أن عمليات الكتابة على الأقراص تحتاج لكتابة كتلة بيانات واحدة وكتلتين فائضتين، وهذا يجعل الكتابة أبطأ.

en: RAID-1+0
ar-MA: ‏RAID-1+0

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
ar-MA: تتحمل مصفوفات RAID-1+0 تعطل عدة أقراص: فالمصفوفة الموضحة سابقاً يمكن أن تتحمل تعطل N قرص إذا كانت تحوي ‎2×‎N قرص، بشرط أن ينجو قرص واحد على الأقل من كل زوج من أقراص RAID-1.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
ar-MA: <emphasis>التعمق أكثر</emphasis> RAID-10

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
ar-MA: يعتبر RAID-10 كمرادف للمستوى RAID-1+0 عموماً، لكن هناك خاصية في لينكس تجعل الثاني حالة خاصة من الأول. يسمح هذا الإعداد ببناء نظام تُخزَّن فيه كل كتلة على قرصين مختلفين، حتى لو كان عدد الأقراص في النظام فردياً، ويتبع توزيع النسخ على الأقراص نموذجاً محدداً يمكن تعديله.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
ar-MA: سيختلف مستوى الأداء تبعاً لنموذج التقسيم المتبع ومستوى الفائض، وحمل الحيز التخزيني المنطقي.

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
ar-MA: من الواضح أن اختيار مستوى RAID الملائم يعتمد على متطلبات وقيود كل تطبيق. لاحظ أن الحاسوب الواحد يمكن أن يحوي عدة مصفوفات RAID ذات مستويات مختلفة.

en: Setting up RAID
ar-MA: إعداد RAID

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
ar-MA: يحتاج إعداد RAID لحزمة <emphasis role="pkg">mdadm</emphasis>؛ التي توفر الأمر <command>mdadm</command> الذي يستخدم لإنشاء وتعديل مصفوفات RAID، كما توفر أيضًا سكربتات وأدوات تدمج البرنامج في أجزاء نظام التشغيل الأخرى، بما فيه نظام المراقبة.

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
ar-MA: مثالنا هو مُخدِّم فيه عدد من الأقراص، بعضها مستخدم، والباقي متاح لإعداد مصفوفة RAID. هذه هي الحالة الإبتدائية للأقراص والأقسام:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
ar-MA: القرص <filename>sdb</filename>، ‏4 غ.ب، متاح بالكامل؛

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
ar-MA: القرص <filename>sdc</filename>، ‏4 غ.ب، متاح بالكامل أيضاً؛

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
ar-MA: القسم <filename>sdd2</filename> من القرص <filename>sdd</filename> متاح (حوالي 4 غ.ب)؛

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
ar-MA: أخيراً، القرص <filename>sde</filename>، أيضاً 4 غ.ب متاح بالكامل.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
ar-MA: <emphasis>ملاحظة</emphasis> التعرف على أقراص RAID القديمة

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
ar-MA: يسرد الملف <filename dir="ltr">/proc/mdstat</filename> جميع أقراص RAID السابقة وحالاتها. يجب أن تنتبه إلى عدم استخدام اسم قرص مستخدم مسبقًا عند إنشاء قرص جديد.

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
ar-MA: سوف نستخدم هذه العناصر الفيزيائية لبناء حيزين تخزينيين، أحدهما RAID-0، والآخر RAID-1 (مرآة). دعنا نبدأ ببناء حيز RAID-0:

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
ar-MA: يتم إنشاء RAID-1 بأسلوب مشابه، ولا تظهر الاختلافات إلا بعد عملية الإنشاء:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
ar-MA: <emphasis>تلميح</emphasis> RAID والأقراص والأقسام

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
ar-MA: هناك بضعة ملاحظات. أولاً، يلاحظ <command>mdadm</command> اختلاف سعة العناصر الفيزيائية؛ وبما أن هذا يعني ضياع بعض المساحة من العنصر الأكبر، يطلب من المستخدم تأكيد العملية.

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
ar-MA: الأهم من هذا هو حالة المرآة. لاحظ كيف كانت resyncing ثم انتقلت إلى active. إن الحالة الطبيعية لمرآة RAID هي أن تتطابق محتويات القرصين. لكن لا شيء يضمن هذا التطابق عند إنشاء المصفوفة أول مرة، ولذلك يعمل نظام RAID الفرعي على ضمان هذا بنفسه، ويبدأ طور مزامنة المحتويات بعد إنشاء المصفوفة مباشرة. بعد فترة من الزمن (تختلف المدة حسب حجم الأقراص الفعلي...)، تنتقل مصفوفة RAID إلى حالة ”active“ أو ”clean“. لاحظ أن المصفوفة تكون في الوضع degraded خلال طور إعادة البناء، وأن الفائض التخزيني غير جاهز بعد. إذا تعطل قرص أثناء مرحلة الخطر تلك، فسوف يؤدي ذلك إلى خسارة البيانات كلها. لكن نادرًا ما تستخدم مصفوفات RAID الجديدة لتخزين كميات كبيرة من البيانات الحساسة قبل أن تنتهي مرحلة تهيئتها الأولية. لاحظ أيضًا أن <filename dir="ltr">/dev/md1</filename> جاهز للاستخدام حتى في وضع degraded، وأنه يمكن إنشاء نظام ملفات عليه، كما يمكن نسخ البيانات إليه أيضًا.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
ar-MA: <emphasis>تلميح</emphasis> إنشاء مرآة في وضع degraded

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
ar-MA: أحيانًا لا يكون القرصان جاهزين فورًا لحظة إنشاء مرآة RAID-1، مثلاً يمكن أن أحد القرصين الذين نريد استخدامهما مستخدم أصلاً لتخزين البيانات التي نريد نقلها إلى المصفوفة. في مثل هذه الحالات، من الممكن إنشاء مصفوفة RAID-1 في الوضع degraded باستخدام قرص واحد من خلال تمرير <filename>missing</filename> كمعامل للأمر <command>mdadm</command> بدلاً من تمرير اسم الملف الذي يمثل القرص. بعد نسخ البيانات إلى ”المرآة“، يمكن إضافة القرص القديم إلى المصفوفة. عندها تبدأ عملية المزامنة، للوصول إلى الحالة الآمنة التي أردناها في البداية.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
ar-MA: <emphasis>تلميح</emphasis> إعداد مرآة بدون مزامنة

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
ar-MA: تستخدم مصفوفات RAID-1 بعد إنشائها غالبًا كأقراص جديدة، وتعامل على أنها فارغة. أي أن المحتويات الأولية للقرص عديمة القيمة، لأن كل ما نحتاجه هو أن نتأكد أننا سوف نستطيع لاحقاً الوصول البيانات التي سنكتبها بعد إنشاء الحيز التخزيني الجديد، خصوصاً نظام الملفات.

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
ar-MA: قد يتساءل المرء عندئذ عن فائدة مزامنة الأقراص عند إنشائها. ما الفرق إذا كانت محتويات المصفوفة متزامنة إذا كنا لن نقرأ من المصفوفة شيئًا قبل محوها وتهيئتها؟

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
ar-MA: لحسن الحظ، يمكن تفادي طور المزامنة هذا بتمرير الخيار‎ <literal dir="ltr">--assume-clean</literal> للأمر <command>mdadm</command>. لكن هذا الخيار قد يسبب مفاجآت لو حاولنا قراءة البيانات الأولية (مثلاً إذا كانت الأقراص الفيزيائية تحوي نظام ملفات مسبقًا)، لذلك فإن هذا الخيار معطل افتراضيًا.

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
ar-MA: دعنا نرى ما سيحدث عندما يتعطل أحد عناصر مصفوفة RAID-1. يمكن محاكاة عطب قرص ما باستخدام الخيار <literal dir="ltr">--fail</literal> مع الأمر <command>mdadm</command>:

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
ar-MA: تبقى محتويات المصفوفة متاحة (وإذا كانت مرتبطة بشجرة الملفات، فلن تشعر التطبيقات بشيء)، لكن البيانات لم تعد بأمان: فإذا تعطل القرص <filename>sdd</filename> أيضًا، سوف تضيع البيانات. نحن لا نريد أن نخاطر بذلك، ولهذا سوف نستبدل القرص المعطوب بقرص جديد، <filename>sdf</filename>:

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
ar-MA: هنا أيضاً تبدأ النواة طور إعادة بناء تلقائيًا، وتبقى المصفوفة خلال هذا الطور في الوضع degraded أيضًا لكنها متاحة للوصول. ترجع مصفوفة RAID-1 إلى الحالة الطبيعية فور انتهاء إعادة البناء. يمكن عندها أن نخبر النظام أننا سوف نزيل القرص <filename>sde</filename> من المصفوفة، حتى تبقى كمرآة RAID كلاسيكية بقرصين فقط:

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
ar-MA: عند هذه اللحظة يمكن فصل القرص الفيزيائي عند إيقاف تشغيل المخدم، أو يمكن حتى فصلها مباشرة إذا كان العتاد يسمح بالتبديل الساخن hot-swap. تسمح بعض متحكمات SCSI، ومعظم أقراص SATA، والسواقات الخارجية التي تعمل عبر USB أو Firewire بهذا النوع من التبديل.

en: Backing up the Configuration
ar-MA: النسخ الاحتياطي للإعدادات

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
ar-MA: إذاً لا بد من أخذ نسخة احتياطية عن الإعدادات، حتى لو كانت للاستئناس فقط. الطريقة المعيارية لعمل هذا هي تحرير الملف <filename dir="ltr">/etc/mdadm/mdadm.conf</filename>، إليك مثالاً عن هذا الملف:

en: <command>mdadm</command> configuration file
ar-MA: ملف إعداد <command>mdadm</command>

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
ar-MA: أحد أهم التفاصيل هو خيار <literal>DEVICE</literal>، الذي يعدد الأجهزة التي يفحصها النظام بحثًا عن مكونات مصفوفات RAID عند الإقلاع. لقد استبدلنا في مثالنا القيمة الافتراضية – <literal>partitions containers</literal> – بلائحة واضحة تسرد أسماء ملفات الأجهزة، ذلك لأننا اخترنا استخدام بعض الأقراص الكاملة وليس الأقسام فقط.

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
ar-MA: آخر سطرين في مثالنا يسمحان للنواة بإسناد رقم الحيز المناسب إلى المصفوفة المناسبة. إن البيانات الفوقية المخزنة على الأقراص نفسها تكفي لإعادة جمع المصفوفات، لكنها لا تكفي لمعرفة رقم الحيز (ولا معرفة اسم <filename dir="ltr">/dev/md*</filename> الموافق للجهاز).

en: Fortunately, these lines can be generated automatically:
ar-MA: لحسن الحظ، يمكن توليد هذه الأسطر آليًا:

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
ar-MA: لا تعتمد محتويات هذه السطور على الأقراص المتضمنة في المصفوفة. فلا حاجة إلى إعادة توليدها عند استبدال قرص معطوب بآخر جديد. لكن يجب الانتباه إلى تحديث الملف عند إنشاء مصفوفة RAID جديدة أو حذف واحدة قديمة.

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
ar-MA: <emphasis>Logical Volume Manager</emphasis> ًأو اختصارا LVM هو أسلوب آخر لعزل الأقراص التخزينية المنطقية عن الأقراص الفيزيائية، وهو يركز على زيادة المرونة بدلاً من زيادة الوثوقية. يسمح LVM بتغيير القرص المنطقي بشكل شفاف بالنسبة للتطبيقات؛ فمثلاً، يمكن إضافة أقراص فيزيائية جديدة، ونقل البيانات إليها، وإزالة القديمة، دون فصل القرص المنطقي عن شجرة الملفات.

en: LVM Concepts
ar-MA: مفاهيم LVM

en: This flexibility is attained by a level of abstraction involving three concepts.
ar-MA: هذه المرونة نحرزها من خلال مستوى من العزل يشمل ثلاثة مفاهيم.

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
ar-MA: الأول هو PV، أي <emphasis>Physical Volume</emphasis> (الحيز الفيزيائي) وهو أقرب وحدة إلى العتاد: يمكن أن يتألف من قسم من أحد الأقراص، أو قرص كامل، أو أي جهاز كتلي آخر (بما في ذلك مصفوفات RAID على سبيل المثال). لاحظ أنه عندما يتم إعداد عنصر فيزيائي ليشغل دور PV في LVM، فيجب التعامل معه من LVM فقط، وإلا فإن النظام سوف يضطرب.

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
ar-MA: النوع الثالث من المكونات هو LV‏ (<emphasis>Logical Volume</emphasis> – الحيز المنطقي)، وهو قطعة من VG؛ فإذا اعتبرنا VG بمثابة قرص، عندها يقابل LV القسم من القرص. يظهر LV كجهاز كتلي له مدخلة في <filename dir="ltr">/dev</filename>، ويمكن استخدامه كما يستخدم أي قسم فيزيائي آخر (لاستضافة نظام ملفات أو مساحة swap عادة).

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
ar-MA: أهم شيء هنا هو أن تقسيم VG إلى LVs مستقل تمامًا عن المكونات الفيزيائية للـ VG (وهي PVs). يمكن تقسيم VG يتألف من مكون فيزيائي واحد (قرص مثلاً) إلى دزينة من الأقراص المنطقية؛ كما يمكن أن يتألف VG من العديد من الأقراص الفيزيائية ثم يظهر كحيز منطقي كبير مفرد. القيد الوحيد طبعاً هو أن الحجم الكلي المتاح للتخزين على LVs لا يمكن أن يكون أكبر من السعة الكلية للحيزات الفيزيائية في الـVG.

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
ar-MA: إلا أن المنطق يطلب شيئًا من التجانس بين المكونات الفيزيائية للـVG، وأن تقسم الـVG إلى حيزات منطقية لها استخدامات متشابهة. مثلاً، إذا كان العتاد المتوفر يحوي أقراصًا سريعة وأخرى بطيئة، فيمكن تجميع السريعة منها في VG واحدة والأقراص البطيئة في أخرى؛ يمكن تخصيص أجزاء من الأولى للتطبيقات التي تحتاج وصولاً سريعًا للبيانات، بينما تبقى الأخرى للمهام الأقل إلحاحاً.

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
ar-MA: وعلى أية حال، تذكر أن LV لا يرتبط مباشرة بأي PV معيّن. من الممكن التأثير على موقع تخزين بيانات أحد الحيزات المنطقية فيزيائيًا، لكن هذه الإمكانية ليست جوهرية في الاستخدامات العادية. وعلى صعيد آخر: عندما تتطور المكونات الفيزيائية للـVG، يمكن تهجير مواقع التخزين الفيزيائية لأحد LVs بين الأقراص (مع البقاء ضمن PVs المخصصة للـVG بالطبع).

en: Setting up LVM
ar-MA: إعداد LVM

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
ar-MA: دعنا الآن نتبع –خطوة بخطوة– طريقة إعداد LVM لحالة استخدام نموذجية: حيث نريد تبسيط حالة تخزينية معقدة. تحدث هذه الحالات عادة بعد تاريخ طويل ومعقد من تراكم التدابير المؤقتة. سوف ندرس كمثال حالة مخدم تغيرت فيه الحاجات التخزينية مع الزمن، وانتهى المطاف بمتاهة من الأقسام المتاحة الموزعة على عدد من الأقراص المستخدمة جزئيًا. بكلام واضح أكثر، الأقسام التالية هي المتاحة:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
ar-MA: من القرص <filename>sdb</filename>، القسم <filename>sdb2</filename>، الحجم 4 غ.ب؛

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
ar-MA: من القرص <filename>sdc</filename>، القسم <filename>sdc3</filename>، الحجم 3 غ.ب؛

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
ar-MA: القرص <filename>sdd</filename>، متاح بالكامل، 4 غ.ب؛

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
ar-MA: من القرص <filename>sdf</filename>، القسم <filename>sdf1</filename>، ‏4 غ.ب؛ والقسم <filename>sdf2</filename>، ‏5 غ.ب.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
ar-MA: بالإضافة لذلك، دعنا نفترض أن القرصين <filename>sdb</filename> و<filename>sdf</filename> أسرع من البقية.

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
ar-MA: هدفنا هو إعداد ثلاثة حيزات منطقية لثلاثة تطبيقات: مخدم ملفات يحتاج 5 غ.ب. من المساحة التخزينية، وقاعدة بيانات (1 غ.ب) وبعض المساحة للنسخ الاحتياطية (12 غ.ب). يحتاج التطبيقان الأوليان أداء جيداً، بينما النسخ الاحتياطية أقل حرجاً من حيث الحاجة لسرعة النقل. تمنعنا كل هذه القيود من استخدام الأقسام المتاحة مباشرة كما هي؛ لكن يمكن أن يسمح استخدام LVM بعزل الحجم الفيزيائي للأجهزة، بحيث يبقى القيد الوحيد هو المساحة الكلية المتوفرة فقط.

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
ar-MA: الأدوات المطلوبة كلها في حزمة <emphasis role="pkg">lvm2</emphasis> واعتمادياتها. بعد تثبيتها، يتطلب إعداد LVM ثلاث خطوات، تقابل المستويات الثلاث للمفاهيم.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
ar-MA: أولاً، نجهز الحيزات الفيزيائية باستخدام <command>pvcreate</command>:

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
ar-MA: حتى الآن، كل شيء على ما يرام؛ لاحظ أنه يمكن إعداد PV على قرص كامل كما يمكن ذلك على أقسام الأقراص. يسرد الأمر <command>pvdisplay</command> الحيزات الفيزيائية الموجودة، وذلك في صيغتين مختلفتين للخرج، كما هو موضح أعلاه.

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
ar-MA: دعنا الآن نجمع هذه العناصر الفيزيائية في VG باستخدام <command>vgcreate</command>. سوف نجمع الحيزات الفيزيائية من الأقراص السريعة فقط في مجموعة اسمها <filename>vg_critical</filename>؛ أما المجموعة الأخرى، <filename>vg_normal</filename>، فسوف تحوي عناصر سريعة وأخرى بطيئة.

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
ar-MA: الأوامر هنا أيضًا واضحة جداً ( كما أن <command>vgdisplay</command> يوفر صيغتين للخرج). لاحظ أنه من الممكن استخدام قسمين من القرص الفيزيائي نفسه في مجموعتين مختلفتين. لاحظ أيضًا أننا استخدمنا بادئة <filename dir="ltr">vg_</filename> عند تسمية VGs التي أنشأناها ولكن هذا مجرد اصطلاح.

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
ar-MA: يوجد معاملان مطلوبان عند إنشاء الحيزات المنطقية؛ ويجب تمريرهما إلى الأمر <command>lvcreate</command> كخيارات. الأول هو اسم LV الذي سوف ننشئه ويحدد بالخيار <literal dir="ltr">-n</literal>، والثاني هو حجم LV ويعطى عمومًا بالخيار <literal dir="ltr">-L</literal>. نحتاج أيضًا إعلام الأمر باسم VG التي يطبق عليها طبعًا، وهذا هو المعامل الأخير في التعليمة.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
ar-MA: <emphasis>التعمق أكثر</emphasis> خيارات <command>lvcreate</command>

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
ar-MA: للأمر <command>lvcreate</command> العديد من الخيارات تسمح بضبط عملية إنشاء LV.

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
ar-MA: دعنا أولاً نشرح الخيار <literal dir="ltr">-l</literal>، الذي يسمح بتحديد حجم الحيز المنطقي كعدد من الكتل (بدلاً من استخدام الواحدات ”البشرية“ كما فعلنا في المثال السابق). هذه الكتل (التي تدعى PEs، أي <emphasis>physical extents</emphasis>، بحسب مصطلحات LVM) هي وحدات متجاورة من المساحة التخزينية في الحيزات الفيزيائية، ولا يمكن أن تقسم الواحدة منها بين الحيزات المنطقية. عندما يحتاج المرء لتحديد السعة التخزينية للحيز المنطقي بدقة أكبر، مثلاً لاستخدام كامل المساحة المتوفرة، سيكون الخيار <literal dir="ltr">-l</literal> مفضلاً على الخيار <literal dir="ltr">-L</literal> غالبًا.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
ar-MA: ينتهي المطاف بالحيزات المنطقية بعد إنشائها كملفات أجهزة كتلية في <filename dir="ltr">/dev/mapper/</filename>:

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
ar-MA: عند إقلاع الحاسب، تنفذ وحدة الخدمة <filename>lvm2-activation</filename> التابعة لنظام systemd الأمر <command>vgchange -aay</command> ”لتنشيط activate“ مجموعات الحيزات: حيث يفحص الأجهزة المتوفرة؛ وتُسجَّل الأجهزة التي تمت تهيئتها كحيزات فيزيائية ضمن نظام LVM الفرعي، وتجمَع الحيزات التي تنتمي لمجموعات في مجموعاتها، ثم تنشط الحيزات المنطقية وتصبح متوفرة. لا حاجة إذاً لتحرير أي ملفات إعداد عند إنشاء أو تعديل حيزات LVM.

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
ar-MA: لكن لاحظ أن خريطة عناصر LVM ( الحيزات الفيزيائية والمنطقية، والمجموعات) تُنسَخ احتياطيًا إلى <filename dir="ltr">/etc/lvm/backup</filename>، وهذه قد تفيد في حال حدوث مشكلة (أو لاختلاس النظر تحت الغطاء).

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
ar-MA: لتسهيل الأمور، يتم إنشاء اختصارات رمزيّة أيضًا في مجلدات بأسماء VGs نفسها:

en: The LVs can then be used exactly like standard partitions:
ar-MA: يمكن استخدام LVs عندها مثل أي قسم نظامي تماماً:

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
ar-MA: من وجهة نظر التطبيقات، تم تحويل الأقسام الصغيرة العديدة إلى حيز كبير واحد بحجم 12غ.ب، وله اسم ألطف.

en: LVM Over Time
ar-MA: ‏LVM مع الزمن

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
ar-MA: بالرغم من أن ميزة جمع الأقراص أو الأقسام الفيزيائية مفيدة، إلا أنها ليست الميزة الأساسية لاستخدام LVM. لا تبدو المرونة التي تحصل عليها من LVM واضحة إلا بعد مرور فترة من الزمن بشكل خاص، عندما تتغير الحاجات. في مثالنا السابق، دعنا نفترض أن هناك ملفات جديدة كبيرة يجب تخزينها، وأن الحيز المنطقي المخصص لمخدم الملفات صغير جداً عليها. بما أننا لم نستهلك كامل المساحة الحرة المتوفرة على <filename>vg_critical</filename>، يمكننا توسعة <filename>lv_files</filename>. سوف نستخدم الأمر <command>lvresize</command> لذلك الغرض، ثم نستخدم <command>resize2fs</command> لملائمة نظام الملفات مع الحجم الجديد:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
ar-MA: <emphasis>تحذير</emphasis> تحجيم نظم الملفات

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
ar-MA: يمكن توسعة نظم الملفات ext3، وext4 و xfs دون فصل الاتصال (online)؛ أما التقليص فيحتاج الفصل عن شجرة الملفات. يسمح نظام الملفات reiserfs بالتحجيم أثناء الاتصال في الاتجاهين. أما صاحب الجلالة ext2 فلا يسمح بأي منهما، ويحتاج للفصل في جميع الحالات.

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
ar-MA: يمكننا توسعة الحيز الذي يستضيف قاعدة البيانات بنفس الأسلوب، لولا أننا وصلنا لحدود المساحة المتاحة على المجموعة:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
ar-MA: <emphasis>التعمق أكثر</emphasis> LVM متقدم

en: RAID or LVM?
ar-MA: ‏RAID أو LVM؟

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
ar-MA: يقدم كلٌّ من RAID وLVM ميزات لا تقبل الجدل عندما يبتعد المرء عن الحالة البسيطة للحاسوب المكتبي ذي القرص الواحد حيث لا تتغير الاستخدامات مع مرور الزمن. لكن RAID وLVM يتباعدان في اتجاهين مختلفين، وتتباعد أهدافهما، ومن المقبول أن يتسائل المرء عن أي التقنيتين يجب أن يتبناها. الإجابة الأنسب ستعتمد طبعاً على الحاجات الحالية والمتوقعة.

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
ar-MA: هناك عدة حالات بسيطة حيث لا تظهر فيها أي تساؤلات فعلية. إذا كان الهدف هو حماية البيانات من عطب العتاد، فالحل طبعاً هو إعداد RAID مع مصفوفة أقراص ذات فائض تخزيني، نظرًا لأن LVM لا يعالج هذه المشكلة أبداً. من جهة أخرى، إذا كان هناك حاجة لتصميم تخزيني مرن تستقل فيه الحيزات التخزينية عن المخطط الفيزيائي للأقراص، عندها RAID لا يساعد كثيراً وLVM هو الخيار الطبيعي.

en: <emphasis>NOTE</emphasis> If performance matters…
ar-MA: <emphasis>ملاحظة</emphasis> إذا كان الأداء مهمًا…

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
ar-MA: حالة الاستخدام الثالثة الجديرة بالاهتمام هي عندما يحتاج المرء جمع قرصين في حيز تخزيني واحد، وذلك بهدف زيادة الأداء أو للحصول على نظام ملفات أكبر من سعة الأقراص المتوفرة. يمكن معالجة هذه الحالة باستخدم RAID-0 (أو حتى linear-RAID) أو باستخدام LVM. في هذه الحالة، يقع الاختيار على LVM ما لم تكن هناك قيود إضافية (الانسجام مع بقية الحواسيب إذا كانت تعتمد على RAID مثلاً). الإعداد الأولي لنظام LVM أكثر تعقيداً بقليل، ولكن المرونة الإضافية التي يوفرها تعوض هذه الزيادة الطفيفة في التعقيدات عندما تتغير المتطلبات التخزينية أو إذا دعت الحاجة لإضافة أقراص جديدة.

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
ar-MA: ثم نصل طبعاً إلى حالة الاستخدام الشيقة حقاً، وهي عندما نحتاج نظاماً تخزينياً يقاوم أعطال العتاد ومرناً من ناحية توزيع الحيزات التخزينية. لا يستطيع RAID وحده ولا LVM معالجة المتطلبين معاً؛ هذه هي الحالة التي نستخدم فيها الاثنين في الوقت نفسه — أو بالأحرى، نستخدم أحدهما فوق الآخر. أكثر طريقة مستخدمة منذ وصل RAID و LVM إلى مرحلة النضج هي ضمان حماية البيانات أولاً من خلال جمع الأقراص في عدد صغير من مصفوفات RAID الكبيرة، ثم استخدام هذه المصفوفات كحيزات فيزيائية لنظام LVM؛ بعدها تقطع LVs إلى أقسام منطقية لإنشاء نظم الملفات. إن ميزة هذا الأسلوب هي أنه عندما يتعطل قرص ما، سنحتاج لإعادة بناء عدد صغير من مصفوفات RAID، وبالتالي اختصار الوقت الذي يقضيه مدير النظام في الاستعادة.

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
ar-MA: سوف نجمع RAID-1 و LVM معاً لإيفاء هذه الشروط. سوف نصل القرصين إلى متحكمي SATA مختلفين لتحسين الوصول المتوازي وتخفيف خطر الأعطال المتزامنة، بالتالي سوف يظهر القرصان باسمي <filename>sda</filename> و<filename>sdc</filename>. سوف نقطِّع القرصين وفق المخطط التالي:

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
ar-MA: بعد إنشاء VGs، يمكن تقطيعها بطريقة مرنة جداً. يجب أن نأخذ بعين الاعتبار أن LVs التي ننشئها في <filename>vg_raid</filename> ستبقى محفوظة حتى لو تعطل أحد القرصين، لكن هذا لا ينطبق على LVs التي ننشئها في <filename>vg_bulk</filename>؛ من ناحية أخرى، سوف تحجز الحيزات المنطقية في <filename>vg_bulk</filename> على القرصين على التوازي، ما يسمح بسرعات قراءة أو كتابة أكبر للملفات الكبيرة.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
ar-MA: <emphasis>ملاحظة</emphasis> لماذا ثلاثة حيزات RAID-1؟

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
ar-MA: كان يمكن إعداد حيز RAID-1 واحد فقط ليعمل كحيز فيزيائي نضع عليه <filename>vg_raid</filename>. فلم أنشأنا ثلاثة منها إذاً؟

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
ar-MA: السبب وراء القسم الأول (فصل <filename>md0</filename> عن البقية) هو أمان البيانات: فالبيانات التي تكتب على مرايا RAID-1 هي نفسها على جميع الأقراص، ولذلك يمكن تجاوز طبقة RAID وربط أحد أقراص المصفوفة مباشرة. في حال مواجهة علة في النواة مثلاً، أو إذا تضررت البيانات الفوقية التي تُعرّف LVM، يمكن عندها إقلاع نظام أصغري يسمح بالوصول إلى البيانات الحساسة مثل مخطط الأقراص في حيزات RAID وLVM؛ يمكن حينئذ إعادة بناء البيانات الفوقية والوصول للملفات ثانية، بحيث يعود النظام إلى حالته النظامية.

en: <primary>virtualization</primary>
ar-MA: <primary>الحوسبة الظاهرية (virtualization)</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
ar-MA: الحوسبة الظاهرية (virtualization) هي إحدى أهم تطورات الحوسبة في السنوات الأخيرة. يغطي المصطلح العديد من المفاهيم والتقنيات المستخدمة لمحاكاة الحواسيب الظاهرية بدرجات متفاوتة من الاستقلال عن العتاد الفعلي. يمكن لمخدم فيزيائي واحد عندها أن يستضيف العديد من الأنظمة التي تعمل في الوقت نفسه بمعزل عن بعضها. تطبيقات هذه التقنية عديدة، وهي مشتقة غالبًا من فكرة العزل: كاختبار بيئات لها إعدادات مختلفة مثلاً، أو فصل الخدمات المقدمة عبر حواسيب ظاهرية (virtual) مختلفة لزيادة الأمن.

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
ar-MA: هناك الكثير من حلول الحوسبة الظاهرية، لكل منها ميزاته وعيوبه. يركز هذا الكتاب على Xen، و LXC، وKVM، لكن هناك حلول أخرى تستحق الذكر منها:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
ar-MA: Bochs هو نظام محاكاة حر آخر، لكنه يحاكي معماريات x86 فقط (i386 و amd64).

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
ar-MA: Xen<indexterm><primary>Xen</primary></indexterm> هو حل محاكاة ”شبه ظاهرية – paravirtualization“. يقدم Xen طبقة عزل رقيقة، تدعى ”المشرف – hypervisor“، بين العتاد والأنظمة العليا؛ تعمل بمثابة مرجع يتحكم بالوصول للعتاد من الحواسيب الظاهرية. لكنها تعالج عدداً قليلاً من التعليمات، أما البقية فتنفذ مباشرة على العتاد بالنيابة عن الأنظمة الظاهرية. الميزة الأساسية هي أن مستوى الأداء لا ينخفض، والنظم تعمل بسرعات تقترب من السرعة الأصلية؛ لكن نقطة الضعف هي أن نوى نظم التشغيل التي يمكن استخدامها مع مشرف Xen يجب تعديلها لتناسب العمل على Xen.

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
ar-MA: <emphasis>ثقافة</emphasis> Xen والإصدارات المختلفة من لينكس

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
ar-MA: تم تطوير Xen أساسًا كمجموعة من الترقيعات التي بقيت خارج الشجرة الرسمية، ولم تدمج في النواة لينكس. في الوقت نفسه، تطلبت عدة نظم محاكاة جديدة (بما فيها KVM) بعض الدوال العامة المتعلقة بالمحاكاة لتسهيل دمجها، وأضيفت هذه الدوال إلى النواة لينكس (التي تعرف بواجهة <emphasis>paravirt_ops</emphasis> أو <emphasis>pv_ops</emphasis>). وبما أن رقع Xen كانت تكرر بعض وظائف هذه الواجهة، لم يعد قبولها رسميًا ممكنًا.

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
ar-MA: <emphasis>ثقافة</emphasis> Xen والنوى المختلفة عن لينكس

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
ar-MA: لكن إذا كان Xen يستطيع الاعتماد على تعليمات العتاد المختصة بالمحاكاة (المتوفرة فقط في المعالجات الأحدث)، فيمكن تشغيل النظم غير المعدلة أيضًا في domU (بما في ذلك Windows).

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
ar-MA: <emphasis>ملاحظة</emphasis> المعماريات المتوافقة مع Xen

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
ar-MA: حالياً Xen متاح فقط لمعماريات i386 وamd64 وarm64 وarmhf.

en: Using Xen under Debian requires three components:
ar-MA: استخدام Xen في دبيان يحتاج ثلاثة مكونات:

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
ar-MA: معمارية i386 تحتاج أيضًا لمكتبة قياسية مع الترقيعات المناسبة للاستفادة من Xen؛ هذه متوفرة في الحزمة <emphasis role="pkg">libc6-xen</emphasis>.

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
ar-MA: بعد تثبيت هذه المتطلبات، يأتي دور اختبار سلوك dom0 نفسه؛ هذا يحتاج إعادة الإقلاع إلى المشرف ونواة Xen. يجب أن يقلع النظام بالأسلوب العادي، مع بعض الرسائل الإضافية على الشاشة خلال خطوات التهيئة المبكرة.

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
ar-MA: الآن حان وقت تثبيت أنظمة مفيدة على نطاقات domU، باستخدام الأدوات من حزمة <emphasis role="pkg">xen-tools</emphasis>. توفر هذه الحزمة الأمر <command>xen-create-image</command>، الذي يؤتمت معظم المهمة. البارامتر الإجباري الوحيد هو <literal dir="ltr">--hostname</literal>، لإعطاء اسم للنطاق domU؛ الخيارات الأخرى هامة، لكن يمكن تخزينها في ملف الضبط <filename dir="ltr">/etc/xen-tools/xen-tools.conf</filename>، وغيابها من سطر الأوامر لا يسبب خطأ. من المهم إذاً التحقق من محتويات هذا الملف قبل إنشاء الصور، أو استخدام بارامترات إضافية عند استدعاء <command>xen-create-image</command>. نذكر من البارامترات الهامة:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
ar-MA: <literal dir="ltr">--memory</literal>، لتحديد كمية RAM المخصصة للنظام الجديد؛

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
ar-MA: <literal dir="ltr">--size</literal> و <literal dir="ltr">--swap</literal>، لتحديد حجم ”الأقراص الظاهرية“ المتاحة للـ domU؛

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
ar-MA: <emphasis>التعمق أكثر</emphasis> تثبيت نظام آخر غير دبيان في domU

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
ar-MA: في حال تثبيت نظام تشغيل لا يعتمد على نواة لينكس، يجب الانتباه لتحديد النواة التي يجب أن يستخدمها domU، عبر استخدام الخيار <literal dir="ltr">--kernel</literal>.

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
ar-MA: يبين <literal dir="ltr">--dhcp</literal> أن الحصول على إعدادات الشبكة في domU يتم من خلال DHCP بينما يسمح <literal dir="ltr">--ip</literal> بتحديد عنوان IP ستاتيكي (ثابت).

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
ar-MA: أخيراً، يجب اختيار طريقة التخزين للصور المنشأة (التي سيراها domU على أنها أقراص صلبة). أبسط طريقة، التي تقابل الخيار <literal dir="ltr">--dir</literal>، هي إنشاء ملف على dom0 لكل جهاز يجب تقديمه للـ domU. هناك بديل للأنظمة التي تستخدم LVM، وهو استخدام الخيار <literal dir="ltr">--lvm</literal>، متبوعاً باسم مجموعة حيزات (VG)؛ عندئذ سينشئ <command>xen-create-image</command> حيزاً منطقيًا جديداً داخل تلك المجموعة، وسيكون هذا الحيز الجديد متاحاً للـ domU بشكل قرص صلب.

en: <emphasis>NOTE</emphasis> Storage in the domU
ar-MA: <emphasis>ملاحظة</emphasis> التخزين في domU

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
ar-MA: يمكن تصدير أقراص صلبة كاملة إلى domU، كما يمكن تصدير أقسام الأقراص، أو مصفوفات RAID أو حيزات LVM منطقية موجودة مسبقًا. لكن هذه العمليات لا يديرها الأمر <command>xen-create-image</command>، لذلك يجب تحرير ملف إعداد صورة Xen بعد إنشاءه أولاً باستخدام <command>xen-create-image</command>.

en: Once these choices are made, we can create the image for our future Xen domU:
ar-MA: بعد تحديد هذه الخيارات، يمكننا إنشاء صورة domU:

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
ar-MA: لدينا الآن حاسوب ظاهري، لكنه لا يعمل حاليًا (وبالتالي فهو لا يشغل سوى المساحة على القرص الصلب في dom0). طبعاً يمكننا إنشاء المزيد من الصور، وربما استخدمنا بارامترات أخرى.

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
ar-MA: أبسط نموذج هو النموذج الجسري <emphasis>bridge</emphasis> model؛ وفيه تعمل جميع بطاقات eth0 (في أنظمة dom0 وdomU على حد سواء) كما لو كانت موصولة مباشرة مع تحويلة إيثرنت Ethernet switch.

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
ar-MA: بعدها يأتي نموذج التوجيه <emphasis>routing</emphasis> model، حيث يعمل dom0 كموجه (راوتر) ما بين أنظمة domU والشبكة الخارجية (الفيزيائية).

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
ar-MA: أخيراً، نموذج <emphasis>NAT</emphasis>، وفيه يصل dom0 ثانية بين أنظمة domU وباقي عناصر الشبكة، لكن لا يمكن الوصول مباشرة من الخارج إلى أنظمة domU، وتمر البيانات عبر dom0 باستخدام network address translation (ترجمة عنوان الشبكة).

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
ar-MA: هذه الأنماط الثلاثة تحتاج عدداً من الواجهات ذات المسميات الغريبة، مثل <filename dir="ltr">vif*</filename>، و<filename dir="ltr">veth*</filename>، ‏<filename dir="ltr">peth*</filename> وأيضًا <filename>xenbr0</filename>. يرتب مشرف Xen هذه الواجهات في التخطيط الذي يعرفه المستخدم، حيث يتم التحكم بأدوات من فضاء المستخدم (user-space tools). سوف نقتصر على شرح النموذج الجسري، بما أن نموذج NAT ونموذج التوجيه يناسبان بعض الحالات الخاصة فقط.

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
ar-MA: <emphasis>أدوات</emphasis> اختيار أدوات إدارة أجهزة Xen الظاهرية

en: <emphasis>CAUTION</emphasis> Only one domU per image!
ar-MA: <emphasis>تحذير</emphasis> domU واحد فقط لكل صورة!

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
ar-MA: لاحظ أن النطاق <filename>testxen</filename> يستهلك ذاكرة حقيقية من الـRAM المتاحة للنطاق dom0، وليست ذاكرة ظاهرية. يجب أخذ الحيطة إذن عند بناء مخدم لاستضافة نسخ Xen، وتزويده بذاكرة فيزيائية مناسبة.

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
ar-MA: ڤوالا! آلتنا الظاهرية قيد الإقلاع. يمكننا الوصول إليها بإحدى طريقتين. الطريقة المعتادة هي الاتصال بها ”عن بعد“ عبر الشبكة، كما كنا سنتصل بأي حاسب حقيقي؛ هذا يحتاج عادة مخدم DHCP أو بعض إعدادات DNS. الطريقة الأخرى، ولعلها الطريقة الوحيدة إذا كانت إعدادات الشبكة غير صحيحة، هي استخدام طرفية <filename>hvc0</filename>، باستخدام الأمر <command>xl console</command>:

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
ar-MA: بعدها يمكنك بدء جلسة، كما لو كنت تجلس وراء لوحة مفاتيح الحاسب الظاهري. يتم الانفصال عن هذه الطرفية بالمفتاحين <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo>‎.

en: <emphasis>TIP</emphasis> Getting the console straight away
ar-MA: <emphasis>تلميح</emphasis> الوصول للطرفية مباشرة

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
ar-MA: أحياناً يرغب المرء بتشغيل domU والوصول إلى طرفية النظام فوراً؛ ولذلك يقبل الأمر <command>xl create</command> الخيار <literal dir="ltr">-c</literal>. تشغيل domU مع هذا الخيار سوف يعرض كل الرسائل مع إقلاع النظام.

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
ar-MA: بعد أن يعمل domU، يمكن استخدامه مثل أي مخدم آخر (بما أنه نظام غنو/لينكس في النهاية). لكن بما أنه حاسب ظاهري فهذه الحالة تسمح ببعض المزايا الإضافية. مثلاً، يمكن إيقاف عمل domU مؤقتاً ثم استكماله، بالأمرين <command>xl pause</command> و<command>xl unpause</command>. لاحظ أن الذاكرة المخصصة للنطاق domU تبقى محجوزة أثناء الإيقاف المؤقت، رغم أنه لا يستهلك أي طاقة حسابية من المعالج. الأمران <command>xl save</command> و<command>xl restore</command> جديران بالاهتمام أيضاً: حفظ domU يحرر الموارد التي كان يستهلكها، بما في ذلك ذاكرة RAM. لا يلاحظ domU عند استعادته (أو استكمال عمله) أي شيء إلا مرور الزمن. إذا كان domU يعمل عند إيقاف تشغيل dom0، فسوف تحفظ سكربتات الحزمة حالة domU آلياً، وتستعيدها عند الإقلاع التالي. هذا يؤدي طبعاً للمتاعب التي تظهر عادة عند إسبات الحاسب المحمول. على سبيل المثال؛ إذا تعلق domU لفترة طويلة، فقد تلغى اتصالاته الشبكية. لاحظ أيضاً أن Xen حتى الآن غير متوافق مع شريحة واسعة من واجهة ACPI لإدارة الطاقة، ما يحول دون إمكانية إسبات النظام المستضيف (dom0).

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
ar-MA: يمكن إيقاف أو إعادة تشغيل domU إما من داخل domU نفسه (بالأمر <command>shutdown</command>) أو من dom0، بالأمر <command>xl shutdown</command> أو <command>xl reboot</command>.

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
ar-MA: تحتاج معظم أوامر <command>xl</command> الفرعية إلى متغير واحد أو أكثر، غالباً هي اسم domU. هذه المتغيرات مشروحة بشكل جيد في صفحة التعليمات <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry>‎.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
ar-MA: <emphasis>التعمق أكثر</emphasis> خيارات Xen المتقدمة

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
ar-MA: بالرغم من أن LXC يستخدم لبناء ”حواسيب ظاهرية“، إلا أن LXC –إذا تحرينا الدقة– ليس نظام محاكاة، بل هو نظام لعزل مجموعات من العمليات عن بعضها مع أنها تعمل على نفس الحاسب المستضيف. يستفيد هذا النظام من مجموعة من التطورات الحديثة في النواة لينكس، التي تعرف باسم مجموعات التحكم—<emphasis>control groups</emphasis>، التي تسمح لعدة زمر مختلفة من العمليات التي تدعى ”المجموعات“ برؤية بعض مظاهر النظام الكلي بشكل مختلف. من أبرز هذه المظاهر هي أرقام تعريف العمليات PIDs، وإعدادات الشبكة، ونقاط الربط في نظام الملفات. لا تستطيع أي مجموعة عمليات معزولة مثل هذه الوصول بأي شكل إلى العمليات الأخرى في النظام، كما يمكن تقييد وصولها إلى نظام الملفات بجزء فرعي محدد. يمكن لها أن تملك واجهة شبكية وجدول توجيه خاصين بها، ويمكن ضبطها حتى ترى مجموعة جزئية فقط من الأجهزة المتاحة المتصلة بالنظام.

en: <emphasis>NOTE</emphasis> LXC isolation limits
ar-MA: <emphasis>ملاحظة</emphasis> حدود العزل في LXC

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
ar-MA: حاويات LXC لا توفر درجة العزل التي تحصل عليها عند استخدام محاكيات أو حلول حوسبة ظاهرية أثقل. على وجه الخصوص:

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
ar-MA: بما أن النواة مشتركة بين النظام المستضيف والحاويات، فإن العمليات المحجوزة في الحاويات ستبقى تصل لرسائل النواة، ما قد يؤدي لتسرب المعلومات إذا بثت الحاوية الرسائل؛

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
ar-MA: للأسباب ذاتها، إذا تم اختراق حاوية وتم استغلال ثغرة في النواة، فقد تتأثر الحاويات الأخرى أيضًا؛

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
ar-MA: في نظام الملفات، تتحقق النواة من الصلاحيات وفقاً للمعرفات العددية للمستخدمين والمجموعات؛ وربما كانت هذه المعرفات تشير لمستخدمين ومجموعات مختلفة حسب الحاوية، ويجب أخذ هذا بعين الاعتبار عند مشاركة أجزاء قابلة للكتابة من نظام الملفات بين عدد من الحاويات.

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
ar-MA: بما أننا نتعامل مع تقنية عزل وليست محاكاة وحسب، فإن إعداد حاويات LXC أعقد من تشغيل مثبت دبيان على جهاز ظاهري. سوف نشرح بعض المتطلبات الأولية، ثم نتجه إلى إعداد الشبكة؛ وبعدها سوف نتمكن من إنشاء النظام الذي سيعمل ضمن الحاوية.

en: Preliminary Steps
ar-MA: الخطوات الأولية

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
ar-MA: تحوي الحزمة <emphasis role="pkg">lxc</emphasis> الأدوات اللازمة لتشغيل LXC، ويجب تثبيتها إذن.

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
ar-MA: يحتاج LXC أيضاً لنظام مجموعات التحكم <emphasis>control groups</emphasis> للإعداد، وهو نظام ملفات ظاهري يتم ربطه على <filename dir="ltr">/sys/fs/cgroup</filename>. بما أن دبيان 8 قد انتقلت إلى systemd، الذي يعتمد أيضاً على مجموعات التحكم، فهذا يتم تلقائياً أثناء الإقلاع دون الحاجة لأي عمليات إضافية.

en: Network Configuration
ar-MA: إعداد الشبكة

en: They should be disabled and replaced with the following:
ar-MA: فيجب تعطيلها واستبدالها بالتالي:

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
ar-MA: إن نتيجة هذا الإعداد ستشبه ما نحصل عليه لو كانت الحاويات أجهزة تتصل بشبكة المستضيف الفيزيائية نفسها. يدير الإعداد ”الجسري“ حركة إطارات الإيثرنت بين جميع الواجهات المجسَّرة، بما فيها الواجهة الفيزيائية <literal>eth0</literal> بالإضافة للواجهات الظاهرية المعرفة في الحاويات.

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
ar-MA: هذا الإعداد ”الغني“ يحتاج –بالإضافة إلى حزمة <emphasis role="pkg">bridge-utils</emphasis>– إلى الحزمة <emphasis role="pkg">vde2</emphasis>؛ عندئذ يصبح ملف <filename dir="ltr">/etc/network/interfaces</filename> كما يلي:

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
ar-MA: بعدها يمكن إعداد الشبكة إما ستاتيكيًا في الحاويات، أو ديناميكيًا باستخدام مخدم DHCP يعمل على المستضيف. إذا استخدم مخدم DHCP فيجب إعداده لإجابة الطلبات على الواجهة <literal>br0</literal>.

en: Setting Up the System
ar-MA: إعداد النظام

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
ar-MA: لاحظ أن إنشاء نظام الملفات يتم أولاً في <filename dir="ltr">/var/cache/lxc</filename>، ثم ينقل إلى المجلد الوجهة. هذا يسمح بإنشاء حاويات متطابقة أسرع بكثير، نظراً لأنك تحتاج للنسخ فقط لا أكثر.

en: Another useful entry in that file is the setting of the hostname:
ar-MA: من المدخلات المفيدة أيضًا التي يمكن إضافتها لهذا الملف هي تعيين اسم المستضيف hostname:

en: Starting the Container
ar-MA: تشغيل الحاوية

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
ar-MA: نحن الآن داخل الحاوية؛ ووصولنا إلى العمليات مقيد بالعمليات التي بدأت من داخل الحاوية نفسها، كما أن وصولنا إلى نظام الملفات مقيد إلى المجموعة الجزئية المعينة لهذه الحاوية من نظام الملفات الكامل (<filename dir="ltr">/var/lib/lxc/testlxc/rootfs</filename>). يمكننا الخروج من الطرفية باستخدام <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
ar-MA: تحوي الحزمة <emphasis role="pkg">lxc</emphasis> سكربت تهيئة يستطيع تشغيل حاوية واحدة أو أكثر آلياً عند إقلاع المستضيف (يعتمد السكربت على أمر <command>lxc-autostart</command> الذي يشغل كل الحاويات التي يكون خيار <literal>lxc.start.auto</literal> فيها مضبوطاً على القيمة 1). يمكن التحكم بدقة أكبر بترتيب التشغيل من خلال <literal>lxc.start.order</literal> و<literal>lxc.group</literal>: افتراضياً، يبدأ السكربت أولاً بتشغيل الحاويات التي تنتمي للمجموعة <literal>onboot</literal> ثم الحاويات التي لا تنتمي لأي مجموعة. وفي كلا الحالتين، يتحدد الترتيب فيما بين أعضاء المجموعة الواحدة من خلال الخيار <literal>lxc.start.order</literal>.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
ar-MA: <emphasis>التعمق أكثر</emphasis> المحاكاة العملاقة

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
ar-MA: بما أن LXC هو نظام عزل خفيف جداً، يمكن تكييفه للاستضافة الكبيرة للعديد من المخدمات الظاهرية. لعل إعداد الشبكة سيكون أعقد بقليل مما شرحناه هنا، لكن الإعداد ”الغني“ باستخدام واجهات <literal>tap</literal> و<literal>veth</literal> يجب أن يكون كافيًا في العديد من الحالات.

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
ar-MA: ربما كان مناسباً أيضًا مشاركة أجزاء من نظام الملفات، مثل <filename dir="ltr">/usr</filename> و<filename dir="ltr">/lib</filename>، لتفادي تكرار البرمجيات المشتركة بين عدة حاويات. هذا يحقق عادة باستخدام مدخلات <literal>lxc.mount.entry</literal> في ملف إعداد الحاويات. هناك أثر جانبي جميل هنا وهو أن العمليات ستستهلك ذاكرة أقل في هذه الحالة، لأن النواة تقدر على اكتشاف البرامج المشتركة. عندئذ يمكن تخفيض الكلفة الهامشية لإضافة حاوية جديدة للمساحة التخزينية المخصصة لبياناتها، والعمليات القليلة الإضافية التي ستديرها النواة وتجدولها.

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
ar-MA: لم نشرح كافة الخيارات المتاحة، بالطبع؛ يمكنك الحصول على معلومات أوسع من صفحات الكتيبات <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry>‎ و<citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>‎ والصفحات التي تشيران إليها.

en: Virtualization with KVM
ar-MA: المحاكاة في KVM

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
ar-MA: KVM، التي ترمز إلى <emphasis>Kernel-based Virtual Machine</emphasis>، هي أولاً وأخيراً وحدة من وحدات النواة توفر معظم البنية التحتية التي يمكن أن يستفيد منها برنامج المحاكاة، لكنها ليست محاكيًا. التحكم الفعلي بالمحاكاة يتم من خلال تطبيق مبني على QEMU. لا تقلق إذا كان هذا القسم يذكر أوامر تبدأ ب <command dir="ltr">qemu-*</command>: نحن لا نزال نتحدث عن KVM.

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
ar-MA: لقد دمجت KVM منذ البداية في النواة لينكس، بخلاف نظم المحاكاة الأخرى. اختر مطوروها استغلال مجموعات تعليمات المعالج المخصصة للمحاكاة (Intel-VT و AMD-V)، ما جعل KVM خفيفة الوزن، وأنيقة وغير شرهة للموارد. الجانب السلبي، طبعاً، هو أن KVM لا تعمل إلا على الحواسيب التي تملك معالجات مناسبة. بالنسبة للحواسيب ذات معمارية x86، يمكنك التأكد أن المعالج مناسب عن طريق البحث عن ”vmx“ أو ”svm“ في أعلام المعالج المذكورة في <filename dir="ltr">/proc/cpuinfo</filename>.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
ar-MA: مع دعم Red Hat النشط لتطوير KVM، فقد أصبحت بشكل أو بآخر المرجع في الحوسبة الظاهرية في لينكس.

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
ar-MA: تقدم الحزمة <emphasis role="pkg">virtinst</emphasis> الأداة <command>virt-install</command>، التي تسمح بإنشاء الحواسيب الظاهرية من سطر الأوامر. أخيراً، يسمح <emphasis role="pkg">virt-viewer</emphasis> بالوصول إلى الطرفية الرسومية للحاسب الظاهري.

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
ar-MA: كما في Xen و LXC، أكثر الخيارات شيوعاً عند إعداد الشبكة هو استخدام جسر يجمع الواجهات الشبكية لعدة حواسيب ظاهرية (انظر <xref linkend="sect.lxc.network" />).

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
ar-MA: أو يمكن، كما هو الإعداد الافتراضي الذي تقدمه KVM، إعطاء الحاسب الظاهري عنوناً داخلياً (ضمن المجال 192.168.122.0/24)، وإعداد NAT حتى يتمكن الجهاز الظاهري من الوصول إلى الشبكة الخارجية.

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
ar-MA: سنفترض في تتمة هذا القسم أن المستضيف لديه واجهة فيزيائية <literal>eth0</literal> وجسر <literal>br0</literal>، وأن الأولى متصلة مع الأخير.

en: Installation with <command>virt-install</command>
ar-MA: التثبيت باستخدام <command>virt-install</command>

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
ar-MA: يشبه إنشاء حاسب ظاهري تثبيت النظم العادية كثيراً، عدا أن مواصفات الحواسب الظاهري تُحدَّد في أمر طويل جداً.

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
ar-MA: عملياً، هذا يعني أننا سنستخدم برنامج تثبيت دبيان، من خلال إقلاع الحاسب الظاهري من سواقة DVD-ROM ظاهرية ترتبط مع صورة DVD دبيان مخزنة على النظام المستضيف. سوف يُصدِّر الجهاز الظاهري طرفيته الرسومية عبر بروتوكول VNC (انظر <xref linkend="sect.remote-desktops" /> للتفاصيل)، ما يسمح لنا بالتحكم بعملية التثبيت.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
ar-MA: <emphasis>تلميح</emphasis> أضف مستخدمك إلى المجموعة libvirt

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
ar-MA: دعنا نبدأ الآن عملية تثبيت الحاسب الظاهري، وإلقاء نظرة قريبة على أهم خيارات <command>virt-install</command>. هذا الأمر يسجل الجهاز الظاهري وبارامتراته عند libvirtd، ثم يشغله حتى نتابع عملية التثبيت.

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
ar-MA: يحدد خيار <literal dir="ltr">--connect</literal> ”المشرف“ المستخدم. شكله هو شكل URL يحوي اسم نظام المحاكاة (<literal dir="ltr">xen://</literal>‏، <literal dir="ltr">qemu://</literal>‏، <literal dir="ltr">lxc://</literal>‏، <literal dir="ltr">openvz://</literal>‏، <literal dir="ltr">vbox://</literal>، وهكذا) والحاسب الذي يجب أن يستضيف الجهاز الظاهري (يمكن ترك هذا فارغًا في حالة  الاستضافة المحلية). لالإضافة لذلك، في حالة استخدام QEMU/KVM، يستطيع كل مستخدم إدارة الحواسيب الظاهرية ولكن بصلاحيات مقيدة، ويسمح مسار URL بتمييز حواسيب ”النظام“ (<literal dir="ltr">/system</literal>) من الحواسيب الظاهرية (<literal dir="ltr">/session</literal>).

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
ar-MA: بما أن طريقة إدارة KVM تطابق طريقة إدارة QEMU، فإن الخيار <literal dir="ltr">--virt-type kvm</literal> يسمح بتحديد استخدام KVM بالرغم من أن URL يبدو وكأنه QEMU.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
ar-MA: خيار <literal dir="ltr">--name</literal> يحدد اسمًا (فريداً) للجهاز الظاهري.

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
ar-MA: يستخدم خيار <literal dir="ltr">--cdrom</literal> للإشارة إلى موقع القرص الضوئي المستخدم للتثبيت. يمكن أن يكون المسار مساراً محلياً لصورة ISO، أو URL يمكن الحصول منه على الملف، أو ملف جهاز يمثل سواقة CD-ROM فيزيائية (مثل <literal dir="ltr">/dev/cdrom</literal>).

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
ar-MA: يحدد <literal dir="ltr">--network</literal> طريقة دمج بطاقة الشبكة الظاهرية في إعدادات الشبكة في المستضيف. السلوك الافتراضي (الذي  حددنا استخدامه صراحة في مثالنا) هو دمجها في أي جسر شبكي سابق. إذا لم يكن هناك أي جسر من قبل، فلن يستطيع الجهاز الظاهري الوصول إلى الشبكة الفيزيائية إلا من خلال NAT، لذلك يأخذ عنواناً ضمن مجال شبكة فرعية داخلية (192.168.122.0/24).

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
ar-MA: يسمح الخياران <literal dir="ltr">--os-type</literal> و<literal dir="ltr">--os-variant</literal> بتحسين بعض متغيرات الجهاز الظاهري، اعتماداً على بعض المزايا المعروفة لنظام التشغيل المذكور هنا.

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
ar-MA: عند هذه النقطة، بدأ الجهاز الظاهري يعمل، ونحتاج الاتصال بالطرفية الرسومية  لمتابعة عملية التثبيت. إذا تم تنفيذ العملية السابقة من بيئة سطح مكتب رسومية، فيجب أن يبدأ هذا الاتصال آلياً. إذا لم يحدث هذا، أو إذا كنا نعمل عن بعد، يمكن تشغيل <command>virt-viewer</command> من أي بيئة رسومية لفتح الطرفية الرسومية (لاحظ أن كلمة سر الجذر للنظام البعيد ستطلب مرتين لأن العملية تحتاج لاتصالي SSH):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
ar-MA: عند انتهاء عملية التثبيت، تتم إعادة تشغيل الجهاز الظاهري، ويصبح جاهزاً عند ذلك للاستخدام.

en: Managing Machines with <command>virsh</command>
ar-MA: إدارة الأجهزة باستخدام <command>virsh</command>

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
ar-MA: بعد أن انتهينا من التثبيت، دعنا نرى كيف ندير الأجهزة الظاهرية المتوفرة. أول شيئ سنجربه هو طلب قائمة بالأجهزة التي تديرها <command>libvirtd</command>:

en: Let's start our test virtual machine:
ar-MA: دعنا نبدأ تشغيل جهازنا التجريبي:

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
ar-MA: يمكننا الآن الحصول على تعليمات الاتصال بالطرفية الرسومية (يمكن تمرير لوحة عرض VNC المعادة كمتغير للبرنامج <command>vncviewer</command>):

en: Other available <command>virsh</command> subcommands include:
ar-MA: من أوامر <command>virsh</command> الفرعية المتاحة أيضاً:

en: <literal>reboot</literal> to restart a virtual machine;
ar-MA: <literal>reboot</literal> لإعادة إقلاع الجهاز الظاهري؛

en: <literal>shutdown</literal> to trigger a clean shutdown;
ar-MA: <literal>shutdown</literal> لبدء عملية إيقاف تشغيل نظيفة؛

en: <literal>destroy</literal>, to stop it brutally;
ar-MA: <literal>destroy</literal>، لإيقاف عمل الجهاز الظاهري قسراً؛

en: <literal>suspend</literal> to pause it;
ar-MA: <literal>suspend</literal> لإيقاف عمله مؤقتاً؛

en: <literal>resume</literal> to unpause it;
ar-MA: <literal>resume</literal> لاستكمال عمله؛

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
ar-MA: <literal>autostart</literal> لتفعيل (أو تعطيل، إذا استخدم الخيار <literal dir="ltr">--disable</literal>) تشغيل الجهاز الظاهري تلقائياً عند إقلاع المستضيف؛

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
ar-MA: <literal>undefine</literal> لإزالة كافة آثار الجهاز الظاهري من <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
ar-MA: جميع هذه الأوامر الفرعية تأخذ الاسم المُعِّرف للجهاز الظاهري كمتغير لها.

en: Automated Installation
ar-MA: التثبيت المؤتمت

en: <primary>deployment</primary>
ar-MA: <primary>تنصيب</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
ar-MA: <primary>تثبيت</primary><secondary>التثبيت المؤتمت</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
ar-MA: يحتاج مدراء النظم في شركة فلكوت، كما هو حال مدراء النظم في العديد من شركات الخدمات التقنية الكبيرة، لأدوات تساعدهم على تثبيت (أو إعادة تثبيت) النظام على الأجهزة الجديدة بسرعة، وبصورة آلية إذا أمكن.

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
ar-MA: يمكن تلبية هذه الحاجة بطيف واسع من الحلول. فالأدوات العامة مثل SystemImager تعالج هذه القضية بإنشاء صورة بالاعتماد على جهاز نموذجي، ثم نشر تلك الصورة على الأجهزة المستهدفة، وعلى النهاية الأخرى من الطيف، هناك برنامج تثبيت دبيان القياسي الذي يمكن تغذيته بملف إعداد يجيب على الأسئلة المطروحة أثناء عملية التثبيت. وكنوع من الحلول الوسط، يمكن استخدام أداة هجينة مثل FAI (‏<emphasis>Fully Automatic Installer</emphasis>) لتثبيت النظام على الأجهزة باستخدام نظام إدارة الحزم، لكنها تستخدم بنية تحتية خاصة بها للمهام المتعلقة بالنشر واسع النطاق massive deployment (مثل الإقلاع، وتقطيع الأقراص، وإعداد النظام وما شابه).

en: Fully Automatic Installer (FAI)
ar-MA: ‏Fully Automatic Installer (FAI)‎

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
ar-MA: لعل <foreignphrase>Fully Automatic Installer</foreignphrase> أقدم نظم النشر المؤتمت لأنظمة دبيان، وهذا ما يفسر ذكر هذه الأداة كثيراً؛ إلا أن طبيعته فائقة المرونة بالكاد تغطي تعقيد استخدامه.

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
ar-MA: يحتاج FAI لنظام يعمل كمخدم لتخزين معلومات النشر ويسمح للأجهزة المستهدفة بالإقلاع عبر الشبكة. يحتاج هذا المخدم حزمة <emphasis role="pkg">fai-server</emphasis> (أو <emphasis role="pkg">fai-quickstart</emphasis> التي تثبت أيضًا العناصر المطلوبة للإعداد القياسي).

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
ar-MA: لإنشاء كل ملفات الضبط هذه يجب فهم طريقة عمل FAI. تتألف عملية التثبيت النموذجية من الخطوات التالية:

en: fetching a kernel from the network, and booting it;
ar-MA: إحضار النواة عبر الشبكة، وإقلاعها؛

en: mounting the root filesystem from NFS;
ar-MA: ربط نظام الملفات الجذر عبر NFS‏ (nfsroot المذكور سابقاً)؛

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
ar-MA: تنفيذ <command dir="ltr">/usr/sbin/fai</command> الذ يتحكم بتتمة العملية (أي أن الخطوات التالية سينفذها هذا السكربت)؛

en: copying the configuration space from the server into <filename>/fai/</filename>;
ar-MA: نسخ مساحة الإعداد من المخدم إلى <filename>/fai/</filename>؛

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
ar-MA: استدعاء <command>fai-class</command>. سوف تُنفَّذ السكربتات <filename dir="ltr">/fai/class/[0-9][0-9]*</filename> بالدور، وتعيد أسماء ”الفئات“ (classes) التي يجب تطبيقها على الجهاز الذي تجري عليه عملية التثبيت؛ سوف تعمل هذه المعلومات كأساس للخطوات التالية. هذا يسمح ببعض المرونة في تعريف الخدمات التي سوف تُثبَّت وتُضبَط.

en: fetching a number of configuration variables, depending on the relevant classes;
ar-MA: قراءة عدد من متغيرات الضبط، وذلك تبعاً للفئات (classes) المحددة؛

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
ar-MA: تقسيم الأقراص وتهيئة الأقسام الناتجة، حسب المعلومات المتوفرة في <filename dir="ltr">/fai/disk_config/<replaceable>class</replaceable></filename>؛

en: mounting said partitions;
ar-MA: ربط الأقسام السابقة؛

en: installing the base system;
ar-MA: تثبيت أساس النظام؛

en: preseeding the Debconf database with <command>fai-debconf</command>;
ar-MA: تغذية قاعدة بيانات Debconf باستخدام <command>fai-debconf</command>؛

en: fetching the list of available packages for APT;
ar-MA: الحصول على قائمة الحزم المتاحة لأداة APT؛

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
ar-MA: تثبيت الحزم المذكورة في <filename dir="ltr">/fai/package_config/<replaceable>class</replaceable></filename>؛

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
ar-MA: تنفيذ السكربتات التالية للإعداد، <filename dir="ltr">/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>؛

en: recording the installation logs, unmounting the partitions, and rebooting.
ar-MA: حفظ سجلات التثبيت، فصل أقسام الأقراص الصلبة، ثم إعادة الإقلاع؛

en: Preseeding Debian-Installer
ar-MA: تغذية مثبت دبيان

en: <primary>preseed</primary>
ar-MA: <primary>تغذية</primary>

en: <primary>preconfiguration</primary>
ar-MA: <primary>إعداد مسبق</primary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
ar-MA: <emphasis>التعمق أكثر</emphasis> Debconf مع قاعدة بيانات مركزية

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
ar-MA: تسمح التغذية بالإجابة على أسئلة Debconf التي تطرحها أثناء التثبيت، لكن هذه الأجوبة ثابتة ولا تتطور بمرور الزمن. بما أن النظم المثبتة مسبقًا قد تحتاج للترقية، وقد تطرح أسئلة جديدة أثناء العملية، فيمكن ضبط ملف الإعداد <filename dir="ltr">/etc/debconf.conf</filename> بحيث تستخدم Debconf مصادر بيانات خارجية (مثل مخدم LDAP directory، أو ملف بعيد تصل إليه عبر NFS أو Samba). يمكن تعريف عدة مصادر خارجية للبيانات في الوقت نفسه، وسوف تكمل هذه المصادر بعضها البعض. ستبقى قاعدة البيانات المحلية قيد الاستخدام (لاستخدامها للقراءة والكتابة)، أما قواعد البيانات الخارجية فتقتصر الصلاحيات فيها على القراءة فقط عادة. تشرح صفحة التعليمات <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>‎ كافة الاحتمالات بالتفصيل (ستحتاج للحزمة <emphasis role="pkg">debconf-doc</emphasis>).

en: Using a Preseed File
ar-MA: استخدام ملف تغذية

en: There are several places where the installer can get a preseeding file:
ar-MA: يستطيع المُثبّت الحصول على ملف التغذية من العديد من الأماكن:

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
ar-MA: من initrd المستخدمة لإقلاع الجهاز، في هذه الحالة، تتم التغذية منذ بداية التثبيت الأولية، وسوف يتم تجاوز جميع الأسئلة. يجب فقط تسمية الملف preseed.cfg وتخزينه في جذر initrd.

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
ar-MA: من وسيط الإقلاع (CD أو مفتاح USB)؛ وتحدث التغذية فور ربط الوسيط التخزيني، أي  مباشرة بعد السؤال عن اللغة وتخطيط لوحة المفاتيح. يمكن استخدام متغير الإقلاع <literal>preseed/file</literal> للإشارة إلى موقع ملف التغذية (مثلا، <filename dir="ltr">/cdrom/preseed.cfg</filename> عند التثبيت من قرص CD-ROM، أو <filename dir="ltr">/hd-media/preseed.cfg</filename> في حال استخدام مفتاح USB).

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
ar-MA: كنظرة أولية، يبدو تضمين ملف التغذية في initrd أنه الحل الأكثر جاذبية؛ لكنه نادراً ما يستخدم عملياً، لأن توليد initrd للمثبت معقد جداً. الحلين الآخرين أكثر انتشاراً بكثير، خصوصًا أنك تستطيع استخدام المتغيرات الإقلاعية كطريق بديل لتغذية الأسئلة الأولى لعملية التثبيت. جرت العادة أن تحفظ هذه المتغيرات في إعدادات <command>isolinux</command> (في حال استخدام CD-ROM) أو <command>syslinux</command> (ذاكرة USB) بدلاً من كتابتها يدوياً عند كل عملية تثبيت.

en: Creating a Preseed File
ar-MA: إنشاء ملف التغذية

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
ar-MA: ملف التغذية هو ملف نصي عادي، كل سطر منه يحوي إجابة لسؤال واحد من أسئلة Debconf. يفصل السطر إلى أربعة أقسام تفصلها مسافات بيضاء (علامة مسافة space أو علامة جدولة tab)، فمثلاً <literal>d-i mirror/suite string stable</literal>:

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
ar-MA: الحقل الأول هو ”صاحب“ السؤال؛ تستخدم ”d-i“ للأسئلة المتعلقة بالمثبت، لكن يمكن أن تكتب اسم حزمة للأسئلة التي تطرحها حزم دبيان؛

en: third, the type of question;
ar-MA: الثالث، نوع السؤال؛

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
ar-MA: الحقل الرابع والأخير يحوي قيمة الإجابة. لاحظ أن هذا الحقل يجب فصله عن سابقه بمسافة واحدة؛ وإذا كان هناك أكثر من واحدة ستعتبر المسافات اللاحقة جزءاً من الإجابة.

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
ar-MA: أبسط طريقة لكتابة ملف تغذية هي تثبيت النظام يدوياً. ثم يعطيك الأمر <command>debconf-get-selections --installer</command> الإجابات المتعلقة بالمثبت. يمكن الحصول على الإجابات المتعلقة بالحزم الأخرى بالأمر <command>debconf-get-selections</command>. لكن الحل الأفضل هو أن تكتب ملف التغذية يدوياً، بالاعتماد على مثال وعلى الوثائق: بهذا الشكل يمكن تغذية الأسئلة التي تحتاج تغيير إجاباتها الافتراضية فقط؛ واستخدام متغير الإقلاع <literal>priority=critical</literal> سوف يفرض على Debconf أن تطرح الأسئلة الحرجة فقط، وأن تستخدم الإجابات الافتراضية لبقية الأسئلة.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
ar-MA: <emphasis>توثيق</emphasis> الملحق في دليل التثبيت

en: Creating a Customized Boot Media
ar-MA: إنشاء وسيط إقلاعي مخصص

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
ar-MA: من الجيد أن يعرف المرء مكان تخزين ملف التغذية، لكن مكان التخزين ليس كل شيء: يجب تعديل وسيط الإقلاع –بشكل أو بآخر– لتغيير متغيرات الإقلاع وإضافة ملف التغذية.

en: Booting From the Network
ar-MA: الإقلاع من الشبكة

en: Preparing a Bootable USB Key
ar-MA: تحضير ذاكرة USB إقلاعية

en: syslinux.cfg file and preseeding parameters
ar-MA: ملف syslinux.cfg وبارامترات التغذية

en: Creating a CD-ROM Image
ar-MA: إنشاء صورة CD-ROM

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
ar-MA: ذاكرة USB هي وسيط تخزين يقبل القراءة والكتابة، لذلك كانت إضافة الملف إليها وتعديل بعض المتغيرات فيها عملية سهلة. لكن في حالة استخدام CD-ROM، فالعملية معقدة أكثر، لأننا نحتاج توليد صورة ISO كاملة. هذه المهمة تحتاج الأداة <emphasis role="pkg">debian-cd</emphasis>، لكن استخدام هذه الأداة مزعج نوعًا ما: تحتاج الأداة لمرآة محلية، كما تحتاج لفهم جميع الخيارات في <filename dir="ltr">/usr/share/debian-cd/CONF.sh</filename>؛ وحتى بعد ذلك، يجب استدعاء <command>make</command> عدة مرات. عليك إذن قراءة <filename dir="ltr">/usr/share/debian-cd/README</filename>.

en: Simple-CDD: The All-In-One Solution
ar-MA: ‏Simple-CDD: كل الحلول في حل واحد

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
ar-MA: ببساطة إن استخدام ملف التغذية لا يكفي لتلبية كافة المطالب التي قد تظهر عند النشر واسع النطاق. وبالرغم أنه يمكن تنفيذ بضعة سكربتات عند نهاية عملية التثبيت العادية، إلا أن مجموعة الحزم التي ستثبت ليست مرنة بما يكفي (أساساً لا يمكن إلا اختيار ”المهام“)؛ وأهم من هذا، لا يمكن إلا تثبيت حزم دبيان الرسمية، ولا يسمح بالحزم المولدة محليًا.

en: Creating Profiles
ar-MA: تعريف البروفايلات

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
ar-MA: يعرف Simple-CDD ”بروفايلات“ تقابل مفهوم ”الفئات – classes“ في FAI، ويمكن إعطاء الجهاز عدة بروفايلات (تُحدَّد أثناء التثبيت). يعرف البروفايل بمجموعة من ملفات <filename dir="ltr">profiles/<replaceable>profile</replaceable>.*</filename>:

en: the <filename>.description</filename> file contains a one-line description for the profile;
ar-MA: ملف <filename dir="ltr">.description</filename> يحوي سطراً واحداً يصف البروفايل؛

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
ar-MA: ملف <filename dir="ltr">.packages</filename> يسرد أسماء الحزم التي ستثبت تلقائيًا عند تحديد هذا البروفايل؛

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
ar-MA: ملف <filename dir="ltr">.downloads</filename> يسرد أسماء الحزم التي ستخزن على وسيط التثبيت، لكن لا يشترط تثبيتها؛

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
ar-MA: ملف <filename dir="ltr">.preseed</filename> يحوي معلومات التغذية لأسئلة Debconf (للمثبت أو للحزم)؛

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
ar-MA: ملف <filename dir="ltr">.postinst</filename> يحوي سكربتًا يعمل عند نهاية التثبيت؛

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
ar-MA: البروفايل <literal>default</literal> له دور خاص، لأنه محدد دوماً؛ ولذلك يحوي الحد الأدنى المطلوب لعمل Simple-CDD. الشيء الوحيد الذي يخصص عادة في هذا البروفايل هو متغير التغذية <literal>simple-cdd/profiles</literal>: هذا يسمح بتفادي طلب Simple-CDD تحديد البروفايل الذي يريد تثبيته من المستخدم.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
ar-MA: لاحظ أيضًا أنه يجب استدعاء الأوامر من المجلد الأب للمجلد <filename>profiles</filename>.

en: Configuring and Using <command>build-simple-cdd</command>
ar-MA: إعداد واستخدام <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
ar-MA: <emphasis>نظرة سريعة</emphasis> ملف إعداد مفصل

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
ar-MA: يحتاج Simple-CDD للكثير من المتغيرات ليعمل بشكل كامل. غالبًا ما تجمع هذه المتغيرات في ملف إعداد، وبعدها نمرره للأمر <command>build-simple-cdd</command> بالخيار <literal dir="ltr">--conf</literal>، لكن يمكن أيضاً تحديد قيم هذه المتغيرات باستخدام بارمترات خاصة تعطى للأمر <command>build-simple-cdd</command>. إليك نظرة عامة عن عمل هذا الأمر، وعن تأثير متغيراته المختلفة:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
ar-MA: يحدد المتغير <literal>profiles</literal> البروفايلات التي ستضمن في صورة CD-ROM المولدة؛

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
ar-MA: اعتماداً على قائمة الحزم المطلوبة سوف ينزل Simple-CDD الملفات المناسبة من المخدم المذكور في <literal>server</literal>، ويجمعها في مرآة جزئية (التي ستعطى لاحقًا إلى debian-cd).

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
ar-MA: تدمج الحزم المخصصة المذكورة في <literal>local_packages</literal> أيضًا في هذه المرآة المحلية؛

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
ar-MA: بعدها تستدعى debian-cd (ويستخدم موقع افتراضي يمكن تعديله بالمتغير <literal>debian_cd_dir</literal>)، وتعطى قائمة بالحزم المراد دمجها؛

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
ar-MA: بعدما جهزت debian-cd المجلد، تطبق Simple-CDD بعض التعديلات عليه:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
ar-MA: تضاف الملفات التي تحوي البروفايلات إلى مجلد فرعي باسم <filename>simple-cdd</filename> (وسوف يظهر في القرص النهائي)؛

en: other files listed in the <literal>all_extras</literal> parameter are also added;
ar-MA: تضاف الملفات الأخرى المذكورة في المتغير <literal>all_extras</literal> أيضًا؛

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
ar-MA: تضبط متغيرات الإقلاع لتفعيل التغذية. يتم تفادي الأسئلة عن اللغة والبلد إذا كانت المعلومات المطلوبة مخزنة في المتغيرين <literal>language</literal> و<literal>country</literal>.

en: debian-cd then generates the final ISO image.
ar-MA: تولد debian-cd صورة ISO النهائية.

en: Generating an ISO Image
ar-MA: توليد صورة ISO

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
ar-MA: المراقبة هي مصطلح عام، ونشاطات المراقبة المتنوعة لها أهداف عدة: فمن ناحية أولى، تسمح متابعة استهلاك موارد الحاسب بتوقع الإشباع والتطويرات اللاحقة له؛ ومن ناحية أخرى، فإن تنبيه مدير النظام فور خروج إحدى الخدمات عن العمل أو عدم عملها بشكل صحيح يعني أن إصلاح المشاكل التي تحدث قد يتم أبكر.

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
ar-MA: يغطي <emphasis>Munin</emphasis> الناحية الأولى، من خلال عرض مخططات بيانية للقيم التاريخية لعدد من المتغيرات (الذاكرة المستخدمة، مساحة القرص المحجوزة، حمل المعالج، نشاط الشبكة، حمل Apache/MySQL، وهكذا). أما <emphasis>Nagios</emphasis> فيغطي الناحية الأخرى، من خلال التحقق المنتظم من عمل الخدمات وتوفرها، وإرسال تنبيهات عبر القنوات المناسبة (بريد إلكتروني، رسائل نصية، وهكذا). لكل منهما تصميم تجزيئي يسهل إنشاء إضافات جديدة لمراقبة متغيرات أو خدمات محددة.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
ar-MA: <emphasis>بدائل</emphasis> Zabbix، أداة مراقبة متكاملة

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
ar-MA: <emphasis>بدائل</emphasis> Icinga، مشتق من Nagios

en: Setting Up Munin
ar-MA: إعداد Munin

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
ar-MA: يهدف Munin لمراقبة العديد من الأجهزة؛ وبالتالي، من الطبيعي أن يعتمد بنية مخدم/عميل. يجمع المستضيف المركزي –راسم البيانات (the grapher)– المعطيات من جميع حواسيب المراقبة، ويولد المخططات البيانية الزمنية.

en: Configuring Hosts To Monitor
ar-MA: إعداد الأجهزة للمراقبة

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
ar-MA: الخطوة الأولى هي تثبيت الحزمة <emphasis role="pkg">munin-node</emphasis>. تنصت الخدمة التي تثبتها هذه الحزمة إلى المنفذ 4949 وترد بإرسال البيانات التي تجمعها كافة الملحقات الفعالة. كل ملحق هو برنامج بسيط يعيد وصفاً للبيانات التي يجمعها بالإضافة إلى آخر قيمة مقاسة. تخزن الملحقات في <filename>/usr/share/munin/plugins/</filename>، لكن لا تستخدم منها إلا التي لها رابط رمزي في المجلد <filename>/etc/munin/plugins/</filename>.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
ar-MA: <emphasis>التعمق أكثر</emphasis> إنشاء ملحقات محلية

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
ar-MA: أفضل اختبار للملحق هو عند تشغيله في الظروف نفسها التي يعمل فيها عندما تستدعيه الخدمة munin-node؛ ويمكن محاكاة هذا باستدعاء الأمر <command>munin-run <replaceable>plugin</replaceable></command> بصلاحيات الجذر. إذا تم تمرير متغير ثان لهذا الأمر (مثل <literal>config</literal>) فسوف يعطى للملحق كمتغير.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
ar-MA: عند استدعاء الملحق مع المتغير <literal>config</literal>، عليه توصيف نفسه عبر إعادة زمرة من الحقول:

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
ar-MA: عند استدعاء الملحلق دون أي متغيرات، سوف يعيد آخر قيمة مقاسة ببساطة؛ مثلاً، تنفيذ <command>sudo munin-run load</command> سوف يعيد القيمة <literal>load.value 0.12</literal>.

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
ar-MA: أخيراً، عند استدعاء الملحق مع المتغير <literal>autoconf</literal>، عليه أن يعيد ”yes“ (مع حالة الخروج—exit status ‏0) إذا كان تفعيل الملحق واجباً على هذا المستضيف، أو ”no“ (مع حالة الخروج 1) في الحالة المعاكسة.

en: Configuring the Grapher
ar-MA: إعداد راسم البيانات

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
ar-MA: ”راسم البيانات“ هو ببساطة حاسوب يجمع البيانات ويولد الرسوم البيانية الموافقة. البرنامج المطلوب متوفر في الحزمة <emphasis role="pkg">munin</emphasis>. يشغل الإعداد الافتراضي <command>munin-cron</command> (مرة كل 5 دقائق)، الذي يجمع البيانات من كافة الأجهزة المذكورة في <filename dir="ltr">/etc/munin/munin.conf</filename> (المستضيف المحلي هو الوحيد المذكور افتراضيًا)، ويحفظ البيانات التاريخية في ملفات RRD (‏<emphasis>Round Robin Database</emphasis>، وهي صيغة ملفات مصممة لحفظ البيانات التي تتغير مع الزمن) محفوظة في <filename>/var/lib/munin/</filename> ويولد صفحة HTML تحوي المخططات البيانية في المجلد <filename>/var/cache/munin/www/</filename>.

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
ar-MA: يجب إذن ذكر جميع الأجهزة المراقبة في ملف الضبط <filename dir="ltr">/etc/munin/munin.conf</filename>. كل جهاز يذكر في قسم كامل مع اسم يقابل الجهاز ومدخلة <literal>address</literal> واحدة على الأقل هي مدخلة العنوان التي تعطي عنوان IP المناسب.

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
ar-MA: يمكن أن تصبح الأقسام معقدة أكثر وتضاف إليها معلومات وصف مخططات بيانية إضافية لتوليدها بجمع البيانات من عدة أجهزة. العينات الموفرة في ملف الضبط هي نقاط بدء جيدة للتخصيص.

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
ar-MA: آخر خطوة هي نشر الصفحات المولدة؛ وهذا يحتاج إعداد مخدم وب حتى تتاح محتويات <filename>/var/cache/munin/www/</filename> على موقع وب. سيكون الوصول لهذا الموقع مقيَّداً غالباً، إما باستخدام نظام مصادقة أو بتقييد الوصول حسب عناوين IP. انظر <xref linkend="sect.http-web-server" /> لمزيد من التفاصيل.

en: Setting Up Nagios
ar-MA: إعداد Nagios

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
ar-MA: لا يشترط Nagios تثبيت أي شيء على الأجهزة المراقبة بخلاف Munin؛ بل يستخدم Nagios –معظم الأحيان– للتحقق من توفر الخدمات الشبكية. مثلاً، يمكن أن يتصل Nagios بمخدم الوب ويتحقق أنه يستطيع الحصول على صفحة وب معينة خلال مدة زمنية محددة.

en: Installing
ar-MA: التثبيت

en: Configuring
ar-MA: الضبط

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
ar-MA: قبل الغوص في هذه الملفات، يجب فهم بعض مفاهيم Nagios. يشمل الإعداد مجموعة من الأنواع المختلفة من الكائنات:

en: a <emphasis>host</emphasis> is a machine to be monitored;
ar-MA: <emphasis>host</emphasis> (المستضيف) هو الجهاز الذي ستتم مراقبته؛

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
ar-MA: <emphasis>hostgroup</emphasis> هي مجموعة من المستضيفين يجب تجميعهم معاً عند العرض، أو لتجميع بعض الإعدادات المشتركة؛

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
ar-MA: <emphasis>service</emphasis> (الخدمة) هي عنصر قابل للقياس متعلق بمستضيف أو بمجموعة من المستضيفين. الغالب أنها فحص لخدمة شبكية ما، لكن يمكن أن تشمل اختبار متغيرات أخرى أيضًا والتحقق أن قيمها ضمن مجال مقبول (مثلاً، مساحة القرص الحرة أو حمل المعالج)؛

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
ar-MA: <emphasis>servicegroup</emphasis> هي مجموعة من الخدمات التي يجب تجميعها معاً عند العرض؛

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
ar-MA: <emphasis>contact</emphasis> هو شخص يتلقى التنبيهات؛

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
ar-MA: <emphasis>contactgroup</emphasis> مجموعة من الأشخاص الذين يتلقون التنبيهات؛

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
ar-MA: <emphasis>timeperiod</emphasis> الفاصل الزمني بين كل عملية تحقق من بعض الخدمات؛

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
ar-MA: <emphasis>command</emphasis> هو سطر من الأوامر يستدعى للتحقق من خدمة معينة.

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
ar-MA: لكل كائن عدد من الخصائص (تختلف حسب نوعه) التي يمكن تعديلها. لا يمكن أن نضع قائمة كاملة بها لكثرتها، لكن أهم الخصائص هي العلاقات بين الكائنات.

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
ar-MA: تستخدم الخدمة (<emphasis>service</emphasis>) أمراً (<emphasis>command</emphasis>) للتحقق من حالة ميزة على مستضيف (<emphasis>host</emphasis>) معين (أو مجموعة <emphasis>hostgroup</emphasis>) خلال فاصل زمني (<emphasis>timeperiod</emphasis>). في حال حدوث مشكلة، يرسل Nagios تنبيهاً لجميع أعضاء <emphasis>contactgroup</emphasis> المرتبطة بتلك الخدمة. يرسل التنبيه لكل عضو وفقاً لقناة الاتصال المحددة في كائن <emphasis>contact</emphasis> المقابل له.

en: The Falcot Corp administrators use the following configuration:
ar-MA: يستخدم مديرو النظم في شركة فلكوت الإعداد التالي:

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
ar-MA: لاحظ استخدام الوراثة: يرث الكائن من كائن آخر باستخدام ”use <replaceable>parent-name</replaceable>“. يجب أن يكون الكائن الأب قابلاً للتعرف، عبر إسناد اسم له في خاصية ”name <replaceable>identifier</replaceable>“. إذا كان الهدف من الكائن الأب أن يستعمل في الوراثة فقط دون أن يكون كائناً حقيقياً، عندها يعطى الخاصية ”register 0“ حتى لا يأخذه Nagios بعين الاعتبار، وبالتالي يتجاهل نقصان بعض المتغيرات المطلوبة في الحالة الطبيعية.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
ar-MA: <emphasis>توثيق</emphasis> قائمة بخصائص الكائنات

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
ar-MA: <emphasis>التعمق أكثر</emphasis> الاختبار عن بعد باستخدام NRPE
