أي نظام تذاكر Helpdesk يناسب قسم تقنية المعلومات؟

في مقال إدارة خدمات تقنية المعلومات ITSM شرحنا الحادثة Incident والمشكلة Problem والتغيير Change وطلب الخدمة Service Request، ورأينا مؤقتات ال SLA والتصعيد على تذكرة حقيقية، والسؤال الذي يأتي بعد ذلك عملي: أي نظام تثبته على سيرفرك؟ فإذا بحثت عن «Helpdesk مفتوح المصدر» سوف تجد عشرات الأسماء، بعضها صندوق بريد مشترك بسيط، وبعضها نظام ITSM كامل فيه قاعدة بيانات الإعدادات CMDB وإدارة التغييرات، وبعضها توقف تطويره منذ سنوات وما زال يظهر في المقالات القديمة.

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

• ثمانية أنظمة نشطة: Zammad وosTicket وGLPI وFreeScout وiTop وRequest Tracker، ثم Znuny وOTOBO مع قصة ترخيص OTRS التي أنتجتهما.
• لكل نظام: الترخيص والأجزاء المدفوعة كما هي في 13 أكتوبر 2026، وآخر إصدار، وهل هو مكتب دعم Helpdesk أو ITSM كامل، والعربية، والبريد وال SLA والدخول الموحد SSO وال API.
• نسبة الترجمة العربية في ملفات كل مشروع، لأن «يدعم العربية» في صفحات المنتجات لا تعني الكثير.
• تجربة على ثلاثة أنظمة: Zammad وGLPI وFreeScout، مع بريد يمر عبر Mailpit وقاعدة SLA وقياس الذاكرة.
• جدول قرار حسب حجم فريقك وما تحتاجه فعلاً.

وهذه مقالات مرتبطة ننصح بها قبل القراءة أو بعدها، من المفاهيم إلى الأدوات التي تكمل عمل قسم تقنية المعلومات:

دليلإدارة خدمات تقنية المعلومات ITSM: ما الذي تحتاجه فعلاً؟كيف تنظم عمل الدعم الفني بالتذاكر والمؤقتات والتصعيد، وما الذي تأخذه من ITIL دون بيروقراطية.دليلMDM: إدارة أجهزة الموظفين وتأمينها بأدوات مفتوحةكيف تدير الشركة حواسيب موظفيها وهواتفهم وتفرض عليها التشفير والتحديث، وما الذي تستطيع أن تراه فعلاً على كل جهاز.دليلأدوات الوصول الآمن إلى السيرفرات: خريطة مفتوحة المصدرخريطة لأدوات الوصول الآمن مفتوحة المصدر إلى السيرفرات، ماذا تحل كل عائلة منها وما ترخيصها، وكيف تختار ما يناسب فريقك.دليلمستخدم أم مدير؟ إدارة الأدوار عبر تطبيقاتك من authentikكيف تحدد من authentik من يدخل كل تطبيق ومن يكون مديراً فيه، وماذا يحدث للجلسات والتوكنات عندما تسحب الصلاحية.

ثلاث فئات قبل أي مقارنة

أكثر خطأ نراه أن تقارن FreeScout بGLPI كأنهما منافسان، والحقيقة أن الأول صندوق بريد مشترك بفكرة التذاكر، والثاني نظام لإدارة الأصول والتذاكر والمشكلات والتغييرات، ولكل منهما جمهور مختلف. والصورة التالية تبين الأنظمة الثمانية في ثلاث فئات:

والقاعدة العملية أن تبدأ من الفئة التي تحتاجها اليوم مع هامش صغير، فقسم من ثلاثة أشخاص يخدم مئة موظف لا يحتاج iTop في سنته الأولى، وقسم في مستشفى أو جامعة يدير آلاف الأجهزة ويخضع للتدقيق سوف يتعب مع FreeScout بعد أشهر قليلة.

نظام Zammad

نظام Zammad مكتب دعم حديث مكتوب بلغة Ruby on Rails، ترخيصه AGPL-3.0، وآخر إصدار مستقر هو 7.2.2 في 8 أكتوبر 2026. وهو نظام تذاكر متعدد القنوات: البريد عبر IMAP وPOP3 وحسابات Microsoft 365 وGoogle، والمحادثة على الموقع، والهاتف، وقاعدة معرفة مدمجة، واتفاقيات SLA بثلاثة مؤقتات مع تقويم ساعات العمل، وقواعد Triggers للأتمتة، وREST API كامل استخدمناه في التجربة. والدخول الموحد فيه مدمج: تكامل LDAP وOpenID Connect وSAML. أما ما ليس فيه فهو قاعدة بيانات الإعدادات CMDB وسجلات المشكلات Problem والتغييرات Change، فهو مكتب دعم Helpdesk وليس ITSM كاملاً.

والنسخة المستضافة على سيرفرك مجانية بكل ميزاتها، والشركة تبيع الاستضافة السحابية وعقود الدعم، وبحسب صفحة الأسعار في 13 أكتوبر 2026 فإن السحابة تبدأ من 7 يورو لكل فني شهرياً بالدفع السنوي في خطة Starter وتصل إلى 25 يورو في خطة Plus، وعقود دعم النسخة الذاتية بين 2,999 و9,999 يورو سنوياً.

• نقاط القوة: واجهة حديثة وسريعة، وSLA وتصعيد وقواعد أتمتة مدمجة دون إضافات، وقنوات كثيرة، وAPI كامل، ودخول موحد مدمج.
• نقاط الضعف: الترجمة العربية 20% فقط كما سنرى، ويحتاج ذاكرة أكبر من غيره، وتوصي متطلبات العتاد الرسمية ب 6 GB من الذاكرة ومعها 4 GB إضافية إذا شغلت Elasticsearch على السيرفر نفسه، ولا توجد فيه CMDB.

نظام osTicket

نظام osTicket من أقدم أنظمة التذاكر المفتوحة، مكتوب بلغة PHP وترخيصه GPL-2.0، وآخر إصدار هو v1.18.4 في 17 يونيو 2026، وهو آخر تحديث في المستودع حتى تاريخ كتابة المقال، أي أن التطوير مستمر ولكن بإيقاع أبطأ بكثير من الباقين. وفيه البريد عبر IMAP وPOP3 أو تمرير الرسائل Piping، واتفاقيات SLA بسيطة بمهلة واحدة تقاس بالساعات كما في توثيق خطط SLA، والدخول عبر إضافات رسمية ل LDAP وOAuth2. أما ال API فيقول توثيقه في المستودع نفسه إنه يدعم إنشاء التذاكر فقط حتى الآن، ولا توجد فيه CMDB أو أصول.

