چرا هشدار پاکسازی مسیر vpnc در یک کانتینر ظاهر میشود
پاکسازی حافظه نهان مسیرها بازمانده هستهای است که دیگر آن حافظه را نگه نمیدارد؛ خطای فقط-خواندنی از اتصال کانتینر میآید، نه از تونل.
گزارشهای تازه کانتینر اغلب با شکایتی Read-only file system درباره /proc/sys/net/ipv4/route/flush پایان مییابند و آن خط را به گردن تونلی میاندازند که ممکن است کاملاً سالم باشد. نوشتنی که پشت آن است یک ورودی هسته را هدف میگیرد که با از بین رفتن حافظه نهان مسیرهای IPv4 دیگر کار مفیدی نمیکند. درون کانتینر /proc/sys فقط-خواندنی سوار میشود، بنابراین تغییرمسیر پیش از رسیدن هر مقداری رد میشود و پوسته همان رد را چاپ میکند. تونل سالم میتواند تا زمانی که خط قدیمی در اسکریپت بماند این هشدار را چاپ کند و --privileged هرگز نوشتن را معنادار نمیکند.
اسکریپت چه چیزی را میخواست پاک کند
اسکریپتهای اتصال قدیمیتر با پاکسازی حافظه نهان تمام میشدند: نوشتن یک مقدار در پرونده کنترل هسته و درخواست از پشته IPv4 برای دور انداختن حافظه نهان مسیریابیاش، تا مسیر تونل جدید بدون انتظار برای منقضی شدن ورودیهای کهنه انتخاب شود. پرونده زیر /proc/sys/net/ipv4/ نشانی میشد و همین کار را به تغییرمسیر پوسته تبدیل میکرد، نه فرمان مسیریابی. هسته 3.6 آن حافظه را حذف کرد و با آن دلیل وجود پاکسازی را. هیچ چیز در مسیر داده کنونی به آن نوشتن وابسته نیست.
خود ورودی بهعنوان پرونده قدیمی فقط-نوشتنی باقی ماند، پس اسکریپتی که هنوز در آن مینویسد به مسیری واقعی و بررسی مجوزی واقعی میرسد. روی میزبان نوشتن موفقیت برمیگرداند و چیزی را تغییر نمیدهد. در کانتینر همان تغییرمسیر به /proc/sys فقط-خواندنی میخورد و با EROFS شکست میخورد، که پوسته آن را بهصورت پیام فایلسیستم فقط-خواندنی چاپ میکند. روی هستههایی که مسیر واقعاً وجود ندارد عبارت No such file or directory میشود و نتیجه تغییر نمیکند.
دو خطا دو چیز متفاوت میگویند و ارزش دارد تفاوت را روشن نگه داریم. Read-only file system یعنی هسته به ورودی رسید و نوشتن را رد کرد؛ No such file or directory یعنی ورودی رفته است. هیچیک از پیامها درباره دستگاه تونل، مسیرها یا حل نام گزارش نمیدهد، پس هیچکدام نمیتواند امتیاز بیشتری را توجیه کند.
ترتیب است که پیام را علّی نشان میدهد. اسکریپت اتصال مسیرها را نصب میکند، وضعیت رابط را تغییر میدهد و حل نام را بازنویسی میکند تا به پاکسازی در پایان برسد، پس آخرین خط چاپشده همان خطی است که مردم نقل میکنند، حتی وقتی هر گام مهمی موفقیت برگردانده است. تونلی که برقرار میشود و ترافیک حمل میکند در حالی که این هشدار را چاپ میکند، دقیقاً با سازوکار بالا جور در میآید.
پیش از افزودن امتیاز، اتصال و مسیر را بررسی کنید
سه خواندن یک هشدار ظاهری را از یک شکست واقعی جدا میکند: اینکه اسکریپت نصبشده هنوز خط را دارد یا نه، /proc/sys چگونه سوار شده و ترافیک برنامه واقعاً کجا میرود. آنها را در همان فضای نام کانتینر یا روی میزبانی اجرا کنید که هشدار در آن ظاهر شد، چون بررسی روی ماشینی نامرتبط به پرسش دیگری پاسخ میدهد.
grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10پاسخ grep ضعیفتر از آن است که به نظر میرسد، چون یافتن ثابت میکند خط وجود دارد، نه اینکه بدون محافظ اجرا میشود؛ اسکریپت نگهداریشده میتواند نوشتن را درون محافظی داشته باشد که از آن میگذرد. findmnt -no OPTIONS /proc/sys اتصال را مستقیم روشن میکند و ro در آن خروجی یعنی هر نوشتنی پایینتر از آن نقطه رد میشود، هر چه اسکریپت بکند. سپس جستوجوی مسیر نشان میدهد مقصدی که برنامه لازم دارد از رابط تونل حل میشود یا از دروازه پیشفرض کانتینر. جستوجویی که دروازه پیشفرض را انتخاب میکند یعنی تونل بالا آمده و چیزی به آن مسیریابی نمیشود، که مشکل مسیریابی است نه مشکل امتیاز.
اصلاح واقعاً از کجا میآید
اصلاح نگهداریشده در اسکریپت زندگی میکند، نه در پرچمهای کانتینر. upstream vpnc-script شیوه برخوردش با این عملیات را تغییر داده است، پس نسخه درون ایمیج را با upstream کنونی مقایسه کنید و از طریق بسته یا ساخت ایمیجی که آن را تأمین میکند بهروزرسانی کنید. پرونده دستیویرایششده درون کانتینر در حال اجرا قابل بازبینی نیست و تا ساخت بعدی دوام نمیآورد.
--privileged مستند شده است که همه توانمندیها بههمراه دسترسی گسترده به دستگاهها را میدهد، امتیاز بزرگی برای پیامی که چیزی را تغییر نمیدهد، پس اگر واقعاً توانمندیای کم است همان را نام ببرید. پس از بهروزرسانی، جستوجوی مسیر را تکرار کنید و بگذارید برنامهای از تونل استفاده کند، چون گزارش ساکت و اتصال کارکننده دو نتیجه جداگانهاند.