Edge for Private Cloud 4.53.01 में हुए बदलाव

बदलावों की खास जानकारी

Edge for Private Cloud 4.53.01 में कई बदलाव किए गए हैं. इससे प्लैटफ़ॉर्म की सुरक्षा बेहतर हुई है. साथ ही, इसमें सॉफ़्टवेयर/लाइब्रेरी के अपडेट किए गए वर्शन शामिल किए गए हैं. इन बदलावों का असर इन पर पड़ेगा:

  • OAS (OpenAPI स्पेसिफ़िकेशन) की पुष्टि करने की नीति
  • ऐसी नीतियां जिनमें JSONPath क्वेरी का इस्तेमाल किया जा सकता है
  • बंद हो चुकी लाइब्रेरी पर निर्भर Java कॉलआउट नीति
  • OpenLDAP

इस सेक्शन में, वर्शन 4.53.01 में किए गए अलग-अलग बदलावों के बारे में बताया गया है. अपग्रेड करने के दौरान या बाद में, इन बदलावों की वजह से आपके वर्कफ़्लो में रुकावट आ सकती है. इसमें संभावित समस्याओं की पहचान करने के तरीके और उन्हें कम करने या उनसे बचने के तरीके भी शामिल हैं.

OAS (OpenAPI स्पेसिफ़िकेशन) की पुष्टि करने की नीति

कॉन्टेक्स्ट

OAS की पुष्टि करने की नीति, OpenAPI 3.0 स्पेसिफ़िकेशन (JSON या YAML) में तय किए गए नियमों के हिसाब से, आने वाले अनुरोधों या जवाबों की पुष्टि करती है. Edge for Private Cloud 4.53.01 में, OAS (OpenAPI स्पेसिफ़िकेशन) नीति को बेहतर बनाया गया है. इसमें एपीआई रिस्पॉन्स बॉडी की पुष्टि को ज़्यादा सटीक और सख्त बनाया गया है.

बदलाव

Edge for Private Cloud 4.53.01 में, OAS नीति के ज़रिए एपीआई से मिले जवाबों की पुष्टि करने के तरीके में दो अहम बदलाव किए गए हैं. इससे यह पक्का किया जा सकेगा कि आपके OpenAPI स्पेसिफ़िकेशन के साथ बेहतर तरीके से काम किया जा सके:

  • पहला विकल्प:
    • पिछला व्यवहार: अगर आपके OpenAPI स्पेसिफ़िकेशन में जवाब के मुख्य भाग की ज़रूरत होती थी, लेकिन टारगेट या अपस्ट्रीम नीति से मिले जवाब में वह शामिल नहीं था, तो नीति इसे पुष्टि करने से जुड़ी गड़बड़ी के तौर पर फ़्लैग नहीं करती थी.
    • मौजूदा तरीका: इस स्थिति में, नीति अब पुष्टि करने से जुड़ी गड़बड़ी (उदाहरण: defines a response schema but no response body found) को सही तरीके से दिखाएगी. इससे पता चलेगा कि अनुमानित और असल जवाब मेल नहीं खाते.
  • दूसरी स्थिति:
    • पिछला तरीका: अगर आपके OpenAPI स्पेसिफ़िकेशन में साफ़ तौर पर बताया गया था कि जवाब के मुख्य हिस्से की ज़रूरत नहीं है, लेकिन टारगेट या अपस्ट्रीम नीति से मिले जवाब में मुख्य हिस्सा शामिल था, तो नीति का पालन न करने से जुड़ी समस्या नहीं होती थी.
    • मौजूदा तरीका: इस मामले में, नीति का पालन न करने पर अब गड़बड़ी (उदाहरण: No response body is expected but one was found) दिखेगी. इससे यह पक्का किया जा सकेगा कि जवाब, तय किए गए स्कीमा के मुताबिक ही हों.

गड़बड़ी की गंभीरता को कम करना

उन सभी प्रॉक्सी या शेयर किए गए फ़्लो की पहचान करें जिनमें OAS की पुष्टि करने वाली नीति को Source टैग के साथ कॉन्फ़िगर किया गया है. इस टैग को response पर सेट किया गया है. इसके अलावा, उन प्रॉक्सी या शेयर किए गए फ़्लो की पहचान करें जो जवाब जनरेट करने वाली किसी अन्य नीति से मिले जवाब की पुष्टि करते हैं.

