الاشتراك والترخيص

ينقسم ترخيص Rediacc إلى ثلاثة أجزاء متحركة:

• account يُوقّع الاستحقاقات ويتتبع الاستخدام
• rdc يُصادق، ويطلب التراخيص، ويُسلّمها إلى الأجهزة، ويُطبّقها أثناء التشغيل
• renet (وقت التشغيل على الجهاز) يتحقق من التراخيص المثبتة محلياً دون الاتصال بخادم الحساب

تشرح هذه الصفحة كيفية تلاؤم هذه الأجزاء معاً لعمليات النشر المحلية.

ما الذي يفعله الترخيص

يتحكم الترخيص في أمرين مختلفين:

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

هذان مرتبطان، لكنهما ليسا نفس العنصر.

كيف يعمل الترخيص

account هو مصدر الحقيقة للخطط وتجاوزات العقود وحالة فتحات الأجهزة وإصدارات تراخيص المستودع الشهرية.

rdc يعمل على محطة العمل الخاصة بك. يُسجّل دخولك إلى خادم الحساب، ويطلب التراخيص التي يحتاجها، ويثبّتها على الأجهزة البعيدة عبر SSH. عند تشغيل أمر مستودع، يضمن rdc وجود التراخيص المطلوبة ويتحقق منها على الجهاز أثناء التشغيل.

يبدو التدفق الطبيعي كما يلي:

1. تُصادق باستخدام rdc subscription login
2. تُشغّل أمر مستودع مثل rdc repo create أو rdc repo up أو rdc repo down
3. إذا كان الترخيص المطلوب مفقوداً أو منتهي الصلاحية، يطلبه rdc من account
4. يكتب rdc الترخيص الموقَّع على الجهاز
5. يُتحقق من الترخيص محلياً على الجهاز وتستمر العملية

راجع rdc vs renet للتعرف على تقسيم محطة العمل مقابل الخادم، والمستودعات لدورة حياة المستودع نفسها.

للأتمتة ووكلاء الذكاء الاصطناعي، استخدم رمز اشتراك محدد النطاق بدلاً من تسجيل الدخول عبر المتصفح:

rdc subscription login --token "$REDIACC_TOKEN"

يمكنك أيضاً حقن الرمز مباشرةً عبر البيئة حتى يتمكن CLI من إصدار وتجديد تراخيص المستودع دون أي خطوة تسجيل دخول تفاعلية:

export REDIACC_TOKEN="rdt_..."
export REDIACC_ACCOUNT_SERVER="https://www.rediacc.com/account"

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

فتحات الأجهزة (من جانب الخادم)

يتم فرض تتبع فتحات الأجهزة من جانب الخادم. عندما يُصدر CLI ترخيص مستودع، يتحقق خادم الحساب من حصة فتحات الأجهزة للاشتراك. تتضمن كل خطة ذاتية الخدمة (Community وProfessional وBusiness) فتحة جهاز واحدة؛ أما عمليات النشر متعددة الأجهزة فهي إعداد Enterprise يُحدَّد حجمه مع شركائنا. تُحتفظ بالفتحة لمدة 5 ساعات من آخر إصدار ترخيص مستودع على ذلك الجهاز وتُحرَّر تلقائياً بعد الخمول. ولأن الفتحة لا تُحتفظ بها إلا أثناء التوفير النشط، يمكن للفتحة الواحدة أن تغطي عدة أجهزة على مدار الشهر.

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

يُفرض الإصدار والتجديد بطريقتين مختلفتين، وهذا الفرق مهم:

• إصدار ترخيص جديد يتوقف عند السقف. إذا كانت كل الفتحات مشغولة، يفشل الطلب بـ MAX_MACHINES_REACHED ولا يُوفَّر أي شيء.
• تجديد ترخيص قائم لا يتوقف أبداً. الجهاز الذي يُجدد بينما كل الفتحات مشغولة يستمر في العمل، وتُسجَّل فتحته على أنها تتجاوز الحد. يظهر ذلك في البوابة على صفحة الأجهزة، وفي rdc subscription status، وفي حقل overLimitCount في واجهة حالة التراخيص. وتزول العلامة تلقائياً بمجرد عودة الجهاز إلى داخل الحد.

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

لا توجد ملف ترخيص جهاز مخزّن على الجهاز. يحدث فرض الفتحة في وقت الإصدار على الخادم.

