آیا فایل باینری VPN شما برای این پردازنده ساخته شده است؟ سرصفحه ELF را بخوانید

هر دو فایل 32 بیتی هستند و فقط یکی از آن‌ها روی برد شما اجرا می‌شود. یک ساخت ELF32 برای Intel و یک ساخت ELF32 برای ARM در فیلد کلاس توافق دارند و در هر چیز مهمی اختلاف دارند. صفحه‌ای که گزینه 32 بیتی ارائه می‌دهد تقریباً هیچ چیزی به شما نگفته است تا سرصفحه فایلی را که واقعاً دانلود کرده‌اید بخوانید. تغییر نام آن حتی یک دستور را عوض نمی‌کند.

کلاس و ماشین به پرسش‌های متفاوتی پاسخ می‌دهند

فیلد کلاس می‌گوید فایل از ساختارهای 32 بیتی یا 64 بیتی استفاده می‌کند. فیلد ماشین نام مجموعه دستورالعملی را می‌آورد که فایل برای آن کامپایل شده است. خواندن فقط فیلد اول همان راهی است که یک ساخت x86 با نام فایلی کاملاً باورپذیر روی یک برد ARM فرود می‌آید. هر دو مقدار از یک فرمان می‌آیند، به همین دلیل نادیده گرفتن یکی این‌قدر آسان است.

همین سردرگمی برای برچسب‌های 64 بیتی هم صدق می‌کند، جایی که aarch64 و x86-64 اندازه کلمه را شریک‌اند و هیچ دستورالعملی را شریک نیستند. صفحه یک فروشنده که یک دانلود 64 بیتی فهرست می‌کند ساخت خودش را توصیف می‌کند، نه ماشین شما را. سرصفحه فایل را بررسی کنید نه عنوان ستون در صفحه را.

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

فرمان اول سرصفحه را چاپ می‌کند، شامل کلاس و ماشین. فرمان دوم سرصفحه‌های برنامه را نشان می‌دهد، جایی که درخواست مفسر قرار دارد. فرمان سوم وقتی جدول بیش از نیاز شماست یک خط به شما می‌دهد.

افزودن مجوز اجرا یا وصله کردن بررسی توزیع چیزی را ترجمه نمی‌کند. شبیه‌سازی، جایی که پلتفرم پشتیبانی می‌کند، تصمیمی در استقرار است با هزینه عملکرد و وابستگی خاص خود.

پیش از اجرای نصب‌کننده سرصفحه را بخوانید

پیش از اجرای هر چیزی از یک مصنوع مورد اعتماد، آن را بررسی کنید. نصب‌کننده‌ای که در نیمه راه شکست می‌خورد می‌تواند کتابخانه‌های جایگزین‌شده و هیچ چیز کارکننده‌ای بر جای بگذارد، که نقطه شروعی بدتر از آرشیوی است که با آن آغاز کردید. بررسی سرصفحه فقط خواندنی و بازگشت‌پذیر است از این نظر که هیچ چیز در سیستم تغییر نمی‌کند.

فیلد ماشین را با معماری بسته‌های سیستم در حال اجرا مقایسه کنید، نه با نام بازاریابی برد. پردازنده 64 بیتی که فضای کاربری 32 بیتی اجرا می‌کند به ساخت 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

فرمان اول مسیر مفسری را نشان می‌دهد که فایل باینری درخواست می‌کند. فرمان دوم بررسی می‌کند آن مسیر وجود دارد یا نه، که ساخت اشتباه را از بارگذار گمشده جدا می‌کند.

فهرست‌گر وابستگی را روی یک باینری نامعتبر اجرا نکنید، چون بعضی پیاده‌سازی‌ها می‌توانند فایلی را که بررسی می‌کنند اجرا کنند. بررسی را فقط خواندنی نگه دارید و در برابر افزودن پیوندهای نمادین بارگذار برای به راه انداختن ساخت پشتیبانی‌نشده مقاومت کنید.

با حقایق در دست، ساخت بخواهید

به فروشنده نسخه سیستم‌عامل، معماری بسته‌ها، مقادیر کلاس و ماشین و اولین پیام خطا را بفرستید. این ترکیب پاسخ مفیدی می‌گیرد، در حالی که تصویر یک شکست عمومی یک الگوی پشتیبانی می‌گیرد.

پرسش باینری را از پرسش پیکربندی جدا نگه دارید. وقتی ساخت درست راه افتاد، پروفایل‌ها، اعتبارنامه‌ها و مسیرها هنوز مشکلات خودشان هستند و هیچ مقدار ویرایش پروفایل یک باینری با معماری اشتباه را اجرا نخواهد کرد.