وللعربية حزمة لغة رسمية تنزل من موقع المشروع لسلسلة الإصدارات 1.18، وفي الكود ملف أنماط للاتجاه من اليمين إلى اليسار css/rtl.css. والنسخة المفتوحة مجانية، وبحسب صفحة الإصدارات تبدأ النسخة السحابية من 12 دولاراً لكل فني شهرياً، والجهاز الافتراضي Virtual Appliance بسعر حسب الطلب.

• نقاط القوة: بسيط وخفيف ومعروف، وفيه حزمة عربية، ويكفي مكتب دعم صغير يعمل بالبريد.
• نقاط الضعف: إيقاع إصدارات بطيء، وSLA بمهلة واحدة بالساعات، وAPI لا يفعل إلا إنشاء التذاكر، ولا توجد Docker Image رسمية، وال Images المجتمعية المشهورة التي وجدناها توقفت عند 1.17.5 في 2024، ولهذا لم ندخله في التجربة.

نظام GLPI

نظام GLPI فرنسي الأصل مكتوب بلغة PHP وترخيصه GPL-3.0، وتطوره شركة Teclib، وآخر إصدار هو 12.0.0 في 7 أكتوبر 2026، مع استمرار تحديثات السلسلة 11 (آخرها 11.0.11 في 1 أكتوبر 2026). وهو ITSM كامل: تذاكر بأنواع الحادثة وطلب الخدمة، ومشكلات وتغييرات، وكتالوج خدمة، وقاعدة معرفة، وإدارة أصول قوية مع وكيل اكتشاف للأجهزة، واتفاقيات SLA وOLA بنوعين: وقت الاستلام TTO (Time To Own) ووقت الحل TTR (Time To Resolve). ويجمع البريد عبر IMAP وPOP، وفيه LDAP مدمج، وREST API.

والنسخة المفتوحة مجانية، ولكن بعض الأشياء التي تتوقعها مدمجة تأتي في اشتراك GLPI Network، فبحسب صفحة الأسعار في 13 أكتوبر 2026 تبدأ اشتراكات النسخة الذاتية من 100 يورو شهرياً حتى 10 فنيين وتصل إلى 4,500 يورو، والسحابة من 19 يورو لكل مستخدم شهرياً، ومن أهم ما في الاشتراك الدخول عبر OpenID Connect، لأن إضافة OAuth SSO تشترط اشتراك GLPI Network Basic أو أعلى.

• نقاط القوة: أفضل ترجمة عربية بين الأنظمة التي فحصناها بنحو 93%، وواجهة عربية من اليمين إلى اليسار، وأصول ومشكلات وتغييرات في نظام واحد، وDocker Image رسمية تثبت نفسها.
• نقاط الضعف: الإعدادات كثيرة ومتشعبة، ومستويات التصعيد تعمل على ال SLA من نوع TTR فقط كما سنرى في التجربة، وجامع البريد يعمل كل عشر دقائق افتراضياً ويرفض رسائل من لا يملك حساباً، والدخول الموحد OIDC مدفوع.

نظام FreeScout

نظام FreeScout صندوق بريد مشترك Shared Inbox بفكرة Help Scout، مكتوب بلغة PHP على Laravel وترخيصه AGPL-3.0، وتطويره نشط جداً، فآخر إصدار هو 1.8.247 في 10 أكتوبر 2026، وتصدر نسخة جديدة كل بضعة أيام. والنواة مجانية وخفيفة: صناديق بريد ومحادثات وتعيين وملاحظات داخلية، أما أغلب ما يحتاجه قسم تقنية المعلومات فيأتي في وحدات مدفوعة بترخيص مدى الحياة لكل نسخة، ومنها LDAP وOAuth وSAML وقاعدة المعرفة وAPI & Webhooks واستبيان الرضا وبوابة المستخدم End-User Portal. ولا توجد في قائمة الوحدات وحدة SLA، والأقرب لها وحدة Workflows التي تصف نفسها بأنها تسمح ببناء سير عمل «شبيه بال SLA».

• نقاط القوة: أخف الأنظمة الثلاثة في التجربة، وواجهة بسيطة يفهمها أي شخص يستخدم البريد، وتطوير نشط جداً، وواجهة عربية من اليمين إلى اليسار جيدة.
• نقاط الضعف: لا يوجد SLA حقيقي ولا أصول ولا مشكلات ولا تغييرات، والدخول الموحد وال API في وحدات مدفوعة، ولا توجد Docker Image رسمية فاستخدمنا Docker Image مجتمعية.

نظام iTop

نظام iTop من شركة Combodo الفرنسية، مكتوب بلغة PHP وترخيصه AGPL-3.0، وآخر إصدار هو 3.3.0 في 15 سبتمبر 2026. وهو أقرب الأنظمة إلى ITIL: قاعدة بيانات الإعدادات CMDB هي قلبه، مع نموذج بيانات يمكن تعديله، وحوادث وطلبات ومشكلات وتغييرات وكتالوج خدمة واتفاقيات SLA وبوابة للمستخدمين. ويدعم LDAP، والدخول عبر OpenID Connect يأتي بإضافة Authentication with OpenID، وتحويل البريد إلى تذاكر بإضافة Mail to Ticket Automation من متجر الشركة.

ونسخة Community مجانية، وتبيع Combodo بحسب صفحة العروض باقتين باسم Atelier وForge فيهما الدعم وأداة تخصيص النماذج Designer ووحدات إضافية مثل إدارة عناوين IP ومراكز البيانات، والأسعار حسب الطلب. أما العربية فلا يوجد ملف قاموس عربي في مجلد الترجمات في المستودع، فالواجهة ستكون بالإنجليزية أو بإحدى اللغات الموجودة.

• نقاط القوة: أقوى CMDB بين الأنظمة المفتوحة هنا، ونموذج بيانات قابل للتعديل، وتغطية واسعة لعمليات ITIL.
• نقاط الضعف: لا توجد ترجمة عربية، ومنحنى تعلم طويل، والبريد والدخول الموحد عبر إضافات، والتخصيص المريح في الباقات المدفوعة.

نظام Request Tracker

نظام Request Tracker واختصاراً RT من شركة Best Practical، مكتوب بلغة Perl وترخيصه GPL-2.0، وآخر إصدار هو 6.0.3 في 20 مايو 2026 مع نشاط مستمر في المستودع حتى أكتوبر. وفكرته المرونة: قوائم انتظار Queues ودورات حياة Lifecycles تعرف حالاتها بنفسك، وحقول مخصصة، وأصول Assets مدمجة في النظام، ولكن المشكلات والتغييرات تبنيها أنت كقوائم ودورات حياة. ويستقبل البريد عبر أداة rt-mailgate التي يمرر لها خادم البريد الرسائل، وفيه REST2 API، وتوثيق الدخول يشرح LDAP عبر ExternalAuth والدخول عبر خادم الويب، أي أن OIDC يأتي من وكيل أمامه مثل authentik وليس من RT نفسه.