ترخيص المستودع

ترخيص المستودع هو ترخيص موقَّع لمستودع واحد على جهاز واحد. هو ملف الترخيص الوحيد المخزَّن على الجهاز، ومنظَّم لكل مخزن بيانات ولكل مفتاح توقيع:

/var/lib/rediacc/license/repos/{guid}/{keyId}.json
/var/lib/rediacc/license/datastores/{datastoreId}/repos/{guid}/{keyId}.json

المستودعات الموجودة على التخزين الافتراضي للجهاز تستخدم المسار الأول. أما المستودعات الموجودة في مخزن بيانات مُسمّى فتستخدم المسار الثاني، حيث {datastoreId} هي الهوية التي مُنحت لذلك المخزن عند إنشائه. هذا التحديد بالنطاق هو ما يجعل تفريع مخزن البيانات يُحتسب بأمانة: المخزن المُفرَّع يحصل على هوية جديدة تماماً، فتبدأ مستودعاته بلا أي تراخيص، وتُبلّغ عن missing في أول عملية مرخَّصة لها، ثم تحصل على تراخيصها الخاصة. والمستودع الذي يُسمّي ترخيصه مخزن بيانات غير الذي يوجد فيه يفشل فوراً بـ identity_mismatch بدلاً من إعادة الإصدار تلقائياً، وهذا ما يمنع نسخ ملف ترخيص جانبياً.

{keyId} هي بصمة سداسية عشرية من 16 خانة (أول 8 بايتات من SHA-256 لمفتاح Ed25519 العام لخادم التوقيع). المستودع المُدار من أكثر من كون حساب واحد (مثل الإنتاج وbench اللذين يُنشران على نفس الجهاز) يحتفظ بملف واحد لكل مفتاح توقيع ضمن دليل {guid} الخاص به. تُصادق نسخة renet الخاصة بالجهاز فقط على الملف الذي يستطيع مفتاحها المدمج، أو شهادة تفويض متسلسلة إليه، التحقق منه؛ ملفات الأكوان الأخرى خاملة. التبديل بين الأكوان لا يُبطل التراخيص أبداً: تُصدر أول عملية في كون جديد ترخيص ذلك الكون مرةً واحدة (نتيجة missing تُصدر تلقائياً)، ويتعايش الاثنان بعد ذلك.

يُستخدم من أجل:

• rdc repo create وrdc repo fork وrdc repo commit، يُتحقق منها قبل التوفير (تُصدَر مسبقاً بدون إثباتات الهوية، ثم يُعاد إصدارها مع إثباتات الهوية بعد الإنشاء، لأن المستودع لا يكون موجوداً بعد لحظة الفحص)
• rdc repo resize وrdc repo expand وrdc repo merge وrdc repo promote، تحقق كامل بما في ذلك انتهاء الصلاحية
• نقل النسخ الاحتياطية، تحقق كامل بما في ذلك انتهاء الصلاحية: rdc repo push وrdc repo pull وrdc repo migrate والنسخ الاحتياطية المجدولة
• rdc repo up وrdc repo up --all وrdc repo exec والبدء التلقائي للمستودع عند إعادة تشغيل الجهاز، يُتحقق منها مع تخطي انتهاء الصلاحية ونافذة شهادة التفويض معاً
• rdc repo down وrdc repo delete والأوامر التي تقرأ فقط، مثل سرد المستودعات، لا تحتاج إلى ترخيص إطلاقاً

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

تراخيص المستودع مرتبطة بالجهاز والمستودع المستهدف. كل ترخيص يحتوي على معرّف الجهاز ومعرّف GUID للمستودع ومعرّف الاشتراك وحدود الخطة وانتهاء الصلاحية. بالنسبة للمستودعات المشفرة، يتحقق Rediacc أيضاً من هوية LUKS للحجم الأساسي.

يمكن لاشتراكات متعددة أن تتعايش على نفس الجهاز. كل مستودع يحمل ترخيصه الخاص مع سياق الاشتراك الخاص به.

العناقيد

يُباع التجميع في عناقيد عبر شركائنا كجزء من اتفاقية Enterprise. وهو ليس خياراً ضمن الخطط ذاتية الخدمة، والأقسام التالية تشرح كيفية احتسابه لا كيفية شرائه.

