الفصل الافتراضي Virtual Classroom مع BigBlueButton وMoodle

عندما تنتقل المحاضرة إلى الإنترنت، فالحل الذي تبدأ به أغلب المدارس والجامعات هو رابط Zoom أو Teams يلصقه المعلم في صفحة المقرر، وهذا يعمل في الأسبوع الأول، ولكن بعد شهر سوف تجد أن الحضور مسجل في نظام آخر، والتسجيلات في حساب شخصي للمعلم، وأن الطالب يدخل باسم يختاره هو وليس بحسابه في المنصة. ولهذا السبب تحديداً بني BigBlueButton، فهو نظام مفتوح المصدر للفصل الافتراضي Virtual Classroom مصمم للتعليم، ونشاطه موجود داخل Moodle نفسه، فيدخل الطالب القاعة من صفحة المقرر بحسابه ودوره. وكما ذكرنا في دليل تثبيت Moodle على سيرفرك، فالمنصة هي المكان الذي يعيش فيه المقرر، والسؤال في هذا المقال: كيف تضيف إليها القاعة المباشرة، وما الذي تحتاجه لذلك فعلاً؟

في هذا المقال سوف نتناول:

• ما الذي يقدمه BigBlueButton في الدرس المباشر، وما الذي يعمل داخل سيرفره، مع مخطط للمكونات.
• متطلبات الإصدار 4.0 بصراحة، ولماذا لا يصلح تشغيله على سيرفر مشترك أو على جهاز التطوير.
• التثبيت على سيرفر مخصص بالسكربت الرسمي، وخيارات الاستضافة الأخرى.
• ربطه مع Moodle 5.3 خطوة بخطوة في مختبر حقيقي، والعطل الذي سوف تقابله على الأغلب في الشبكات الداخلية، وكيف يوقع Moodle طلباته بالسر المشترك Shared Secret.
• التسجيلات والسعة، ومشكلات شائعة وحلولها.

ما الذي يقدمه BigBlueButton للدرس المباشر؟

BigBlueButton، واختصاراً BBB، هو نظام مؤتمرات ويب Web Conferencing يعمل من المتصفح دون تثبيت أي برنامج عند الطالب، والفرق بينه وبين أدوات الاجتماعات العامة أن أدواته مبنية حول المحاضرة: المعلم هو المشرف Moderator والطلاب مشاهدون Viewers، والعرض التقديمي يرفع إلى القاعة ويتحول إلى سبورة Whiteboard يكتب عليها المعلم، والتسجيل يعرض بعد المحاضرة بالشرائح والصوت معاً. وفيما يلي أهم ما يأتي مع الإصدار 4.0 بحسب صفحة الجديد في الإصدار 4.0:

• معرض التطبيقات Apps Gallery: فيه الاستطلاعات Polls، والغرف الفرعية Breakout Rooms لتقسيم الطلاب إلى مجموعات، والمؤقت Timer، والترجمة الصوتية Audio Captions.
• طلب العرض Request to Present: يطلب الطالب أن يصبح هو المقدم، ويوافق المعلم أو يرفض.
• الملاحظات المشتركة Shared Notes: أصبحت تعمل بمحرر BlockNote، وحذف الإصدار 4.0 محرر Etherpad القديم بالكامل.
• لوحة التعلم Learning Dashboard: تعرض للمعلم مشاركة الطلاب، وأصبحت تعمل في الغرف الفرعية أيضاً.

والمشروع مرخص بالرخصة LGPL الإصدار 3.0 كما في الأسئلة الشائعة الرسمية، وآخر إصدار مستقر هو 4.0.0 الصادر في 14 أكتوبر 2026، بينما ما زال فرع 3.0 يتلقى تحديثات، وآخرها 3.0.39 في 2 أكتوبر 2026.

ما الذي يعمل داخل سيرفر BigBlueButton؟

