Naser Dakhel

يعطّل معظم الأشخاص التأمين المُعزَّز في لينكس Security-Enhanced Linux -أو اختصارًا سي لينوكس SELinux- إذا واجهتهم أي مشكلة خلال عملهم على بيئة لينكس، إذ يبدو أن تعطيلها يحل المشاكل بصورةٍ مفاجئة، لكن هذا يتسبب بخسارتهم لأداة حماية فائقة القوّة والأهميّة. تتزايد التهديدات الأمنية مع تزايد استخدام الحاويات Containers والخدمات المصغرة Microservices ومعمارية الحوسبة الموزّعة Distributed Architecture، وذلك بسبب مشكلة قديمة ومعروفة جيّدًا، ألا وهي: التسارع velocity؛ إذ تتميز الحاويات بمنحك القدرة على التحرك بسرعة وإنجاز المزيد والتغير بسرعة أيضًا. وهذا يعني أن تطبيق الحاويات انتشر بصورةٍ كبيرة، ولكن سرعة تطبيقها محدودة. وستواجهك الكثير من المشاكل ونقاط الضعف خلال استخدامها؛ فهذا أمرٌ طبيعي عندما تسعى لإنجاز الأمور على نحوٍ أسرع. كيف تخفف من التهديدات؟ يقول سن تزو: "المحارب الحكيم يتفادى المعركة". ينطبق هذا الاقتباس على عملية حماية الحاويات بصورةٍ مثالية؛ إذ لتفادي المشكلات (المعارك)، عليك التأكد أن مضيف الحاوية آمن ويستخدَم سي لينكس مثل خط دفاعٍ أوّل. أُطلِق سي لينكس على أنه مشروعٌ مفتوح المصدر في عام 2000، ودُمج مع نواة لينكس في عام 2003. ووفقًا لموقع Red Hat's explainer، فإن سي لينكس هو معماريّة أمان لأنظمة لينكس، تسمح لمسؤولي النظام بالتحكم بمن لديه صلاحية الولوج للنظام، وقد طوِّرت البرمجية من قبل وكالة الأمن القومي United States National Security Agency -أو اختصارًا NSA-، بكونها سلسلةً ضمن مجموعةٍ من الرُقع Patches لـ نواة لينكس باستخدام وحدات أمن لينكس Linux Security Modules -أو اختصارًا LSM". البداية عندما تسمع كلمة حاويات، سيتبادر لذهنك أولًا دوكر Docker، فقد بدأ دوكر بثورةٍ ساهمت بتبنٍ واسعٍ لتقنية الحاويات بعد ظهوره في عام 2013؛ فهو من أبرز الأسباب التي ساهمت بانتشار شعبية الحاويات. وكما ذكرنا سابقًا، ساهم تزايد معدل تبنّي هذه التقنية بتزايد معدل الثغرات الأمنية. قبل البدء بعملية تأمين حاويات دوكر باستخدام سي لينكس، عليك تجهيز بعض الأشياء. المتطلبات نظام تشغيل سينت أو إس CentOS إصدار 8/RHEL مُثبت ومهيّأ. دوكر Docker CE مُثبَّت ومهيّأ. حسابين مستخدم، إحداها بصلاحيات الجذر root والآخر بدون؛ وهو موجود باسم mcalizo في الأمثلة ضمن هذه المقالة. يمكنك اتباع التعليمات، إذا أردت تثبيت دوكر على خادم CentOS RHEL/8؛ وإذا كنت تعمل على RHEL 8، فعليك إزالة الحزمتين المثبّتتين تلقائيًّا Podman وrunc قبل البدء. دعنا نتأكد أوّلًا من أن سي لينكس يعمل: mcalizo@Rhel82 ~]$ sestatus] SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed (Memory protection checking: actual (secure Max kernel policy version: 31 $ [ ~ mcalizo@Rhel82] من ثم، تأكد أن إصدار نظام التشغيل الخاص بك ودوكر يعملان. سجّل الدخول مثل مستخدمٍ بصلاحيات الجذر، ونفّذ التعليمات التالية: root@rhel82 ~]# cat /etc/redhat-release] (Red Hat Enterprise Linux release 8.2 (Ootpa [root@rhel82 ~]# root@rhel82 ~]# systemctl status docker] docker.service - Docker Application Container Engine ● (Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled Active: active (running) since Wed 2020-10-28 19:10:14 EDT; 15s ago Docs: https://docs.docker.com (Main PID: 30768 (dockerd Tasks: 8 Memory: 39.0M CGroup: /system.slice/docker.service └─ 30768 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.889602941-04:00" level=error msg="> Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903413613-04:00" level=warning msg> Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903427451-04:00" level=warning msg> Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903538271-04:00" level=info msg="L> Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.132060506-04:00" level=info msg="D> Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.308943088-04:00" level=info msg="L> Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.319438549-04:00" level=info msg="D> Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.319570298-04:00" level=info msg="D> Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.333419209-04:00" level=info msg="A> Oct 28 19:10:14 rhel82.home.labs.com systemd[1]: Started Docker Application Container Engine تحقق من إصدار دوكر لديك: root@rhel82 ~]# docker --version] Docker version 19.03.13, build 4484c46d9d اخترق المضيف أفضل الطرق للتعلم هي خوض التجربة، لذلك سنبيّن في هذه الفقرة سهولة اختراق مضيف دوكر باستخدام شيفرة حقن Injection خبيثة، إذا لم يكن أمن الحاوية مُعدًّا على النحو الصحيح. لكي تكون قادرًا على إجراء هجومٍ ما على المضيف، يجب أن يكون المستخدم الخبيث الذي لا يملك صلاحيات الجذر (باسم mcalizo في أمثلتنا) منتميًا للمجموعة التي أنشأت حاويات دوكر. وللتأكد من ذلك، نتفقّد المجموعة التي ينتمي إليها الحساب mcalizo عن طريق: root@Rhel82 ~]# groups mcalizo] mcalizo : mcalizo تُظهِر رسالة الخَرج أن الحساب mcalizo ينتمي لمجموعته الخاصة، وهذا يعني أنه لا يمكنه إنشاء حاوية دوكر. وإذا حاولت إنشاء حاوية دوكر باستخدام الحساب سيظهر الخطأ التالي: mcalizo@Rhel82 ~]$ docker run -it --rm centos:latest /bin/sh] docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/create: dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'. للسماح لحساب mcalizo بإنشاء الحاوية، أضِف المستخدم لمجموعة docker: root@Rhel82 ~]# usermod -G docker -a mcalizo] root@Rhel82 ~]# groups mcalizo] mcalizo : mcalizo docker ثم أنشئ حاويةً من نوع fedora:latest وادخل إليها لتكتشفها: mcalizo@Rhel82 ~]$ docker run -it --rm fedora:latest /bin/sh] Unable to find image 'fedora:latest' locally latest: Pulling from library/fedora ee7e89337106: Pull complete Digest: sha256:b9ec86d36fca7b1d3de39cd7c258e8d90c377d312c21a7748071ce49069b8db4 Status: Downloaded newer image for fedora:latest sh-5.0# cat /etc/redhat-release (Fedora release 33 (Thirty Three ستُسجَّل مثل مستخدم بصلاحيات الجذر تلقائيًّا، عندما تسجل الدخول لحاوية منشأة جديدًا: sh-5.0# whoami root sh-5.0# تستطيع فعل أي شيء بداخل الحاوية بصفتك مستخدمًا بصلاحيات الجذر؛ وهذا يعني أنك تستطيع إساءة استخدام مضيف الحاوية وتتسبّب بكثيرٍ من الضرر. تعني قدرتك على إنشاء الحاويات أنّك تستطيع فعل أي شيء للمضيف، حتى إن لم تكن جزءًا من المستخدمين بصلاحيات الجذر على الجهاز المضيف. لتوضيح الثغرة الأمنية هذه، أُخرج من الحاوية التي أنشأتها وأنشئ حاويةً جديدة: mcalizo@Rhel82 ~]$ docker run -it --rm -v /:/exploit fedora:latest /bin/bash] #[root@131043f2e306 /] ينقل الخيار ‎-v مسار المضيف الرئيس الخاص بدوكر / إلى مسار الحاوية المدعوّ exploit/: /root@131043f2e306 /]#ls exploit] bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var بسبب عملية النقل هذه، تستطيع فعل أي شيء على جهاز دوكر المضيف؛ إذ يمكنك مثلًا حذف الملفات، أو تعديل ملفات الضبط بهدف إلحاق الضرر بالنظام، أو تثبيت تطبيق حصان طروادة أو برمجيات خبيثة مشابهة لسرقة البيانات المهمة. سبب هذه الثغرة لعلك تتسائل عن سبب حدوث ذلك بالرغم من أن سي لينكس مفعّل، إذ نستطيع فهم ما السبب بالتحديد، من خلال النظر الدقيق لكيفية عمل سي لينكس. تأكد من أن سي لينكس يحتوي على سياق دوكر Docker Context: mcalizo@Rhel82 ~]$ ps -eZ | grep docker] system_u:system_r:container_runtime_t:s0 30768 ? 00:00:04 dockerd $[~ mcalizo@Rhel82] يحتوي سي لينكس على السياق كما توقعنا؛ وهذا يعني أن سي لينكس مسؤولٌ عن إدارة عفريت دوكر Docker daemon. افحص عفريت دوكر للتحقُّق مما إذا كان سي لينكس مفعّلًا تلقائيًا: mcalizo@Rhel82 ~]$ docker info | grep Security -A3] :Security Options seccomp Profile: default Kernel Version: 4.18.0-193.el8.x86_64 كما نلاحظ، سي لينكس غير مفعَّل تلقائيًا، بالتالي لقد وجدنا المشكلة، وكل ما علينا فعله هو تفعيل سي لينكس لسد الثغرة؛ بحيث يتحكّم ويدير دوكر. ولتفعيل سي لينكس، أنشئ ملفًّا في المسار etc/docker/daemon.json كما هو موضح هنا، ولكن يجب أن تمتلك صلاحيات الجذر لتفعيله: root@Rhel82 ~]# cat /etc/docker/daemon.json] { "selinux-enabled": true } #[~ root@Rhel82] root@Rhel82 ~]# systemctl restart docker] بعد إنشائك للملف أو تحديثه، وإعادة تشغيل دوكر؛ يجب أن ترى أن سي لينكس مفعّل في عفريت دوكر: root@Rhel82 ~]# systemctl restart docker] mcalizo@Rhel82 root]$ docker info | grep Security -A3] :Security Options seccomp Profile: default selinux [mcalizo@Rhel82 root]$ على الرغم من أنّ وصل مسارات ملفات filesystem معيّنة لمضيف دوكر داخل حاوية دوكر ما زال ممكنًا، إلّا أنّ تحديث الملفات أو الوصول إليها أصبح غير متاحًا الآن: mcalizo@Rhel82 root]$ docker run -it --rm -v /:/exploit fedora:latest /bin/bash] root@ecb5836da1f6 /]# touch /exploit/etc/shadow.sh] touch: cannot touch '/exploit/etc/shadow.sh': Permission denied #[/ root@ecb5836da1f6] تعتمد درجة أمان حاويتك على قوة أمان نظام تشغيل مضيف الحاوية. وهناك كثيرٌ من الوسائل لتأمين نظام لينكس، والعديد منها متاحٌ بهدف زيادة أمان نظامك. يتواجد سي لينكس افتراضيًا مع توزيعات لينكس ليضيف طبقةً إضافية من الحماية؛ فتأكد من تفعيله وعمله صحيحًا للاستفادة منه ومن الحماية التي يقدمها لنظامك. ترجمة -وبتصرف- للمقال Secure your containers with SELinux لصاحبه Mike Calizo. اقرأ أيضًا بدء تشغيل واستعمال حاويات لينكس (LXC) التعامل مع حاويات Docker إجراء مهام معينة عند مختلف مراحل دورة حياة حاويات لينكس (LXC) مدخل إلى حاويات لينكس LXC

