التغييرات في Edge for Private Cloud 4.53.01

نظرة عامة على التغييرات

أدخل الإصدار 4.53.01 من Edge for Private Cloud تغييرات متعدّدة تعمل على تحسين مستوى أمان المنصة، بما في ذلك إصدارات محدّثة من البرامج/المكتبات. تؤثر هذه التغييرات في ما يلي:

  • سياسة التحقّق من صحة OAS (مواصفات OpenAPI)
  • السياسات التي تتوافق مع طلبات بحث JSONPath
  • سياسة Java callout التي تعتمد على مكتبات متوقّفة نهائيًا
  • OpenLDAP

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

سياسة التحقّق من صحة OAS (مواصفات OpenAPI)

السياق

تتحقّق سياسة التحقّق من صحة OAS من صحة الطلبات أو الردود الواردة استنادًا إلى القواعد المحدّدة في مواصفات OpenAPI 3.0 (JSON أو YAML). يوفّر الإصدار 4.53.01 من Edge for Private Cloud تحسينات على سياسة OAS (مواصفات OpenAPI)، مع التركيز على التحقّق الأكثر صرامة ودقة من نص الردود من واجهة برمجة التطبيقات.

التغييرات

يقدّم الإصدار 4.53.01 من Edge for Private Cloud تغييرَين مهمَّين في طريقة تحقّق سياسة OAS من صحة ردود واجهة برمجة التطبيقات، ما يضمن توافقًا أكبر مع مواصفات OpenAPI:

  • السيناريو 1:
    • السلوك السابق: إذا كان مواصفات OpenAPI تتطلّب نص استجابة ولكن الاستجابة الفعلية من السياسة المستهدَفة أو سياسة المصدر لم تتضمّن نص استجابة، لن تصنّف السياسة ذلك على أنّه خطأ في التحقّق من الصحة.
    • السلوك الحالي: ستعرض السياسة الآن بشكل صحيح خطأ في التحقّق من الصحة (مثال: defines a response schema but no response body found) في هذا السيناريو، ما يشير إلى عدم تطابق بين الاستجابة المتوقّعة والفعلية.
  • السيناريو 2:
    • السلوك السابق: إذا كانت مواصفات OpenAPI تنصّ صراحةً على أنّه لا يُتوقّع أي نص استجابة، ولكن الاستجابة الفعلية من السياسة المستهدَفة أو المصدرية تتضمّن نصًا، لن تؤدي السياسة إلى حدوث خطأ.
    • السلوك الحالي: ستؤدي السياسة الآن إلى حدوث خطأ (مثال: No response body is expected but one was found) في هذا السيناريو، ما يضمن التزام الردود بشكل صارم بالمخطط المحدّد.

التخفيف من حدة المشكلة

تحديد أي وكلاء أو تدفقات مشتركة تم فيها ضبط سياسة التحقّق من صحة OAS باستخدام مجموعة علامات Source تم ضبطها على response أو تلك التي تتحقّق من صحة الردّ من أي سياسة أخرى تنشئ ردًا

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

  • إذا كان ملف مواصفات OAS يحدّد نص استجابة، يجب أن تقدّم الاستجابة من السياسة المستهدَفة أو سياسة المصدر دائمًا نصًا.
  • إذا لم يحدّد ملف مواصفات OAS نص ردّ، يجب ألا ترسل السياسة المستهدَفة أو سياسة المصدر نص ردّ.

عدِّل سياسة التحقّق من صحة مواصفات OpenAPI أو السلوك المستهدف حسب الحاجة قبل محاولة الترقية إلى Private Cloud 4.53.01. عليك أولاً التحقّق من صحة سير العمل المحدَّدة هذه في بيئات غير إنتاجية للحدّ من مخاطر حدوث انقطاعات أثناء ترقية مجموعة الإنتاج.

مسار JSON

السياق

أدخلت الإصدار 4.53.01 من Edge for Private Cloud تغييرات على طريقة استخدام تعبيرات مسار JSON في السياسات المختلفة. يمكن استخدام تعبيرات JSONPath في سياسات مثل سياسة ExtractVariable وسياسة RegularExpressionProtection وإخفاء البيانات لتحليل محتوى JSON أو تخزين القيم في متغيرات. يمكن أيضًا استخدام تعبيرات JSONPath في نماذج الرسائل العامة لاستبدال المتغيرات بالقيم بشكلٍ ديناميكي أثناء تنفيذ الخادم الوكيل. تتّبع تعبيرات JSONPath وتنسيقاتها الجديدة أحدث معايير تعبيرات JSON.