प्रॉक्सी/शेयर किए गए फ़्लो की पहचान होने के बाद, पक्का करें कि जवाब और ओएएस स्पेसिफ़िकेशन एक जैसे हों. जवाब, जवाब के मुख्य हिस्से के मौजूद होने या न होने के बारे में, OpenAPI स्पेसिफ़िकेशन के मुताबिक होना चाहिए. अपने ट्रैफ़िक पैटर्न की समीक्षा करने के लिए, Apigee के स्टैंडर्ड ट्रेस का इस्तेमाल किया जा सकता है. अगर टारगेट कभी-कभी रिस्पॉन्स देता है, तो ओएएस नीति से पहले इसकी पुष्टि करने के लिए अन्य नीतियों का इस्तेमाल करें

  • अगर आपकी ओएएस स्पेसिफ़िकेशन फ़ाइल में रिस्पॉन्स बॉडी तय की गई है, तो टारगेट या अपस्ट्रीम नीति से मिलने वाले जवाब में हमेशा एक रिस्पॉन्स बॉडी होनी चाहिए.
  • अगर आपकी ओएएस स्पेसिफ़िकेशन फ़ाइल में रिस्पॉन्स बॉडी के बारे में नहीं बताया गया है, तो टारगेट या अपस्ट्रीम नीति को रिस्पॉन्स बॉडी नहीं भेजनी चाहिए.

Private Cloud 4.53.01 पर अपग्रेड करने से पहले, OAS की पुष्टि करने की नीति या अपने टारगेट व्यवहार को ज़रूरत के मुताबिक अपडेट करें. आपको सबसे पहले अपने नॉन-प्रोडक्शन एनवायरमेंट में, ऐसे वर्कफ़्लो की पुष्टि करनी चाहिए. इससे प्रोडक्शन क्लस्टर को अपग्रेड करने के दौरान होने वाली रुकावटों के जोखिम को कम किया जा सकेगा.

JSON पाथ

कॉन्टेक्स्ट

Edge for Private Cloud 4.53.01 में, JSON पाथ एक्सप्रेशन को अलग-अलग नीतियों में इस्तेमाल करने के तरीके में बदलाव किए गए हैं. JSON कॉन्टेंट को पार्स करने या वैरिएबल में वैल्यू सेव करने के लिए, JSONPath एक्सप्रेशन का इस्तेमाल ExtractVariable नीति, RegularExpressionProtection नीति, डेटा मास्किंग जैसी नीतियों में किया जा सकता है. JSONPath एक्सप्रेशन का इस्तेमाल, सामान्य मैसेज टेंप्लेटिंग में भी किया जा सकता है. इससे प्रॉक्सी के एक्ज़ीक्यूशन के दौरान, वैरिएबल को वैल्यू से डाइनैमिक तरीके से बदला जा सकता है. नए JSONPath एक्सप्रेशन और फ़ॉर्मैट, JSON एक्सप्रेशन के नए स्टैंडर्ड के मुताबिक हैं.

बदलाव

यह ज़रूरी है कि आप उन नीतियों के लिए मौजूदा एपीआई प्रॉक्सी/शेयर्ड फ़्लो की समीक्षा करें जो JSONPath एक्सप्रेशन का इस्तेमाल करती हैं. इसमें Extract Variables नीति, Regular Expression Protection नीति या 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 इंडेक्सिंग से खाली कलेक्शन मिलता है

    मल्टी-आइटम सिलेक्टर (जैसे कि [*]) या फ़िल्टर ([?(condition)]) के तुरंत बाद इंडेक्स (उदाहरण: [0]) लागू करने पर, नतीजे अलग-अलग दिखते हैं. इससे पहले, इस तरह के एक्सप्रेशन से, मिले-जुले नतीजों में से तय किए गए इंडेक्स पर मौजूद आइटम को चुना जाता था. नए वर्शन में, ये एक्सप्रेशन अब खाली कलेक्शन ([]) दिखाएंगे.

    उदाहरण के लिए, $.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 एक्सप्रेशन को ठीक करने के लिए ज़रूरी बदलाव करना शामिल है.