هل يمكنك الحصول على حاويات لينكس Linux Containers دون استخدام Docker أو OpebShift أو Kubernetes؟ نعم، يمكنك، فقد طوّر مشروع LXC مفهوم تشغيل نظام تشغيل افتراضي يعمل على نواة النظام، ومُحتوًى ضمن مجموعةٍ من التعليمات المعرفة مسبقًا، وذلك قبل سنوات عدّة من ظهور Docker وانتشار مصطلح الحاويات. في الحقيقة، بُنيَ Docker على مشروع LXC، وتتوافر اليوم كثيرٌ من المنصات التي تُبرِز مزايا LXC بصورةٍ مباشرة أو غير مباشرة، كما تبسّط معظم هذه المنصات عملية إنشاء وإدارة الحاويات بصورةٍ ملحوظة، ومن المنطقي أن تُستخدم هذه الأدوات المتخصصة في مشروعات كبيرة، لكن لا تنطبق هذه الحالة على الجميع، إذ من المحتمل ألا تدير مشروعًا كبيرًا، وألا تكون لديك الرغبة بالوصول إلى خدمات كبيرة وتعلّم أدوات مخصّصة لإنشاء الحاويات. لحسن الحظ، تستطيع إنشاء واستخدام وتعلّم الحاويات باستخدام حاسوبٍ يعمل على نظام لينكس ضمن هذا الدليل؛ إذ سنساعدك في فهم الحاويات باستخدام LXC، وكيفية عملها، ولماذا تعمل، وكيف تصحّح الأخطاء إذا واجهت أي مشكلات. تثبيت LXC إذا كنتَ تبحث عن مصدر سريع لفهم مشروع LXC، فزُر موقع المشروع الرسمي. إذا لم يكن LXC مثبتًا بعد على جهازك، فثبّته باستخدام مدير الحزم على لينكس. وبالنسبة لتوزيعة فيدورا Fedora والتوزيعات المشابهة، اكتب: sudo dnf install lxc lxc-templates lxc-doc $ أما بالنسبة لتوزيعتي ديبيان Debian وأوبنتو Ubuntu والتوزيعات المشابهة، فاكتب: sudo apt install lxc $ إنشاء جسر للشبكة تفترض معظم الحاويات توافر اتّصال بالشبكة، كما تفترض معظم أدوات إدارة الحاويات أن المستخدم سينشئ شبكات افتراضية. يُعد جسر الشبكة network bridge من المكونات الأساسية في أيّ حاوية، وهو يكافئ إلى حدٍ ما مبدّل switch شبكة، إذ يعمل بمثابة مأخذ ذكي ذي مخرجين Y-Adapter، مثل مأخذ سماعات الرأس الذي يسمح لك ولصديقك بالاستماع للصوت في الوقت ذاته باستخدام سماعتين منفصلتين، والفرق هنا هو أنّ الإشارة التي تُنقل هي حزم البيانات وليس إشارة الصوت. يمكنك إنشاء جسر للشبكة برمجيًّا، لتمكين كلٍّ من حاسوبك المضيف والنظام المحتوى من إرسال واستقبال البيانات عبر الشبكة باستخدام جهاز اتصالٍ واحد، مثل منفذ الإيثرنت Ethernet، أو شريحة الاتصال اللاسلكية. يُهمل هذا الجانب الأساسي غالبًا عند استخدامك لبرنامج يولّد حاويات النظام تلقائيًا، وذلك رغم أهميته؛ إذ من المستبعد أن تخصّص جهاز اتصال فيزيائي لكل حاوية تشغّلها. وبالتالي يجب أن تستوعب أنّ الحاويات تتعامل مع أجهزة اتصال افتراضية، وفهمك لهذا سيساهم في نجاح عملية تصحيح الأخطاء، إذا فقدت الحاوية اتّصالها بالشبكة. لإنشاء جسرٍ للشبكة على جهازك، عليك الحصول على الأذونات المطلوبة. ومن خلال تنفيذك للتعليمات في هذا الدليل، استخدم الأمر sudo الذي سيعطيك صلاحيات الجذر؛ بينما يقدم توثيق LXC طريقةً لتهيئة صلاحيات المستخدمين دون استخدام الأمر sudo. sudo ip link add br0 type bridge $ يمكن التحقق من عملية إنشاء واجهة الشبكة الافتراضية بنجاح عن طريق: sudo ip addr show br0 $ 7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 26:fa:21:5f:cf:99 brd ff:ff:ff:ff:ff:ff بما أنّ br0 واجهة شبكة افتراضية Virtual Network Interface، فهو يتطلب عنوان بروتوكول الإنترنت الخاص به. لذلك، اختر عنوانًا محليًا صالحًا لا يتعارض مع أي عنوانٍ آخر موجود على شبكتك، واربطه مع جهاز الشبكة الافتراضية br0 على النحو التالي: sudo ip addr add 192.168.168.168 dev br0 $ تأكّد في النهاية أن br0 يعمل بنجاح من خلال الأمر التالي: sudo ip link set br0 up $ تهيئة تكوين الحاوية قد يكون ملف ضبط Config حاوية LXC معقدًا بحسب الحاجة لتهيئة الحاوية على شبكتك ونظام المضيف، ولكن سيكون ملف الضبط في مثالنا التالي بسيطًا. أنشئ ملفًا باستخدام أي محرر نصوص تفضّله، وعرّف اسمًا للحاوية واكتب إعدادات الشبكة: lxc.utsname = opensourcedotcom lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.hwaddr = 4a:49:43:49:79:bd lxc.network.ipv4 = 192.168.168.1/24 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596 احفظ هذا الملف في المسار الرئيسي Home باسم mycontainer.conf، وتكون تسمية lxc.utsname اختياريّة، إذ يمكنك تسمية الحاوية كما شئت، وستستخدم هذا الاسم لتشغيل وإيقاف الحاوية. يُضبط نوع الشبكة إلى veth، وهو نوع من كابلات الإيثرنت Ethernet الافتراضية؛ إذ يتمحور مبدأ عملها في إرسال الاتصال من نوع veth من الحاوية إلى جهاز جسر الشبكة، المُعرّف بخاصية lxc.network.link، وبقيمة br0. يقع عنوان بروتوكول الإنترنت الخاص بالحاوية في شبكة جهاز التجسير نفسها، ولكنّه مختلف لتفادي أي تعارض. جميع القيم متغيّرة ويمكن تعديلها حسب الحاجة، باستثناء نوع الشبكة veth وراية الشبكة up. ويمكن استعراض لائحة الخصائص عن طريق الأمر man lxc.container.conf؛ وإذا كان الأمر مفقودًا من نظامك، تفقّد مدير الحزم للحصول على حزم توثيق LXC منفصلة. هناك كثيرٌ من الأمثلة التي يمكنك مطالعتها لاحقًا على هيئة ملفات ضبط ضمن المسار usr/share/doc/lxc/examples. تشغيل صدفة الحاوية أنجزنا أكثر من نصف العمل اللازم لإنشاء حاوية؛ فقد أنشأنا بنية الشبكة التحتية، وثبتنا شريحة الاتصال الافتراضية على حاسوبنا الافتراضي؛ وبقي الآن تثبيت نظام التشغيل الخاص بالحاوية. ولكن يمكنك رؤية حاوية LXC تعمل بتشغيل الصدفة Shell ضمن مساحة الحاوية دون تثبيت نظام التشغيل، من خلال الأمر التالي: \ sudo lxc-execute --name basic $ \ rcfile ~/mycontainer.conf /bin/bash-- logfile mycontainer.log-- # في هذه المرحلة من بناء الحاوية، ألقِ نظرةً على إعدادات الشبكة، إذ ستكون مشابهةً لتلك الموجودة في الأسفل ولكن بقيم فريدة: /usr/sbin/ip addr show # 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state [...] link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo [...] 22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> [...] qlen 1000 link/ether 4a:49:43:49:79:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.168.167/24 brd 192.168.168.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2003:db8:1:0:214:1234:fe0b:3596/64 scope global valid_lft forever preferred_lft forever [...] تميِّز الحاوية بنية الشبكة المزيفة، ونواة النظام المستخدمة: uname -av # Linux opensourcedotcom 4.18.13-100.fc27.x86_64 #1 SMP Wed Oct 10 18:34:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux استخدم الأمر exit لمغادرة الحاوية: exit # تثبيت نظام تشغيل الحاوية تُعَد عملية بناء بيئة مُحتواة كاملة من البداية معقدةً أكثر موازنةً بمرحلة تهيئة الشبكة الافتراضية وضبطها، لذا يمكننا استخدام قوالب حاويات جاهزة من LXC. وإذا لم يحتو جهازك على أيّ قالب، فألقِ نظرةً على حزمة قوالب LXC الموجودة ضمن مستودع برمجيّتك. ويكون المسار الافتراضي لقوالب LXC هو usr/share/lxc/templates. ls -m /usr/share/lxc/templates/ $ lxc-alpine, lxc-altlinux, lxc-archlinux, lxc-busybox, lxc-centos, lxc-cirros, lxc-debian, lxc-download, lxc-fedora, lxc-gentoo, lxc-openmandriva, lxc-opensuse, lxc-oracle, lxc-plamo, lxc-slackware, lxc-sparclinux, lxc-sshd, lxc-ubuntu, lxc-ubuntu-cloud اختر قالبك المفضل، وأنشئ الحاوية. استخدمنا في مثالنا هذا قالب Slackware. sudo lxc-create --name slackware --template slackware $ ستعلّمك مشاهدة عملية تنفيذ القالب عن كثب الكثير عن كيفية عمل القوالب، وكأنّك تبني قالبًا من الصفر بيديك؛ إذ تُوصَف عملية التنفيذ بأنها واضحة ومسهبة، وتستطيع ملاحظة أن lxc-createيضبط جذر Root الحاوية للمسار var/lib/lxc/slackware/rootfs، كما يمكن تحميل وتثبيت كثيرٍ من الحزم في هذا المسار أيضًا. تمنحك قراءة ملفات القالب فهمًا أكبر لكيفية عمل شجرة الأجهزة الدنيا minimal device tree وملفات تخزين البيانات المؤقتة Spool الشائعة وملف جدول الأنظمة fstab وملفات init وغيرها، كما تمنع القوالب بعض الخدمات التي لا تحتوي على فائدة مرجوّة في الحاويات من العمل، مثل udev للتعرُّف على العتاد الصلب. ونظرًا لاحتواء القوالب على عددٍ كبيرٍ من إعدادات لينكس التقليدية، فمن الأفضل بناء القالب مع التقيُّد بقالبٍ مشابه للقالب الذي تبنيه (إذا أردت بناء قالبٍ من الصفر)، وذلك تجنّبًا للأخطاء والعثرات التي قد تحدث، مثل بعض الأخطاء التي كُشف عنها وعولجت من قِبل مشروع LXC. بعد تهيئة بيئة نظام التشغيل الأساسيّة، تستطيع بدء الحاوية من خلال الأمر التالي: \ sudo lxc-start --name slackware $ rcfile ~/mycontainer.conf-- بكتابتك للأمر السابق، تكون قد بدأت تشغيل الحاوية، ولكنك لم تربطها بعد؛ فبعكس المثال السابق، أنت لا تتعامل مع الحاوية في سطر الأوامر Shell، وإنما تتعامل مع نظام تشغيل محتوى، لهذا اربط الحاوية بالاسم، عن طريق الأمر: sudo lxc-attach --name slackware $ # تأكد أن عنوان بروتوكول الإنترنت التابع للحاوية وعنوان بروتوكول الإنترنت في ملف الضبط Config متماثلان، عن طريق: usr/sbin/ip addr SHOW | grep eth/ # 34: eth0@if35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 [...] 1000 link/ether 4a:49:43:49:79:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.168.167/24 brd 192.168.168.255 scope global eth0 اُخرُج من الحاوية، وأغلقها عن طريق: exit # sudo lxc-stop slackware $ استخدام حاويات LXC في التطبيقات الواقعية يسهّل لنا مشروع LXC عملية إنشاء وتشغيل حاوية آمنة. تطورت الحاويات كثيرًا منذ ظهورها أول مرة بواسطة LXC في عام 2008، وننصحك بالاستفادة من خبرات مطوّريها لمصلحتك. على الرغم من وضوح توجيهات دليل LXC، إلّا أن هدفنا في هذا الدليل هو توفير فهمٍ أعمق لما يحصل خلال تنفيذ هذه الأوامر خلف الكواليس. ترجمة -وبتصرف- للمقال Behind the scenes with Linux containers لصاحبه Seth Kenlon اقرأ أيضًا إجراء مهام معينة عند مختلف مراحل دورة حياة حاويات لينكس (LXC) ألف باء أساسيات التعامل مع لينكس