قد يبدو BigBlueButton من الخارج تطبيق ويب عادياً، ولكنه في الواقع مجموعة خدمات على سيرفر واحد، وأهمها خادم الوسائط Media Server الذي يمر عليه صوت وصورة كل طالب، ولهذا السبب فمتطلباته أعلى بكثير من متطلبات Moodle. والصورة التالية تبين المكونات كما في صفحة البنية الرسمية:

في المخطط أعلاه لاحظ التالي:

• خادم الوسائط LiveKit: هو الافتراضي في الإصدار 4.0 للصوت والكاميرا ومشاركة الشاشة، وهو من نوع SFU، أي أنه يستقبل تدفق كل مشارك ويعيد توزيعه على الآخرين، وهذا ما يستهلك المعالج والـ Bandwidth، وما زال البديل القديم mediasoup متاحاً.
• FreeSWITCH: هو جسر الصوت، ومن خلاله يمكن أن ينضم الطالب برقم هاتف Dial-in، وهو المشروع نفسه الذي شرحناه في FreeSWITCH للمنصات الكبيرة.
• bbb-web: هو الذي يقدم الواجهة البرمجية API التي يتكلم معها Moodle، وكل طلب إليها موقع بالسر المشترك كما سيأتي.
• تحويل العروض: ملفات Office يحولها LibreOffice إلى PDF ثم إلى SVG، ويعمل داخل Docker في بيئة معزولة Sandbox، لأن ملف العرض يأتي من المستخدم ولا يجوز أن يعمل بصلاحيات السيرفر.
• معالجة التسجيلات Recording Processor: تعمل بعد نهاية الاجتماع، فتجمع الأحداث المحفوظة في Redis مع ملفات الصوت والعروض وتنتج التسجيل الذي يشاهده الطالب.

المتطلبات: لماذا يحتاج سيرفراً مخصصاً؟

صفحة التثبيت الرسمية للإصدار 4.0 تحدد الحد الأدنى لسيرفر الإنتاج كما في الجدول التالي:

والصفحة نفسها تشترط أن يكون السيرفر نظيفاً، دون أي سيرفر ويب آخر على المنفذين 80 و443، وألا يستخدم لشيء آخر غير BigBlueButton وتطبيقاته مثل Greenlight، وتقول إن اعتماد الإصدار 4.0 على Docker قد يمنع تشغيله في بعض البيئات الافتراضية. والسبب في شهادة TLS ليس الأمان وحده، فالمتصفحات كلها ترفض إعطاء الصفحة إذن الميكروفون والكاميرا إذا لم تكن على HTTPS بشهادة صالحة، أي أن القاعة دون شهادة لا يسمع فيها أحد أحداً.

وقد يتساءل البعض: هل يمكن أن أضعه على سيرفر Moodle نفسه لأوفر سيرفراً؟ والإجابة لا، والسبب أن خادم الوسائط في محاضرة فيها مئة طالب يستهلك المعالج والشبكة في الوقت نفسه الذي يحتاجهما Moodle، وأن السكربت الرسمي يثبت nginx وجدار الحماية UFW ويعيد ضبطهما على مقاسه، فيتعارض مع أي خدمة أخرى على السيرفر. ولنفس السبب لا يصلح جهاز التطوير الذي يعمل عليه Docker Desktop، لأن القاعة تحتاج عنواناً يصل إليه الطلاب ومنافذ UDP مفتوحة، ولذلك فالتثبيت في القسم التالي من التوثيق الرسمي، والتجربة العملية في قسم الربط مع Moodle تختبر جانب Moodle كاملاً مع سيرفر بديل كما سيأتي.

التثبيت على سيرفر مخصص

الطريقة البسيطة هي أن تبحث عن حزمة BigBlueButton في مستودعات Ubuntu، ولا توجد حزمة كهذه، والطريقة الثانية أن تثبت المكونات واحداً واحداً من التوثيق، وهي ممكنة ولكنها عشرات الخطوات، والطريقة الموصى بها هي السكربت الرسمي bbb-install.sh، وهو يثبت كل شيء ويضبط الشهادة والجدار الناري، ونسخته الآن على فرع خاص بكل إصدار.

