دليل التثبيت على Linux لـ digna إصدار 2026.06¶
الإصدار: 2026.06
آخر تحديث: 5 سبتمبر 2026
جدول المحتويات¶
- مقدمة
- متطلبات النظام
- التهيئة ما قبل التثبيت
- إعداد خادم PostgreSQL
- تهيئة خادم الويب
- التثبيت الابتدائي
- تكوين الخلفية (Backend)
- تكوين الواجهة (Dashboard)
- تشغيل digna كخدمة systemd
- الترقية إلى إصدار جديد
مقدمة¶
عن digna¶
digna هي منصة شاملة مدفوعة بالذكاء الاصطناعي مصممة لتحسين إدارة جودة البيانات عبر بيئات بيانات متعددة مثل المستودعات، البحيرات، وlakehouses. بُنيت لتكون قابلة للتوسع والتكيف بدرجة عالية، وتتعامل digna مع تحديات البيانات الحديثة عبر الأتمتة، المراقبة في الوقت الحقيقي، واكتشاف الشذوذ.
تتكون digna من مكوّنَين رئيسيين:
- digna: نواة التطبيق، وهي المسؤولة عن معالجة البيانات وتنفيذ فحوص الجودة. تجمع الواجهة الخلفية وواجهة سطر الأوامر في ملف تنفيذي واحد، وتحل محل البرنامجين المنفصلين
dignabackendوdignacliفي الإصدارات السابقة. - dignadashboard: واجهة ويب مستضافة على خادم ويب، توفّر وسيلة سهلة التفاعل مع منصة digna وتصوّر مقاييس جودة البيانات.
ما الجديد في إصدار 2026.06¶
يجلب هذا الإصدار قدرات مراقبة البيانات داخل الشيفرة نفسها، مما يتيح للمطورين مراقبة جودة البيانات من المصدر. راجع ملاحظات الإصدار للتفاصيل الكاملة.
تبحث عن Windows أو macOS؟¶
يغطي هذا الدليل Linux. للمنصات الأخرى، راجع دليل التثبيت على Windows أو دليل التثبيت على macOS.
أي توزيعة يغطي هذا الدليل؟¶
التعليمات مكتوبة لعائلتين شائعتين من الخوادم. حيث تختلف الأوامر بينهما، يتم عرض كلا الأمرين:
- عائلة Debian — Debian، Ubuntu. مدير الحزم:
apt. - عائلة RHEL — Red Hat Enterprise Linux، Rocky Linux، AlmaLinux، Fedora. مدير الحزم:
dnf.
أي توزيعة حديثة تحتوي على systemd ستعمل؛ ما يتغير فقط أسماء الحزم وبعض مسارات التهيئة.
متطلبات النظام¶
قبل أن تبدأ التثبيت، تأكد من أن نظامك يفي بالحد الأدنى من المتطلبات التالية:
| المتطلب | المواصفات |
|---|---|
| نظام التشغيل | Ubuntu 22.04 LTS أو أحدث، Debian 12 أو أحدث، RHEL 9 / Rocky 9 / AlmaLinux 9 أو أحدث |
| العمارة | x86_64 (amd64) أو arm64 |
| نظام التهيئة (Init System) | systemd |
| الذاكرة (إعداد أدنى) | 16 GB RAM |
| مساحة القرص | 10 GB مساحة متاحة |
| قاعدة البيانات | خادم PostgreSQL 12 أو أحدث |
| خادم الويب | nginx، Apache httpd، أو مكافئ |
خيارات تثبيت قاعدة البيانات¶
إذا كان PostgreSQL مثبتًا بالفعل: يمكنك إضافة قاعدة بيانات جديدة لـ digna إلى خادم PostgreSQL الموجود لديك.
إذا كنت ستثبت PostgreSQL على نفس الجهاز الذي سيشغّل digna:
المواصفات الموصى بها
- الذاكرة: 32 GB RAM (بدلاً من 16 GB)
- مساحة القرص: 50 GB مساحة متاحة (بدلاً من 10 GB)
هذه المواصفات الأعلى تستوعب تشغيل digna وقاعدة بيانات PostgreSQL معًا.
التحقق من التوزيعة والعمارة¶
تختلف عدة أوامر في هذا الدليل بين عائلتي Debian و RHEL. للتحقق أي منهما تستخدم، شغّل:
ID=ubuntuأوID=debian— استخدم أوامرapt.ID=rhel,rocky,almalinuxأوfedora— استخدم أوامرdnf.x86_64أوaarch64— هي معمارية حزمة التثبيت التي تحتاجها.
التهيئة ما قبل التثبيت¶
قبل تثبيت digna، تأكد من توافر شرطين أساسيين:
- خادم PostgreSQL – لتخزين المقاييس المحسوبة وبيانات الأداء
- خادم الويب – لاستضافة لوحة تحكم digna
إذا لم تكن هذه المكونات معدّة بالفعل، اتبع الأقسام أدناه لتثبيتها وتكوينها.
تحديث فهارس الحزم¶
حدّث قوائم الحزم قبل تثبيت أي شيء:
ملاحظة
طوال هذا الدليل، الأمر الأول في كل زوج مخصص لعائلة Debian والثاني لعائلة RHEL. شغّل الأمر الذي يطابق نظامك فقط.
إعداد خادم PostgreSQL¶
إذا كان PostgreSQL مثبتًا بالفعل¶
إذا كان PostgreSQL مثبتًا ويعمل على جهازك المحلي أو كنت تستخدم خادم PostgreSQL مدارًا عن بُعد، يمكنك الانتقال إلى القسم التالي.
تثبيت PostgreSQL¶
الخطوة 1: تثبيت حزمة الخادم¶
نصيحة
حزم التوزيعة قد تتأخر عن إصدار PostgreSQL الحالي. إذا احتجت إلى إصدار أحدث محدد، استخدم المستودع الرسمي الخاص بـ PostgreSQL apt أو yum.
الخطوة 2: تهيئة عنقود قاعدة البيانات¶
على عائلة Debian، الحزمة تُنشئ وتبدأ العنقود تلقائيًا — انتقل إلى الخطوة التالية.
على عائلة RHEL، يجب إنشاء العنقود صراحة:
الخطوة 3: بدء وتمكين الخدمة¶
هذا يبدأ PostgreSQL فورًا ويضبطه ليعمل تلقائيًا عند الإقلاع.
الخطوة 4: التحقق من التثبيت¶
يجب أن ترى إصدار PostgreSQL وخدمة في حالة active (running).
الخطوة 5: الاتصال بالخادم¶
حزمة PostgreSQL على Linux تنشئ حساب نظامي postgres الذي يملك العنقود. اتصل من خلاله:
ملاحظة — يختلف Linux عن Windows هنا
مُثبِّت Windows يطالبك بتعيين كلمة مرور لمستخدم postgres أثناء التثبيت. حزم Linux لا تفعل ذلك. بدلًا من ذلك، تُجرى المصادقة على الاتصالات المحلية عبر peer authentication: يُسمح لمستخدم نظام التشغيل postgres بالاتصال كمستخدم قاعدة بيانات postgres بدون كلمة مرور.
لهذا السبب يستخدم الأمر أعلاه sudo -u postgres. يتصل digna backend عبر TCP باسم مستخدم وكلمة مرور، لذا ستنشئ مستخدمًا صريحًا لـ digna في التثبيت الابتدائي.
الخطوة 6: تأكيد المنفذ¶
المنفذ الافتراضي لـ PostgreSQL هو 5432. لتأكيد المنفذ الذي يستمع عليه خادمك:
دوّن هذه القيمة — ستحتاجها عند تكوين backend الخاص بـ digna.
الخطوة 7: تمكين مصادقة كلمات المرور لمستخدم digna¶
digna يتصل بـ PostgreSQL عبر TCP كمستخدم digna_user، ويتطلب ذلك مصادقة بكلمة مرور بدلًا من peer authentication. تحقق أن pg_hba.conf يسمح بذلك.
حدد موقع الملف:
افتحه بمحرر وتأكد أن الأسطر الخاصة بالاتصالات TCP المحلية تستخدم scram-sha-256 (أو md5 على الخوادم الأقدم) بدلاً من ident:
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
أعد تحميل PostgreSQL بعد أي تغيير:
مهم
إذا أبلغت digna عن FATAL: Ident authentication failed for user "digna_user", فهذه الإعدادات هي السبب.
الخطوة 8: إذا كان PostgreSQL يعمل على جهاز آخر¶
للسماح بالاتصالات من مضيف مختلف، اضبط listen_addresses في postgresql.conf وأضف سطر host مناسبًا لشبكتك في pg_hba.conf:
ثم افتح المنفذ في جدار الحماية وأعد تشغيل الخدمة:
تهيئة خادم الويب¶
تتطلب digna خادم ويب لاستضافة الواجهة. اختر أحد الخيارات التالية:
- nginx — خفيف ومُوصى به
- Apache httpd — بديل واسع الانتشار
تحتاج فقط إلى تثبيت وتكوين أحد هذين الخادمين.
تقوم كلا القسمين بتكوين أمرين تعتمد عليهما الواجهة:
- استرجاع تطبيق الصفحة الواحدة (single-page-application fallback)، حتى لا يعيد تحديث عنوان URL في لوحة التحكم خطأ 404
- نوع MIME للاحقة
.md، حتى تُخدَمّ ملفات Markdown بشكل صحيح
إعداد nginx¶
نظرة عامة¶
nginx هو خادم ويب خفيف وعالي الأداء مناسب جيدًا لخدمة لوحة تحكم digna الثابتة.
التثبيت¶
بدء nginx¶
التحقق من التثبيت¶
- افتح المتصفح
- انتقل إلى
http://localhost - يجب أن ترى صفحة الترحيب الخاصة بـ nginx
فتح جدار الحماية¶
إذا كان الخادم مُتاحًا من أجهزة أخرى، سمح بحركة HTTP:
تكوين موقع للوحة التحكم¶
nginx يضمن تضمين كل ملف في دليل conf.d على كلتا العائلتين. أنشئ ملف تهيئة مخصص لـ digna هناك:
ألصق التالي، مع استبدال /opt/digna/dashboard بالمسار الفعلي لمجلد dashboard المستخرج لديك:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /opt/digna/dashboard;
index index.html;
# Serve Markdown files with the correct MIME type.
types {
text/markdown md;
}
# Single-page-application fallback: unknown paths return index.html
# instead of a 404, so dashboard routes survive a browser refresh.
location / {
try_files $uri $uri/ /index.html;
}
}
مهم
بدون توجيه try_files، يؤدي إعادة تحميل أي صفحة في لوحة التحكم غير صفحة الجذر إلى 404. هذا مكافئ nginx لوظيفة URL Rewrite المطلوبة في IIS على Windows.
تعطيل الموقع الافتراضي¶
يمكن أن يكون بلوك سيرفر واحد فقط هو الـ default_server لمنفذ. على عائلة Debian، احذف الإعداد الافتراضي المعبأ حتى لا يتعارض:
على عائلة RHEL، علّق أو احذف بلوك server { ... } داخل /etc/nginx/nginx.conf.
تطبيق التهيئة¶
اختبر التهيئة لصياغة صحيحة، ثم أعد تحميل nginx:
إعداد Apache httpd¶
نظرة عامة¶
Apache httpd متوفر في مستودعات التوزيعة الافتراضية لكل توزيعة مدعومة. اسم الحزمة هو apache2 على عائلة Debian و httpd على عائلة RHEL.
التثبيت¶
بدء Apache¶
التحقق من التثبيت¶
- افتح المتصفح
- انتقل إلى
http://localhost - يجب أن ترى صفحة Apache الافتراضية لتوزيعتك
مطلوب: تفعيل mod_rewrite¶
تتطلب الواجهة إعادة كتابة عناوين URL.
على عائلة Debian، فعّل الوِحدة وأعد التشغيل:
على عائلة RHEL، mod_rewrite محمّل افتراضيًا. تأكد من وجوده:
مطلوب: السماح بتجاوزات .htaccess¶
افتح ملف التهيئة لجذر المستندات:
حدِّد بلوك <Directory> الذي يغطي جذر المستندات (/var/www/html على كلتا العائلتين) وغيّر:
إلى:
مطلوب: نوع MIME لملفات Markdown¶
في نفس الملف، أضف السطر التالي حتى تُخدم ملفات Markdown بشكل صحيح:
مهم
بدون هذا الإعداد، قد لا تُخدم ملفات .md بشكل صحيح.
تطبيق التهيئة¶
تحقق من التهيئة لصياغة صحيحة، ثم أعد تشغيل Apache:
التثبيت الابتدائي¶
الخطوة 1: إعداد مستودع digna¶
مستودع digna يخزن جميع المقاييس المحسوبة بواسطة digna. يعمل كقاعدة بيانات مركزية للبيانات التحليلية وأداء النظام.
إنشاء مخطط المستودع والمستخدم¶
افتح عميل PostgreSQL الخاص بك (psql، pgAdmin، أو ما شابه) ونفّذ أوامر SQL التالية:
CREATE SCHEMA <digna_repo_schema>;
CREATE USER <digna_repo_user> WITH PASSWORD '<digna_repo_password>';
GRANT ALL PRIVILEGES ON SCHEMA <digna_repo_schema> TO <digna_repo_user>;
استبدل العناصر النائبة التالية:
<digna_repo_schema>— اسم المخطط المطلوب (مثلاًdignarepo)<digna_repo_user>— اسم المستخدم المطلوب (مثلاًdigna_user)<digna_repo_password>— كلمة مرور آمنة لهذا المستخدم
مثال:
CREATE SCHEMA dignarepo;
CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';
GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;
لتنفيذ هذه الأوامر من الشل في خطوة واحدة:
ثم ألصق العبارات عند موجه postgres=# واكتب \q للخروج.
أفضل ممارسة
استخدم كلمات مرور قوية ومعقدة لمستخدمي قاعدة البيانات. تجنّب بيانات اعتماد سهلة التخمين.
الخطوة 2: فك حزمة تثبيت digna¶
- حدّد ملف ZIP لتثبيت digna المزوَّد لك
- فكّه في موقع التثبيت الذي تريده — على سبيل المثال
/opt/digna - بعد الفك، يجب أن ترى العناصر التالية:
dashboard/— واجهة الويبdigna— الملف التنفيذي الرئيسي (backend + CLI مدمجان)
ملفا التهيئة والترخيص غير موجودين في الحزمة
لا يأتي config.toml ولا dashboard/dashboard_config.toml مع التثبيت — بل تنشئ كليهما بنفسك، في تهيئة الواجهة الخلفية و تهيئة لوحة التحكم. ولا يأتي license.toml معه كذلك؛ إذ يقدّمه digna بشكل منفصل، كما هو موضّح في الخطوة 3.
لفك الضغط من الشل:
ملاحظة
إذا لم يكن unzip مثبتًا، أضفه بـ sudo apt install -y unzip أو sudo dnf install -y unzip.
جعل الملف التنفيذي قابلاً للتشغيل¶
اعتمادًا على طريقة نقل الأرشيف، قد لا تحتفظ بيانات الترخيص بحقوق التنفيذ عند الفك. اضبطها صراحة:
إنشاء حساب خدمة¶
يوصى بتشغيل الخلفية كمستخدم غير مميز مخصص للإنتاج:
sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna
ملاحظة
على عائلة RHEL، مسار الشِل المعادل هو /sbin/nologin.
الخطوة 3: تثبيت ملف الترخيص¶
مهم
ملف الترخيص غير متضمن في حزمة التثبيت وسيزوَّد لك منفصلًا من digna.
- حدّد ملف
license.tomlالمزود لك - انسخه إلى دليل تثبيت digna الجذري (حيث يوجد
config.tomlوالملف التنفيذيdigna)
لماذا هذا مهم: يحتوي ملف الترخيص على معلومات العميل، تاريخ انتهاء الترخيص، والتوقيع الرقمي. لا تُعدِّل هذا الملف — أي تغيّر سيبطله.
هيكل الدليل بعد الإعداد:
/opt/digna/
├── config.toml (ملف التهيئة)
├── license.toml (ملف الترخيص الخاص بك - انسخه هنا)
├── digna (الملف التنفيذي الرئيسي)
├── bin/ (سكريبتات إدارة الخدمة)
└── dashboard/ (واجهة الويب)
└── (ملفات الdashboard)
تكوين الخلفية (Backend)¶
الخطوة 1: إنشاء وتحرير ملف التهيئة¶
ملف config_template.toml مُقدم في دليل تثبيت digna. كل ما عليك هو إعادة تسميته إلى config.toml.
الموقع: /opt/digna/config.toml
افتح config.toml في محرر نصّي وقم بتكوين كل قسم أدناه.
قسم [app]¶
هذا القسم يضبط إعدادات تطبيق backend الخاص بـ digna:
[app]
digna_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
digna_APP_CORS_ALLOW_CREDENTIALS = true
digna_APP_CORS_ALLOW_METHODS = ["*"]
digna_APP_CORS_ALLOW_HEADERS = ["*"]
| المعامل | القيمة | ملاحظات |
|---|---|---|
digna_APP_CORS_ALLOW_ORIGINS | عنوان الواجهة الأمامية | إذا كانت الواجهة على خادم مختلف، أضف عنوانها هنا |
digna_APP_CORS_ALLOW_CREDENTIALS | true | مطلوب للـ CORS مع الاعتمادات |
digna_APP_CORS_ALLOW_METHODS | ["*"] | السماح بجميع طرق HTTP |
digna_APP_CORS_ALLOW_HEADERS | ["*"] | السماح بجميع الرؤوس |
ملاحظة
إذا كنت تخدم الواجهة من nginx أو Apache على منفذ HTTP الافتراضي، فالأصل المسموح هو http://localhost — أو عنوان الخادم العام عندما تُصل الواجهة من أجهزة أخرى.
قسم [repo]¶
هذا القسم يضبط الاتصال بقاعدة بيانات PostgreSQL:
[repo]
digna_REPO_HOST = "localhost"
digna_REPO_PORT = 5432
digna_REPO_DB = "postgres"
digna_REPO_SCHEMA = "dignarepo"
digna_REPO_USER = "digna_user"
digna_REPO_PASSWORD = "YourSecurePassword123!"
| المعامل | القيمة | ملاحظات |
|---|---|---|
digna_REPO_HOST | localhost أو IP | اسم مضيف/IP خادم PostgreSQL |
digna_REPO_PORT | 5432 (افتراضي) | منفذ PostgreSQL |
digna_REPO_DB | postgres | اسم قاعدة البيانات |
digna_REPO_SCHEMA | dignarepo | المخطط الذي أنشأته سابقًا |
digna_REPO_USER | digna_user | المستخدم الذي أنشأته في إعداد PostgreSQL |
digna_REPO_PASSWORD | كلمة مرورك | كلمة المرور التي عيّنتها أثناء إنشاء المخطط |
أفضل ممارسة
يحتوي config.toml على كلمة مرور قاعدة البيانات كنص صريح. قيد أذوناته بحيث لا يقرأه سوى حساب الخدمة:
قسم [base]¶
يحتوي هذا القسم على إعدادات الأمان وملفات تعريف الارتباط:
[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
digna_COOKIE_DOMAIN = "localhost"
digna_COOKIE_PATH = "/"
digna_COOKIE_SECURE = false
digna_COOKIE_HTTPONLY = true
digna_COOKIE_SAME_SITE = "lax"
digna_TOKEN_EXPIRES_IN = 86400
digna_MAX_WORKERS = 4
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
| المعامل | القيمة | ملاحظات |
|---|---|---|
DIGNA_FERNET_KEY | مفتاح تشفير | يُستخدم لتشفير الرموز وملفات تعريف الارتباط (يوجد مفتاح افتراضي) |
digna_COOKIE_DOMAIN | localhost | طابق نطاق الواجهة الأمامية |
digna_COOKIE_SECURE | false (محلي) / true (إنتاج) | استخدم true للاتصالات عبر HTTPS |
digna_COOKIE_HTTPONLY | true | مفعل دائمًا لأسباب أمنية |
digna_COOKIE_SAME_SITE | lax | يقي من هجمات CSRF |
digna_TOKEN_EXPIRES_IN | 86400 (24 ساعة) | مهلة الجلسة بالثواني |
digna_MAX_WORKERS | عدد أنوية CPU - 1 | عدد مهام الفحص المتوازية |
DIGNA_SCHEDULER_MAX_DELAY | 100 | أقصى تأخير بالثواني يمكن للمجدول إضافته قبل بدء مهمة حان موعدها |
DIGNA_CLEANUP_TIME | "12:00" | وقت اليوم (تنسيق 24 ساعة HH:MM) الذي يبدأ عنده التنظيف اليومي |
نصيحة
لمعرفة عدد أنوية CPU المتاحة على الخادم، شغّل nproc.
قسم [encryption]¶
يحتوي هذا القسم على المفتاح المستخدم لتشفير القيم الحساسة المخزنة في المستودع. وهو إلزامي — يُبلغ config check عن القسم [encryption] بحالة FAILED إذا كان المفتاح مفقودًا.
| المعامل | القيمة | ملاحظات |
|---|---|---|
DIGNA_ENCRYPTION_KEY | مفتاح مُرمّز بصيغة Base64 | يشفّر القيم الحساسة المخزنة في مستودع digna |
احمِ الملف config.toml
هذا المفتاح قيمة ثابتة ومتطابقة في جميع تثبيتات digna، وهو ما يفك تشفير القيم الحساسة في مستودعك. اقصر الوصول إلى config.toml على الحساب الذي يشغّل digna، وأبقِ الملف خارج نظام إدارة الإصدارات والأقراص المشتركة، واستبعده من أي نسخة احتياطية تُحفظ بأمان أقل من المستودع نفسه.
قسم [logging]¶
هذا القسم يضبط سلوك التسجيل:
| المعامل | القيمة | ملاحظات |
|---|---|---|
digna_LOGGING_MODE | INFO أو DEBUG | INFO للإنتاج، DEBUG لاستكشاف الأخطاء |
digna_LOGGING_BACKUP_COUNT | 10 | عدد نُسَخ التسجيل اليومية التي سيتم الاحتفاظ بها |
الخطوة 2: تحقق من التهيئة¶
قبل تهيئة المستودع، تحقق من أن config.toml مكتمل ومبني بشكل صحيح. نفّذ في دليل تثبيت digna:
يُتحقق من كل قسم على حدة، بحيث لا يخفي خطأ واحد حالة الأقسام الأخرى:
Configuration validation report (source: config.toml):
- App config: OK
- Repository config: OK
- Base config: OK
- Logging config: OK
- Encryption config: OK
- OIDC config(s): OK
Overall: OK
صحّح كل ما يُبلَّغ عنه بحالة FAILED، وأعد تنفيذ الأمر قبل المتابعة. القائمة الكاملة للخيارات موجودة في مرجع CLI.
الخطوة 3: تهيئة المستودع¶
- افتح طرفية
- انتقل إلى دليل تثبيت digna (حيث يوجد
config.tomlوالملف التنفيذيdigna) - شغّل اختبار الاتصال:
يجب أن ترى تأكيدًا على نجاح الاتصال (المستودع نفسه لم يُهيأ بعد).
ملاحظة
على Linux، الدليل الحالي ليس في PATH، لذا يُستدعى الملف التنفيذي كـ ./digna بدلًا من digna. لاستخدام الشكل الأقصر في كل مكان، أضف رابطًا رمزيًا:
الخطوة 4: تثبيت مخطط المستودع¶
في نفس الدليل، شغّل:
يُنشئ هذا الأمر الجداول والمخططات اللازمة في قاعدة بيانات PostgreSQL الخاصة بك.
الخطوة 5: إنشاء مستخدم مشرف¶
- افتح نافذة طرفية جديدة
- انتقل إلى دليل تثبيت digna
- شغّل الأمر التالي لإنشاء مستخدم مشرف:
مثال:
يؤدي ذلك إلى إنشاء مستخدم بعنوان البريد الإلكتروني admin@example.com وامتيازات إدارية كاملة.
نصيحة
ضمّن كلمة المرور بين علامات اقتباس مفردة. تتعامل bash و zsh مع الأحرف مثل ! و $ و * بشكل خاص، وكلمة مرور غير محاطة قد لا تُمرَّر كما كتبت.
أفضل ممارسة
استخدم كلمة مرور قوية تضم مزيجًا من أحرف كبيرة وصغيرة وأرقام ورموز خاصة.
الخطوة 6: بدء خادم digna¶
في دليل تثبيت digna، ابدأ الخادم بـ:
المعلمات: - --address — اسم المضيف/عنوان IP للخادم - --port — منفذ الخادم
يجب أن ترى رسائل بدء تُؤكِّد أن الخادم يعمل:
INFO: Started server process [1234]
INFO: Waiting for application startup.
INFO: Application startup complete
INFO: Uvicorn running on http://localhost:8082
نصيحة
إذا كانت الواجهة تُخدم من جهاز مختلف عن الـ backend، افتح منفذ API أيضًا في جدار الحماية:
الخادم يشغل الطرفية
يعمل serve في المقدمة ويستمر حتى توقفه بالضغط على Ctrl+C. اتركه يعمل بينما تكمل الإعداد؛ ولتشغيله تلقائيًا عند الإقلاع بدلًا من ذلك انظر تشغيل digna كخدمة systemd.
تكوين الواجهة (Dashboard)¶
الخطوة 1: نشر الواجهة على خادم الويب¶
تقرأ لوحة digna تهيئتها الخاصة من dashboard/dashboard_config.toml. هذا الملف لا يأتي مع التثبيت — بل تنشئه في دليل dashboard/ إلى جانب ملفات لوحة التحكم.
محتوياته موضّحة في الدخول الموحّد (SSO)، وهناك أيضًا يلزم الملف: فهو يحمل خيارات تسجيل الدخول التي تعرضها لوحة التحكم، وفي عمليات النشر متعددة النسخ، اتصال الواجهة الخلفية.
اختر خادم الويب واتبع خطوات النشر المناسبة.
النشر على nginx¶
إذا اتبعت قسم إعداد nginx، فإن بلوك السيرفر يشير بالفعل إلى مجلد dashboard ولا حاجة للنسخ.
- أكد المسار
- افتح
/etc/nginx/conf.d/digna.conf -
تحقق أن
rootيشير إلى مجلدdashboardالمستخرج -
تأكد من أن المجلد قابل للقراءة
-
أعد تحميل nginx
-
اختبر التثبيت
- افتح المتصفح
- انتقل إلى
http://localhost(أو عنوان الـ URL المكوّن) - يجب أن ترى صفحة تسجيل دخول لوحة digna
النشر على Apache httpd¶
-
انسخ الواجهة إلى جذر المستندات
-
أضف قواعد إعادة الكتابة
أنشئ ملف .htaccess داخل المجلد المنشور ليظلّت مسارات الواجهة صالحة بعد تحديث المتصفح:
ألصق التالي:
RewriteEngine On
RewriteBase /digna/
# Serve existing files and directories as-is.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# Everything else falls back to the single-page application entry point.
RewriteRule ^ index.html [L]
-
أعد تشغيل Apache
-
افتح الواجهة
- افتح المتصفح
- انتقل إلى
http://localhost/digna - يجب أن ترى صفحة تسجيل دخول لوحة digna
الخطوة 2: SELinux (عائلة RHEL فقط)¶
على RHEL، Rocky، AlmaLinux و Fedora، يكون SELinux في الوضع المطبق (enforcing) افتراضيًا وسيمنع خادم الويب من قراءة الملفات خارج المواقع المتوقعة. تحقّق ما إذا كان مفعلًا:
إذا كانت النتيجة Enforcing وكنت تخدم الواجهة من /opt/digna/dashboard، صنف المجلد بحيث يتمكن خادم الويب من قراءته:
sudo semanage fcontext -a -t httpd_sys_content_t "/opt/digna/dashboard(/.*)?"
sudo restorecon -Rv /opt/digna/dashboard
ملاحظة
إذا لم تجد semanage، ثبِّته بـ sudo dnf install -y policycoreutils-python-utils.
مهم
غالبًا ما يكون سبب ظهور 403 Forbidden على خادم RHEL مهيأ حديثًا هو مشكلة في تمييز SELinux وليس في أذونات الملفات. تأكد باستخدام sudo ausearch -m avc -ts recent.
تشغيل digna كخدمة systemd¶
لماذا تشغيل digna كخدمة؟¶
تشغيل backend الخاص بـ digna كخدمة systemd يضمن أنه:
- يبدأ تلقائيًا عند إقلاع الجهاز
- يعمل في الخلفية دون نافذة طرفية مفتوحة
- يعاد تشغيله تلقائيًا إذا تعطل
- يمكن إدارته عبر
systemctl، مدير الخدمات القياسي على Linux
ملفات إدارة الخدمة¶
جميع الملفات اللازمة موجودة في دليل تثبيت digna تحت: bin/
السكريبتات الشل التالية متاحة:
install_service.sh— يسجل digna لدى systemduninstall_service.sh— يلغى تسجيل الخدمةstart_service.sh— يبدء الخدمة المسجلةstop_service.sh— يوقف الخدمة الجارية
مطلوب صلاحيات الروت
يجب تنفيذ جميع السكريبتات باستخدام sudo، لأن تسجيل خدمة تبدأ عند الإقلاع يكتب ملف وحدة إلى /etc/systemd/system.
جعل السكريبتات قابلة للتنفيذ¶
قد لا تحافظ عملية الفك على بت التنفيذ. قبل الاستخدام الأول:
تثبيت الخدمة¶
-
افتح طرفية
-
انتقل إلى مجلد bin
-
شغّل سكريبت التثبيت
تم الآن تسجيل خادم digna لدى systemd مع تمكين بدء التشغيل التلقائي. الخدمة لا تبدأ فورًا — راجع القسم التالي لبدءها.
بدء وإيقاف الخدمة¶
لبدء الخدمة¶
- افتح طرفية
- انتقل إلى
/opt/digna/bin - شغّل:
لإيقاف الخدمة¶
- افتح طرفية
- انتقل إلى
/opt/digna/bin - شغّل:
نصيحة
أوقف الخدمة دائمًا قبل تحديث ملفات التطبيق.
إدارة الخدمة عبر systemctl¶
بعد التسجيل، يمكن أيضًا التحكم بالخدمة باستخدام أوامر systemd القياسية من أي دليل:
sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna
التحقق من الخدمة¶
للتأكد أن الخدمة مسجلة وتعمل:
enabled يعني أن الخدمة تبدأ عند الإقلاع؛ active يعني أنها تعمل الآن.
عرض سجلات الخدمة¶
يقوم systemd بالتقاط كل ما يطبعه الـ backend على الطرفية. لقراءته:
لمتابعة السجل مباشرًة أثناء إعادة إنتاج المشكلة:
نصيحة
هذه أسرع طريقة لتشخيص خدمة تبدأ ثم تتوقف فورًا. فشل اتصال المستودع أو افتقار license.toml يُبلغ عنه هنا.
نقل الخدمة إلى دليل جديد¶
ملف الوحدة يخزن المسار المطلق للملف التنفيذي، لذا يتطلب نقل التثبيت إعادة تسجيل الخدمة:
-
إلغاء تثبيت الخدمة الحالية
-
نقل ملفات التطبيق
-
إعادة تثبيت الخدمة
-
بدء الخدمة
إلغاء تثبيت الخدمة¶
-
أوقف الخدمة الجارية
-
أزل الخدمة
تم الآن إلغاء تسجيل خادم digna من systemd.
الترقية إلى إصدار جديد¶
قبل الترقية¶
تحقق أولًا من جميع اتصالات قواعد البيانات
ابتداءً من الإصدار 2026.06، يصل digna إلى كل تقنية مصدر عبر ODBC. كانت الإصدارات السابقة تتيح الاختيار بين برنامج تشغيل خاص بكل تقنية وبين ODBC، عبر المفتاح Use ODBC. قرر فريق digna الاعتماد على ODBC وحده، لأن واجهة قياسية واحدة تقدّم أكثر مما تقدّمه مجموعة من برامج التشغيل المصممة خصيصًا:
- المصادقة — المصادقة جزء من ODBC، لذا يمكن للاتصال استخدام كل ما يدعمه برنامج التشغيل الخاص به: كلمات المرور، والرموز المميزة و PAT، وKerberos وActive Directory، والمصادقة متعددة العوامل وتسجيل الدخول الموحّد عبر المتصفح، وهويات السحابة، وشهادات العميل وTLS. تصل الطرق الجديدة مع تحديث برنامج التشغيل، بدلًا من انتظار إصدار من digna.
- برامج تشغيل تتولى صيانتها شركات قواعد البيانات — يتابع برنامج التشغيل الخاص بالشركة المصنّعة إصدارات الخادم الجديدة والإصلاحات الأمنية، ويمكنك تحديثه وفق جدولك الخاص وبمعزل عن digna.
- طريقة واحدة لتهيئة كل شيء — كل تقنية هي قائمة من خصائص المفتاح/القيمة، بالواجهة نفسها، وتشفير القيم الحساسة نفسه، وأسلوب استكشاف الأخطاء نفسه، بدلًا من مجموعة حقول مختلفة لكل مصدر.
- الضبط والاتساع — خيارات برنامج التشغيل مثل المهل الزمنية وإعدادات TLS والوسطاء وأحجام الجلب متاحة لكل مصدر، ويمكن توصيل أي تقنية لديها برنامج تشغيل ODBC متوافق، بما في ذلك تلك التي لا ينشر digna دليلًا خاصًا بها.
عمليًا يعني ذلك أن المفتاح Use ODBC والحقول المنفصلة للمضيف والمنفذ وقاعدة البيانات والمستخدم وكلمة المرور لم تعد موجودة. كل اتصال لا يستخدم ODBC بالفعل يجب تحويله إلى ODBC — لا يوجد تحويل تلقائي، لذا خطّط لذلك قبل الترقية:
- راجع كل اتصال بقاعدة بيانات مُعرَّف في تثبيتك ودوّن الاتصالات التي لا تستخدم ODBC بعد — كل منها يحتاج إلى إعادة تهيئة.
- ثبّت برنامج تشغيل ODBC المناسب على مضيف digna — تُفتح الاتصالات من الخادم الذي يشغّل الواجهة الخلفية لـ digna، لا من المتصفح. انظر تثبيت برنامج تشغيل ODBC على مضيف digna.
- جهّز خصائص ODBC لكل اتصال متأثر. أدلة التقنيات تسرد لكل مصدر مجموعة خصائص مجرَّبة.
بعد الترقية، حوّل كل اتصال متأثر إلى ODBC واختبره من لوحة المعلومات — انظر إنشاء اتصال بقاعدة بيانات و اختبار اتصال.
اتصالات Databricks Legacy
أُزيل موصل Databricks Legacy في هذا الإصدار. انقل تلك الاتصالات إلى موصل Databricks.
النسخ الاحتياطي لمستودع digna إلزامي
قبل ترقية digna، اعمل نسخة احتياطية من مستودعك (PostgreSQL) لحماية بياناتك من الضياع. النسخة الاحتياطية تضمن إمكانية الاسترداد إذا واجهت الترقية مشكلات غير متوقعة.
لإنشاء نسخة احتياطية من الشل:
عملية الترقية¶
الخطوة 1: إيقاف خدمة digna¶
إذا كانت digna تعمل كخدمة systemd، أوقفها أولًا:
إذا كانت تعمل في المقدمة (foreground)، اضغط Ctrl + C في نافذة الطرفية الخاصة بها.
الخطوة 2: انسخ التثبيت الحالي احتياطيًا¶
في دليل تثبيت digna، أعد تسمية مجلدات التثبيت الحالي حتى يمكن نشر الإصدار الجديد بجوارها:
لم يعد dignabackend وdignacli مستخدمَين
ابتداءً من الإصدار 2026.06، يحل الملف التنفيذي الواحد digna محل dignabackend وdignacli، وهو يجمع الواجهة الخلفية وواجهة سطر الأوامر. احتفظ بـ dignabackend_old وdignacli_old فقط حتى تتحقق من الترقية — بعدها يمكنك حذف المجلدين. احتفظ بـ dashboard_old حتى تستعيد منه ملفات التهيئة الخاصة بك (انظر الخطوة 4).
الخطوة 3: فك ونشر النسخة الجديدة¶
- فك ملف ZIP للنسخة الجديدة من digna
- انسخ الملف التنفيذي الجديد
dignaومجلدdashboardإلى دليل التثبيت - أعد بت التنفيذ وملكية حساب الخدمة:
مهم
لا يُضمَّن config.toml ولا dashboard/dashboard_config.toml أبدًا في أرشيف ZIP الخاص بالتثبيت — فريق digna لا يرسل أيًّا من الملفين أبدًا. لذلك تبقى تهيئتك الحالية بمنأى عن الترقية، والنسخ الموجودة في المجلدات المعاد تسميتها *_old هي النسخ الوحيدة التي لديك.
الخطوة 4: استعادة ملفات التهيئة الخاصة بك¶
الإصدار 2026.06 يغيّر الملف config.toml
ثلاثة إعدادات جديدة وإلزامية، واثنان لم يعودا مستخدمَين. الملف config.toml المنقول من إصدار سابق لا يحتوي على الإعدادات الجديدة، ولن يبدأ digna ما دامت مفقودة. أضف ما يلي إلى ملف config.toml الحالي:
[base]
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
أضف مفتاحَي [base] إلى قسم [base] الحالي، وأضف [encryption] كقسم جديد. ثم احذف من [app] الإعدادَين اللذين لم يعودا مستخدمَين: digna_APP_HOST وdigna_APP_PORT — إذ صار الخادم يأخذ عنوانه ومنفذه من digna serve.
ما تفعله كل إعداد موضّح في تهيئة الواجهة الخلفية.
الدخول الموحّد: تغيّرت صيغة [oidc_clients]
يستبدل الإصدار 2026.06 مصفوفة الجداول بجدول واحد لكل مزوّد، يحمل اسم مفتاح المزوّد. أُلغي DIGNA_OIDC_KEY — فالمفتاح صار جزءًا من عنوان القسم.
قبل:
[[oidc_clients]]
DIGNA_OIDC_KEY = 'microsoft'
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'
بعد:
[oidc_clients.microsoft]
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'
كرّر القسم لكل مزوّد، وأبقِ كل مفتاح مطابقًا لـ key في dashboard_config.toml. يُبلغ digna config check عن oidc_clients بحالة FAILED ما دامت الصيغة القديمة قائمة. لا يتأثر بذلك سوى التثبيتات التي تستخدم الدخول الموحّد.
الخطوة 5: إعادة تحميل خادم الويب¶
لوحة التحكم عبارة عن مجموعة من الملفات الثابتة، لذا قد يظل خادم الويب — والمتصفح — يقدّمان الإصدار السابق. أعد تحميل أو أعد تشغيل خادم الويب الذي يستضيف مجلد dashboard، ثم أعد تحميل الصفحة بتحديث كامل (Ctrl+F5).
الخطوة 6: تحقق من التهيئة¶
تأكد من أن ملف config.toml المحدَّث مكتمل قبل أن تمسّ المستودع:
يجب أن يُبلِّغ كل قسم بحالة OK. صحّح كل ما يُبلَّغ عنه بحالة FAILED، وأعد تنفيذ الأمر قبل المتابعة.
الخطوة 7: استبدال ملف الترخيص¶
يُرخَّص كل إصدار على حدة. انسخ ملف license.toml الذي قدّمه فريق digna لهذا الإصدار إلى دليل التثبيت، ليحل محل الملف القديم:
لا تحتفظ بالترخيص السابق
ملف license.toml الصادر لإصدار سابق لا يغطي هذا الإصدار، وكل أمر يتحقق من الترخيص — user وinspection وrepo — يتوقف قبل أن يمسّ المستودع عند فشل التحقق. تحقّق منه قبل المتابعة:
الخطوة 8: ترقية مخطط المستودع¶
انتقل إلى دليل تثبيت digna وشغّل:
سيحدِّث هذا مخطط PostgreSQL إلى أحدث إصدار مع المحافظة على جميع البيانات الحالية.
الخطوة 9: إعادة تشغيل الخدمات¶
إذا كانت تعمل كخدمة systemd:
إذا كنت تديرها يدويًا، أعد تشغيل الخادم:
إذا كنت تستخدم nginx أو Apache، أعد تحميل خادم الويب المعني:
على عائلة RHEL، أعد تطبيق تمييز SELinux إذا استُبدل دليل dashboard:
الخطوة 10: التحقق من الترقية¶
- افتح لوحة digna
- تحقق من تحميل الواجهة بشكل صحيح
- تحقق من سجلات الخادم لأي أخطاء:
- حوّل إلى ODBC كل اتصال لم يكن يستخدمه بعد، ثم اختبر جميع الاتصالات — انظر اختبار اتصال