يُعَد فهم الشبكات جزءًا أساسيًّا من تهيئة كيانات معقدة على الإنترنت، ويؤثر ذلك كثيرًا على كفاءة تواصل الخوادم بين بعضها بعضًا، وتطوير ضوابط أمان للشبكات، وإبقاء عقد الاتّصال منظمة. شرحنا في الدليل السابق بعض المصطلحات المهمة في عالم الشبكات. اطّلع على الدليل إذا أردت فهم المفاهيم، التي سنستعرضها هنا. سنناقش في هذا المقال بعضًا من المفاهيم المرتبطة بتصميم شبكات الحاسوب والتفاعل معها، كما سنغطّي على وجه التحديد أصناف الشبكات Network Classes، والشبكات الفرعية Subnets، والتوجيه غير الصنفي بين النطاقات CIDR لتجميع عناوين بروتوكول الإنترنت. فهم عناوين بروتوكول الإنترنت IP Addresses يجب أن يحتوي كلّ موقعٍ أو جهاز على الشبكة عنوانًا يدل عليه، وهذا يعني أنه يمكن الوصول إلى أي موقع أو جهاز عن طريق معرفة العنوان الخاص به، بحيث ينتمي هذا العنوان لنظام عناوينٍ ما مُعرَّف بواسطته؛ ففي حالة شبكة من نمط بروتوكول الإنترنت TCP/IP الاعتياديّة، يُعالَج الأمر باستخدام عدة طبقات، لكن عندما نذكر "عنوانًا على الشبكة" فنحن نقصد غالبًا عنوان بروتوكول الإنترنت. تمكننا عناوين بروتوكول الإنترنت من الوصول لموارد شبكةٍ ما باستخدام واجهتها Interface؛ فإذا أردنا إجراء اتّصال بين حاسوبٍ وحاسوب آخر مثلًا، فنحن بحاجة لإرسال المعلومات باستخدام بروتوكول الإنترنت الخاص بالحاسوب المتلقّي. يمكننا نظريًا فعل ذلك، وهذا بفرض أنّ الجهازين على الشبكة نفسها، أو أن هناك بعض الأجهزة الوسيطة التي تفسّر الطلب عبر عدّة شبكات. لا ينبغي تكرار عنوان بروتوكول الإنترنت ذاته على الشبكة نفسها، فكلّ عنوان فريدٌ عن غيره؛ ويمكن للشبكات أن تُعزل أو تُربط ببعضها بعضًا بعد تهيئتها لتضمن الوصول بين شبكتين منفصلتين. يسمح نظام ترجمة عنوان الشبكة Network Address Translation -أو اختصارًا NAT-، بإعادة كتابة العناوين عندَ إرسال حزمٍ من البيانات بين شبكتين، وذلك بهدف وصول الحزم لوجهتها النهائية. وبالتالي يمكننا بفضل هذا النظام استعمال عناوين متشابهة ضمن عدّة شبكاتٍ معزولة دون أيّ مشكلات. الفرق بين معياري IPv4 وIPv6 هناك معياران لبروتوكول الإنترنت، ومُستخدمان بكثرة ضمن أنظمة الاتّصالات، هما: معيار IPv4 ومعيار IPv6. نظرًا للتحسينات التي طرأت على معيار IPv6، فهو يستبدل ببطء معيار IPv4 المحدود؛ والسبب في ذلك ببساطة هو احتواء العالم على كثيرٍ من الأجهزة المتصلة بالإنترنت ولا يكفي معيار IPv4 لسدّ الحاجة. يكون عنوان معيار IPv4 بطول 32 بِت، ويُقسَّم إلى 4 أقسام، إذ يكون كل واحدٍ منها بطول بايت أو 8 بِت، ويفصل بين كل بايتٍ وآخر نقطة ويُمثَّل كل بايت برقم من 0 إلى 255. بالرغم من أنّ العنوان يتألّف من أرقام في النظام العشري ليسهل التعامل بها بواسطتنا نحن البشر، إلّا أنّها في الحقيقة قيمٌ مُمثّلة بثمان خانات (واحدات وأصفار)، وتدعى كل 8 خانات بثُمانيّة Octet. يبدو عنوان IPv4 الاعتيادي على النحو التالي: 192.168.0.5 إذ أن أعلى قيمة ممكنة هي 255، وأصغر قيمة هي 0. يمكننا التعبير عن العنوان السابق باستخدام النظام الثنائي، بحيث نفصل بين كل ثمانيّة وأخرى بشَرطة بدل نقطة، ونفصل بمسافةٍ بين كل 4 خانات بهدف تسهيل قراءة العنوان: 1010 0000 - 0000 0000 - 1000 1010 - 0000 1100 لا بُد أن نفهم جيّدًا أن التمثيلين السابقين متكافئين، فهذا مهمّ لاستيعاب المفاهيم التي سترِد لاحقًا. على الرغم من وجود بعض الاختلافات الأخرى بين المعيارين بخصوص البروتوكول وكيف يعمل كلّ منهما، إلّا أن الفرق الأبرز هو اختلاف سعة كلّ منهما؛ إذ يُمثَّل معيار IPv6 عنوان بروتوكول الإنترنت باستخدام رقم مؤلف من 128 بِت؛ وبالتالي يحوي IPv6 ما يساوي: 7.9 x 10²⁸ ضعف ما يستطيع معيار IPv4 تمثيله. يُكتب عنوان بروتوكول الإنترنت بمعيار IPv6 متمثّلًا بثمانية أقسام؛ ويتكوّن كل قسم من 4 خانات في النظام السداسي عشري. يحتوي النظام السداسي عشري على 16 رقم من 0 إلى 15، ويُمثَّل بالأرقام من 0 إلى 9 بالإضافة للأحرف من A إلى F. هذا ما قد يبدو عليه عنوان بروتوكول إنترنت بمعيار IPv6: 1203:8fe0:fe80:b897:8990:8a7c:99bf:323d قد ترى أن بعض العناوين مكتوبةً أقصر من السابق، إذ يمكن اختصار الخانات الصفرية اليسرى لأي ثمانيّة دون أن تؤثر على قيمة العنوان، كما يمكن اختصار ثمانيّة صفرية باستخدام "::". على سبيل المثال إن كان لدينا ثمانيّة ما في عنوان IPv6 على النحو التالي: ...:00bc:... فيمكننا اختصاره إلى: ...:bc:... لتوضيح الحالة الثانية المذكورة، سنفترض أنه لدينا العنوان التالي الذي يحتوي على ثمانيّات صفريّة: ...:18bc:0000:0000:0000:00ff:... يمكن كتابته بصيغةٍ مختصرة، وذلك عن طريق إزالة الأصفار اليسرى واستبدال الثمانيّات الصفرية بالرمز "::"، وفق: ...:18bc::ff... ولكن يمكن اختصار الثمانيّات الصفرية مرّةً واحدةً في العنوان؛ وإلّا فلن تكون قادرًا على إعادته للعنوان الكامل مرةً أخرى. رغم أنّ المعيار IPv6 أكثر شيوعًا وانتشارًا هذه الأيام، إلّا أننا سنبني شرحنا وأمثلتنا على معيار IPv4، نظرًا لسهولة التعامل معه واحتوائه على خاناتٍ أقلّ. أصناف عنوان IPv4 والنطاقات المحجوزة تحتوي عناوين بروتوكول الإنترنت عادةً على مكوّنين يدلّان على معلومتين؛ إذ يدلّ المكون الأول على الشبكة network التي ينتمي العنوان إليها؛ بينما يدلّ المكون الثاني على جهاز معيّن (مضيف host) على الشبكة. ويعتمد موضع بدء المكون وانتهائه على الطريقة التي هُيئت بها الشبكة، وسنتكلّم عن ذلك في الفقرات التالية. تتوزع عناوين IPv4 على أربعة أقسام تدعى بالأصناف Classes، من A إلى E، هدفها الفصل بين نطاقات عناوين الإنترنت المتاحة وتجزئتها. يمكننا معرفة صنف كل عنوان عن طريق ملاحظة أول أربعة بِتات، إذ يُعرَّف صنف العنوان بواسطتها. نستطيع التعرف على صنف العنوان على النحو التالي: الصنف A ‎0---‎: يبدأ أول بِت من عنوان IPv4 ذو الصنف A بالصفر، وأي عنوان يقع بين المجال 0.0.0.0 و127.255.255.255 ينتمي للصنف A. الصنف B ‎10--‎: يحتوي الصنف B على جميع العناوين بين المجال 128.0.0.0 و 191.255.255.255. أو بمعنى آخر، أي عنوانٍ يحتوي على 1 في البِت الأول، و 0 في البِت الثاني. الصنف C ‎110‎-‎: يحتوي الصنف C على جميع العناوين بين المجال 192.0.0.0 و223.255.255.255. أو بمعنى آخر، أي عنوانٍ يحتوي على 1 في البِت الأول والثاني، و0 في الثالث. الصنف D ‎1110‎: يحتوي الصنف D على جميع العناوين بين المجال 244.0.0.0 و329.255.255.255. بمعنى آخر، أي عنوانٍ يحتوي على 1 في البِت الأول والثاني والثالث، و0 في الرابع. الصنف E 1111: يحتوي الصنف E على جميع العناوين بين المجال 240.0.0.0 و255.255.255.255. بمعنى آخر، أي عنوان يحتوي على 1 في البِت الأول والثاني والثالث والرابع. الصنف D مخصّص لبروتوكولات التحويل المتعدد Multi-casting، التي تسمح بإرسال حزم البيانات لمجموعةٍ من المضيفين دفعةً واحدةً. عناوين الصنف E محجوزة للاستخدام المستقبلي والتجريبي، وهي غير مُستخدمة غالبًا. تقسِّم كل من الأصناف A و B و C الشبكات والأجهزة المضيفة على نحوٍ مختلف وفقًا لحجم الشبكة؛ إذ يستخدم الصنف A الخانات المتبقية من الثُمانيّة الأولى في تمثيل الشبكة، ويُمثّل المضيف بباقي العنوان. يُعد هذا الصنف جيدًا لتعريف شبكاتٍ قليلة تضمّ كثيرًا من الأجهزة المضيفة. يستخدم الصنف B أوّل ثمانيّتان (المتبقي من الثمانية الأولى، وكامل الثمانية الثانية) في تمثيل الشبكة والمتبقي من العنوان لتمثيل الأجهزة المضيفة؛ بينما يستخدم الصنف C أوّل ثلاث ثمانيّات لتمثيل الشبكة، والثمانية الأخيرة لتمثيل الجهاز المضيف داخل الشبكة. تقسيم عنوان بروتوكول الإنترنت لأصناف عدّة طريقةٌ قديمةٌ بعض الشيء، إذ قُدِّمَت هذه الطريقة مثل حلٍ لمشكلة نفاذ عناوين IPv4، وذلك نظرًا لإمكانية وجود عدة حواسيب للمضيف ذاته وتابعة لشبكاتٍ مختلفة، واستُبدلت هذه الطريقة بطرقٍ أخرى سنناقشها. النطاقات الخاصة المحجوزة هناك بعض الأجزاء من عنوان IPv4 المحجوزة لأغراضٍ معينة. ويُعد نطاق الاسترجاع Loopback Range واحدًا من أكثر النطاقات المحجوزة إفادةً، وهو مُحددٌ بالنطاقات ما بين 127.0.0.0 و 127.255.255.255؛ إذ يُستخدم هذا النطاق من قبل المضيف لفحص سلامة الشبكة، ويُستخدم أوّل عنوان في النطاق غالبًا وهو 127.0.0.1. يمتلك كل صنف من أصناف عنوان الإنترنت نطاقًا محجوزًا للشبكات الخاصة؛ إذ أن نطاق العناوين من 10.0.0.0 إلى 10.255.255.255 محجوزٌ للشبكات الخاصة للعناوين من الصنف A؛ بينما يوجد للصنف B النطاق المحجوز من 172.16.0.0 إلى 172.31.255.255، وأخيرًا للصنف C النطاق من 192.168.0.0 إلى 192.168.255.255. يمكن لأي حاسوب غير متّصل بالإنترنت مباشرةً، بمعنى غير متصل عبر جهاز توجيه Router، أو نظامٍ لترجمة عناوين الشبكات NAT، استخدام العناوين المذكورة في أي وقت. هناك بعض نطاقات العناوين الإضافية المحجوزة لأغراض معيّنة، يمكنك مراجعة ملخص ويكيبيديا لمزيدٍ من المعلومات عنها. أقنعة الشبكة والشبكات الفرعية تُدعى عملية تقسيم الشبكة إلى شبكات فرعية أصغر منها بتفريع الشبكة Subnetting، إذ تُعد هذه العملية مفيدةً في كثيرٍ من الحالات، وتساعد بعزل مجموعات من المضيفين عن بعضها بعضًا للتعامل معها بسهولة. كما ناقشنا سابقًا، يمكن تجزئة كل نطاق من عناوين بروتوكول الإنترنت إلى جزء يدل على الشبكة، وآخر يدل على المضيف؛ إذ يعود طول الجزء الذي يدلّ على كلٍّ منهما للصنف الذي ينتمي إليه هذا العنوان؛ فبالنسبة لعنوانٍ من الصنف C مثلًا، تُستخدم أوّل ثلاث ثمانيّات للدلالة على الشبكة. إذًا، يدل الجزء 192.168.0 بالنسبة للعنوان 192.168.0.15 على الشبكة، ويدلّ 15 على المضيف. تحتوي كل شبكة افتراضيًا على شبكةٍ فرعية واحدة، وتضمّ هذه الشبكة الفرعية على جميع عناوين المضيفين المعرّفة بداخلها. ويُعَد قناع الشبكة بمثابة توصيفٍ لعدد بِتّات العنوان المستخدم في الشبكة الفرعية هذه؛ وقناع الشبكة الفرعية هو قناع شبكة آخر يُستخدم لتقسيم الشبكة لأقسامٍ أكثر. كلّ بِت في العنوان هامٌ في التمثيل والدلالة على الشبكة يجب أن يُمثّل بـ 1 في قناع الشبكة، إذ يمكننا مثلًا تمثيل العنوان 192.168.0.15، الذي ناقشناه في مثالنا السابق بالترميز الثنائي على النحو التالي: 1100 0000 - 1010 1000 - 0000 0000 - 0000 1111 كما شرحنا في السابق، تمثّل الثمانيّات الثلاثة الأولى الجزء الذي يدل على الشبكة في عنوان من التصنيف C، أو بكلماتٍ أخرى، الأربع وعشرين بتًا الأوّليات. ونظرًا لأن هذه هي البتات المهمة التي نريد الاحتفاظ بها، فسيكون قناع الشبكة على النحو التالي: 0000 0000 - 1111 1111 - 1111 1111 - 1111 1111 يمكننا كتابة قناع الشبكة السابق بترميز IPv4 اعتيادي، أي 255.255.255.0؛ إذ أن كل بِت يتخذ القيمة 0 بالتمثيل الثنائي لقناع الشبكة يدلّ على أنّه جزءٌ من العنوان الذي يمثل المضيف، ويمكن عدّه متغيرًا. تُعَد البِتّات التي تتخذ القيمة 1 ثابتة القيمة ضمن الشبكة أو الشبكة الفرعية. يمكننا الحصول على الجزء الدالّ على الشبكة بإجراء عمليّة ثنائية من نوع AND بين عنوان بروتوكول الإنترنت وقناع الشبكة. وبإجراء هذه العملية، نحافظ على القسم الذي يدل على الشبكة في العنوان ونهمل القسم الذي يدل على المضيف. ستكون نتيجة العملية وفقًا لمثالنا السابق على النحو التالي: 0000 0000 - 0000 0000 - 0000 1010 - 0000 1100 يمكننا تمثيل العنوان السابق على النحو التالي: 192.168.0.0. النطاق الذي يدل على المضيف هو الفرق بين القيم الأصلية وقسم المضيف. وفي هذه الحالة، قيمة نطاق المضيف، هي: 1111 0000 أو 15. الهدف من تفريع الشبكة هو استخدام قسمٍ من نطاق المضيف في العنوان، واستخدامه لتقسيم العنوان من جديد. إذ يزودنا قناع الشبكة للعنوان 255.255.255.0 مثلًا، بـ 254 مضيف على الشبكة (الرقمان 0 و255 محجوزان). إذا أردنا تقسيم الشبكة لشبكتين فرعيتين، يمكننا استخدام بِت واحد من قسم العنوان الذي يدل على المضيف قناعًا للشبكة. بعودتنا للمثال السابق، القسم الذي يعود للشبكة هو: 0000 0000 - 1000 1010- 0000 1100 والقسم الذي يعود للمضيف هو: 1111 0000 يمكننا استخدام أول بِت من القسم الذي يدلّ على المضيف وتغييره لإنشاء شبكة فرعية، وذلك بتعديل قناع الشبكة من هذا القناع: 0000 0000 - 1111 1111 - 1111 1111 - 1111 1111 لهذا القناع: 0000 1000 - 1111 1111 - 1111 1111 - 1111 1111 في ترميز IPv4 الاعتيادي، يُمثّل العنوان السابق على النحو التالي: 192.168.0.128. خصّصنا بهذه العملية أوّل بِت في الثمانيّة الأخيرة على أنها خانة ذات أهمية تدل على الشبكة، إذ تعطينا هذه العملية شبكتين فرعيتين؛ ويغطي قناع الشبكة الأول النطاق من 192.168.0.1 إلى 192.168.0.127؛ بينما يغطي قناع الشبكة الثاني النطاق 192.168.0.129 إلى 192.168.0.255. بطبيعة الحال، يجب ألاّ تُستخدم الشبكة الفرعية بنفسها عنوانًا. إذا استخدمنا بِتّات أكثر من قسم العنوان العائد للشبكة، عندها يمكننا الحصول على شبكاتٍ فرعية أكثر وأكثر. ألقِ نظرةً على بناء مخطط لعناوين IP عبر الشبكات الفرعية لمزيدٍ من المعلومات. ترميز التوجيه غير الصنفي بين النطاقات CIDR طُوِّر نظام التوجيه غير الصنفي بين النطاقات Classless Inter-Domain Routing -أو اختصارًا CIDR- بديلًا لطريقة تفريع الشبكة التقليدي، إذ يعتمد مبدأ هذا النظام على إضافة خانةٍ جديدة لعنوان بروتوكول الإنترنت بنفسه للدلالة على عدد البِتّات التي تمثل القسم الخاص بتوجيه الشبكة. على سبيل المثال، عنوان بروتوكول الإنترنت 192.168.0.15 مرتبطٌ بقناع الشبكة 255.255.255.0، ويمكننا التعبير عن ذلك بترميز CIDR عن طريق كتابة 192.168.0.15/24؛ إذ يمثل العدد 24 عدد البِتّات الموجودة في عنوان بروتوكول الإنترنت، والتي تدل على القسم الخاص بتوجيه الشبكة. يفتح هذا النظام المجال لفرصٍ مثيرةٍ للاهتمام، إذ يمكن استخدامه للدلالة على الشبكات الفوقية Supernets، ونقصد هنا نطاقات عناوين كبيرة من غير الممكن تمثيلها بطريقة قناع الشبكة الاعتياديّة. على سبيل المثال، في شبكةٍ من الصنف C، مثل الشبكة في أمثلتنا السابقة، لا يمكننا جمع العنوانين 192.168.0.0 و192.168.1.0، وذلك نظرًا لأن عنوان قناع الشبكة للصنف C هو 255.255.255.0، ولكن مع استخدام ترميز CIDR، يمكننا جمع العنوانين بالدلالة على النطاق الذي ينتميان إليه على النحو التالي 192.168.0.0/23؛ وهذا يدلّ على أن هناك 23 بِت مُستخدمٌ للدلالة على الشبكة التي نقصدها. يمكننا تمثيل الشبكة الأولى 192.168.0.0 بالترميز الثنائي على النحو التالي: 0000 0000 - 0000 0000 - 1000 1010 - 0000 1100 ونمثل الشبكة الثانية 192.168.1.0 على النحو التالي: 0000 0000 - 0001 0000 - 1000 1010 - 0000 1100 وبالتالي، يدلنا عنوان CIDR الذي كتبناه سابقًا، على أوّل 24 بِت مستخدَم لتمثيل القسم الذي يعود للشبكة، ويساوي هذا التمثيل قناع الشبكة 255.255.254.0، أو بالتمثيل الثنائي على النحو التالي: 0000 0000 - 1110 1111 - 1111 1111 - 1111 1111 كما نلاحظ، يمكن أن يكون البِت ذو الترتيب 24 بقيمة 1 أو 0، لأن الجزء الذي يدل على الشبكة يشمل فقط أوّل 23 بِت. يمنح نظام CIDR مزيدًا من التحكم للدلالة على نطاقاتٍ مستمرّة من عنوان بروتوكول الإنترنت، وهو أفضل من طريقة قناع الشبكة التي استعرضناها سابقًا. الخاتمة نأمل أنك استطعت فهم بعض تطبيقات الشبكات على عناوين بروتوكول الإنترنت. مع أنّ صعوبة التعامل مع هذا النوع من الشبكات كبيرة وغير بديهية، إلا أنها هامة لفهم طريقة تهيئة مكونات شبكتك وبرمجياتها. هناك الكثير من الأدوات والآلات الحاسبة على الإنترنت التي ستساعدك في فهم بعض من هذه المبادئ، والحصول على نطاقات عناوين صحيحة من خلال إدخال بعض المعلومات. توفر بعض الأدوات تحويلًا لعنوان بروتوكول الإنترنت من التمثيل العشري الاعتيادي إلى التمثيل الثنائي (الثمانيّات)، وتعرض لك تمثيلًا بصريًّا لأقنعة شبكة نظام CIDR. ترجمة -وبتصرف- للمقال Understanding IP Addresses, Subnets, and CIDR Notation for Networking لصاحبه Justing Ellingwood. اقرأ أيضًا الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP بناء مخطط لعناوين IP عبر الشبكات الفرعية عند بناء الشبكات التوجيه بين الشبكات المحلية الافتراضية VLANs استكشاف وظائف الموجهات في الشبكات معمارية الشبكة الحاسوبية وشبكة الإنترنت (Network Architecture)