قبل تشغيل السكربت

1. سجل DNS: أنشئ سجلاً من نوع A للاسم bbb.example.com يشير إلى عنوان IP العام للسيرفر، وتأكد منه قبل التثبيت، لأن السكربت يطلب الشهادة من Let's Encrypt في أثناء التثبيت.
2. الجدار الناري الخارجي: إذا كان السيرفر خلف جدار ناري لمزود السحابة Security Group، فافتح فيه TCP 22 و80 و443، وUDP من 16384 إلى 32768، فالسكربت لا يستطيع فتحها لك.
3. منفذ SSH: السكربت يثبت UFW على السيرفر ولا يسمح إلا بالمنفذ 22 لـ SSH، فإذا كان SSH على منفذ آخر فإنه يتوقف، ويمكنك تجاوز ذلك بالخيار -W وإدارة الجدار الناري بنفسك.

dig bbb.example.com @8.8.8.8

تشغيل السكربت

سجل الدخول كمستخدم root على سيرفر Ubuntu 24.04 نظيف، ثم شغل الأمر التالي كما في ملف المشروع:

wget -qO- https://raw.githubusercontent.com/bigbluebutton/bbb-install/v4.0.x-release/bbb-install.sh | bash -s -- -v noble-400 -s bbb.example.com -e [email protected]

في الأمر أعلاه لاحظ التالي:

• -v noble-400 يختار خط الإصدار 4.0 على Ubuntu 24.04، وإعادة تشغيل الأمر نفسه لاحقاً تحدث السيرفر إلى آخر إصدار في الخط نفسه، وتغيير القيمة هو طريقة الانتقال إلى خط أحدث.
• -s هو اسم السيرفر و-e هو البريد الذي يسجل به في Let's Encrypt، والمشروع يقول إنهما إلزاميان عملياً لأن القاعة لا تعمل دون HTTPS.
• لا يدعم السكربت الترقية من إصدار Ubuntu إلى آخر، فمن كان على سيرفر قديم بالإصدار 22.04 يثبت سيرفراً جديداً وينقل التسجيلات إليه.
• إذا أردت واجهة لإدارة الغرف دون منصة تعلم، فالخيار -g يثبت Greenlight معه، ومع Moodle لا تحتاجه.
• إذا كانت التسجيلات كثيرة فالخيار -m /mnt/recordings يضع المجلد /var/bigbluebutton على قرص مستقل، وهو المجلد الذي يكبر مع كل محاضرة.

بعد التثبيت تحتاج شيئين لربط Moodle: عنوان الواجهة البرمجية والسر المشترك، ويعرضهما الأمر التالي بحسب توثيق الواجهة البرمجية:

bbb-conf --secret

والمخرج سطران، الأول URL: بعنوان مثل https://bbb.example.com/bigbluebutton/، والثاني Secret: بالسر، وهذا السر يوضع في Moodle فقط، والتوثيق يحذر من وضعه في أي مكان يصل إليه المستخدم أو في كود JavaScript في المتصفح.

هل يجب أن تستضيفه بنفسك؟

ليس بالضرورة، وهناك ثلاثة خيارات:

الربط مع Moodle 5.3

نشاط BigBlueButton جزء من كود Moodle الأساسي منذ الإصدار 4.0، وتوثيق Moodle 5.3 يذكر أنه أصبح مفعلاً افتراضياً في التثبيتات الجديدة، ولكنه يبقى رمادياً في قائمة الأنشطة حتى يكتب المدير عنوان السيرفر والسر المشترك. والصورة التالية تبين ما يحدث عندما يضغط الطالب زر الانضمام:

التجربة العملية: Moodle مع سيرفر BigBlueButton بديل