التغييرات

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

يتم استخدام إدخال json أدناه لشرح التغييرات:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. تغيير في سلوك حرف البدل [*] في JSONPath لقيم الكائنات

    تم تغيير سلوك حرف البدل [*] عند استخدامه للوصول إلى جميع القيم المباشرة لكائن JSON. في السابق، كانت الدالة $.object[*] تعرض القيم المباشرة مضمّنة في عنصر JSON واحد. باستخدام المكتبات المعدَّلة، أصبح الناتج الآن عبارة عن مصفوفة تحتوي على هذه القيم.

    على سبيل المثال، $.store[*]:

    السلوك السابق: 
    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
    آلية العمل الحالية: 
    [
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
    الإجراء:

    غيِّر تعبير JSONPath لاستهداف العنصر الرئيسي فقط (مثال: $.store) لاستهداف العناصر التي تم استردادها سابقًا بشكل مباشر.

  2. تتسبب النقطة الأخيرة (.) في مسارات JSONPath في حدوث خطأ

    يتم التحقّق من صحة تعبيرات JSONPath بشكل أكثر صرامة. في السابق، كان يتم تجاهل المسارات التي تنتهي بنقطة لاحقة غير صالحة (مثال: $.path.to.element.) بدون إشعار، وكان طلب البحث يعرض نتيجة إذا كان جزء المسار الصالح السابق يتطابق مع طلب البحث. باستخدام الإصدار الجديد، يتم الآن تحديد هذه المسارات غير الصالحة بشكل صحيح وسيؤدي ذلك إلى حدوث خطأ.

    على سبيل المثال، $.store.book.

    السلوك السابق: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    آلية العمل الحالية: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    ستتعذّر الآن أي سياسات حالية تستخدم تعبيرات JSONPath مع نقطة لاحقة غير مقصودة مع ظهور الخطأ InvalidPathException.

    الإجراء:

    أزِل النقطة الأخيرة من أي تعبير JSONPath ينتهي بنقطة. على سبيل المثال، غيِّر $.store.book. إلى $.store.book.

  3. تغيير بنية إخراج (..) في عملية البحث المتكرّر في JSONPath

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

    على سبيل المثال، $..book

    السلوك السابق: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
    آلية العمل الحالية: 
    [
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
    الإجراء:

    عدِّل منطق المعالجة النهائية ليراعي بنية المصفوفة المتداخلة الجديدة. من المحتمل أنّك ستحتاج إلى تكرار JSONArray الخارجي ثم تكرار كل JSONArray داخلي للوصول إلى العناصر الفردية.

  4. فهرسة JSONPath بعد اختيار عناصر متعددة أو فلتر يعرض مصفوفة فارغة

    هناك تغيير في السلوك عند تطبيق فهرس (مثال: [0]) مباشرةً بعد أداة اختيار عناصر متعدّدة (مثل [*]) أو فلتر ([?(condition)]). في السابق، كانت هذه التعبيرات تحاول اختيار العنصر في الفهرس المحدّد من النتائج المدمَجة. باستخدام الإصدار الجديد، ستعرض هذه التعبيرات الآن مصفوفة فارغة ([]).

    على سبيل المثال، $.store.book[*][0]

    السلوك السابق: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    آلية العمل الحالية: 
    []
    الإجراء:

    إذا كانت هناك حاجة إلى فلترة مجموعة ثم الحصول على عنصر معيّن من المجموعة التي تمّت فلترتها، يمكنك معالجة المصفوفة التي تمّت فلترتها والتي تمّ إرجاعها بواسطة JSONPath، على سبيل المثال $..book[?(@.category == 'fiction')]، ثمّ الحصول على [0] من النتيجة السابقة.

  5. تغيير في إخراج تقسيم المصفوفة السلبي في JSONPath

    عدّلت النسخة الجديدة سلوك تقسيم المصفوفات السلبي (مثال: [-2:], [-1:]). في السابق، عند تطبيق تقسيم سلبي على مصفوفة (يشير إلى عناصر من نهاية المصفوفة)، كانت النسخة القديمة تعرض بشكل غير صحيح عنصرًا واحدًا فقط من هذا التقسيم. يعرض الإصدار الجديد الآن بشكل صحيح قائمة (مصفوفة) تحتوي على جميع العناصر التي تقع ضمن النطاق السلبي المحدّد.

    على سبيل المثال $.store.book[-2:]

    السلوك السابق: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    آلية العمل الحالية: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    الإجراء:

    يجب الآن تعديل منطق المعالجة النهائية لتكرار مصفوفة JSON التي تم إرجاعها للحصول على الناتج المطلوب.

  6. نقطة سابقة أكثر صرامة في JSONPath

    يتم تطبيق قواعد أكثر صرامة على صيغة العناصر التي يتم الوصول إليها مباشرةً من الجذر. عند الوصول إلى العناصر مباشرةً من الجذر بدون نقطة سابقة (مثال: $propertyelement)، يتم الآن اعتبار هذه البنية خطأً وستمنع نشر الخادم الوكيل.

    على سبيل المثال $store،

    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}

    آلية العمل الحالية:

    Proxy will fail to deploy.

    الإجراء:

    غيِّر JSONPath لتضمين النقطة: $.propertyName (مثال: $.store). سيؤدي ذلك إلى استهداف القيمة واستردادها بشكل صحيح.

  7. تعبيرات JSONPath الديناميكية

    انتبه جيدًا إلى السياسات التي يتم فيها توفير تعبير JSONPath نفسه من خلال متغيّر (مثال: {myJsonPathVariable} أو {dynamicPath}). يجب أيضًا التحقّق من قيمة هذه المتغيّرات مقارنةً بالتغييرات المحتملة في السلوك الموضّحة أعلاه.

التخفيف من حدة المشكلة

وللحدّ من ذلك، من الضروري وضع استراتيجية شاملة. تتضمّن هذه العملية تحديد مسار التحديث المناسب وتطبيق الإصلاح اللازم لتعبيرات JSONPath غير الصالحة.

اختَر طريقة ترقية النظام الأنسب لك:

  • Zero Downtime Migration

    تتضمّن هذه الاستراتيجية توفير بيئة جديدة واحدة أو أكثر لتتمكّن من ربط عُقد معالجة الرسائل المنفصلة بها. يمكن ضبط عُقد معالجة الرسائل هذه لتثبيت الإصدار 4.53.01 واستخدام وكلاء مع تعبيرات JSONPath الحديثة. يمكن استخدامها أثناء الترقية ويمكن إيقافها نهائيًا بعد اكتمال الترقية. هذه الاستراتيجية سلسة ولكنّها تتضمّن توفير عُقد إضافية لمعالجة الرسائل بشكل مؤقت من أجل إتاحة الترقية بسلاسة. يمكنك الاطّلاع على التفاصيل أدناه:

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

    تتضمّن هذه الاستراتيجية الحصول على وقت تعذُّر الوصول إلى خوادم وكيل API باستخدام تعبيرات JSON Path خاطئة. ولا يتطلّب ذلك توفير عُقد إضافية لمعالجة الرسائل، ولكنّه يؤدي إلى تعطيل حركة بيانات واجهة برمجة التطبيقات للوكلاء المتأثّرين.

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

    يمكنك إعادة تصميم الخادم الوكيل نفسه قبل الترقية إلى Edge for Private Cloud 4.53.01. بدلاً من الاعتماد على تعبيرات مسار JSON معيّنة، يمكنك الحصول على النتيجة نفسها باستخدام طريقة مختلفة.

    على سبيل المثال، إذا كنت تستخدم سياسة "استخراج المتغيّر" مع مسار JSON، يمكنك استبدال السياسة بسياسة Javascript تستخرج بيانات مشابهة قبل الترقية إلى الإصدار الأحدث. بعد اكتمال الترقية، يمكنك إعادة ضبط الخادم الوكيل لاستخدام مسارات JSON مع تنسيقات أحدث.

تغييرات JavaCallout

السياق

كانت الإصدارات 4.53.00 والإصدارات الأقدم من Edge for Private Cloud تتضمّن دليلًا باسم deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) يحتوي على مجموعة من مكتبات JAR. كانت هذه المكتبات متاحة للاستخدام في رمز Java البرمجي في سياسة JavaCallout، وكان من الممكن أن يستخدمها رمز Java البرمجي المخصّص بشكل مباشر أو غير مباشر.