अपग्रेड करने का वह तरीका चुनें जो आपके लिए सबसे सही हो:

  • बिना किसी डाउनटाइम के माइग्रेशन

    इस रणनीति में, एक या उससे ज़्यादा नए एनवायरमेंट हासिल करना शामिल है, ताकि आप अलग-अलग मैसेज प्रोसेसर नोड को इससे कनेक्ट कर सकें. ऐसे मैसेज प्रोसेसर नोड को 4.53.01 वर्शन इंस्टॉल करने के लिए सेट किया जा सकता है. साथ ही, इनमें मॉडर्न JSONPath एक्सप्रेशन वाली प्रॉक्सी होती हैं. इनका इस्तेमाल अपग्रेड के दौरान किया जा सकता है. अपग्रेड पूरा होने के बाद, इन्हें बंद किया जा सकता है. यह रणनीति बिना किसी रुकावट के काम करती है. हालांकि, इसमें अपग्रेड को आसानी से पूरा करने के लिए, कुछ समय के लिए मैसेज-प्रोसेसर के अतिरिक्त नोड हासिल करने पड़ते हैं. इसकी जानकारी यहां दी गई है:

    • एक नया एनवायरमेंट बनाएं. इसके बाद, इस नए एनवायरमेंट में वर्शन 4.53.01 के नए मैसेज-प्रोसेसर नोड जोड़ें.
    • जिन प्रॉक्सी पर असर पड़ा है उनके लिए, नए एनवायरमेंट में प्रॉक्सी बंडल अपलोड करें. साथ ही, समस्या हल करने के सेक्शन में बताए गए ज़रूरी सुधार लागू करें और अपडेट किए गए प्रॉक्सी बंडल को नए एनवायरमेंट में डिप्लॉय करें.
    • ट्रैफ़िक को नए एनवायरमेंट पर रीडायरेक्ट करें और पुराने एनवायरमेंट से उन प्रॉक्सी को अन-डिप्लॉय करें जिन पर असर पड़ा है.
    • ओरिजनल मैसेज प्रोसेसर नोड को 4.53.01 पर अपग्रेड करें. उन प्रॉक्सी को डिप्लॉय करें जिनमें ओरिजनल एनवायरमेंट में JSONPath से जुड़ी समस्याओं को ठीक किया गया हो.
    • ट्रैफ़िक को वापस पुराने एनवायरमेंट पर स्विच करें. इसमें अब 4.53.01 वर्शन वाले मैसेज प्रोसेसर और नई jsonpath एक्सप्रेशन के लिए अपडेट किया गया प्रॉक्सी है.
    • नए एनवायरमेंट और उससे जुड़े नोड को मिटाएं और बंद करें.
  • डाउनटाइम और अपग्रेड

    इस रणनीति में, गलत JSON पाथ एक्सप्रेशन का इस्तेमाल करके एपीआई प्रॉक्सी के लिए डाउनटाइम हासिल करना शामिल है. इसके लिए, अतिरिक्त मैसेज प्रोसेसर नोड खरीदने की ज़रूरत नहीं होती. हालांकि, इससे उन प्रॉक्सी के लिए एपीआई ट्रैफ़िक में रुकावट आती है जिन पर असर पड़ा है.

    • उन प्रॉक्सी की पहचान करें जिन पर नीतियों का असर पड़ा है. साथ ही, उन सभी प्रॉक्सी के लिए नया वर्शन जनरेट करें.
    • ज़रूरी सुधार करें. इसके लिए, प्रॉक्सी के नए वर्शन में समस्या हल करने वाले सेक्शन में बताए गए सुधारों को लागू करें. इसे अभी डिप्लॉय न करें.
    • जिन प्रॉक्सी पर असर पड़ा है उनके लिए डाउनटाइम का पता लगाएं.
    • निजी क्लाउड वर्शन 4.53.01 के लिए, सभी मैसेज प्रोसेसर को Edge में अपग्रेड करें. ध्यान दें कि अपग्रेड किए गए नए मैसेज प्रोसेसर पर, मौजूदा प्रॉक्सी काम नहीं कर सकती हैं.
    • सभी मैसेज प्रोसेसर को Edge for Private Cloud के वर्शन 4.53.01 पर अपग्रेड करने के बाद , JSONPath एक्सप्रेशन को ठीक करके बनाई गई प्रॉक्सी के नए वर्शन को डिप्लॉय करें.
    • ऐसी प्रॉक्सी पर ट्रैफ़िक फिर से शुरू करें.
  • अपग्रेड करने से पहले प्रॉक्सी को फिर से डिज़ाइन करना

    Edge for Private Cloud 4.53.01 पर अपग्रेड करने से पहले, प्रॉक्सी को फिर से डिज़ाइन किया जा सकता है. किसी खास JSON पाथ एक्सप्रेशन पर भरोसा करने के बजाय, किसी दूसरे तरीके का इस्तेमाल करके भी वही नतीजा पाया जा सकता है.

    उदाहरण के लिए, अगर JSON पाथ के साथ Extract Variable Policy का इस्तेमाल किया जा रहा है, तो इस नीति को Javascript नीति से बदला जा सकता है. इससे नए वर्शन पर अपग्रेड करने से पहले, मिलता-जुलता डेटा निकाला जा सकता है. अपग्रेड पूरा होने के बाद, प्रॉक्सी को नए फ़ॉर्मैट के साथ JSON पाथ का इस्तेमाल करने के लिए वापस बदला जा सकता है.