كما ذكرنا فسيرفر BigBlueButton الحقيقي لا يعمل على جهاز تطوير، ولكن ما يهمنا في هذا القسم هو جانب Moodle: هل يصل إلى السيرفر، وهل يوقع الطلبات بشكل صحيح، وماذا يرسل للمتصفح. ولهذا الغرض ينشر فريق Moodle نفسه bigbluebutton_mock، وهو سيرفر بديل Mock يقدم الواجهة البرمجية نفسها ويتحقق من الـ checksum بالسر الافتراضي، ويستخدمه Moodle في اختباراته الآلية، ولكنه لا ينقل صوتاً ولا صورة، فصفحة القاعة فيه نص بسيط يعرض اسم المستخدم ودوره.

بدأنا من مختبر Moodle 5.3 الذي بنيناه في دليل Moodle، وأضفنا إليه الملف compose.bbb.yaml التالي:

services:
  bbb:
    image: moodlehq/bigbluebutton_mock@sha256:36a0fa06ada86c883c0eab1db9e9cea95865094aff9194c5db041315aa47ee96
    container_name: edu2-lms-bbb
    restart: unless-stopped
    command: ["symfony", "server:start", "--port=28081", "--no-tls", "--allow-http"]
    ports:
      - "127.0.0.1:28081:28081"
    networks:
      default:
        aliases: [bbb.localhost]
    mem_limit: 512m

docker compose -f compose.yaml -f compose.bbb.yaml up -d bbb
curl -s http://127.0.0.1:28081/edu2/api

<?xml version="1.0"?>
<response><version>0.9</version><returncode>SUCCESS</returncode></response>

لاحظ أن المسار يبدأ بـ /edu2/، فالسيرفر البديل يطلب معرفاً قبل /api حتى تعمل عدة اختبارات عليه معاً، وفي السيرفر الحقيقي يكون المسار /bigbluebutton/api.

عنوان السيرفر والسر المشترك

من إدارة الموقع ثم الإضافات ثم وحدات النشاط ثم BigBlueButton ثم الإعدادات العامة، تجد الحقلين، ويمكن ضبطهما من سطر الأوامر أيضاً، وهي الطريقة المناسبة إذا كنت تدير الإعدادات بسكربتات:

docker exec -u www-data edu2-lms-web php /var/www/html/admin/cli/cfg.php \
  --name=bigbluebuttonbn_server_url --set=http://host.docker.internal:28081/edu2/
docker exec -u www-data edu2-lms-web php /var/www/html/admin/cli/cfg.php \
  --name=bigbluebuttonbn_shared_secret --set=0b21fcaf34673a8c3ec8ed877d76ae34

في الإعداد أعلاه لاحظ التالي:

• السر 0b21fcaf… هو السر الافتراضي للسيرفر البديل، وهو منشور في كود Moodle نفسه، فلا تستخدمه إلا مع هذا السيرفر، وفي الإنتاج ضع السر الذي يعرضه bbb-conf --secret.
• الخوارزمية الافتراضية في Moodle 5.3 هي SHA256، والإعداد يقبل SHA1 للسيرفرات القديمة وSHA512، وتوثيق BigBlueButton يقول إن السيرفر يقبل أي خوارزمية مدعومة إلا إذا قصرها المدير بالإعداد supportedChecksumAlgorithms، فلا تختر SHA1 إلا إذا اضطررت.
• العنوان host.docker.internal هو اسم يصل به ال Container إلى الجهاز المضيف في Docker Desktop، واستخدمناه لأن السيرفر البديل منشور على منفذ في الجهاز نفسه.

نجرب العطل: تعذر الاتصال بالسيرفر

بعد ذلك أنشأنا نشاط BigBlueButton في مقرر «مقدمة في الشبكات» من نوع «غرفة مع تسجيلات»، المعلمة فيه مشرفة Moderator والطلاب مشاهدون، ثم فتحناه بحساب المعلمة، فظهرت الرسالة التالية بدلاً من القاعة:

والرسالة لا تقول السبب، لذلك طلبنا عنوان السيرفر من داخل Moodle بالكلاس نفسه الذي يستخدمه النشاط، عبر سكربت PHP صغير:

<?php
define('CLI_SCRIPT', true);
require('/var/www/html/config.php');
$v = \mod_bigbluebuttonbn\local\proxy\bigbluebutton_proxy::get_server_version();
echo 'server version: ', var_export($v, true), "\n";
$c = new \mod_bigbluebuttonbn\local\proxy\curl();
$r = $c->get(\mod_bigbluebuttonbn\local\config::get('server_url') . 'api');
echo 'curl error: ', $c->error, "\nresponse: ", trim((string)$r), "\n";

server version: NULL
curl error: تم حظر عنوان URL.
response: 

والسبب أن Moodle يمنع نفسه من طلب عناوين الشبكة الداخلية والمنافذ غير المعتادة، وهي حماية من نوع SSRF، أي أن المستخدم لا يستطيع أن يجعل Moodle يطلب نيابة عنه سيرفراً داخلياً لا يصل إليه هو، وصفحة HTTP security في توثيق Moodle توصي بقائمة الحظر هذه وبالمنفذين 80 و443 فقط. وفي موقعنا الجديد كانت القائمتان كما يلي:

docker exec -u www-data edu2-lms-web php /var/www/html/admin/cli/cfg.php --name=curlsecurityblockedhosts
docker exec -u www-data edu2-lms-web php /var/www/html/admin/cli/cfg.php --name=curlsecurityallowedport

127.0.0.0/8
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
0.0.0.0
localhost
169.254.169.254
0000::1
443
80

والعنوان host.docker.internal داخل ال Container هو 192.168.65.254، أي داخل النطاق المحظور 192.168.0.0/16، والمنفذ 28081 ليس في قائمة المنافذ المسموحة، فكل واحد منهما يكفي لمنع الطلب. وجربنا كل سبب وحده: سمحنا بالمنفذ وأبقينا النطاق محظوراً فبقي الخطأ، ثم أزلنا النطاق من القائمة فنجح الطلب:

server version: '0.9'
curl error:
response: 

وهنا يظهر سبب آخر للرسالة نفسها، وهو السر الخاطئ، فالسيرفر يرد على الطلب ولكن برفض. أرسلنا طلب create مرتين، مرة موقعاً بالسر الصحيح ومرة بسر خاطئ:

<response><meetingID>lab-test</meetingID><attendeePW>ap</attendeePW><moderatorPW>mp</moderatorPW>...<returncode>SUCCESS</returncode></response>
<response><messageKey>checksumError</messageKey><message>checksumError</message><returncode>FAILED</returncode></response>

والرد checksumError يعامله Moodle في الكود كأن السيرفر غير متاح، فيعرض الرسالة نفسها، لذلك إذا ظهرت لك فابدأ بالسر، ثم بالحظر، ثم بالعنوان.

ماذا يرسل Moodle عند الانضمام؟

بعد إصلاح الاتصال أصبحت صفحة النشاط تعرض أن الغرفة جاهزة مع زر الانضمام وقائمة التسجيلات:

لاحظ في الصورة أن جدول التسجيلات الفارغ يعرض «No data to display» بالإنجليزية، وأنه يتجاوز حدود الصفحة من اليسار في الاتجاه من اليمين إلى اليسار RTL، وهي تفاصيل لا تمنع العمل ولكن سوف يسألك عنها المعلمون. وزر الانضمام رابط إلى bbb_view.php، وطلبناه بجلسة المعلمة دون أن نتبع التحويل، لنرى ما يرسله Moodle إلى المتصفح:

STATUS 303 LOCATION http://host.docker.internal:28081/edu2/api/join?meetingID=0bd4159adf55fe9ed0e989b31dfae9a315e19eb0-2-1%5B0%5D&fullName=%D8%B3%D8%A7%D8%B1%D8%A9+%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%85%D8%A9&password=zXyapHcZD5l4&logoutURL=http%3A%2F%2F127.0.0.1%3A28080%2Fmod%2Fbigbluebuttonbn%2Fbbb_view.php%3Faction%3Dlogout%26id%3D2%26courseid%3D2&role=MODERATOR&userID=3&guest=false&createTime=1792588896&userdata-bbb_override_default_locale=ar&checksum=32649e3fa16a1be7cfff1142acedf5839a9a89b88fe027abbae0847e5efc5f21

في الرابط أعلاه لاحظ التالي:

• fullName هو اسم المعلمة «سارة المعلمة» من حسابها في Moodle، وuserID=3 هو رقمها في Moodle، فالحضور في القاعة مرتبط بالحساب وليس باسم يكتبه المستخدم.
• role=MODERATOR جاء من إعداد المشاركين في النشاط، وعندما طلبنا الرابط نفسه بحساب الطالب خالد كان role=VIEWER.
• userdata-bbb_override_default_locale=ar يطلب من القاعة أن تفتح بالعربية، لأن لغة المستخدم في Moodle عربية.
• logoutURL يعيد المستخدم إلى Moodle عند الخروج من القاعة.
• checksum طوله 64 حرفاً، أي SHA256، وهو الهاش للنص join ثم باقي الرابط ثم السر.

وتحققنا من الهاش بأنفسنا بـ Node.js، بالسر الصحيح ثم بسر خاطئ:

node -e "
const c = require('crypto');
const q = 'meetingID=0bd4159adf55fe9ed0e989b31dfae9a315e19eb0-2-1%5B0%5D&fullName=%D8%B3%D8%A7%D8%B1%D8%A9+%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%85%D8%A9&password=zXyapHcZD5l4&logoutURL=http%3A%2F%2F127.0.0.1%3A28080%2Fmod%2Fbigbluebuttonbn%2Fbbb_view.php%3Faction%3Dlogout%26id%3D2%26courseid%3D2&role=MODERATOR&userID=3&guest=false&createTime=1792588896&userdata-bbb_override_default_locale=ar';
console.log(c.createHash('sha256').update('join' + q + '0b21fcaf34673a8c3ec8ed877d76ae34').digest('hex'));
console.log(c.createHash('sha256').update('join' + q + 'wrong-secret').digest('hex'));
"

32649e3fa16a1be7cfff1142acedf5839a9a89b88fe027abbae0847e5efc5f21
5a57521055b3ca4ebaa9389c0409b3a5818fe5662a5c2cfe0111f82ccad008fd

السطر الأول يطابق الهاش في الرابط حرفاً بحرف، والثاني مختلف تماماً، وهذا هو كل الأمان في الربط: من لا يعرف السر لا يستطيع أن يصنع رابطاً بدور MODERATOR، وأي تغيير في الرابط يغير الهاش فيرفضه السيرفر. ولهذا السبب تحديداً لا يجوز أن يصل السر إلى المتصفح، فمن يعرفه يستطيع أن ينشئ أي قاعة ويدخل أي قاعة بأي دور. وفي سجل السيرفر البديل ظهرت الطلبات بالترتيب الذي في المخطط: create ثم getMeetingInfo من سيرفر Moodle، ثم join من المتصفح.

التسجيلات Recordings والخصوصية

التسجيلات تبقى على سيرفر BigBlueButton في المجلد /var/bigbluebutton، وMoodle لا يخزنها، وإنما يطلب قائمتها بالطلب getRecordings ويعرضها في صفحة النشاط. وهذا يعني ثلاثة أشياء عملية:

• النسخ الاحتياطي Backup: نسخة Moodle الكاملة التي شرحناها في دليل Moodle لا تحتوي على التسجيلات، فيجب أن تنسخ مجلد التسجيلات من سيرفر BigBlueButton بخطة مستقلة.
• مكان البيانات: إذا كانت سياسة المؤسسة تطلب بقاء تسجيلات الطلاب داخلها، فالاستضافة المجانية التي تحذف التسجيلات بعد 7 أيام وتديرها جهة أخرى لا تناسبها.
• الإذن: في الإصدار 4.0 أصبح التسجيل مفعلاً افتراضياً لجلسات LiveKit بحسب صفحة الجديد في الإصدار، فاتفق مع المعلمين على متى تسجل المحاضرة، وأخبر الطلاب بذلك قبل أن تبدأ.

كم طالباً يتحمل السيرفر؟

الأسئلة الشائعة الرسمية تعطي قاعدة تقريبية: السيرفر الذي يحقق الحد الأدنى من المتطلبات يتحمل نحو 200 مستخدم في الوقت نفسه، وتوصي بألا تزيد الجلسة الواحدة على 200 مستخدم. والرقم الحقيقي يتغير كثيراً بعدد الكاميرات المفتوحة، فمحاضرة فيها كاميرا المعلم وحده غير محاضرة يفتح فيها كل طالب كاميرته، لذلك اطلب من المعلمين أن يبقى الطلاب بالصوت فقط إلا عند الحاجة.

وعندما يزيد العدد على ما يتحمله سيرفر واحد، فالحل ليس سيرفراً أكبر بلا حد، وإنما عدة سيرفرات خلف Scalelite، وهو موزع حمل Load Balancer لسيرفرات BigBlueButton يقدم لـ Moodle الواجهة البرمجية نفسها، فيكتب المدير عنوان Scalelite وسره في الإعدادات نفسها التي رأيناها، ويوزع Scalelite الغرف على السيرفرات. وقبل ذلك قس الحمل الحقيقي كما في اختبار الأحمال والضغط، فقد تكون المشكلة في عرض النطاق وليس في عدد السيرفرات.

مشكلات شائعة وحلولها

تنظيف المختبر

docker compose -f compose.yaml -f compose.bbb.yaml down -v
docker image rm moodlehq/bigbluebutton_mock@sha256:36a0fa06ada86c883c0eab1db9e9cea95865094aff9194c5db041315aa47ee96

وإذا غيرت قائمة الحظر أو المنافذ في المختبر، فلا تنقل هذا التغيير إلى أي موقع آخر.

تدريب عملي

• غير إعداد المشاركين في النشاط ليصبح كل الطلاب مشرفين، ثم اطلب رابط الانضمام بحساب طالب، ولاحظ قيمة role.
• غير خوارزمية الـ checksum في إعدادات Moodle إلى SHA512، واحسب الهاش لرابط الانضمام بنفسك كما فعلنا، وتأكد من طوله.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• BigBlueButton فصل افتراضي مبني للتعليم، ونشاطه في كود Moodle الأساسي، ولكنه يحتاج سيرفراً خاصاً به.
• الإصدار 4.0 يطلب Ubuntu 24.04 و8 أنوية و16GB وشبكة 250Mbit/s متماثلة ونطاقاً بشهادة TLS، على سيرفر لا يعمل عليه شيء آخر.
• التثبيت بالسكربت الرسمي bbb-install.sh، والسر والعنوان من bbb-conf --secret.
• Moodle يوقع كل طلب بهاش SHA256 من اسم الطلب والمعاملات والسر، ويرسل للمتصفح رابطاً موقعاً فيه الاسم والدور، والسر لا يغادر السيرفر.
• رسالة «تعذر الاتصال» لها ثلاثة أسباب شائعة: السر، وقائمة الحظر والمنافذ في Moodle، والعنوان.
• التسجيلات على سيرفر BigBlueButton وليست في نسخة Moodle، فلها خطة نسخ مستقلة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتجربة الربط على Moodle 5.3.0 مع سيرفر bigbluebutton_mock البديل، ومتطلبات BigBlueButton 4.0.0 من التوثيق الرسمي.