العقدة جهاز. ليس للعنقود هوية ترخيص خاصة به. كل عقدة فيه هي جهاز عادي مثبَّت عليه Renet Agent، وتُحتسب تماماً كما يُحتسب جهاز مستقل.

لا يوجد تجميع للحصص. العنقود المكوَّن من خمس عقد لا يسحب من فتحة عنقود واحدة مشتركة. كل عقدة تطالب بفتحتها الخاصة أول مرة يُوضَع عليها مستودع، وتتبع تلك الفتحة قاعدة الخمس ساعات العائمة نفسها كأي فتحة أخرى: تُحتفظ بها 5 ساعات من آخر إصدار ترخيص مستودع على تلك العقدة ثم تُحرَّر تلقائياً.

بناء العنقود مجاني. ما يُحتسب هو وضع المستودعات. إنشاء العنقود وضم العقد إليه وتثبيت طبقة التخزين الموزَّع وإقامة مستوى تحكم Kubernetes لا يكلّف أي فتحة. يبدأ الاحتساب عندما يحط مستودع على عقدة.

تفريع العنقود يُعيد الاحتساب لكل مستودع. تفريع عنقود كامل يمنح مخزن البيانات المُفرَّع هوية جديدة، فيحصل كل مستودع في الفرع على ترخيصه الخاص أول مرة يُلمَس، على أي عقدة كان يعمل. أما الترحيل العادي فهو الحالة المعاكسة: نقل مستودع بين الأجهزة يحمل ترخيصه معه ويظل صالحاً، لأن شيئاً في هوية تخزينه لم يتغير.

التجديد داخل العنقود يتبع قاعدة المطالبة المرنة أعلاه. تُجدد العقد تراخيصها بنفسها دون إشراف، فالعنقود الذي تجاوز عدد تفعيلاته يستمر في العمل ويُبلّغ عن عقده المتجاوزة للحد بدلاً من أن يُفشل النسخ الاحتياطي في منتصف الليل. أما إضافة عقدة جديدة فتظل متوقفة عند السقف.

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

الحدود الافتراضية

يعتمد حجم المستودع على مستوى الاستحقاق:

• Community: حتى 10 GB
• الخطط المدفوعة: حد الخطة أو العقد

الحدود الافتراضية للخطط المدفوعة:

الخطة	التراخيص العائمة	حجم المستودع	إصدارات تراخيص المستودع الشهرية	الافتراضي/الحد الأقصى لشهادة التفويض
Community	1	10 GB	100	15d / 30d
Professional	1	100 GB	2,000+	60d / 120d
Business	1	500 GB	5,000+	90d / 180d
Enterprise	مخصص	1 TB+	15,000+	120d / 365d

يمكن للحدود المحددة في العقد رفع هذه القيم أو خفضها لعميل محدد. كذلك تخضع صلاحية شهادة التفويض لحد أقصى صارم هو subscription.expiresAt + 3 day grace، مما يجعل الاشتراكات المدفوعة شهرياً تحصل تلقائياً على شهادات متوافقة مع دورة فوترتها. راجع سلسلة الترخيص والتفويض - سياسة الصلاحية للاطلاع على القواعد الكاملة.

الفترة التجريبية المجانية والعودة إلى Community

تبدأ الحسابات الجديدة بفترة تجريبية مجانية مدتها 14 يوماً على خطة Professional أو Business. يُطلَب رقم بطاقة ائتمان عند التسجيل، ولا يُخصم أول مبلغ إلا عند انتهاء الفترة التجريبية، لذا فإن الإلغاء قبل ذلك لا يُكلّف شيئاً. تتوفر فترة تجريبية واحدة لكل عميل.

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

يبقى التطبيق مرناً حيث يهم ذلك أكثر: تستمر المستودعات قيد التشغيل في العمل حتى بعد انتهاء الاشتراك (up وdown وdelete والبدء التلقائي). وفيما عدا ذلك تسري قاعدتان مختلفتان، والخلط بينهما هو ما يجعل مهلة الستين يوماً تبدو غير متسقة:

• العمليات التي تحتاج خادم الحساب لا يمكن أن تتم بدون اشتراك نشط، لأن الخادم يرفض التوقيع. وهي create وfork وأي تحديث أو تجديد للترخيص. فما إن ينقضي الاشتراك حتى يتوقف توفير أي شيء جديد.
• العمليات التي يكفيها ترخيص مثبَّت صالح تستمر في العمل حتى انتهاء الصلاحية الصعبة لذلك الترخيص، دون أي تدخل من الخادم. وهي resize وexpand على المستودعات التي تملكها فعلاً، ونقل النسخ الاحتياطية (push وpull والنسخ المجدولة). تنتهي الصلاحية الصعبة للترخيص الأساسي لأي مستودع بعد 60 يوماً من تاريخ انتهاء الاشتراك، ومن هنا تأتي مهلة الستين يوماً. أما ترخيص الفرع فعمره أقصر بكثير، بحد أقصى 7 أيام، ولهذا تعتمد الأجهزة كثيرة الفروع على التجديد الذاتي الموضَّح أدناه.

أي أن الاشتراك المنقضي يمنعك فوراً من توسيع أسطولك، ويمنعك بعد 60 يوماً من توسيع المستودعات التي فيه.

فترة السماح للهجرة الافتراضية

عندما تهاجر شركة الاستضافة جهازاً افتراضياً إلى أجهزة فيزيائية مختلفة، يتغير معرّف الجهاز (يُشتق من معرّفات الأجهزة مثل DMI UUID و/etc/machine-id وعناوين MAC بطاقات الشبكة). تراخيص المستودع مرتبطة بمعرّف الجهاز، لذا ستؤدي الهجرة عادةً إلى إبطال جميع التراخيص.

للتعامل مع هذا بشفافية، تشمل تراخيص المستودع فترة سماح 40 يوماً لمعرّف الجهاز. إذا لم يتطابق معرّف الجهاز لكن الترخيص صُدِر منذ أقل من 40 يوماً، فإن الترخيص لا يزال مقبولاً. بما أن التراخيص تُنعّش كل 30 يوماً، يربط التنعيش التالي تلقائياً بمعرّف الجهاز الجديد.

عملياً:

• تم هجرة الجهاز الافتراضي، تغير معرّف الجهاز: تستمر المستودعات في العمل (ضمن نافذة 40 يوماً)
• يُنعّش عملية rdc التالية الترخيص مع معرّف الجهاز الجديد
• لا تُتطلب أي تدخل يدوي
• تحقق من معرّف الجهاز وحالة الترخيص باستخدام rdc machine status <machine> --system --licenses

حسابات قناة Edge تعمل على خطة Community بضعف الحدود (مستودعات 20 GB، 200 عملية إعداد/شهر، جهازان). الخطط المدفوعة متاحة فقط على قناة Stable. راجع قنوات الإصدار للتفاصيل.

ما يحدث أثناء إنشاء المستودع وتشغيله وإيقافه وإعادة التشغيل

إنشاء المستودع وتفريعه

عند إنشاء مستودع أو تفريعه:

1. يضمن rdc توفر رمز الاشتراك الخاص بك (يُطلق مصادقة رمز الجهاز إذا لزم)
2. يُفعّل rdc رمز ترخيص مستودع مسبق من خادم الحساب (يتحقق الخادم من حصة فتحات الأجهزة وحدود الإصدارات الشهرية في هذه النقطة)
3. يُكتب ترخيص المستودع المسبق على الجهاز ويُتحقق منه محلياً (التوقيع ومعرّف الجهاز ومعرّف GUID للمستودع وانتهاء الصلاحية وحد الحجم)
4. بعد الإنشاء الناجح، يُعيد rdc إصدار ترخيص المستودع مع إثباتات هوية المستودع (UUID LUKS أو بصمة التخزين)

يُحتسب هذا الإصدار المدعوم بالحساب ضمن استخدامك الشهري لـإصدارات تراخيص المستودع. يحتوي كل ترخيص على البريد الإلكتروني واسم الشركة لصاحب الحساب، والذي يُسجَّل عند تحقق renet من الترخيص.

تشغيل المستودع وإيقافه وحذفه

يتحقق rdc من ترخيص المستودع المثبت على الجهاز لكنه يتخطى فحص انتهاء الصلاحية. لا يزال يتم التحقق من التوقيع ومعرّف الجهاز ومعرّف GUID للمستودع والهوية. لن يُحرم المستخدمون أبداً من تشغيل مستودعاتهم، حتى مع اشتراك منتهي الصلاحية.

تغيير حجم المستودع وتوسيعه

