लॉन्चर उत्पाद Bitnami दस्तावेज़imaxe CLI ब्लॉग संपर्क

AWS Marketplace और जीवनकाल समाप्त सॉफ़्टवेयर: हम केवल Zabbix का नवीनतम LTS ही क्यों बनाए रखते हैं

AWS Marketplace बिना सपोर्ट वाले सिस्टम या सॉफ़्टवेयर वाली इमेज प्रकाशित नहीं करता। जानिए यह नियम कैसे लागू होता है और हमारे Zabbix कैटलॉग में केवल नवीनतम LTS ही क्यों रह सकता है।

एक ट्रॉली पर रखे सेवा से हटाए गए रैक सर्वरों का ढेर, कबाड़ में भेजने के लिए तैयार
एक ट्रॉली पर रखे सेवा से हटाए गए रैक सर्वरों का ढेर, कबाड़ में भेजने के लिए तैयार फ़ोटो: Jemimus · CC BY 2.0 · Wikimedia Commons

वर्षों तक हमने AWS Marketplace पर एक साथ कई Zabbix AMI रखीं: 4.2, 4.4, 6.0, 6.4 और 7.0। विचार सरल था: कुछ टीमों के इंस्टॉलेशन इंटीग्रेशन, टेम्पलेट या सिर्फ़ सावधानी के कारण नए मेजर संस्करण पर नहीं जा सकते, और हम चाहते थे कि उनके पास उनके संस्करण की एक रखरखाव वाली इमेज हो।

अब यह संभव नहीं है। उस पूरे कैटलॉग में से Marketplace पर अब केवल हमारी Zabbix 7.0 LTS AMI बची है, और यह हमारा फ़ैसला नहीं है: AWS Marketplace बाकी को स्वीकार नहीं करता। कारण यह है।

नियम: जीवनकाल समाप्त कुछ भी नहीं

AWS Marketplace हर AMI संस्करण को प्रकाशित करने से पहले जाँचता है। इमेज बूट होती है या नहीं और तकनीकी शर्तें पूरी करती है या नहीं, यह देखने के साथ-साथ वह कमज़ोरियों और बिना सपोर्ट वाले सॉफ़्टवेयर के लिए स्कैन भी करता है। नीति स्पष्ट है: ऐसे उत्पाद स्वीकार नहीं किए जाते जो जीवनकाल के अंत (end of life, EOL) तक पहुँच चुके ऑपरेटिंग सिस्टम या सॉफ़्टवेयर का उपयोग करते हैं

वाक्य के दोनों हिस्से मायने रखते हैं। केवल बेस सिस्टम का समर्थित होना काफ़ी नहीं; इमेज के भीतर का सॉफ़्टवेयर भी गिना जाता है। और कसौटी यह नहीं कि «पैच लगा है या नहीं», बल्कि यह कि «इसे बनाने वाले अब भी इसका रखरखाव करते हैं या नहीं»।

यह कैसे लागू होता है

व्यवहार में जाँच दो रास्तों से आती है:

  • नया संस्करण प्रकाशित करते समय। इमेज स्कैन EOL सिस्टम या सॉफ़्टवेयर को समस्या के रूप में चिह्नित करता है और संस्करण अस्वीकार हो जाता है। बाकी सब कितना भी साफ़ हो, दोबारा बिल्ड करने से समस्या नहीं जाती।
  • पहले से प्रकाशित उत्पाद पर। AWS उत्पाद को Restricted स्थिति में डाल सकता है: तब वह नए खरीदारों को नहीं दिखाया जाता और नए संस्करण स्वीकार नहीं करता। मौजूदा सब्सक्राइबर अपने इंस्टेंस तक पहुँच बनाए रखते हैं, लेकिन उत्पाद जम जाता है।

दोनों बातें साथ चलती हैं। प्रतिबंधित उत्पाद को ऐसा संस्करण नहीं मिल सकता जो उसे उस स्थिति से बाहर निकाले, और उसी आधार पर बना कोई भी संस्करण उसी स्कैन में अटकेगा।

दो कैलेंडर जिनका मेल खाना ज़रूरी है

एक Zabbix AMI एक साथ दो जीवनचक्रों पर निर्भर करती है, और दोनों का सपोर्ट में होना ज़रूरी है:

  • Zabbix का। Standard संस्करण (4.2, 4.4, 6.4…) अगला संस्करण आने तक केवल कुछ महीने रखरखाव पाते हैं। LTS संस्करण (6.0, 7.0…) कई वर्षों का सपोर्ट पाते हैं, पर उनकी भी अवधि ख़त्म होती है।
  • Ubuntu का। हर Zabbix संस्करण केवल उन Ubuntu रिलीज़ के लिए पैकेज प्रकाशित करता है जो उसके विकास के समय मौजूद थीं। पुराना Zabbix संस्करण कभी नई Ubuntu तक नहीं पहुँचता और ऐसे सिस्टम से बँधा रहता है जो देर-सबेर सपोर्ट से बाहर हो जाएगा।

इन दो कैलेंडरों के हिसाब से हमारी पुरानी AMI की स्थिति यह है:

AMIZabbixUbuntuक्यों पास नहीं होती
Zabbix 4.2standard, 2019 से रखरखाव नहीं18.04, 2023 से मानक सपोर्ट नहींZabbix और सिस्टम दोनों EOL। 18.04 के बाद की किसी Ubuntu के लिए 4.2 के पैकेज नहीं हैं
Zabbix 4.4standard, रखरखाव नहीं18.04, 2023 से मानक सपोर्ट नहींZabbix और सिस्टम दोनों EOL। 4.4 अधिकतम Ubuntu 20.04 तक जाता है, जो भी सपोर्ट से बाहर है
Zabbix 6.0LTS20.04, 2025 से मानक सपोर्ट नहींबेस सिस्टम EOL है
Zabbix 6.4standard, रखरखाव नहीं22.04Zabbix संस्करण स्वयं EOL है

निष्कर्ष असहज पर स्पष्ट है: लंबे समय तक नीति का पालन करने वाली एकमात्र लाइन है किसी समर्थित Ubuntu LTS पर Zabbix का नवीनतम LTS। आज वह Ubuntu 24.04 पर Zabbix 7.0 है। Marketplace पर और लाइनें रखने का मतलब है ऐसे उत्पादों का रखरखाव करना जिन्हें अगला कैलेंडर ख़त्म होते ही AWS हटा देगा।

वह मामला जिसने इसे उजागर किया: Zabbix 4.2

हमें यह Zabbix 4.2 AMI का नवीनतम संस्करण तैयार करते समय पता चला। AWS के स्कैन ने तीन समस्याएँ बताईं: जीवनकाल समाप्त सॉफ़्टवेयर का उपयोग (Ubuntu 18.04) और दो CVE, libwebp में CVE-2023-4863 और nghttp2 में CVE-2023-44487

पैच लगा दें तो?

यही पहला सवाल है, और जवाब है कि इससे कुछ नहीं होता। Ubuntu 18.04 के लिए उन दोनों CVE के पैच केवल ESM, यानी Ubuntu Pro में हैं। उन्हें लगा भी दें, तो मुख्य समस्या बनी रहेगी: सशुल्क विस्तारित सपोर्ट मानक सपोर्ट से बाहर हो चुकी रिलीज़ को समर्थित नहीं बनाता।

सिस्टम बदल दें तो?

वह भी नहीं। Zabbix 4.2 की आधिकारिक रिपॉज़िटरी केवल Ubuntu 18.04 तक पैकेज प्रकाशित करती है। हमने Debian का रास्ता भी आज़माया, और नतीजा वही रहा: 4.2 पैकेज वाली अंतिम Debian सपोर्ट से बाहर है, और मौजूदा रिलीज़ पर न पैकेज इंस्टॉल होते हैं, न आधा फ़्रंटएंड दोबारा लिखे बिना कोड कंपाइल होता है। और सफल हो भी जाते, तो भी वह Zabbix 4.2 ही रहता, जो अपने आप में EOL सॉफ़्टवेयर है।

यही तर्क, कुछ अंतर के साथ, तालिका के बाकी संस्करणों पर भी लागू होता है। इसलिए हमने Zabbix 4.2 का पेज हटा दिया है और Marketplace पर केवल 7.0 रखते हैं।

आपके लिए इसका क्या अर्थ है

  • अगर आपके पास पहले से पुराने संस्करण का इंस्टेंस चल रहा है, तो वह ठीक पहले की तरह चलता रहेगा। कुछ बंद नहीं होगा। बस Marketplace पर नए संस्करण नहीं आएँगे।
  • अगर आप अपग्रेड कर सकते हैं, तो अनुशंसित रास्ता Ubuntu 24.04 पर हमारी Zabbix 7.0 LTS AMI है। उसके पेज पर माइग्रेशन गाइड है, जिससे आप इतिहास खोए बिना डेटाबेस ले जा सकते हैं।
  • अगर आपको पुराने संस्करण पर ही रहना है, तो हम Marketplace के बाहर आपके AWS खाते के लिए उसी ऑटोस्केलिंग और उन्हीं SNS सूचनाओं के साथ एक कस्टम संस्करण तैयार कर सकते हैं। सपोर्ट को लिखें, हम देखेंगे।

Zabbix से आगे का सबक

हमारे Zabbix कैटलॉग के साथ जो हुआ, वह देर-सबेर किसी भी ऐसी इमेज के साथ होगा जो किसी विशेष रिलीज़ पर निर्भर है। इसीलिए हमारी AMI हर घटक को उसके प्रोजेक्ट की आधिकारिक रिपॉज़िटरी से इंस्टॉल करती हैं और समर्थित लाइनों का पालन करती हैं, और इसीलिए हम AWS से पहले हर उत्पाद का कैलेंडर जाँचते हैं: जब सिस्टम या सॉफ़्टवेयर जीवनकाल के अंत के पास हों, तो स्कैन के बताने से पहले ही माइग्रेशन हो जाना चाहिए।

aws marketplaceeolzabbixubuntuजीवनचक्र
IM

imaxe टीम

हम सूची की AMIs बनाते और अनुरक्षित करते हैं। जब हम कोई संस्करण प्रकाशित करते हैं, तो हम इसे किसी से भी पहले उत्पादन में उपयोग करते हैं।

कैटलॉग से

इस लेख से संबंधित AMI

पढ़ना जारी रखें

संबंधित लेख