JavaCallout में बदलाव

कॉन्टेक्स्ट

Edge for Private Cloud 4.53.00 और इससे पहले के वर्शन में, deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) नाम की एक डायरेक्ट्री होती थी. इसमें कई JAR लाइब्रेरी होती थीं. इन लाइब्रेरी का इस्तेमाल, JavaCallout नीति में Java कोड के लिए किया जा सकता था. साथ ही, इनका इस्तेमाल आपके कस्टम Java कोड से सीधे या किसी और तरीके से किया जा सकता था.

बदलाव

Edge for Private Cloud के वर्शन 4.53.01 में, सेवा में नहीं है डायरेक्ट्री को हटा दिया गया है. अगर आपका Java कोड ऐसी लाइब्रेरी पर निर्भर करता है, तो Java कॉलआउट का इस्तेमाल करने वाली प्रॉक्सी काम नहीं करेंगी. ऐसा तब होगा, जब मैसेज प्रोसेसर को 4.53.01 वर्शन पर अपग्रेड किया जाएगा. इस तरह की समस्याओं से बचने के लिए, मैसेज-प्रोसेसर को वर्शन 4.53.01 पर अपग्रेड करने से पहले, यहां दिया गया तरीका अपनाएं.

गड़बड़ी की गंभीरता को कम करना

  1. Java-Callout की अपनी नीतियों और उनसे जुड़ी जार फ़ाइलों की समीक्षा करें. साथ ही, यह पता लगाएं कि क्या उनमें से कोई भी, आपके मौजूदा मैसेज-प्रोसेसर की “deprecated” डायरेक्ट्री में मौजूद किसी लाइब्रेरी का रेफ़रंस देता है या उसका इस्तेमाल करता है. ध्यान दें कि Java कॉलआउट, संगठन या एनवायरमेंट लेवल पर अपलोड किए गए जार को संसाधन के तौर पर इस्तेमाल कर सकते हैं. इन लाइब्रेरी का भी इस्तेमाल किया जा सकता है.
  2. ऐसी बंद की गई लाइब्रेरी की पहचान करने के बाद , समस्या को कम करने के लिए इनमें से कोई एक तरीका अपनाया जा सकता है.
    • संसाधन प्लेसमेंट (अगर आपके पास बंद की गई डायरेक्ट्री से कुछ जार / लाइब्रेरी हैं जिन्हें Java-Callout जार से रेफ़र किया जा रहा है, तो इसका सुझाव दिया जाता है)
      • पहचान किए गए बंद किए गए जार को, संसाधन के तौर पर अपनी ज़रूरत के हिसाब से अपलोड करें: एपीआई प्रॉक्सी में बदलाव, एनवायरमेंट या संगठन.
      • Apigee सॉफ़्टवेयर को हमेशा की तरह अपग्रेड करें.
    • मैन्युअल प्लेसमेंट (अगर आपके पास बड़ी संख्या में जार / लाइब्रेरी हैं जिन्हें Java-Callout जार से रेफ़र किया जा रहा है, तो यह तरीका इस्तेमाल करने का सुझाव दिया जाता है)
      • हर मैसेज प्रोसेसर नोड पर, $APIGEE_ROOT/data/edge-message-processor/ पाथ पर external-lib नाम की एक नई डायरेक्ट्री बनाएं.
      • पहचाने गए JAR को, बंद की गई डायरेक्ट्री से इस external-lib डायरेक्ट्री में कॉपी करें: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • पक्का करें कि Apigee उपयोगकर्ता, डायरेक्ट्री और उससे जुड़ी जार फ़ाइलों को पढ़ सकता हो: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Apigee सॉफ़्टवेयर को हमेशा की तरह अपग्रेड करें.