يُجري rdc تحققاً كاملاً من ترخيص المستودع بما في ذلك انتهاء الصلاحية وحدود الحجم.

إعادة تشغيل الجهاز والبدء التلقائي

يستخدم البدء التلقائي نفس قواعد rdc repo up: يُتخطى انتهاء الصلاحية، لذا تُعيد المستودعات التشغيل دائماً بحرية.

تستخدم تراخيص المستودع نموذج صلاحية طويل الأمد:

• refreshRecommendedAt هي نقطة التنعيش الناعمة
• hardExpiresAt هي نقطة الحظر

إذا كان ترخيص المستودع قديماً لكن قبل انتهاء الصلاحية الصعبة، يمكن لوقت التشغيل الاستمرار. بمجرد الوصول إلى انتهاء الصلاحية الصعبة، يجب على rdc تنعيشه لعمليات تغيير الحجم/التوسيع.

عمليات المستودع الأخرى

العمليات مثل سرد المستودعات وفحص معلومات المستودع والتحميل لا تتطلب أي تحقق من الترخيص.

التحقق من الحالة وتجديد التراخيص

تسجيل دخول بشري:

rdc subscription login

تسجيل دخول للأتمتة أو وكيل الذكاء الاصطناعي:

rdc subscription login --token "$REDIACC_TOKEN"

للبيئات غير التفاعلية، يُعدّ ضبط REDIACC_TOKEN أبسط خيار. يجب أن يكون نطاق الرمز محدوداً بعمليات الاشتراك وترخيص المستودع التي يحتاجها الوكيل.

عرض حالة الاشتراك المدعومة بالحساب:

rdc subscription status

عرض تفاصيل تفعيل الجهاز لجهاز واحد:

rdc subscription status -m hostinger

عرض تفاصيل ترخيص المستودع المثبت على جهاز واحد:

rdc subscription status -m hostinger

تنعيش ترخيص مستودع على جهاز:

rdc subscription refresh -m hostinger --repo my-app

يجب أن يُحَل مرجع --repo في تكوين rdc المحلي لديك. المستودع المكتشف على الجهاز لكن المفقود من التكوين المحلي يُرفض: يُبلَّغ عنه كإخفاق ولا يُصنَّف تلقائياً.

عند الاستخدام الأول، يمكن لعملية مستودع أو نسخ احتياطي مرخَّصة لا تجد ترخيص مستودع قابلاً للاستخدام أن تُطلق تفويضاً تلقائياً من الحساب. يطبع CLI عنوان URL للتفويض، ويحاول فتح المتصفح في المحطات التفاعلية، ويُعيد المحاولة مرةً واحدة بعد نجاح التفويض والإصدار.

في البيئات غير التفاعلية، لا ينتظر CLI موافقة المتصفح. بدلاً من ذلك، يطلب منك توفير رمز محدد النطاق باستخدام rdc subscription login --token ... أو REDIACC_TOKEN.

لإعداد الجهاز لأول مرة، راجع إعداد الجهاز.

التجديد الذاتي للتراخيص

كل ما سبق يفترض أنك جالس أمام لوحة المفاتيح. أما النسخ الاحتياطية المجدولة فلا أحد يجلس أمامها، ولهذه الحالة تحديداً وُجد التجديد الذاتي.

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

كيف يُجدد الجهاز دون أن يحمل رمزاً

كل ترخيص تُصدره Rediacc أو تُجدده يحمل renewalUrl، وهو العنوان الكامل لنقطة نهاية التجديد على خادم الحساب الذي وقّعه. يقرأ الجهاز ذلك العنوان من ترخيصه المثبَّت، فلا يحتاج أبداً إلى أن يُخبَر بمكان خادم حسابه.

ثم يُقدّم الجهاز الترخيص المثبَّت إلى تلك النقطة نفسها. الترخيص هو بيان اعتماده الخاص: فهو موقَّع، ويتحقق الخادم من ذلك التوقيع، ولا يدخل أي رمز API في العملية إطلاقاً. يُعيد الخادم ترخيصاً جديداً بنوافذ صلاحية جديدة، ويثبّته الجهاز ويعيد التحقق منه قبل أن يعتبر التجديد منتهياً.

التجديد عملية تشمل الجهاز كله:

sudo renet license renew