والنسخة الذاتية مجانية، والنسخة السحابية بين 15 و39 دولاراً لكل مستخدم شهرياً مع حد أدنى للمستخدمين. والترجمة العربية في ملف ar.po بالمستودع نحو 21% فقط.

• نقاط القوة: مرونة كبيرة، ونظام ناضج منذ سنوات طويلة، وأصول مدمجة، وبريد قوي.
• نقاط الضعف: واجهة تقليدية، والتخصيص يحتاج خبرة بلغة Perl، والعربية ضعيفة، وال SLA والتصعيد يحتاجان إعداداً يدوياً أكثر من غيره.

قصة OTRS وZnuny وOTOBO

كان OTRS من أشهر أنظمة التذاكر المفتوحة في أوروبا، وترخيصه GPL حتى الإصدار 6، وكانت الشركة OTRS AG تصدر النسخة المجانية باسم ((OTRS)) Community Edition. وبحسب شرح Znuny لسبب التفرع أعلنت OTRS AG في 23 ديسمبر 2020 أنها ستوقف دعم Community Edition بما فيه التحديثات الأمنية ابتداء من 1 يناير 2021، أي بمهلة ثمانية أيام في موسم الإجازات، ثم أعلن لاحقاً أن Community Edition معلقة إلى أجل غير مسمى كما في إعلان OTOBO عن نهاية OTRS 6، وبقيت الإصدارات 7 وما بعدها تجارية فقط بحسب صفحة OTRS في ويكيبيديا. ولأن الكود القديم كان GPL، فقد تفرع منه مشروعان ما زالا نشطين:

• نظام Znuny: من شركة Znuny GmbH، بدأ بتحمل التحديثات الأمنية لمستخدمي Community Edition ثم أصبح مشروعاً مستقلاً، وترخيص مستودعه GPL-3.0، وآخر إصدار 7.3.7 في 16 سبتمبر 2026. وفي الإصدار 7.3 في 25 مارس 2026 أضيف دخول SAML مدمج للفنيين والعملاء دون إضافات، وفي توثيقه الرسمي أقسام لقاعدة بيانات الإعدادات CMDB وإدارة مستوى الخدمة. والبرنامج مجاني، وعقود الدعم بين 4,499 و28,999 دولاراً سنوياً. والترجمة العربية في ملف ar_SA.pm نحو 10% فقط بحسب عدنا للنصوص الفارغة فيه.
• نظام OTOBO: من شركة Rother OSS، ترخيص مستودعه GPL-3.0، وآخر إصدار مستقر 11.0.18 في 16 سبتمبر 2026 مع نسخة تجريبية من 11.1، وفي كوده وحدة دخول OpenID Connect، وللشركة وحدة ITSM Configuration Management لقاعدة بيانات الإعدادات CMDB، والشركة تبيع الدعم والاستضافة دون أسعار منشورة. والترجمة العربية في ملفه نحو 87%، وهو فرق كبير عن Znuny مع أن أصلهما واحد.
• نقاط القوة: عمليات ITSM ناضجة من سنوات OTRS، ومحرك بريد ووكلاء قوي، وطريق انتقال طبيعي لمن يستخدم OTRS 6.
• نقاط الضعف: واجهة ثقيلة ومنحنى إعداد طويل، والعربية في Znuny ضعيفة جداً، ولم نجربهما في هذا المقال.

العربية: ما تقوله ملفات الترجمة

كل هذه الأنظمة تقول إنها تدعم لغات كثيرة، ولكن السؤال الحقيقي كم من النصوص مترجم فعلاً، لأن الواجهة نصف المترجمة أسوأ للموظف من الإنجليزية الكاملة. ولذلك نزلنا ملف الترجمة العربية من مستودع كل مشروع في 13 أكتوبر 2026 وعددنا النصوص المترجمة، باستخدام msgfmt --statistics لملفات .po، وبعد النصوص الفارغة لملفات Perl في Znuny وOTOBO:

ولاحظ أن نسبة الترجمة لا تقول كل شيء، فقد يكون النص مترجماً ترجمة خاطئة، وسوف نرى في التجربة أمثلة على ذلك، ولكنها تعطيك فكرة سريعة قبل أن تثبت أي شيء.

التراخيص والأجزاء المدفوعة في جدول واحد

كل الأسعار التالية كما هي في صفحات الشركات في 13 أكتوبر 2026، والإصدارات من مستودعات المشاريع في التاريخ نفسه:

ولاحظ أن الترخيص AGPL-3.0 في Zammad وFreeScout وiTop لا يمنعك من استخدامها داخل شركتك، ولكنه يلزمك بنشر تعديلاتك على الكود إذا قدمت النظام المعدل كخدمة لمستخدمين عبر الشبكة، فإذا كنت ستعدل الكود نفسه وتبيعه كخدمة فاقرأ الترخيص بعناية أو استشر مختصاً.

تجربة عملية: البريد وال SLA والذاكرة على ثلاثة أنظمة

اخترنا للتجربة ممثلاً لكل فئة يمكن تشغيله بسهولة: Zammad لمكتب الدعم الحديث، وGLPI لل ITSM الكامل، وFreeScout لصندوق البريد المشترك. أما osTicket فلا توجد له Docker Image رسمية وأشهر ال Images المجتمعية متوقفة عند 1.17.5، وZnuny وOTOBO وiTop تحتاج وقت إعداد أطول ونتركها لمقالات قادمة. والهدف ثلاثة أسئلة: هل تصل رسالة البريد كتذكرة؟ هل يعمل ال SLA ويصعد التذكرة؟ وكم ذاكرة يحتاج كل نظام؟ والصورة التالية تبين بيئة التجربة:

البريد: Mailpit أمام صناديق GreenMail

أداة Mailpit تستقبل البريد بال SMTP وتعرضه في واجهة ويب، ولكنها لا تقدم IMAP، والأنظمة الثلاثة تقرأ البريد بال IMAP، ولذلك أضفنا GreenMail كخادم IMAP للتجارب، وجعلنا Mailpit يمرر إليه كل رسالة يستقبلها، فتمر كل رسالة على Mailpit ونراها هناك، ثم تصل إلى صندوق النظام المقصود. والملف التالي هو الأساس المشترك لكل التجربة:

# Shared mail for the helpdesk lab: everything goes through Mailpit (visible at http://127.0.0.1:18025),
# and Mailpit relays every message to GreenMail, which holds the IMAP mailboxes the helpdesks read.
name: lab-itsm-mail
services:
  mailpit:
    image: axllent/mailpit:v1.31.5
    container_name: lab-itsm-mailpit
    environment:
      MP_SMTP_RELAY_CONFIG: /relay.yaml
      MP_SMTP_RELAY_ALL: "true"
    configs:
      - source: relay
        target: /relay.yaml
    ports: ["127.0.0.1:18025:8025"]
    networks: [lab-itsm-net]
  greenmail:
    image: greenmail/standalone:2.1.14
    container_name: lab-itsm-greenmail
    environment:
      GREENMAIL_OPTS: >-
        -Dgreenmail.setup.test.smtp -Dgreenmail.setup.test.imap
        -Dgreenmail.hostname=0.0.0.0 -Dgreenmail.auth.disabled
        -Dgreenmail.users=zammad:[email protected],glpi:[email protected],freescout:[email protected]
        -Dgreenmail.users.login=email
    networks: [lab-itsm-net]
configs:
  relay:
    content: |
      host: lab-itsm-greenmail
      port: 3025
      starttls: false
      allow-insecure: true
      auth: none
networks:
  lab-itsm-net:
    name: lab-itsm-net

docker compose -f mail.yaml up -d

والمخرج سوف يكون كما يلي في سجل Mailpit:

time="2026/10/12 21:33:20" level=warning msg="[relay] auto-relaying all new messages via lab-itsm-greenmail:3025"
time="2026/10/12 21:33:21" level=warning msg="[http] listening on [::]:8025 without --ui-auth-file or --allowed-hosts; the API is reachable from any host that can route to this interface"
time="2026/10/12 21:33:21" level=info msg="[smtpd] starting on [::]:1025 (no encryption)"

ولاحظ التحذير الثاني: واجهة Mailpit دون كلمة مرور، وهذا مقبول هنا لأن المنفذ مربوط بالعنوان 127.0.0.1 فقط، ولا تقم بفتحه على الشبكة بهذا الشكل. ولإرسال رسالة الموظف استخدمنا هذا السكربت داخل Container مؤقت من Alpine:

#!/bin/sh
# Sends one test message from an employee to a helpdesk mailbox through Mailpit:
#   docker run --rm --network lab-itsm-net -v "$PWD:/lab" alpine:3.22 sh /lab/send-mail.sh [email protected]
set -e
apk add -q curl >/dev/null
TO="$1"
SUBJ=$(printf 'لا أستطيع الدخول إلى نظام الرواتب' | base64 | tr -d '\n')
cat > /tmp/msg.eml <<MSG
From: Employee <[email protected]>
To: <$TO>
Subject: =?UTF-8?B?$SUBJ?=
Date: $(date -R)
Message-ID: <$(date +%s)[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

السلام عليكم، منذ الصباح تظهر لي رسالة خطأ عند فتح نظام الرواتب، وأحتاج إلى إرسال كشف الشهر اليوم.
MSG
curl -s --url smtp://lab-itsm-mailpit:1025 --mail-from [email protected] --mail-rcpt "$TO" --upload-file /tmp/msg.eml && echo "sent to $TO"

نظام Zammad: التثبيت والبريد

بنينا ملف Compose على أساس المستودع الرسمي zammad-docker-compose مع تبسيطين للتجربة: لا يوجد Elasticsearch، ومستخدم قاعدة البيانات هو نفسه مالكها، أما في الإنتاج فاتبع الملف الرسمي الذي يفصل بينهما:

# Zammad 7.2.2 without Elasticsearch (search falls back to the database), based on zammad-docker-compose.
name: lab-itsm-zammad
x-zammad: &zammad
  image: ghcr.io/zammad/zammad:7.2.2-0003
  init: true
  restart: unless-stopped
  environment:
    POSTGRESQL_HOST: lab-itsm-zammad-db
    POSTGRESQL_DB: zammad_production
    POSTGRESQL_USER: zammad
    POSTGRESQL_PASS: lab-zammad-pass
    POSTGRESQL_DB_CREATE: "false"
    MEMCACHE_SERVERS: lab-itsm-zammad-memcached:11211
    REDIS_URL: redis://lab-itsm-zammad-redis:6379
    TZ: Asia/Riyadh
    ELASTICSEARCH_ENABLED: "false"
  volumes: [zammad-storage:/opt/zammad/storage]
  networks: [lab-itsm-net]
  depends_on:
    db: { condition: service_healthy }
    redis: { condition: service_started }
    memcached: { condition: service_started }
services:
  db:
    image: postgres:17.11
    container_name: lab-itsm-zammad-db
    environment:
      POSTGRES_USER: zammad
      POSTGRES_PASSWORD: lab-zammad-pass
      POSTGRES_DB: zammad_production
    volumes: [zammad-db:/var/lib/postgresql/data]
    healthcheck: { test: ["CMD", "pg_isready", "-U", "zammad"], interval: 5s, retries: 20 }
    networks: [lab-itsm-net]
  redis:
    image: redis:8.10.2
    container_name: lab-itsm-zammad-redis
    networks: [lab-itsm-net]
  memcached:
    image: memcached:1.6.45-alpine
    container_name: lab-itsm-zammad-memcached
    command: memcached -m 256M
    networks: [lab-itsm-net]
  init:
    <<: *zammad
    container_name: lab-itsm-zammad-init
    command: ["zammad-init"]
    restart: on-failure
    user: 0:0
  railsserver:
    <<: *zammad
    container_name: lab-itsm-zammad-rails
    networks:
      lab-itsm-net: { aliases: [zammad-railsserver] }
    command: ["zammad-railsserver"]
  scheduler:
    <<: *zammad
    container_name: lab-itsm-zammad-scheduler
    command: ["zammad-scheduler"]
  websocket:
    <<: *zammad
    container_name: lab-itsm-zammad-websocket
    networks:
      lab-itsm-net: { aliases: [zammad-websocket] }
    command: ["zammad-websocket"]
  nginx:
    <<: *zammad
    container_name: lab-itsm-zammad-nginx
    command: ["zammad-nginx"]
    init: false
    ports: ["127.0.0.1:18080:8080"]
volumes:
  zammad-db: { name: lab-itsm-zammad-db }
  zammad-storage: { name: lab-itsm-zammad-storage }
networks:
  lab-itsm-net: { external: true }

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

• القيمة ELASTICSEARCH_ENABLED: "false" ضرورية إذا لم تشغل Elasticsearch، وبدونها بقي ال Container zammad-init يكرر السطر «zammad-init waiting for elasticsearch server to be ready…» دون نهاية.
• الأسماء البديلة zammad-railsserver وzammad-websocket لازمة لأن إعداد Nginx داخل Image يبحث عن هذه الأسماء، وعندما غيرنا أسماء ال Containers ظهر في سجل Nginx الخطأ «zammad-railsserver could not be resolved» ورد الموقع ب 502.

بعد ذلك أنشأنا المستخدمين ومفتاح ال API وتقويم 24 ساعة بسكربت Ruby يشغل داخل ال Container بالأمر rails r، ثم قناة البريد التي تقرأ من GreenMail وترسل عبر Mailpit:

# Email channel: read from the GreenMail mailbox over IMAP, send through Mailpit (rails r)
UserInfo.current_user_id = 1
ch = Channel.where(area: 'Email::Account').first || Channel.new(area: 'Email::Account')
ch.update!(group_id: 1, active: true, options: {
  inbound:  { adapter: 'imap', options: { host: 'lab-itsm-greenmail', port: 3143, ssl: 'off', ssl_verify: false,
              user: '[email protected]', password: 'lab-pass', folder: 'INBOX', keep_on_server: false } },
  outbound: { adapter: 'smtp', options: { host: 'lab-itsm-mailpit', port: 1025, ssl: false, ssl_verify: false,
              start_tls: false, enable_starttls_auto: false } } })
addr = EmailAddress.find_by(email: '[email protected]') || EmailAddress.create!(name: 'دعم تقنية المعلومات', email: '[email protected]', channel_id: ch.id, active: true)
Group.all.each { |g| g.update!(email_address_id: addr.id) }
Setting.set('notification_sender', 'دعم تقنية المعلومات <[email protected]>')
puts "channel=#{ch.id} address=#{addr.id}"

docker cp zammad-email.rb lab-itsm-zammad-rails:/tmp/email.rb
docker exec lab-itsm-zammad-rails bundle exec rails r /tmp/email.rb

channel=3 address=1

أرسلنا الرسالة في 01:14:03 بتوقيت الرياض، وظهرت التذكرة 37003 في 01:14:14، أي بعد نحو 11 ثانية دون أي تشغيل يدوي، وخرج الرد الآلي إلى الموظف وإشعارات الفنيين إلى Mailpit. أما ال SLA فقد شرحنا تجربته كاملة في مقال المفاهيم: SLA بدقيقتين للأولوية العالية، وقاعدة زمنية تنقل التذكرة إلى الدعم الثاني L2 وتبلغ قائد الفريق، والتصعيد حدث بعد الموعد بدقيقتين و15 ثانية لأن مهمة التصعيد تعمل كل خمس دقائق.

والصورة التالية هي أول ما ظهر لنا عند الدخول بالواجهة العربية:

والتخطيط من اليمين إلى اليسار صحيح، والقائمة الجانبية في اليمين، ولكن الواجهة خليط من العربية والإنجليزية، وفي شاشة ال SLA ترجمت كلمة الأولوية Priority إلى «صلاحيات»، وترجمت Manage إلى «يدير»، وبقيت الإشعارات والرد الآلي بالإنجليزية مثل «New ticket» و«Thanks for your inquiry» حتى تعدل قوالبها بنفسك. وهذا لا يمنع استخدامه، ولكن خطط لوقت تراجع فيه القوالب والنصوص التي يراها الموظف، أو ساهم في الترجمة على منصة المشروع.

نظام GLPI: البريد المرفوض وال SLA الذي لا يصعد

ال Docker Image الرسمية glpi/glpi تثبت GLPI وحدها عند أول تشغيل، كما في مستودع ال Docker Images الرسمي:

# GLPI 12.0.0 with MariaDB, from the official glpi/glpi image (auto-installs on first start)
name: lab-itsm-glpi
services:
  glpi:
    image: glpi/glpi:12.0.0
    container_name: lab-itsm-glpi
    environment:
      GLPI_DB_HOST: lab-itsm-glpi-db
      GLPI_DB_PORT: "3306"
      GLPI_DB_NAME: glpi
      GLPI_DB_USER: glpi
      GLPI_DB_PASSWORD: lab-glpi-pass
      TZ: Asia/Riyadh
    volumes: [glpi-data:/var/glpi]
    ports: ["127.0.0.1:18081:80"]
    depends_on: [db]
    networks: [lab-itsm-net]
  db:
    image: mariadb:11.8.9
    container_name: lab-itsm-glpi-db
    environment:
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
      MARIADB_DATABASE: glpi
      MARIADB_USER: glpi
      MARIADB_PASSWORD: lab-glpi-pass
    volumes: [glpi-db:/var/lib/mysql]
    networks: [lab-itsm-net]
volumes:
  glpi-data: { name: lab-itsm-glpi-data }
  glpi-db: { name: lab-itsm-glpi-db }
networks:
  lab-itsm-net: { external: true }

[entrypoint] The database is now ready and reachable.
GLPI is not installed. but auto-install is enabled. Starting installation.
GLPI installation completed successfully!

ثم ضبطنا اللغة والبريد الصادر وال API من سطر الأوامر:

for kv in "language ar_SA" "enable_api 1" "enable_api_login_credentials 1" \
  "url_base_api http://127.0.0.1:18081/apirest.php" "url_base http://127.0.0.1:18081" \
  "admin_email [email protected]" "from_email [email protected]" "use_notifications 1" "notifications_mailing 1" \
  "smtp_mode 1" "smtp_host lab-itsm-mailpit" "smtp_port 1025" "smtp_check_certificate 0"; do
  set -- $kv
  docker exec -u www-data lab-itsm-glpi php /var/www/glpi/bin/console config:set $1 "$2"
done

وعند أول اتصال بال API من الجهاز ظهر هذا الخطأ:

["ERROR_NOT_ALLOWED_IP","لا يوجد عميل API نشط يطابق عنوان IP الخاص بك في التكوين (192.168.48.1)"]

والسبب أن عميل ال API الافتراضي «full access from localhost» يقبل 127.0.0.1 فقط، والطلب يصل إلى ال Container من عنوان شبكة Docker. وفي التجربة وسعنا النطاق مباشرة في قاعدة البيانات، أما في الإنتاج فأنشئ عميل API بنطاق ضيق وبمفتاح تطبيق App Token من شاشة الإعداد:

docker exec lab-itsm-glpi-db mariadb -uglpi -plab-glpi-pass glpi -e \
  "update glpi_apiclients set ipv4_range_start=INET_ATON('192.168.0.0'), ipv4_range_end=INET_ATON('192.168.255.255') where id=1"

بعد ذلك أنشأنا عبر ال API جامع البريد ومجموعتي الدعم الأول والثاني واتفاقية SLA لوقت الاستلام TTO مدتها دقيقتان مع مستوى تصعيد، وقاعدة أعمال تعطي كل تذكرة من البريد هذه الاتفاقية وتسندها إلى الدعم الأول:

// GLPI lab setup through the REST API (apirest.php): mail collector, L2 group, SLA with an escalation level,
// and a business rule that gives every e-mail ticket that SLA.  node glpi-setup.mjs
const B = 'http://127.0.0.1:18081/apirest.php';
const { session_token } = await (await fetch(`${B}/initSession`, { headers: { Authorization: 'Basic ' + btoa('glpi:Lab-Pass-2026!') } })).json();
const H = { 'Session-Token': session_token, 'Content-Type': 'application/json' };
const add = async (type, input) => {
  const r = await fetch(`${B}/${type}`, { method: 'POST', headers: H, body: JSON.stringify({ input }) });
  const j = await r.json(); if (!r.ok) throw new Error(`${type}: ${JSON.stringify(j)}`);
  console.log(`${type} → id ${j.id}`); return j.id;
};
await add('MailCollector', { name: 'helpdesk', host: '{lab-itsm-greenmail:3143/imap/notls}INBOX', login: '[email protected]', passwd: 'lab-pass', is_active: 1 });
const l1 = await add('Group', { name: 'الدعم الأول L1', is_assign: 1 });
const l2 = await add('Group', { name: 'الدعم الثاني L2', is_assign: 1 });
const slm = await add('SLM', { name: 'دعم الموظفين', calendars_id: 0 });
const sla = await add('SLA', { name: 'استلام التذكرة خلال دقيقتين', slms_id: slm, type: 1, number_time: 2, definition_time: 'minute' });
const lvl = await add('SlaLevel', { name: 'تصعيد إلى L2', slas_id: sla, execution_time: 0, is_active: 1, match: 'AND' });
await add('SlaLevelAction', { slalevels_id: lvl, action_type: 'assign', field: '_groups_id_assign', value: l2 });
const rule = await add('RuleTicket', { name: 'تذاكر البريد: SLA ومجموعة L1', sub_type: 'RuleTicket', match: 'AND', is_active: 1, condition: 1, ranking: 0, entities_id: 0, is_recursive: 1 });
await add('RuleCriteria', { rules_id: rule, criteria: 'requesttypes_id', condition: 0, pattern: 2 });
await add('RuleAction', { rules_id: rule, action_type: 'assign', field: 'slas_id_tto', value: sla });
await add('RuleAction', { rules_id: rule, action_type: 'assign', field: '_groups_id_assign', value: l1 });

أرسلنا الرسالة وشغلنا جامع البريد يدوياً، لأن مهمته mailgate تعمل افتراضياً كل 600 ثانية، والمخرج في سجل المهام كان كما يلي:

عدد الرسائل: متاح=1، تم استيرادها بالفعل=0، تم استردادها=1، تم رفضها=1، الأخطاء=0، مدرجة في القائمة السوداء=0

id	from	to	subject	reason	date
1	[email protected]	[email protected]	لا أستطيع الدخول إلى نظام الرواتب	1	2026-10-12 22:27:24

الرسالة رفضت، والسبب رقم 1 في جدول الرسائل غير المستوردة هو USER_UNKNOWN ونصه في الكود «Email not found. Impossible import»، أي أن GLPI لا يقبل افتراضياً بريداً من عنوان لا يملك صاحبه حساباً فيه، إلا إذا فعلت خيار الدعم المجهول Anonymous Helpdesk. وهذا في الحقيقة سلوك جيد لقسم تقنية المعلومات، لأن كل موظف يجب أن يكون له حساب يأتي من LDAP، ولكنه يفاجئ من يجرب لأول مرة، فالرسالة لا تختفي ولا تصل. وبعد إنشاء المستخدم employee وإضافة عنوانه وصلت الرسالة الثانية كتذكرة:

id	name	date	requesttypes_id	slas_id_tto	time_to_own	status
1	لا أستطيع الدخول إلى نظام الرواتب	2026-10-13 06:19:15	2	1	2026-10-13 06:21:15	2

التذكرة أخذت ال SLA وموعد الاستلام بعد دقيقتين، وأسندت إلى الدعم الأول، ولكن بعد فوات الموعد وتشغيل مهمة slaticket لم يحدث أي تصعيد، وكان جدول مستويات التصعيد المجدولة للتذكرة فارغاً. وعند قراءة الكود في src/Ticket.php وجدنا السبب:

if ($sla->fields['type'] == SLM::TTR) {
    $data["slalevels_id_ttr"] = SlaLevel::getFirstSlaLevel($slas_id);
}

أي أن GLPI يجدول مستويات التصعيد لاتفاقيات وقت الحل TTR فقط، أما مستويات التصعيد على اتفاقية TTO فتحفظ في الشاشة دون أن تعمل على هذا المسار. ولذلك أضفنا اتفاقية TTR مدتها ثلاث دقائق مع مستوى تصعيد عند الموعد يسند التذكرة إلى الدعم الثاني:

// GLPI runs escalation levels for TTR (time to resolve) SLAs only, so the escalation moves to a TTR SLA:
// a 3-minute TTR with a level at the deadline that assigns the L2 group, added to the e-mail rule. node glpi-ttr.mjs
const B = 'http://127.0.0.1:18081/apirest.php';
const { session_token } = await (await fetch(`${B}/initSession`, { headers: { Authorization: 'Basic ' + btoa('glpi:Lab-Pass-2026!') } })).json();
const H = { 'Session-Token': session_token, 'Content-Type': 'application/json' };
const add = async (type, input) => {
  const r = await fetch(`${B}/${type}`, { method: 'POST', headers: H, body: JSON.stringify({ input }) });
  const j = await r.json(); if (!r.ok) throw new Error(`${type}: ${JSON.stringify(j)}`);
  console.log(`${type} → id ${j.id}`); return j.id;
};
const sla = await add('SLA', { name: 'حل التذكرة خلال 3 دقائق', slms_id: 1, type: 0, number_time: 3, definition_time: 'minute' });
const lvl = await add('SlaLevel', { name: 'تصعيد إلى L2 عند تجاوز وقت الحل', slas_id: sla, execution_time: 0, is_active: 1, match: 'AND' });
await add('SlaLevelAction', { slalevels_id: lvl, action_type: 'assign', field: '_groups_id_assign', value: 2 });
await add('RuleAction', { rules_id: 96, action_type: 'assign', field: 'slas_id_ttr', value: sla });

وبعد رسالة جديدة وفوات موعد الحل، كان سجل التذكرة كما يلي:

id	date_mod	itemtype	items_id	id_search_option	old_value	new_value	user_name
920	2026-10-13 06:22:14	Ticket	2	0			cron_mailgate
921	2026-10-13 06:22:14	Ticket	2	4		employee (7)	cron_mailgate
922	2026-10-13 06:22:14	Ticket	2	150	0	1	cron_mailgate
923	2026-10-13 06:22:14	Ticket	2	8		الدعم الأول L1 (1)	cron_mailgate
924	2026-10-13 06:22:14	Ticket	2	12	1	2	cron_mailgate
925	2026-10-13 06:25:34	Ticket	2	8		الدعم الثاني L2 (2)	cron_slaticket

tickets_id	groups_id	name	type
2	1	الدعم الأول L1	2
2	2	الدعم الثاني L2	2

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

• التصعيد نفذته المهمة cron_slaticket في 06:25:34 UTC، والموعد كان 06:25:14، والفرق بسببنا لأننا شغلنا المهمة يدوياً، أما افتراضياً فهي تعمل كل 300 ثانية.
• الإجراء «assign» أضاف الدعم الثاني L2 ولم يحذف الدعم الأول L1، فأصبحت التذكرة مسندة إلى المجموعتين، فإذا كنت تريد نقلاً حقيقياً فاكتب ذلك صراحة في الإجراءات.
• الأوقات في قاعدة البيانات بتوقيت UTC لأننا لم نفعل دعم المناطق الزمنية في MariaDB، وتوثيق ال Docker Image الرسمية يشرح الأمر database:enable_timezones لذلك.

ثم خرجت الإشعارات بالعربية إلى Mailpit، مثل «[GLPI #0000002] تذكرة جديدة» و«مجموعة جديدة في المكلفين». والصورة التالية تبين التذكرة في الواجهة العربية:

والترجمة هنا شبه كاملة والاتجاه صحيح، والقائمة فيها المشاكل والتغييرات وكتالوج الخدمة بالعربية، والملاحظات قليلة مثل «كاتبان العالمي» في الشريط العلوي وهي على الأرجح خطأ في ترجمة Kanban.

نظام FreeScout: بريد سريع ولا SLA

لا توجد Docker Image رسمية ل FreeScout، فاستخدمنا صورة nfrastack/freescout المجتمعية، وهي تنشئ المدير وتشغل ال Migrations عند أول تشغيل:

# FreeScout (community image nfrastack/freescout; FreeScout has no official Docker image) with MariaDB
name: lab-itsm-freescout
services:
  app:
    image: nfrastack/freescout:2.2.18
    container_name: lab-itsm-freescout
    environment:
      CONTAINER_NAME: lab-itsm-freescout
      TIMEZONE: Asia/Riyadh
      DB_TYPE: mariadb
      DB_HOST: lab-itsm-freescout-db
      DB_PORT: "3306"
      DB_NAME: freescout
      DB_USER: freescout
      DB_PASS: lab-freescout-pass
      ADMIN_EMAIL: [email protected]
      ADMIN_FIRST_NAME: مدير
      ADMIN_LAST_NAME: النظام
      ADMIN_PASS: Lab-Pass-2026!
      APP_URL: http://127.0.0.1:18082
      ENABLE_AUTO_UPDATE: "FALSE"
      FREESCOUT_APP_LOCALE: ar
      FREESCOUT_APP_TIMEZONE: Asia/Riyadh
      FREESCOUT_MAIL_DRIVER: smtp
      FREESCOUT_MAIL_HOST: lab-itsm-mailpit
      FREESCOUT_MAIL_PORT: "1025"
      FREESCOUT_MAIL_FROM_ADDRESS: [email protected]
    volumes: [fs-data:/data]
    ports: ["127.0.0.1:18082:80"]
    depends_on: [db]
    networks: [lab-itsm-net]
  db:
    image: mariadb:11.8.9
    container_name: lab-itsm-freescout-db
    environment:
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
      MARIADB_DATABASE: freescout
      MARIADB_USER: freescout
      MARIADB_PASSWORD: lab-freescout-pass
    volumes: [fs-db:/var/lib/mysql]
    networks: [lab-itsm-net]
volumes:
  fs-data: { name: lab-itsm-freescout-data }
  fs-db: { name: lab-itsm-freescout-db }
networks:
  lab-itsm-net: { external: true }

ثم أنشأنا صندوق البريد بسكربت يشغل داخل php artisan tinker:

<?php
// php artisan tinker < freescout-mailbox.php : a mailbox that reads GreenMail over IMAP and sends through Mailpit
$m = App\Mailbox::firstOrNew(['email' => '[email protected]']);
$m->name = 'دعم تقنية المعلومات';
$m->in_server = 'lab-itsm-greenmail'; $m->in_port = 3143; $m->in_username = '[email protected]'; $m->in_password = 'lab-pass';
$m->in_protocol = App\Mailbox::IN_PROTOCOL_IMAP; $m->in_encryption = App\Mailbox::IN_ENCRYPTION_NONE; $m->in_validate_cert = false;
$m->out_method = App\Mailbox::OUT_METHOD_SMTP; $m->out_server = 'lab-itsm-mailpit'; $m->out_port = 1025; $m->out_encryption = App\Mailbox::OUT_ENCRYPTION_NONE;
$m->save();
$admin = App\User::where('email', '[email protected]')->first();
$m->users()->syncWithoutDetaching([$admin->id]);
echo "mailbox {$m->id}\n";

وبعد إرسال الرسالة شغلنا الجلب يدوياً بدل انتظار المجدول الذي يعمل كل دقيقة افتراضياً:

docker exec lab-itsm-freescout sh -c 'cd /www/html && php artisan freescout:fetch-emails'

[2026-10-13 09:36:21] Mailbox: دعم تقنية المعلومات
[2026-10-13 09:36:21] Folder: INBOX
[2026-10-13 09:36:22] Fetched: 1
[2026-10-13 09:36:22] 1) لا أستطيع الدخول إلى نظام الرواتب
[2026-10-13 09:36:22] Thread successfully created: 1
[2026-10-13 09:36:22] Fetching finished

والواجهة العربية هنا جيدة والاتجاه صحيح، ولكن لم نجد ما نضبطه لل SLA، لأن النظام لا يملك مؤقتات أو مواعيد أصلاً، والطريق الوحيد هو وحدة Workflows المدفوعة بشروط على عمر المحادثة، وهي أتمتة وليست SLA بتقويم ومؤقتات وتقارير.

الذاكرة بعد التشغيل

قسنا الذاكرة بالأمر docker stats --no-stream والأنظمة ساكنة بعد التجربة، وفي كل نظام تذكرة إلى ثلاث تذاكر، والأرقام إرشادية على جهاز التجربة نفسه وليست قياس أداء:

lab-itsm-freescout 134.4MiB / 31.29GiB
lab-itsm-freescout-db 135.4MiB / 31.29GiB
lab-itsm-glpi 188.7MiB / 31.29GiB
lab-itsm-glpi-db 249.4MiB / 31.29GiB
lab-itsm-greenmail 421.5MiB / 31.29GiB
lab-itsm-mailpit 39.55MiB / 31.29GiB
lab-itsm-zammad-db 141.8MiB / 31.29GiB
lab-itsm-zammad-memcached 15.4MiB / 31.29GiB
lab-itsm-zammad-nginx 38.68MiB / 31.29GiB
lab-itsm-zammad-rails 366.3MiB / 31.29GiB
lab-itsm-zammad-redis 13.65MiB / 31.29GiB
lab-itsm-zammad-scheduler 400.1MiB / 31.29GiB
lab-itsm-zammad-websocket 268.3MiB / 31.29GiB

ولاحظ أن GreenMail وحده أخذ 421 MiB لأنه برنامج Java، وهو أداة تجربة فقط ولن يكون في الإنتاج، حيث يقرأ النظام من خادم بريد المؤسسة الحقيقي كما في دليل استضافة البريد للمؤسسات.

كيف تختار؟ جدول قرار

أخطاء شائعة عند الاختيار

• الحكم على العربية من صفحة المنتج، والصحيح أن تفتح ملف الترجمة أو تجرب الواجهة، فقد رأينا نسباً بين 10% و93% لأنظمة كلها تذكر العربية في قائمة لغاتها.
• اختيار نظام ITSM كامل لفريق من شخصين، فيقضي الفريق أشهراً في الإعداد ويعود إلى البريد.
• افتراض أن مستوى التصعيد يعمل لأنه حفظ في الشاشة، وقد رأينا في GLPI مستوى على TTO لا يعمل، وفي Zammad قاعدة إجراء لا ترى حدث التصعيد، فاختبر كل قاعدة بتذكرة حقيقية ومدة قصيرة.
• نسيان أن البريد من عنوان غير معروف قد يرفض بصمت، فراجع قائمة الرسائل غير المستوردة في GLPI أو ما يقابلها في نظامك.
• حساب تكلفة النواة المجانية فقط، والصحيح أن تجمع الوحدات المدفوعة التي تحتاجها فعلاً مثل الدخول الموحد في GLPI أو FreeScout.
• تشغيل Docker Image مجتمعية متوقفة منذ سنتين لأنها الأولى في نتائج البحث، فتحقق من تاريخ آخر تحديث لها ومن إصدار البرنامج داخلها.

الخلاصة

• الأنظمة في ثلاث فئات: مكتب دعم مثل Zammad وosTicket وFreeScout، وتذاكر مع أصول مثل Request Tracker، وITSM كامل مثل GLPI وiTop وZnuny وOTOBO، فاختر الفئة قبل الاسم.
• كل الأنظمة الثمانية مفتوحة المصدر بتراخيص GPL أو AGPL، والفرق في الأجزاء المدفوعة: الدخول عبر OIDC في GLPI، والوحدات في FreeScout، والباقات في iTop، والسحابة والدعم في الباقي.
• أوقفت OTRS AG دعم Community Edition في 1 يناير 2021 بعد إعلان في 23 ديسمبر 2020، ومنها جاء Znuny وOTOBO.
• العربية: GLPI نحو 93% وOTOBO نحو 87% وFreeScout قريب منهما، وZammad وRT نحو 20%، وZnuny نحو 10%، وiTop بلا ترجمة عربية.
• في التجربة وصل البريد إلى Zammad تلقائياً خلال 11 ثانية، ورفضه GLPI حتى أنشأنا حساب المرسل، ونجح في FreeScout، والذاكرة نحو 1244 و438 و270 MiB على الترتيب.
• ال SLA في Zammad صعد التذكرة آلياً، وفي GLPI عمل التصعيد على TTR فقط وأضاف مجموعة ولم يستبدلها، وFreeScout لا يملك SLA.

وفي مقالات قادمة من هذا القسم بإذن الله سوف نشرح تثبيت Zammad وGLPI للإنتاج بالتفصيل، ثم سجل الأجهزة والتراخيص مع Snipe-IT وتوثيق الشبكة مع NetBox. وهذه مقالات مرتبطة بالموضوع:

دليلإدارة خدمات تقنية المعلومات ITSM: ما الذي تحتاجه فعلاً؟كيف تنظم عمل الدعم الفني بالتذاكر والمؤقتات والتصعيد، وما الذي تأخذه من ITIL دون بيروقراطية.دليلMDM: إدارة أجهزة الموظفين وتأمينها بأدوات مفتوحةكيف تدير الشركة حواسيب موظفيها وهواتفهم وتفرض عليها التشفير والتحديث، وما الذي تستطيع أن تراه فعلاً على كل جهاز.دليلBYOD: كيف تحمي بيانات الشركة على أجهزة الموظفين الشخصيةكيف تختار طريقة وصول الموظفين من أجهزتهم الشخصية، وتعرف ما يحق للشركة أن تراه، وتكتب سياسة واضحة لذلك.دليلأدوات الوصول الآمن إلى السيرفرات: خريطة مفتوحة المصدرخريطة لأدوات الوصول الآمن مفتوحة المصدر إلى السيرفرات، ماذا تحل كل عائلة منها وما ترخيصها، وكيف تختار ما يناسب فريقك.دليلتثبيت authentik للدخول الموحد SSO إلى تطبيقاتككيف تثبت authentik حتى يدخل كل موظف إلى تطبيقات الفريق بحساب واحد، مع فرض المصادقة الثنائية على الجميع.دليلتثبيت Chatwoot لخدمة العملاء على خادمككيف تثبت Chatwoot على سيرفرك لتجمع رسائل عملائك من دردشة الموقع والبريد وWhatsApp في صندوق وارد واحد.

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

• أكتوبر 2026: كتابة المقال اعتماداً على مستودعات المشاريع وصفحات الأسعار كما هي في 13 أكتوبر 2026، مع تجربة حقيقية على Zammad 7.2.2 (ghcr.io/zammad/zammad:7.2.2-0003) وGLPI 12.0.0 (glpi/glpi:12.0.0 مع PHP 8.5.11 وMariaDB 11.8.9) وFreeScout 1.8.247 (nfrastack/freescout:2.2.18)، والبريد عبر Mailpit 1.31.5 وGreenMail 2.1.14 على Docker Engine 29.8.0.