OpenVPN اجرا شد اما چیزی چاپ نکرد: ابتدا log-append را بررسی کنید

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

سکوت دو توضیح کاملاً متفاوت دارد

نخست اینکه فرآیند خوب کار می‌کند و در فایلی می‌نویسد که شما آن را نمی‌بینید. دوم اینکه بلافاصله با خطایی که در همان فایل ثبت شده خارج شده است.

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

دستور را پیدا کنید، سپس فرآیند را پیدا کنید.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

مقصدی را که فرآیند در حال اجرا استفاده می‌کند پیدا کنید

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

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

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

log در برابر log-append: شاهد و پاک‌شدن

log-append به آنچه از قبل در فایل است می‌افزاید. log فایل را برای نوشتن باز می‌کند و آن را می‌بُرد، پس جابه‌جایی میان این دو می‌تواند اجرایی را که می‌خواستید بخوانید پاک کند.

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

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

وقتی پوشش سرویس خروجی را می‌گیرد

در systemd، خروجی استاندارد و خطا به ژورنال می‌روند مگر آنکه دستور صریح فایل اولویت داشته باشد، و پوشش فروشنده می‌تواند آن‌ها را جای کاملاً دیگری بگیرد.

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

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

فقط پس از آنکه توانستید بخوانید، سطح جزئیات را بالا ببرید

افزایش جزئیات پیش از یافتن مقصد فقط متن بیشتری در جایی تولید می‌کند که به آن نگاه نمی‌کنید.

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

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