يميل الكثير من الناس لإهمال جانبٍ معيّن من عملية تطوير البرمجيات، ألا وهو كيفية ترخيص البرنامج، حيث تُملي رخصة البرنامج كيفية استعمال وتوزيع الشيفرة المصدرية بواسطة المُرخّص لهم -أي المستخدمين-، وهذا من شأنه أن يؤثر بشدة على حجم تبنّي الحلّ التقني. تُباع معظم البرامج باستخدام رخصة احتكارية تسمح للناشر أو المطوّر بالاحتفاظ بكامل الحقوق الفكرية للبرنامج. هناك بعض وجهات النظر التي تنظر لهذه الرخصة بأنها تضيف قدرة تحكم إضافية للناشر يمكن الاستغناء عنها، إذ يساهم منع الأشخاص المُرخّص لهم بنسخ وتغيير الشيفرة المصدرية للبرنامج بكبح ناشري البرامج الاحتكاريّة من الابتكار والتطوير المحتمل لتقنيات جديدة. ألهم هذا الموقف في إيجاد رخَص تعطي الحقّ للمستخدمين برؤية الشيفرة المصدرية وتعديلها ومشاركتها حسب رغبتهم، وعُرفت البرمجيات المرخّصة وفقًا لتلك الطريقة بأحد الإسمين: البرمجيات الحرّة؛ أو بالبرمجيات مفتوحة المصدر. يرمز كلا المصطلحين للمعنى ذاته عمومًا، وهو: برمجيات تحتوي على القليل من القيود المتعلّقة بكيفية استعمالها، ويرى مناصروها أن البرمجيات الحرّة والبرمجيات مفتوحة المصدر أكثر أمانًا وفاعليّةً، وأنها تعمل بموثوقية أكبر من البرمجيات الاحتكارية. لمَ نستخدم إذًا تسميتين مختلفتين للدلالة على الشيء ذاته؟ يتضمّن التفسير فهمًا لتاريخ كلا المصطلحين، وفهمًا أعمق للتفاصيل الدقيقة التي تفصل المصطلحين المختلفين. لمحة تاريخية لا تُعد إمكانية السماح للفرد برؤية وتعديل ومشاركة الشيفرة المصدرية لبرمجيّة معيّنة دون أي ملاحقة قانونيّة فكرةً جديدة؛ فقد كانت توزّع البرمجيات قبل سبعينيات القرن الماضي مصحوبةً بشيفرتها المصدرية، والسبب في ذلك هو أنّ هذه البرمجيات كانت مخصّصةً لمتطلبات العتاد الصلب، وعلى المستخدم أن يعدلها قبل أن تعمل بنجاح على حاسوبه، أو لإضافة وظائف جديدة. كان التعامل مع الحواسيب في هذه الفترة لمعظم الأشخاص مقتصرًا على أهدافٍ أكاديميّة أو بحثيّة. ومعنى هذا، أن موارد الحوسبة كانت تُشارَك أغلب الأحيان، وكان تغيير البرمجيات لخلق طرق أكثر فاعليّةً ووثوقيّةً لسير العمل مرحّبًا به للغاية. طوّر مشروع المارد Genie في جامعة كاليفورنيا بيركلي مثلًا، نظام تشغيل بيركلي لمشاركة الوقت؛ وهو نظام تشغيل بُنيَ من الصفر عن طريق التعديل على الشيفرة المصدرية لحاسوب SDS 930. مع ارتفاع تكلفة تطوير البرمجيّات وزيادة تعقيدها، توصلت الشركات لطرق أوقفت المشاركة لشيفرتها المصدرية دون أيّ رقيب، وذلك لحماية مصدر ربحهم ومنع المنافسين من الاطّلاع على حلولهم التقنية. عندها، بدأت عملية وضع القيود القانونيّة، متضمّنةً حقوق التأليف والنشر وعقود الشراء، وباعت هذه الشركات منتجاتها تحت مظلّة الرُخَص الاحتكاريّة. ومع نهايات سبعينيّات القرن الماضي، توقفت معظم الشركات المنتجة للبرمجيات عن تضمين الشيفرة المصدرية لمنتجاتها، وأدّت هذه الحركة لاستياء العديد من مستخدمي الحواسيب القدامى، وكانت نتيجتها إيجاد حركة البرمجيات الحرّة. بدايات البرمجيات الحرة كانت حركة البرمجيات الحرة Free Software Movement بالمعظم وليدة أفكار شخصٍ واحد هو ريتشارد ستالمان؛ حيث بدأ ستالمان دراساته في علوم الحاسوب بدايات السبعينيّات، وذلك قبل ولادة البرامج الاحتكاريّة بفترة قصيرة، وعملَ باحثًا في مختبرات جامعة ماساتشوستس للذكاء الاصطناعي في بدايات الثمانينيّات. كان ستالمان يُكِنّ كثيرًا من الإحباط اتجاه انتشار البرمجيات الاحتكارية بصفته عضوًا في مجتمع القرصنة الأكاديمي لما يقارب القرن، ورأى أن انتشارها ينتهك حق الناس في ابتكار وتحسين برمجياتٍ موجودة. أطلق ستالمان في عام 1983 مشروعًا سمّاه باسم مشروع جنو GNU في سبيل إنشاء نظام تشغيل متكامل يسمح لمستخدميه برؤية وتعديل ومشاركة الشيفرة المصدريّة. حدّد ستالمان أهدافه من هذا المشروع في بيان جنو، والذي ذكر فيه بأنّ الرخص الاحتكارية تعيق تطوير البرمجيّات التي يقودها المجتمع، وهذا يؤدي بدوره إلى ركود الابتكار ويعيق تقدُّم التقنية. يضيف هذا الأمر وفقًا لستالمان، عبئًا غير عادل على المستخدمين والمطوّرين الذين أمكنهم عوضًا عن ذلك تعديل الشيفرة البرمجيّة لتلائم حاجاتهم، أو تغييرها لتُستخدَم في غرضٍ جديد. لقد نُظِرَ إلى مشروع جنو على أنه استجابةً للبرمجيات الاحتكارية وتذكيرًا للناس بالعصر الذي سبقها، وذلك عندما كانت الشيفرة المصدريّة للبرمجيات تُشارَك بحريّة بهدف تطوير البرمجيات التعاوني. بنى ستالمان في عام 1985 مؤسسة البرمجيات الحرّة، أو كما تُعرف باسم Free Softwar ،Foundation -أو اختصارًا FSS-، معتمدًا على مشروع جنو حجرًا للأساس، وهي مؤسسةٌ غير ربحية هدفها نشر ثقافة البرمجيات الحرة للعامّة. كما طور ستالمان فيما بعد رخصة جنو العموميّة GPL؛ وهي رخصة برمجيات تمنح الحق للمستخدم بتشغيل الشيفرة المصدرية ورؤيتها ومشاركتها بحرية مطلقة. اعتمادًا على تعريف مؤسسة البرمجيات الحرة، يجب أن تتضمَن أي برمجيّة الحريات الأربع التالية لمستخدميها لتُصنّف برمجيّةً حرة: حرية تشغيل البرنامج متى أراد المستخدم، ولأي غرض. حرية معرفة طريقة عمل البرنامج، وتغييرها بناءً على رغبة المستخدم، فالوصول للشيفرة المصدرية هو شرطٌ مسبق لهذه الحرية. حرية توزيع نسخةٍ من الشيفرة المصدريّة لمعارفك. حرية توزيع نسخ من برنامجك المعدّل للآخرين؛ إذ يمكنك بفعل هذا إتاحة الفرصة لكامل المجتمع بالاستفادة من تعديلاتك. ويُعَد الوصول للشيفرة المصدرية شرطًا مسبقًا لهذه الحرية أيضًا. تعد مؤسسة البرمجيات الحرّة أي برمجيةٍ تخفق بتحقيق هذه الحريات الأربع برمجيّةً غير حرّة، وبذلك غير أخلاقيّة. ولادة البرمجيات مفتوحة المصدر اختار ستالمان مصطلح "البرمجيات الحرّة" للدلالة على المبدأ الذي ينصّ على حرية تعديل الشيفرة المصدرية، ومشاركتها لأي برنامجٍ من مستخدميه وفق رغبتهم. خلقت هذه التسمية كثيرًا من الخلط لدى الناس على مرور السنوات، لاعتقادهم بأنّ البرمجيات الحرة هي البرامج التي يمكنهم الحصول عليها مجانًا دون دفع أي مقابل مادّي؛ وذلك نظرًا لازدواجية معنى كلمة Free، فهي تعني حرّ ومجاني في الوقت ذاته حسب السياق. توضّح مؤسسة البرمجيات الحرة هذا الخلط بالمعاني بواسطة مقولتها "فكّر بالكلمة بسياق حرية الرأي، وليس بسياق مشروبٍ مجاني". تنامى القلق بين مناصري مشروع جنو ونظام لينكس في نهايات تسعينيات القرن الماضي، فقد كان من الممكن أن يتسبب هذا الخلط في المعنى بسوء فهم الناس لمصطلح البرمجيات الحرة، وإيجابياتها موازنةً مع البرمجيات الاحتكارية. كما كانت مؤسسة البرمجيات الحرّة شديدة اللهجة ولاذعة الانتقاد ضدّ جميع أشكال البرمجيات الاحتكارية، وهذا سبّب قلقًا من طرف مناصري البرمجيات الحرّة بكونه سلوكًا عدائيًّا تجاه المصالح التجارية، الذي سيتسبّب في النهاية بعرقلة انتشار حركة البرمجيات الحرة. الكاتدرائية والبازار كتب إريك ريموند في عام 1997 -وهو مطوّرٌ ومناصرٌ للبرمجيات الحرة-، مقالًا بعنوان الكاتدرائية والبازار The Cathedral and the Bazaar؛ وهي مقالةٌ شهيرة توازن بين نمطين من أنماط تطوير البرمجيات المُستخدمة في تطوير مختلف مشاريع البرمجيات الحرّة. ترمز الكاتدرائية هنا للنمط الهرمي في تطوير البرمجيات، إذ تطور مجموعةٌ معينةٌ من المطورين البرمجيات، مثل عملية تطوير محرّر النصوص إيماكس Emacs على نظام جنو؛ بينما يرمز البازار لنمط التطوير المتمثّل بنشر الشيفرة المصدرية للعموم وتطويرها علنيًا، مثل عملية تطوير نواة لينكس. تتمحور فكرة المقال حول كفاءة نمط البازار في إيجاد الأخطاء البرمجية وحلّها موازنةً مع النمط الآخر، وذلك بحكم أن هناك عددٌ أكبر من الأشخاص القادرين على مراجعة وتجربة الشيفرة المصدرية للبرنامج. لذا، يزعم ريموند أن تبني هذا النمط المعتمد على الجهد المجتمعي ينتج بالحصول على برمجياتٍ أكثر أمانًا وموثوقيّة. عُقب الأفكار التي طرحها ريموند في مقالته الكاتدرائية والبازار، أطلقت شركة نتسكيب Netscape الشيفرة المصدريّة لمتصفح الويب الخاص بها المسمى بالمتواصل Communicator مجانًا ومفتوح المصدر للعموم في عام 1998؛ وسيشكّل هذا المتصفح أساس متصفح موزيلا فيرفكس 1.0 لاحقًا. فكّرت مجموعةٌ من مناصري البرمجيات الحرّة، متضمنةً ريموند ولينوس تورفالدس وفيل زيمرمان وآخرون، بإعادة تسويق حركة البرمجيات الحرة، وصرف تركيزها بعيدًا عن الدوافع الفلسفيّة والأخلاقية، مستلهمين ذلك من تجرِبة Netscape والإمكانية التجارية التي أتيحت لها بعد هذه العملية. اختارت هذه المجموعة تسمية "مفتوح المصدر" للدلالة على البرمجيات المشاركة مجانًا، آملين أن تظهر هذه التسمية الفائدة المضافة من نمط تطوير البرمجيات الاجتماعي والتعاوني. بعد ذلك بوقت وجيز، أوجد كلٌّ من ريموند وبروس بيرنز مبادرة المصدر المفتوح Open Source Initiative -أو اختصارًا OSI-، لتشجيع استخدام التسمية الجديدة ونشر مبادئ البرمجيات مفتوحة المصدر، إذ طوّرت هذه المبادرة تعريف المصدر المفتوح؛ وهي لائحةٌ من عشرة مبادئ تصف معايير رخصة أي برمجية لتعدّ مفتوحة المصدر، وهي: حرية إعادة التوزيع: يجب ألّا تمنع الرخصة أي طرفٍ من بيع أو منح البرمجيّة، مثل إضافةٍ لبرمجية أكبر منها تحتوي برمجياتٍ من مصادرٍ متعددة. الشيفرة المصدرية: يجب أن يحتوي البرنامج على الشيفرة المصدرية، وأن يسمح بتوزيع البرنامج مثل شيفرة مصدريّة أو إصدار مُجمّع. الأعمال المشتقة: يجب أن تسمح الرخصة بالتعديل وإنشاء برمجيات مشتقة، وأن تسمح بتوزيعها تحت شروط رخصة البرنامج الأصلي ذاتها. الحفاظ على الشيفرة المصدرية للمؤلّف: يجوز للرخصة أن تمنع توزيع البرامج المعدّلة المبنية على الشيفرة المصدرية الأصل، وذلك في حالة سماح الرخصة بتوزيع ملفات الترقيع patch files مع الشيفرة المصدرية الأصل بهدف تعديل البرنامج بعد تجميعه Compiling. يُمنَع التمييز ضدّ شخص ما أو مجموعة من الأشخاص: على الرخصة ألّا تميّز بين الأشخاص أو مجموعة من الأشخاص. يُمنَع التمييز ضد مجال أو مهنة معيّنة: يجب ألا تمنع الرخصة أي أحدٍ من استخدام البرنامج بحرية بهدف توظيفه في أي مجال أو غرض. توزيع الرخصة: يجب أن تُطبّق الحقوق الموجودة على رخصة البرنامج الأصلية على جميع البرامج المشتقة دون الحاجة لتضمين رخصة إضافية من الموزّعين. لا ينبغي للرخصة أن تكون مخصصة لمنتج معين: لا يشترط على الحقوق المُضمّنة في برنامجٍ ما أن تكون فعالةً بحالة كان جزءًا من برنامج معين فقط. لا ينبغي على الرخصة أن تضع قيودًا على برمجياتٍ أخرى: يجب ألّا تضع الرخصة قيودًا على برنامج معيّن مُوزعٍ مع البرنامج المرخّص. على الرخصة أن تكون محايدة: لا يجوز أن تستند الرخصة على أي تقنيةٍ فردية أو نمط واجهة مستخدم. الاختلافات بين البرمجيات الحرة ومفتوحة المصدر يُعد الفرق بين مصطلح "البرمجيات الحرة" و"البرمجيات مفتوحة المصدر" ضئيلًا في العموم، ويأتي الاختلاف بالتسمية من فروقات فلسفيّة. تقول مبادرة المصدر المفتوح، أن كلا المصطلحين يعنيان الأمر ذاته، ويمكن استخدامهما بالتبادل في أي سياق كان. يفضّل مصطلح "مفتوح المصدر" ببساطة، لأنّه يُعتقد أنه المصطلح الأفضل الذي يظهر طبيعة البرمجيات ونوايا مؤلّفيها في كيفية استخدامها. أما بالنسبة لمناصري فلسفة "البرمجيات الحرة"، فلا يصف المصطلح "مفتوح المصدر" بالضبط أهميّة الحركة، والمشاكل الاجتماعية التي قد تحصل بسبب البرامج الاحتكارية. ترى مؤسسة البرمجيات الحرة أنّ مبادرة المصدر المفتوح تولي كثيرًا من الاهتمام لتسويق ونشر الفوائد العملية من البرامج غير الاحتكارية، متضمّنًة ربحية العملية وكفاءة نمط التطوير التعاوني، وذلك على حساب الاهتمام للمشاكل الأخلاقية الناتجة عن تقييد حقوق المستخدمين في تغيير وتحسين الشيفرة المصدرية طبقًا لرغبتهم. يعتمد تصنيف البرمجية بكونها حرةً أو مفتوحة المصدر، على شروط رخصتها وتحقيقها لشروط كلٍّ من مبادرة المصدر المفتوح، ومؤسسة البرمجيات الحرة، أو كلاهما. هناك نقاط كثيرة مشتركة بين الاثنين، ولكن هناك بعض الاستثناءات في بعض الأحيان؛ إذ تتوافق مثلًا رخصة ناسا مفتوحة المصدر مع معايير مبادرة المصدر المفتوح؛ بينما تعدّها مؤسسة البرمجيات الحرّة رخصة تقييديّة. لكن عمومًا، هناك فرصة كبيرة بكون رخصة ما مفتوحة المصدر إذا عُدّت حرّة. أسماء بديلة ظهرت على مرّ السنوات كثيرٌ من التسميات الأخرى في سعيٍ منها لحسم الخلاف؛ منها "برمجية حرة ومفتوحة المصدر Free and Open-source Software" -أو اختصارًا FOSS-، وهي واحدةٌ من أكثر التسميات استخدامًا، وتُعد تسميةً وسيطةً بين الطرفين. اكتسبت التسمية "برمجية حرة Libre Software" (إذ تأتي كلمة Libre من كلمة حرية Liberty)، أنصارًا هي الأخرى وأصبحت الكلمة FLOSS رائجةً أيضًا. تجدر الإشارة هنا إلى أنّ البرمجيات الحرة ومفتوحة المصدر مختلفةٌ كليًّا عن البرمجيات التي تنتمي للملكية العامة Public Domain؛ إذ تستمد البرمجيات الحرة ومفتوحة المصدر حرياتها من ترخيصها؛ بينما تستمد برمجيات الملكية العامة بعضًا من هذه الحريات من خلال الوقوع خارج نظام الترخيص. الفارق الواضح هنا هو أنه من الواجب توزيع كلٍّ من البرمجيات الحرة ومفتوحة المصدر تحت رخصة FOSS؛ بينما لا تخضع برمجيات الملكية العامة للشرط ذاته. المشكلة المتعلقة ببرمجيات الملكية العامة، هي عدم اعتراف جميع الدول في العالم بمحتواها غير الخاضع لحقوق الطبع والنشر. يجعل هذا الأمر الاعتراف بوجود برمجيّة تحت الملكية العامة عالميًّا أمرًا مستحيلًا. ولهذا السبب، لا تشجّع أيّ من مبادرة المصدر المفتوح OSI ومؤسسة البرمجيات الحرة FSF، بإطلاق المطورين برمجياتهم تحت الملكية العامة. الخاتمة يُستخدم كلا المصطلحين "برمجيات حرة" و"برمجيات مفتوحة المصدر" في معظم السياقات للدلالة على الشيء ذاته. وينبع تفضيل استخدام مصطلحٍ دونًا عن الآخر من اختلافٍ فلسفي بسيط؛ ولكن قد يصبح الفرق مهمًا بالنسبة للمطورين الذين يطوّرون برامجًا ويطلقونها للعالم، أو للنشطاء الذين يسعون لتغيير طريقة تفاعل الناس مع التقنية. بالتالي من المهم جدًا النظر للسلبيات والإيجابيات لمختلف الرُخَص والمتضمّنة الرُخَص الاحتكاريّة قبل نشر أيّ برنامج، واختيار الرُخصة المُثلى التي تناسب احتياجات الناشر. إن كنتَ مهتمًّا بقراءة مزيدٍ من التفاصيل عن مختلف الرخص المناسبة لمشروعك القادم، تقدّم مؤسسة البرمجيات الحرة لائحةً من الرُخَص تبيّن تفاصيل كلّ من الرخص الحرّة وغير الحرّة. كما قد تكون صفحة الرخص والمعايير على موقع مبادرة المصدر المفتوح مفيدةً لك. ترجمة -وبتصرف- للمقال The Difference Between Free and Open-Source Software لصاحبه Mark Drake. اقرأ أيضًا ما المقصود بمصطلح مفتوح المصدر (open source)؟ تعلم البرمجة تعرف على أنواع التراخيص الحرة التي تسمح لك ببيع المواد بشكل تجاري