التغييرات

تمت الآن إزالة الدليل الذي تم إيقافه نهائيًا في Edge للإصدار 4.53.01 من السحابة الخاصة. في حال كان رمز Java يعتمد على هذه المكتبات، ستتعذّر الوكلاء الذين يستخدمون عمليات استدعاء Java هذه عند ترقية معالجات الرسائل إلى الإصدار 4.53.01. لتجنُّب حدوث مثل هذه الأعطال، اتّبِع خطوات التخفيف أدناه قبل ترقية معالجات الرسائل إلى الإصدار 4.53.01.

التخفيف من حدة المشكلة

  1. راجِع سياسات Java-Callout وملفات jar المرتبطة بها وحدِّد ما إذا كان أيّ منها يشير إلى أي مكتبات متوفرة في الدليل "deprecated" أو يستخدمها في معالِجات الرسائل الحالية. يُرجى العِلم أنّ عمليات الربط الخارجية بلغة Java قد تستخدم ملفات JAR تم تحميلها كموارد على مستوى المؤسسة أو البيئة. ننصحك بالاطّلاع على هذه المكتبات أيضًا.
  2. بعد تحديد هذه المكتبات المتوقّفة نهائيًا، يمكنك اتّباع إحدى الطرق أدناه للحدّ من المشكلة.
    • وضع الموارد (يُنصح به إذا كان لديك عدد صغير من ملفات JAR أو المكتبات من الدليل المتوقّف نهائيًا التي تشير إليها ملفات JAR الخاصة بـ Java-Callout)
      • حمِّل ملفات JAR التي تم تحديدها على أنّها متوقّفة نهائيًا كمورد على المستوى المطلوب: مراجعة خادم وكيل واجهة برمجة التطبيقات أو البيئة أو المؤسسة.
      • واصِل ترقية برامج Apigee كالمعتاد.
    • الموضع اليدوي (يُنصح به إذا كان لديك عدد كبير من ملفات JAR أو المكتبات التي تشير إليها ملفات JAR الخاصة بـ Java-Callout)
      • في كل عقدة لمعالجة الرسائل، أنشئ دليلاً جديدًا باسم external-lib في المسار $APIGEE_ROOT/data/edge-message-processor/.
      • انسخ ملفات JAR المحدّدة إلى دليل external-lib هذا من الدليل المتوقّف نهائيًا: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • تأكَّد من أنّ دليل ملفات JAR الأساسية يمكن قراءته من قِبل مستخدم Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • واصِل ترقية برامج Apigee كالمعتاد.