OpenLDAP में बदलाव

कॉन्टेक्स्ट

OpenLDAP का इस्तेमाल, Edge Private Cloud में पुष्टि करने और अनुमति देने, दोनों के लिए किया जा सकता है. Edge for Private Cloud 4.53.01 में, Apigee की ओर से शिप किए गए OpenLDAP सॉफ़्टवेयर को वर्शन 2.4 से 2.6 पर अपग्रेड किया गया था.

बदलाव

OpenLDAP 2.6 में, रिलेटिव डिस्टिंग्विश्ड नेम (आरडीएन) की सीमा करीब 241 बाइट/वर्ण है. यह सीमा तय है और इसे बदला नहीं जा सकता.

असर
  • बहुत बड़े RDN वाली एंट्री के लिए, रेप्लिकेशन या इंपोर्ट नहीं हो पाता.
  • संगठन, एनवायरमेंट, कस्टम रोल, अनुमतियां वगैरह जैसी इकाइयां बनाने की कोशिश करने पर, आपको यह गड़बड़ी का मैसेज मिल सकता है: "message": "[LDAP: error code 80 - Other]".
  • Apigee के LDAP में, 241 बाइट से ज़्यादा लंबाई वाले किसी भी डीएन पर इसका असर पड़ता है. ऐसे डीएन की वजह से, Apigee OpenLDAP सॉफ़्टवेयर को अपग्रेड नहीं किया जा सकेगा. इसलिए, अपग्रेड करने से पहले आपको ऐसे आइटम के लिए, समस्या कम करने की रणनीतियों का पालन करना होगा.

आम तौर पर, Apigee के LDAP में लंबे DN, अनुमतियों से जुड़े होते हैं. ऐसा इसलिए है, क्योंकि इन्हें कई इकाइयों को जोड़कर बनाया जाता है. इस तरह की अनुमतियों वाली एंट्री में, अपग्रेड से जुड़ी समस्याएं होने की आशंका ज़्यादा होती है.

उदाहरण के लिए, 

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

आम तौर पर, आपके पास संगठन, एनवायरमेंट, और भूमिका के ऐसे नाम होते हैं जिनकी लंबाई इस तरह से होती है कि LDAP में RDN 241 बाइट से कम हो जाते हैं.

गड़बड़ी की गंभीरता को कम करना

4.53.01 वर्शन में अपग्रेड करने से पहले:

यहां दिए गए चरणों से, आपके मौजूदा LDAP 2.4 क्लस्टर में लंबे RDN की मौजूदगी की पुष्टि करने में मदद मिलेगी.

#1 - LDAP डेटा एक्सट्रैक्ट करना

डिस्टिंग्विश्ड नेम (डीएन) ढूंढने के लिए, ldapsearch कमांड का इस्तेमाल करें और आउटपुट को किसी फ़ाइल पर रीडायरेक्ट करें: 

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 - लंबे आरडीएन की पहचान करना

ऊपर दी गई DN.ldif फ़ाइल में, 241 बाइट/वर्ण से ज़्यादा वाले RDN ढूंढें:

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 सेटअप में कोई भी RDN, 241 बाइट/वर्ण से ज़्यादा नहीं है. अपग्रेड की प्रोसेस को सामान्य तरीके से जारी रखा जा सकता है.

अगर ऊपर दिए गए निर्देश से कोई आउटपुट जनरेट होता है, तो इसका मतलब है कि RDN की संख्या 241 बाइट/वर्ण से ज़्यादा है. ऐसे आइटम के लिए, Edge for Private Cloud 4.53.01 को अपग्रेड करने से पहले, तीसरे चरण में बताए गए तरीके से समस्या को कम करने के लिए ज़रूरी कार्रवाई करें.

#3 - Handle long RDNs

अगर दूसरे चरण में आउटपुट मिलता है, तो इसका मतलब है कि RDN की संख्या 241 बाइट/वर्ण से ज़्यादा है. इस समस्या को हल करने के लिए, यहां दिया गया तरीका अपनाएं:

241 बाइट से ज़्यादा की LDAP एंट्री की समीक्षा करें.

  • अगर कस्टम भूमिका, ऐप्लिकेशन, एपीआई प्रॉडक्ट या अन्य इकाइयों का नाम लंबा होने की वजह से आरडीएन लंबा हो रहा है, तो कम नाम वाली किसी दूसरी इकाई का इस्तेमाल करें.
  • अगर संगठन या एनवायरमेंट के नाम की वजह से आरडीएन लंबा हो रहा है, तो आपको किसी दूसरे संगठन या एनवायरमेंट पर माइग्रेट करना होगा. इसके लिए, आपको छोटे नाम वाला संगठन या एनवायरमेंट चुनना होगा.

ऊपर दिए गए चरणों को तब तक दोहराएं, जब तक आपके एलडीएपी में 241 बाइट से ज़्यादा लंबाई वाले आरडीएन न हों. इस स्थिति में पहुंचने के बाद, निजी क्लाउड वर्शन को सामान्य तरीके से अपग्रेड करें.

क्रिप्टोग्राफ़ी सेवा देने वाली कंपनी में बदलाव

कॉन्टेक्स्ट

यह बदलाव, Edge for Private Cloud 4.53.00 से लिया गया है. Edge for Private Cloud 4.53.00 में, इंटरनल क्रिप्टोग्राफ़ी प्रोवाइडर को Bouncy Castle (BC) से Bouncy Castle FIPS (BCFIPS) में अपडेट किया गया है, ताकि FIPS की सुविधा चालू की जा सके.

बदलाव

अगर JavaCallout नीतियां, ओरिजनल बीसी प्रोवाइडर का इस्तेमाल करती हैं, तो उन्हें अपग्रेड करना होगा. ऐसा खास तौर पर तब करना होगा, जब बीसीएफ़आईपीएस प्रोवाइडर में सुरक्षा से जुड़ी ऐसी सुविधाओं का इस्तेमाल किया जा रहा हो जो ज़्यादा सुरक्षित हों. उदाहरण के लिए, एन्क्रिप्शन और साइनिंग, दोनों के लिए एक ही सामान्य पासकोड का इस्तेमाल करना. BC नाम का इस्तेमाल करके Bouncy Castle क्रिप्टोग्राफ़ी प्रोवाइडर को लोड करने की कोशिश करने वाली JavaCallout नीतियां काम नहीं कर सकती हैं. ऐसा इसलिए, क्योंकि डिफ़ॉल्ट प्रोवाइडर बदल गया है. बीसी प्रोवाइडर का इस्तेमाल करने वाली ऐसी नीतियां बाद में काम नहीं करेंगी. बीसी की पुरानी सेवा देने वाली कंपनी पर निर्भर रहने वाले सभी कस्टम इंप्लीमेंटेशन अब ऐक्सेस नहीं किए जा सकेंगे. इनकी समीक्षा करके, इन्हें फिर से लागू करना होगा.

गड़बड़ी की गंभीरता को कम करना

इस समस्या को हल करने के लिए, BCFIPS प्रोवाइडर का इस्तेमाल करने का सुझाव दिया जाता है. कस्टम JavaCallout इंप्लीमेंटेशन, पुराने प्रोवाइडर पर निर्भर करते हैं. इसलिए, इनकी समीक्षा करनी होगी. साथ ही, इन्हें Bouncy Castle FIPS प्रोवाइडर का इस्तेमाल करके फिर से लागू करना होगा. इसे "BCFIPS" स्ट्रिंग का इस्तेमाल करके ऐक्सेस किया जा सकता है.

बदलाव का अपने-आप पता लगाने वाला टूल

हम जल्द ही बदलाव का पता लगाने वाला टूल लॉन्च करने वाले हैं. इस टूल में, एपीआई प्रॉक्सी, शेयर किए गए फ़्लो, संसाधन, और एलडीएपी आरडीएन को स्कैन करने और उनकी पहचान करने की सुविधा होगी. ये सभी, इस लेख में बताए गए अलग-अलग बदलावों से प्रभावित हो सकते हैं. इस टूल की मदद से, उन अलग-अलग इकाइयों की पहचान की जा सकती है जो Edge for Private Cloud 4.53.01 पर अपग्रेड करने के दौरान या बाद में काम नहीं करती हैं.