ربط قاعدة بيانات العميل من المنصة

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

القرار التقني

لا تتصل المنصة مباشرة بروابط قواعد بيانات العملاء من الإنترنت. هذا غير مناسب لأن أغلب العملاء خلف NAT، وبعضهم لا يملك IP ثابت، وفتح منفذ قاعدة بيانات للإنترنت خطر حتى مع كلمة مرور قوية.

المسار الصحيح هو FR Connector:

1. يثبت العميل موصلاً صغيراً قرب قاعدة بياناته، على جهاز داخل شبكته أو في نفس بيئة Docker.
2. الموصل يفتح اتصال HTTPS صادراً طويل العمر إلى المنصة.
3. المنصة ترسل أوامر محددة للموصل، والموصل ينفذها محلياً على قاعدة العميل ويرجع النتيجة.
4. لا يحتاج العميل فتح منافذ واردة، ولا يحتاج IP ثابت أو دومين.

التفعيل والاشتراك

لا يوجد ترخيص برنامج أو مفتاح License داخل حاوية العميل. الاشتراك التجاري يبقى على حساب الشبكة في منصة FR، بينما الحاوية تستخدم رمز تسجيل لمرة واحدة صالحاً لمدة محدودة. بعد أول تشغيل تستبدله بتوكن عقدة وتحفظه في volume محلي، والمنصة تخزن hash فقط. يمكن للمالك تدوير التوكن أو إلغاؤه من مركز ربط الشبكة.

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

التثبيت من المنصة

1. يفتح المالك الشبكة > الكونيكتر والبيانات > تثبيت الكونيكتر.
2. يختار Docker أو حاوية MikroTik، ثم يحدد وضع البيانات.
3. يدخل عنوان MikroTik المحلي ومستخدم API محدود الصلاحيات. كلمة المرور تبقى في ملف .env.edge عند العميل ولا ترسل إلى المنصة.
4. يولد مفاتيح الحاوية ثم يصدر رمز الربط لمرة واحدة.
5. ينزل ملف البيئة وينفذ أوامر Docker المعروضة. في الوضع المحلي يضاف ملف PostgreSQL المنفصل تلقائياً داخل Docker network غير منشورة.
6. عند ظهور الحالة متصل يختبر الاتصال، ثم يعتمد نقل البيانات إذا اختار الوضع المحلي أو الهجين.

لماذا هذا آمن

• بيانات اتصال قاعدة العميل تبقى داخل جهاز العميل ولا تخزن في المنصة إلا إذا اختار العميل ذلك صراحة.
• كل موصل يسجل بتوكن إقران لمرة واحدة، ثم يأخذ توكن عقدة مخزناً محلياً؛ المنصة تخزن hash فقط وتدعم التدوير والإلغاء.
• المنصة لا ترسل SQL حر. ترسل أوامر typed/RPC مثل: listSubscribers, renewUser, createVoucherBatch.
• كل أمر مرتبط بصاحب شبكة وصلاحية مستخدم، وله سجل تدقيق.
• النسخ الاحتياطي اختياري ومشفر قبل الرفع، ويظهر للعميل متى آخر نسخة وحجمها وحالتها.

دعم قواعد بيانات مرنة

لا نجعل التطبيق الأساسي يتعامل مع كل لهجة SQL مباشرة. الموصل هو الذي يملك adapters:

• postgres كمسار أول لأنه نفس قاعدة النظام الحالية.
• mysql/mariadb للأنظمة القديمة أو الاستيراد المرحلي.
• adapters لاحقة حسب الطلب، بشرط تحويلها لنفس عقود FR الداخلية.

بهذا ما نعيد كتابة النظام بالكامل. نضيف طبقة اختيار مصدر البيانات تدريجياً:

TenantDataSource;
cloudManaged(clientId);
customerLocalDb(clientId);
hybridBackup(clientId);

الوحدات التشغيلية في v5 تعمل خلف هذا العقد: المشتركين والخطط والاشتراكات والكروت ونقاط البيع والمالية والشركاء والقوالب والتقارير والجلسات.

حالات التشغيل في v5

السحابة

• cloud_managed: الصفحات وRADIUS تستخدم PostgreSQL السحابي.
• Connector يدير MikroTik والرادار والنسخ فقط.

القاعدة المحلية

• customer_local_db: الصفحات تستدعي Typed RPC عبر Connector.
• يبدأ RADIUS المدة عند أول مصادقة صحيحة ويشغل الاشتراك المجدول محلياً.
• الانتقال يمر بحالات تجهيز واستيراد وتحقق ثم cutover صريح لسلطة البيانات.

الوضع الهجين

• hybrid_backup: سلطة البيانات محلية مع snapshots مشفرة اختيارية إلى S3.
• الرفع بروابط مؤقتة، مع احتفاظ وحذف واسترجاع وسجل تدقيق.

تبقى بيانات Control Plane في السحابة: حساب مالك الشبكة، اشتراك المنصة بالدولار، صلاحيات فريق المنصة، حالة Connector، أوامر الأجهزة، وسجل النسخ. أسرار قاعدة العميل وMikroTik لا تغادر Edge.

ما لا نفعله

• لا نطلب من العميل فتح منفذ PostgreSQL أو MySQL للإنترنت.
• لا نعتمد على IP ثابت.
• لا نخزن كلمة مرور قاعدة العميل في المتصفح.
• لا نسمح للمنصة بإرسال استعلامات SQL عشوائية.
• لا نعد بدعم كل قواعد البيانات دفعة واحدة؛ نبدأ بمسار ثابت ثم نضيف adapters.

ملاحظة للعميل

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