تُجمَّع المستودعات حسب الخادم الذي وقّعها، فالجهاز الذي يخدم كونَي حساب يتصل بكل منهما مرةً واحدة. ويمنع ملف قفل تشغيل تجديدين في الوقت نفسه، ويُوزّع --jitter أسطولاً من الأجهزة كانت لولاه ستستيقظ كلها عند رأس الساعة.

يرفض الخادم التجديد في ثلاث حالات، ولكل منها معنى مختلف:

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

الرفض لا يوقف التشغيل بأكمله أبداً. مستودع واحد منقضٍ لا يمنع تجديد بقية المستودعات على الجهاز نفسه.

النسخ الاحتياطية المجدولة تُجدد نفسها

كل وحدة نسخ احتياطي تكتبها Rediacc تُشغّل تجديداً أولاً:

ExecStartPre=-<renet> license renew --jitter 45s

علامة - في البداية تجعله بأفضل جهد ممكن عن قصد. فالتجديد المرفوض أو انقطاع الشبكة العابر أو وجود Renet Agent قديم لا يعرف الأمر بعد، يجب ألا يُسقط النسخ الاحتياطي نفسه أبداً. تعمل النسخة الاحتياطية، ويُجدَّد الترخيص في طريقها كلما أمكن.

عندما يُحظر النسخ الاحتياطي

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

rdc machine status <machine> --licenses

يعرض عمود backups القيمة BLOCKED مع السبب، وتُطبع المعلومة نفسها تحت الجدول كخطأ حتى لا تضيع بين ثلاثين مستودعاً. أما عمود renewed فيعرض كيف جرى آخر تجديد غير مُراقَب، بما في ذلك رمز الرفض من الخادم إن وُجد، وهو ما يدلك على ما إذا كان الحل مسألة فوترة أم مسألة شهادة محلية.

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

السلوك في وضع عدم الاتصال وانتهاء الصلاحية

يحدث التحقق من الترخيص محلياً على الجهاز. لا تحتاج البيئة قيد التشغيل إلى اتصال مباشر بخادم الحساب.

هذا يعني:

• لا تحتاج البيئة قيد التشغيل إلى اتصال حي بالحساب عند كل أمر
• يمكن لجميع المستودعات دائماً البدء والإيقاف والحذف حتى مع تراخيص منتهية الصلاحية، لن يُحرم المستخدمون أبداً من تشغيل مستودعاتهم الخاصة
• تتطلب عمليات التوفير (create وfork) ترخيص مستودع مسبق، وتتطلب عمليات النمو (resize وexpand) ترخيص مستودع صالح
• يجب استبدال تراخيص المستودع المنتهية الصلاحية حقاً قبل تغيير الحجم/التوسيع، إما عبر rdc من محطة عملك أو بأن يُجدد الجهاز نفسه
• تُتحقق توقيعات التراخيص مقابل مفتاح عمومي مُضمَّن، ولا يمكن تعطيل التحقق من التوقيع

سلوك الاسترداد

الاسترداد التلقائي محدود النطاق عمداً:

• missing: قد يُفوّض rdc وصول الحساب إذا لزم، ويُنعّش تراخيص المستودع دفعةً، ويُعيد المحاولة مرةً واحدة
• expired: قد يُنعّش rdc تراخيص المستودع دفعةً ويُعيد المحاولة مرةً واحدة
• machine_mismatch: يفشل بسرعة ويطلب منك إعادة الإصدار من سياق الجهاز الحالي
• repository_mismatch: يفشل بسرعة ويطلب منك تنعيش تراخيص المستودع صراحةً
• sequence_regression: يفشل بسرعة كمشكلة سلامة/حالة لترخيص المستودع
• invalid_signature: يفشل بسرعة كمشكلة سلامة/حالة لترخيص المستودع
• identity_mismatch: يفشل بسرعة، هوية المستودع لا تتطابق مع الترخيص المثبت
• cert_expired: يفشل بسرعة في عمليات النمو (create وfork وresize) وفي نقل النسخ الاحتياطي (push وpull)؛ يستمر عمل repo up والتشغيل التلقائي، بما يطابق نموذج انتهاء صلاحية الترخيص المرن. جدِّد شهادة التفويض
• cert_invalid: يفشل بسرعة، فشلت شهادة التفويض في تحقيق أحد القيود (توقيع مفتاح رئيسي سيئ، أو عدم تطابق الاشتراك/الخطة، أو تجاوز حد الحجم، أو تجاوز التسلسل لـ maxTotalIssuances). أعِد إصدار الشهادة بعد إصلاح الحد الأساسي