تغيير OpenLDAP

السياق

يمكن استخدام OpenLDAP في Edge Private Cloud للمصادقة والتفويض. في الإصدار 4.53.01 من Edge for Private Cloud، تمت ترقية برنامج OpenLDAP الذي توفّره Apigee من الإصدار 2.4 إلى الإصدار 2.6.

التغييرات

في OpenLDAP 2.6، يقتصر الاسم المميز النسبي (RDN) على 241 بايت/حرف تقريبًا. هذا الحدّ الأقصى إلزامي ولا يمكن تعديله.

التأثير
  • تحدث حالات تعذُّر النسخ المتماثل أو الاستيراد للإدخالات التي تحتوي على أسماء مميّزة نسبية كبيرة جدًا.
  • قد تؤدي محاولة إنشاء عناصر، مثل المؤسسات والبيئات والأدوار المخصّصة والأذونات وما إلى ذلك، إلى ظهور رسالة الخطأ: "message": "[LDAP: error code 80 - Other]".
  • سيتأثر أي اسم مميّز أطول من 241 بايت في LDAP من Apigee. ستمنع أسماء DN هذه ترقية برنامج Apigee OpenLDAP بنجاح، وسيكون عليك اتّباع استراتيجيات التخفيف من حدة المشاكل لهذه العناصر قبل المتابعة في عملية الترقية.

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

على سبيل المثال: 

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

عادةً، يكون لديك أسماء مؤسسات وبيئات وأدوار بأطوال تؤدي إلى أن تكون أسماء RDN في LDAP أصغر من 241 بايت.

التخفيف من حدة المشكلة

قبل الترقية إلى الإصدار 4.53.01:

ستساعدك الخطوات التالية في التحقّق من توفّر أسماء مميّزة نسبية طويلة في مجموعة LDAP 2.4 الحالية.

الخطوة 1: استخراج بيانات LDAP

استخدِم الأمر ldapsearch للعثور على الاسم المميز (dn) وإعادة توجيه الناتج إلى ملف: 

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

تأكَّد من أنّ ملف DN.ldif أعلاه يحتوي على إدخالات LDAP.

‫2- تحديد أسماء RDN الطويلة

ابحث عن أسماء RDN التي تتجاوز 241 بايت/حرف من ملف DN.ldif أعلاه:

cat /tmp/DN.ldif |  grep '^dn:' | gawk -F',|dn: ' '{ rdn = $2; char_count = length(rdn); cmd = "echo -n \"" rdn "\" | wc -c"; cmd | getline byte_count; close(cmd); if (char_count > 241 || byte_count > 241) { print rdn, "(chars: " char_count ") (bytes: " byte_count ")"; }}'
o=VeryLongOrgNameWithMoreThan241Chars.... (chars: 245) (bytes: 245)
cn=VeryLongCustomRoleNameWithMoreThan241Chars.... (chars: 258) (bytes: 258)

إذا لم ينتج عن الأمر أعلاه أي ناتج، يعني ذلك أنّه لا تتجاوز أي أسماء مميزة نسبية في إعداد LDAP الحالي 241 بايت/حرف. يمكنك المتابعة وإجراء الترقية كالمعتاد.

إذا كان الأمر أعلاه يؤدي إلى إنشاء ناتج، يشير ذلك إلى توفّر أسماء مميّزة نسبية تتجاوز 241 بايت/حرف. بالنسبة إلى هذه العناصر، اتّبِع خطوات التخفيف كما هو موضّح في الخطوة 3 قبل المتابعة في ترقية Edge for Private Cloud 4.53.01.

‫3- التعامل مع أسماء الموارد المحددة الطويلة

إذا تم تلقّي الناتج من الخطوة رقم 2، يشير ذلك إلى توفّر أسماء مميّزة نسبية تتجاوز 241 بايت/حرفًا، ويجب اتّباع خطوات التخفيف أدناه:

راجِع إدخالات LDAP التي تتجاوز 241 بايت.

  • إذا كان اسم الدور المخصّص أو التطبيق أو منتج واجهة برمجة التطبيقات أو الكيانات الأخرى هو العامل الأساسي الذي يتسبّب في أن يكون اسم RDN طويلاً، يمكنك الانتقال إلى استخدام كيان بديل باسم أقصر.
  • إذا كان اسم المؤسسة أو اسم البيئة هو المساهم الأساسي في طول الاسم المميز النسبي، عليك نقل البيانات إلى مؤسسة أو بيئة أخرى باسم أقصر.

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

تغييرات موفّر التشفير

السياق

هذا التغيير هو نتيجة من الإصدار 4.53.00 من Edge for Private Cloud. في الإصدار 4.53.00 من Edge for Private Cloud، تم تعديل موفِّر التشفير الداخلي من Bouncy Castle (BC) إلى Bouncy Castle FIPS (BCFIPS) لإتاحة التوافق مع معيار FIPS.

التغييرات

إذا كانت سياسات JavaCallout تعتمد على استخدام موفّر BC الأصلي، خاصةً عند استخدام وظائف الأمان التي تم تحسينها في موفّر BCFIPS (على سبيل المثال، استخدام زوج مفاتيح مشترك لكل من التشفير والتوقيع)، يجب تحديث سياسات JavaCallout هذه. قد تتعذّر سياسات JavaCallout التي تحاول تحميل موفّر التشفير Bouncy Castle باستخدام الاسم BC لأنّ الموفّر التلقائي قد تغيّر. وقد تتعطّل هذه السياسات التي تستخدم موفِّر BC لاحقًا. لن يعود بإمكانك الوصول إلى أي عمليات تنفيذ مخصّصة تعتمد على موفّر BC القديم، وسيكون عليك مراجعتها وإعادة تنفيذها.

التخفيف من حدة المشكلة

الحل البديل المقترَح هو استخدام موفّر BCFIPS. يجب مراجعة عمليات تنفيذ JavaCallout المخصّصة التي كانت تعتمد على موفّر الخدمة القديم وإعادة تنفيذها باستخدام موفّر خدمة Bouncy Castle FIPS، الذي يمكن الوصول إليه باستخدام السلسلة "BCFIPS".

أداة رصد التغييرات المبرمَجة

من المقرّر طرح أداة لرصد التغييرات قريبًا. ستتمكّن هذه الأداة من فحص وتحديد خوادم وكيل واجهة برمجة التطبيقات، والتدفقات المشترَكة، والموارد، وأسماء RDN في LDAP التي قد تتأثّر بالتغييرات المختلفة الموضّحة في هذه المقالة. من المفترض أن تساعد هذه الأداة في تحديد الكيانات المختلفة المعرَّضة للفشل أثناء الترقية إلى الإصدار 4.53.01 من Edge for Private Cloud أو بعدها.