प्रॉम्प्ट और दायरा
एक टीम PostgreSQL 18 से PostgreSQL 19 में अपग्रेड करने की योजना बना रही है। वर्तमान क्लस्टर RADIUS और कुछ MD5 पासवर्ड ऑथेंटिकेशन का उपयोग करते हैं; क्लाइंट्स में ऍप्लिकेशन्स, ऑपरेशन्स स्क्रिप्ट्स और BI टूल्स शामिल हैं। बताएं कि आप निर्भरताओं की इन्वेंट्री कैसे बनाएंगे, प्रतिस्थापन कैसे चुनेंगे, क्लाइंट्स को कैसे मान्य करेंगे और स्टॉप कंडीशन्स को कैसे परिभाषित करेंगे।
PostgreSQL का आधिकारिक Beta नोटिस प्री-रिलीज़ फीचर पूर्वावलोकन का वर्णन करता है और सीधे प्रोडक्शन उपयोग के विरुद्ध सलाह देता है। वर्ज़न 19 के माइग्रेशन नोट्स RADIUS सपोर्ट को हटाते हैं और सफल MD5 ऑथेंटिकेशन के बाद एक चेतावनी जारी करते हैं; RADIUS केवल UDP पर समर्थित था, जिसे प्रोजेक्ट द्वारा असंशोधनीय रूप से असुरक्षित बताया गया है। यह प्रश्न बिना यह माने कि प्रत्येक परिवेश प्रभावित है, एक साक्ष्य-आधारित ऑथेंटिकेशन माइग्रेशन का परीक्षण करता है।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर चाहता है कि आप प्रोटोकॉल रिमूवल, पासवर्ड फॉर्मेट्स और क्लाइंट क्षमता को अलग करें; एक पूर्ण निर्भरता इन्वेंट्री बनाएं; और न्यूनतम-विशेषाधिकार (least-privilege) प्रतिस्थापन, अवलोकनीय (observable) रोलआउट और रोलबैक को परिभाषित करें। एक मजबूत उत्तर यह भी बताता है कि Beta परिणाम अंतिम-वर्ज़न की प्रतिबद्धताएं नहीं हैं और यह MD5 चेतावनी को तत्काल कनेक्शन प्रतिबंध के रूप में गलत तरीके से प्रस्तुत नहीं करता है।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- वर्तमान और लक्षित PostgreSQL वर्ज़न्स क्या हैं, और अंतिम रिलीज़ की उम्मीद कब है?
- कौन से प्रवेश बिंदु RADIUS का उपयोग करते हैं, और कौन से उपयोगकर्ता या कनेक्शन अभी भी MD5 का उपयोग करते हैं?
- क्या ड्राइवर्स, पूल्स और ऑपरेशन्स टूल्स SCRAM, सर्टिफिकेट्स या पहचान प्रॉक्सी का समर्थन करते हैं?
- ऑथेंटिकेशन सर्वर, नेटवर्क पाथ, ऑडिट आवश्यकताएं, विफलता प्रबंधन (failover) और आपातकालीन खातों का प्रबंधन कैसे किया जाता है?
- कितना आउटेज समय, रोलबैक विंडो और कौन सा सुरक्षा स्वामी उपलब्ध है?
30-सेकंड का उत्तर ढांचा
"मैं Beta को एक अलग सत्यापन लक्ष्य के रूप में मानूंगा। सबसे पहले, मैं प्रत्येक pg_hba.conf नियम, पासवर्ड फॉर्मेट, क्लाइंट और RADIUS निर्भरता की इन्वेंट्री बनाऊंगा, फिर PostgreSQL 19 टेस्ट क्लस्टर पर SCRAM, सर्टिफिकेट्स या एक नियंत्रित पहचान प्रॉक्सी को मान्य करूंगा। मैं कनेक्शनों के रीप्ले, फ़ेलओवर और ऑडिट परिदृश्यों के दौरान समान पहचान के लिए पुराने और नए पाथ उपलब्ध रखूंगा, फिर कम जोखिम वाले टेनेंट्स को पहले माइग्रेट करूंगा जबकि ऑथेंटिकेशन विफलताओं, लेटेंसी और ऑडिट अंतरालों पर नज़र रखूंगा। कोई भी लॉगिन विफलता, विशेषाधिकार विस्तार, ऑडिट हानि या रोलबैक विफलता रोलआउट को रोक देती है, जिसमें पुराना क्लस्टर और ऑथेंटिकेशन पाथ सुरक्षित रहता है।"
चरण-दर-चरण गहन उत्तर
1. निर्भरता इन्वेंट्री बनाएं
pg_hba.conf, रोल विशेषताएँ, पासवर्ड स्टोरेज, कनेक्शन स्रोत, क्लाइंट वर्ज़न्स, पूल्स और ऑटोमेशन स्क्रिप्ट्स को निर्यात और समीक्षा करें। RADIUS, MD5, SCRAM, सर्टिफिकेट्स और बाहरी प्रॉक्सी को अलग से चिह्नित करें; प्रत्येक नियम के लिए उपयोगकर्ता, नेटवर्क, डेटाबेस, नियम प्राथमिकता और स्वामी को रिकॉर्ड करें। केवल एप्लिकेशन रिपॉजिटरी में न खोजें: अस्थायी स्क्रिप्ट्स और BI टूल्स में भी कनेक्शन क्रेडेंशियल्स हो सकते हैं।
2. हटाने और चेतावनी को अलग करें
PostgreSQL 19 के माइग्रेशन नोट्स RADIUS को हटाते हैं; सफल MD5 ऑथेंटिकेशन एक क्लाइंट चेतावनी उत्पन्न करता है जिसे md5_password_warnings के साथ नियंत्रित किया जा सकता है। चेतावनी माइग्रेशन कार्य का संकेत देती है; इसका मतलब यह नहीं है कि वर्तमान कनेक्शन पहले से ही अस्वीकार कर दिए गए हैं। अपग्रेड से पहले RADIUS निर्भरताओं को बदलें, और जोखिमों को समान मानने के बजाय MD5 निर्भरताओं के लिए पासवर्ड और नियम माइग्रेशन शेड्यूल करें।
3. प्रतिस्थापन चुनें और विशेषाधिकारों को सीमित करें
क्लाइंट समर्थन, कुंजी जीवनचक्र, नेटवर्क सीमाओं और ऑडिट आवश्यकताओं के आधार पर SCRAM-SHA-256, क्लाइंट सर्टिफिकेट्स या किसी मौजूदा एंटरप्राइज़ पहचान प्रॉक्सी का मूल्यांकन करें। अल्पकालिक न्यूनतम-विशेषाधिकार वाले माइग्रेशन खाते बनाएं, कभी भी साझा सुपरयूज़र्स नहीं; पुराने और नए खातों को अलग करें और समाप्ति व स्वामित्व निर्धारित करें। डिज़ाइन में फ़ेलओवर, रीड-ओनली रेप्लिकस, ऑपरेशन्स ब्रेक-ग्लास खाते और ऑफ़लाइन रिकवरी शामिल होनी चाहिए।
4. आइसोलेशन में कनेक्शन मैट्रिक्स को मान्य करें
डी-आइडेंटिफाइड डेटा और अलग क्रेडेंशियल्स के साथ प्रोडक्शन टोपोलॉजी को फिर से बनाएं। एप्लिकेशन, पूल, माइग्रेशन टूल्स, बैकअप रीस्टोर, मॉनिटरिंग और फ़ेलओवर का एक-एक करके परीक्षण करें। प्रत्येक क्लाइंट के लिए एक ड्राइवर वर्ज़न पिन करें और ऑथेंटिकेशन विधि, TLS, कनेक्शन समय, विफलता का कारण और ऑडिट इवेंट रिकॉर्ड करें। परीक्षण के दौरान एक रोल के लिए पुराने और नए लॉगिन पाथ रखना उचित है, लेकिन परीक्षण क्रेडेंशियल्स कभी भी प्रोडक्शन तक नहीं पहुंचने चाहिए।
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. कैनरी, गेट्स और रोलबैक डिज़ाइन करें
कम जोखिम वाले टेनेंट्स या गैर-महत्वपूर्ण नौकरियों को पहले ले जाएं। ऑथेंटिकेशन विफलताओं, कनेक्शन लेटेंसी, पासवर्ड-रीसेट सफलता, ऑडिट पूर्णता और फ़ेलओवर सफलता के लिए थ्रेसहोल्ड सेट करें; विशेषाधिकार विस्तार, लॉगिन विफलता, ऑडिट अंतराल या रिकवरी विफलता पर प्रक्रिया रोक दें। एक बूट करने योग्य PostgreSQL 18 कॉपी, पुराने नियम वर्ज़न्स, पासवर्ड-रोटेशन रिकॉर्ड और रोलबैक स्क्रिप्ट्स रखें, और सत्यापित करें कि पुराने क्लाइंट रोलबैक विंडो के भीतर पुनर्प्राप्त हो सकते हैं।
6. Beta अनिश्चितता को रिकॉर्ड करें
Beta व्यवहार और इंटरफेस अभी भी बदल सकते हैं। निष्कर्षों को एक निर्दिष्ट क्लाइंट, ऑथेंटिकेशन कॉन्फ़िगरेशन और टेस्ट डेटा सेट के परिणामों के रूप में लिखें; वर्ज़न्स, कॉन्फ़िगरेशन हैश और ज्ञात मुद्दों को रिकॉर्ड करें, फिर अंतिम रिलीज़ के बाद अंतिम स्वीकृति प्राप्त करें। एक सफल टेस्ट क्लस्टर प्रत्येक क्लाइंट के लिए कम्पैटिबिलिटी साबित नहीं करता है।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं PostgreSQL 18 ऑथेंटिकेशन बेसलाइन को फ्रीज करूंगा और प्रवेश बिंदु और स्वामी द्वारा pg_hba.conf, रोल्स, क्लाइंट्स और RADIUS निर्भरताओं का एक मैट्रिक्स बनाऊंगा। चूंकि PostgreSQL 19 RADIUS को हटाता है, मैं एक अलग क्लस्टर में प्रभावित पहचानों के लिए SCRAM, सर्टिफिकेट्स या एक एंटरप्राइज़ पहचान प्रॉक्सी को मान्य करूंगा, जबकि शेष MD5 उपयोगकर्ताओं को अलग से संभालूंगा; सफल-MD5 चेतावनी माइग्रेशन कार्य का संकेत देती है लेकिन यह पूर्ण अस्वीकृति नहीं है। मैं विफलताओं, लेटेंसी, ऑडिट और विशेषाधिकार सीमाओं को देखते हुए ऍप्लिकेशन्स, पूल्स, स्क्रिप्ट्स, बैकअप रीस्टोर और फ़ेलओवर को रीप्ले करूंगा। केवल एक कम जोखिम वाले कैनरी द्वारा प्रत्येक गेट को पास करने के बाद ही मैं इसका विस्तार करूंगा; विशेषाधिकार विस्तार, ऑडिट हानि, लॉगिन विफलता या रोलबैक विफलता रोलआउट को रोकती है। Beta साक्ष्य अंतिम-वर्ज़न अनुमोदन के लिए इनपुट बने रहते हैं।
सामान्य गलतियाँ
- RADIUS हटाने और MD5 चेतावनी को एक ही घटना मानना → एक सपोर्ट हटाता है, दूसरा माइग्रेशन का संकेत देता है → इन्हें अलग-अलग इन्वेंट्री करें और योजना बनाएं।
- क्लाइंट्स का परीक्षण किए बिना केवल
pg_hba.confको बदलना → ड्राइवर्स और पूल्स में समर्थन की कमी हो सकती है → एक पूर्ण क्लाइंट मैट्रिक्स को रीप्ले करें। - सभी प्रोडक्शन पासवर्ड को एक साथ रोटेट करना → विफलता और रोलबैक का दायरा बहुत बड़ा हो जाता है → आइसोलेट करें, अस्थायी न्यूनतम-विशेषाधिकार खातों का उपयोग करें, और बैचों में माइग्रेट करें।
- ब्रेक-ग्लास खातों को अनदेखा करना → आउटेज रिकवरी एक्सेस को हटा सकता है → नियंत्रित, ऑडिटेड आपातकालीन एक्सेस तैयार करें।
- Beta सफलता को अंतिम कम्पैटिबिलिटी गारंटी के रूप में प्रस्तुत करना → प्री-रिलीज़ व्यवहार बदल सकता है → सीमाओं को रिकॉर्ड करें और अंतिम वर्ज़न को फिर से स्वीकृत करें।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
अपग्रेड कब रुकना चाहिए?
लॉगिन विफलताओं, विशेषाधिकार विस्तार, ऑडिट अंतराल, महत्वपूर्ण क्लाइंट असंगति, फ़ेलओवर विफलता, या एक ऐसा रोलबैक जो विंडो के भीतर पूरा नहीं हो सकता है, पर अपग्रेड रोक दें।
RADIUS को किसी भी पासवर्ड विधि से क्यों नहीं बदला जा सकता?
ऑथेंटिकेशन शक्ति, कुंजी जीवनचक्र, नेटवर्क सीमाएं और ऑडिट आवश्यकताएं भिन्न होती हैं। प्रतिस्थापन को सुरक्षा नीति को संतुष्ट करना चाहिए और क्लाइंट्स व विफलता परिदृश्यों को कवर करना चाहिए।
क्या MD5 चेतावनी का मतलब हर MD5 उपयोगकर्ता को तुरंत डिस्कनेक्ट करना है?
नहीं। चेतावनी उस पाथ को उजागर करती है जिसे अभी भी माइग्रेशन की आवश्यकता है। क्लाइंट्स की पहचान करें, क्रेडेंशियल्स को रोटेट करें, SCRAM, सर्टिफिकेट्स या प्रॉक्सी को मान्य करें, और बैचों में स्विच करें।
आप कैसे साबित करते हैं कि छिपे हुए क्लाइंट्स छूट नहीं गए थे?
एक निश्चित विंडो पर कनेक्शन लॉग, ऑडिट रिकॉर्ड, रोल उपयोग, नेटवर्क स्रोत, रिपॉजिटरी खोज और ऑपरेशन्स साक्षात्कारों को सहसंबंधित करें; माइग्रेशन से पहले और बाद में अज्ञात स्रोतों और ऑथेंटिकेशन विफलताओं की निगरानी करें।
Beta-परीक्षण किया गया परिवर्तन प्रोडक्शन में कब प्रवेश कर सकता है?
अंतिम रिलीज़, नए वर्ज़न और क्लाइंट-मैट्रिक्स सत्यापन, सफल रोलबैक और ऑडिट अभ्यास, और सुरक्षा, डेटाबेस व व्यावसायिक स्वामियों से संयुक्त अनुमोदन के बाद, एक अवलोकनीय कैनरी के साथ।