حالات الفشل السريع هذه لا تستهلك تلقائياً مكالمات تنعيش أو إصدار مدعومة بالحساب.

ملاحظتان عند قراءة هذه القائمة:

• missing ليست دائماً مشكلة. فهي أيضاً النتيجة الطبيعية أول مرة يُلمَس فيها مستودع داخل مخزن بيانات مُفرَّع حديثاً، وهي بالضبط ما يجعل ذلك التفريع يُحتسب: يُصدَر الترخيص، ويُطالَب بفتحة، وتستمر العملية. أما identity_mismatch فهي النقيض المقصود، حتى يفشل فوراً أي ملف ترخيص منسوخ من مخزن بيانات آخر بدلاً من إعادة إصداره بصمت.
• تصف هذه القائمة الاسترداد من محطة عملك. أما الجهاز الذي يُجدد نفسه فله نتائجه الخاصة، ويُبلَّغ عنها عبر rdc machine status <machine> --licenses بدلاً من إطلاقها كفشل في الأمر، لأن النسخة الاحتياطية المجدولة لا تجد أحداً تُخبره.

شهادات التفويض للتثبيت المحلي

لعمليات النشر المحلية والمعزولة عن الشبكة، يُصدر خادم الحساب الرئيسي شهادة تفويض تُخوّل تثبيتك المحلي بتوقيع التراخيص بمفتاح Ed25519 الخاص به. تُقيّد الشهادة التثبيت المحلي بحدود خطته وتُنشئ سلسلة مقاومة للتلاعب.

نقاط رئيسية لمالكي الاشتراكات:

• شهادة واحدة نشطة لكل اشتراك. يُطبّق كل تثبيت محلي حصص الأجهزة والشهر على دفتر الحسابات المحلي الخاص به، لذا فإن تعدد التثبيتات سيضاعف الحصة الفعلية دون إمكانية تسوية. العملاء الذين يحتاجون إلى إنتاج + اختبار + DR يجب عليهم شراء اشتراك واحد لكل تثبيت.
• صلاحية افتراضية حسب المستوى (15d / 60d / 90d / 120d) وحدود قصوى (30d / 120d / 180d / 365d) - راجع جدول الحدود أعلاه.
• إدارة ذاتية من بوابة العملاء. يمكن لمالكي ومديري المؤسسة إنشاء شهادات التفويض وتنعيشها وإلغاؤها على /account/delegation-certs. الصفحة مرئية لجميع العملاء بغض النظر عن مستوى الخطة - وتختلف فقط الحدود.
• التنعيش التلقائي مدعوم عبر تمهيد بنقرة واحدة يُصدر رمز api محدد النطاق بـ delegation:renew ليستخدمه التثبيت المحلي في مكالمات التنعيش الرئيسية.
• التنعيش المعزول عن الشبكة مدعوم عبر بيان طلب تنعيش موقَّع يُنزّله مدير التثبيت المحلي، وينقله غير متصل إلى الخادم الرئيسي، ويُعالجه الخادم الرئيسي لإصدار شهادة جديدة.

راجع تثبيت التثبيت المحلي - الترخيص لعمليات النشر المعزولة للإعداد التشغيلي، وسلسلة الترخيص والتفويض للتصميم التشفيري.

إصدارات تراخيص المستودع الشهرية

يَعدّ هذا المقياس نشاط إصدار ترخيص المستودع المدعوم بالحساب الناجح في شهر التقويم UTC الحالي.

يشمل:

• إصدار ترخيص المستودع لأول مرة
• تنعيش ترخيص المستودع الناجح الذي يُعيد ترخيصاً موقَّعاً جديداً

لا يشمل:

• إدخالات الدُفعة غير المتغيرة
• محاولات الإصدار الفاشلة
• المستودعات غير المتتبعة المرفوضة قبل الإصدار

إذا كنت بحاجة إلى عرض الاستخدام وسجل إصدار ترخيص المستودع الأخير للعملاء، استخدم بوابة الحساب. وإذا كنت بحاجة إلى فحص من جانب الجهاز، استخدم rdc subscription status -m وrdc subscription status -m.