آیا اسکریپت up در OpenVPN خیلی زود اجرا شد، یا هرگز آماده نبود؟

اسکریپت up اجرا می‌شود، با صفر خارج می‌شود، و وظیفهٔ درون آن نمی‌تواند به یک سرویس خصوصی برسد که دو ثانیه بعد از ترمینال بی‌نقص کار می‌کند. غریزه زمان‌بندی است، و تعمیر معمول یک انتظار است که مسابقه را بدون درک آن پنهان می‌کند. خواندن سودمندتر این است که «up» نام یک قلاب است، نه تضمین آمادگی. زمانی فعال می‌شود که دستگاه تونل پیکربندی شود، که پیش از مسیرها، DNS و قطعاً پیش از هر برنامه‌ای پشت تونل است.

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

جای up در ترتیب راه‌اندازی

OpenVPN دستگاه تونل را پیکربندی می‌کند و سپس قلاب up را اجرا می‌کند. نصب مسیرها مرحلهٔ بعدی است و قلاب خودش را دارد، و به همین دلیل وظیفه‌ای وابسته به مسیر که در up قرار گرفته ممکن است دستگاهی بدون مسیر سودمند ببیند. کار مسیرها را در route-up بگذارید و مشکل زمان‌بندی معمولاً ناپدید می‌شود.

راهنما این ترتیب و محیطی را که هر قلاب دریافت می‌کند مستند می‌کند. این ترتیب تمام توضیح گزارش کلاسیک «از پوستهٔ من کار می‌کند» است، و همچنین دلیل آن است که همان اسکریپت می‌تواند روی یک ماشین قبول شود و روی ماشین دیگری با مرحلهٔ مسیر کندتر شکست بخورد. هیچ‌کدام از دو نتیجه چیزی درباره کیفیت اسکریپت نمی‌گوید.

آمادگی DNS و برنامه‌ها حتی دیرتر می‌آید. حتی مسیرهای نصب‌شده هم مدرکی بر این نیستند که نقطهٔ پایانی دور گوش می‌دهد، نامی حل می‌شود، یا جلسهٔ رومیزی برای وظیفه‌ای وابسته به کاربر وجود دارد.

قلاب در واقع چه چیزی را به ارث می‌برد

قلاب زیر حساب و محیط فرایند OpenVPN اجرا می‌شود، که همان پوستهٔ تعاملی شما نیست. ممکن است گذرگاه جلسهٔ کاربر، محیط رومیزی یا اعتبارنامه‌ای را نداشته باشد که فقط هنگام ورود باز می‌شود. بنویسید وظیفه واقعاً به کدام‌یک نیاز دارد.

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

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

چرا افزودن انتظار بررسی آمادگی نیست

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

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

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

پاک‌سازی و اتصال دوباره به همان اندازه توجه نیاز دارند

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

اتصال‌های دوباره می‌توانند قلاب‌ها را بیشتر از یک راه‌اندازی کامل سرویس اجرا کنند. رابط ماندگاری که جلسه را دوباره برقرار می‌کند ممکن است چرخهٔ up و route-up را دوباره راه بیندازد، بنابراین اسکریپتی که یک اجرا در هر بوت را فرض می‌کند در نهایت بدرفتاری می‌کند. اجراها را در گزارش طی یک روز نوسان بشمارید تا ببینید واقعاً چند وقت یک‌بار اجرا می‌شود. سپس اسکریپت را برای آن تعداد اجرا ایمن کنید.

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

رویدادی را که هر وظیفه به آن وابسته است نام ببرید، سپس آن را به همان رویداد پیوند دهید. هر چیز دیگری تأخیری است که خود را بررسی جا می‌زند.