क्या आपका VPN बाइनरी इस CPU के लिए बना है? ELF हेडर पढ़ें

दोनों फ़ाइलें 32-बिट हैं और उनमें से केवल एक आपके बोर्ड पर चलती है। Intel के लिए ELF32 बिल्ड और ARM के लिए ELF32 बिल्ड वर्ग फ़ील्ड पर सहमत हैं और हर उस चीज़ पर असहमत हैं जो मायने रखती है। 32-बिट विकल्प देने वाला डाउनलोड पेज आपको लगभग कुछ नहीं बताया है जब तक आप उस फ़ाइल का हेडर नहीं पढ़ते जो आपने वास्तव में डाउनलोड की। उसका नाम बदलने से एक भी निर्देश नहीं बदलता।

वर्ग और मशीन अलग-अलग सवालों के जवाब देते हैं

वर्ग फ़ील्ड बताता है कि फ़ाइल 32-बिट या 64-बिट संरचनाएँ उपयोग करती है। मशीन फ़ील्ड उस निर्देश-समुच्चय का नाम देता है जिसके लिए फ़ाइल संकलित हुई थी। केवल पहला पढ़ना ही वह तरीका है जिससे x86 बिल्ड पूरी तरह विश्वसनीय दिखने वाले फ़ाइल नाम के साथ ARM बोर्ड पर पहुँच जाता है। दोनों मान एक ही कमांड से आते हैं, इसलिए एक को छोड़ देना इतना आसान है।

वही भ्रम 64-बिट लेबलों पर भी लागू होता है, जहाँ aarch64 और x86-64 एक शब्द-आकार साझा करते हैं और कोई निर्देश नहीं। एक 64-बिट डाउनलोड सूचीबद्ध करने वाला विक्रेता पेज अपना ही बिल्ड बता रहा है, आपकी मशीन नहीं। पेज पर कॉलम शीर्षक के बजाय फ़ाइल का हेडर जाँचें।

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

पहला कमांड हेडर प्रिंट करता है, जिसमें वर्ग और मशीन शामिल हैं। दूसरा प्रोग्राम हेडर दिखाता है, जहाँ इंटरप्रेटर अनुरोध रहता है। तीसरा आपको एक पंक्ति देता है जब तालिका आपकी ज़रूरत से ज़्यादा हो।

निष्पादन अनुमति जोड़ना या वितरण जाँच को पैच करना कुछ भी अनुवाद नहीं करता। एमुलेशन, जहाँ प्लेटफ़ॉर्म इसका समर्थन करता है, एक परिनियोजन निर्णय है जिसकी अपनी प्रदर्शन और निर्भरता लागत है।

इंस्टॉलर चलाने से पहले हेडर पढ़ें

किसी विश्वसनीय आर्टिफ़ैक्ट से कुछ भी निष्पादित करने से पहले उसका निरीक्षण करें। आधे रास्ते में विफल होने वाला इंस्टॉलर लाइब्रेरी बदली हुई और कुछ भी काम न करता छोड़ सकता है, जो उस आर्काइव से बदतर शुरुआती बिंदु है जिससे आपने शुरू किया था। हेडर निरीक्षण केवल-पढ़ने योग्य है और इस अर्थ में उत्क्रमणीय है कि सिस्टम पर कुछ नहीं बदलता।

मशीन फ़ील्ड की तुलना चल रहे सिस्टम की पैकेज आर्किटेक्चर से करें, बोर्ड के मार्केटिंग नाम से नहीं। 32-बिट यूज़रलैंड चलाने वाले 64-बिट CPU को 32-बिट बिल्ड चाहिए, और यही ब्यौरा तय करता है कि कौन-सा डाउनलोड मूल है। बोर्ड की क्षमता बाधा नहीं है; इंस्टॉल किया गया यूज़रलैंड बाधा है।

dpkg --print-architecture
uname -m
getconf LONG_BIT

पहला कमांड उस आर्किटेक्चर की सूचना देता है जिसके लिए सिस्टम पैकेज इंस्टॉल करता है, और वही मान मेल खाना चाहिए। बाकी दो कर्नेल और शब्द-आकार बताते हैं, और मल्टीआर्क इंस्टॉल में वे यूज़रलैंड से भिन्न हो सकते हैं।

जब वे उत्तर भिन्न हों, तो दूसरा आर्काइव डाउनलोड करने से पहले तय करें कि विक्रेता किसका समर्थन करता है। अनुमान इंस्टॉल का एक चक्र बनाता है जिनमें से हर एक अलग बिंदु पर विफल होता है, और हर विफलता नई समस्या जैसी लगती है।

इंटरप्रेटर जाँचें, केवल आर्किटेक्चर नहीं

एक गतिक निष्पादन-योग्य फ़ाइल प्रोग्राम हेडर में वह लोडर दर्ज करती है जिसकी वह अपेक्षा करती है। अलग लोडर पथ वाले सिस्टम पर कर्नेल फ़ाइल शुरू करने से मना कर देता है, भले ही मशीन फ़ील्ड ठीक मेल खाए। यही वह विफलता है जो लोगों को गायब लाइब्रेरी खोजने भेजती है।

त्रुटि संदेश बताता है कि आप किस स्थिति में हैं, और दोनों स्थितियों को गलचाना आसान है। फ़ॉर्मैट या आर्किटेक्चर का अस्वीकरण गायब फ़ाइल या इंटरप्रेटर से अलग है, और उनमें से केवल एक दूसरा पैकेज इंस्टॉल करके ठीक होती है।

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

पहला कमांड वह इंटरप्रेटर पथ दिखाता है जिसकी माँग बाइनरी करती है। दूसरा जाँचता है कि वह पथ मौजूद है या नहीं, जो गलत बिल्ड को गायब लोडर से अलग करता है।

अविश्वसनीय बाइनरी पर निर्भरता-सूची न चलाएँ, क्योंकि कुछ कार्यान्वयन उस फ़ाइल को निष्पादित कर सकते हैं जिसका वे निरीक्षण करते हैं। निरीक्षण को केवल-पढ़ने योग्य रखें और असमर्थित बिल्ड शुरू करने के लिए लोडर सिमलिंक जोड़ने के लोभ का विरोध करें।

तथ्य हाथ में रखकर बिल्ड माँगें

विक्रेता को OS रिलीज़, पैकेज आर्किटेक्चर, वर्ग और मशीन के मान और पहला त्रुटि संदेश भेजें। यह संयोजन उपयोगी उत्तर अर्जित करता है, जबकि सामान्य विफलता का स्क्रीनशॉट समर्थन टेम्पलेट अर्जित करता है।

बाइनरी का सवाल कॉन्फ़िगरेशन के सवाल से अलग रखें। एक बार सही बिल्ड शुरू हो जाने पर, प्रोफ़ाइल, क्रेडेंशियल और रूट अब भी अपनी समस्याएँ हैं, और प्रोफ़ाइल संपादन की कोई भी मात्रा गलत आर्किटेक्चर वाली बाइनरी को नहीं चलाएगी।