status=200/CHDIR: systemd هرگز OpenVPN را آغاز نکرد

سرویس شکست می‌خورد، گزارش‌ها از یک spawn و یک پوشه نام می‌برند، و نخستین واکنش بررسی پیکربندی VPN است. هنوز چیزی از آن فایل خوانده نشده است. systemd هنگام آماده‌سازی فرایند، پیش از اجرای فایل اجرایی شکست خورد، بنابراین هیچ تجزیه‌گری، هیچ گواهی و هیچ میزبان دوری مشورت نشده است. خواندن کد وضعیت به‌عنوان بیانیه‌ای درباره systemd و نه درباره OpenVPN همان چیزی است که این را به تحقیقی کوتاه تبدیل می‌کند.

کد وضعیت را پیش از برنامه بخوانید

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

این تمایز مهم است چون اصلاح‌ها در فایل‌های متفاوتی هستند. شکست CHDIR درباره یک مسیر و دید سرویس نسبت به آن است. شکست exec درباره فایل دودویی، مفسر آن یا یک mount بی‌ربط است. تغییر نقطه دور VPN، فهرست رمزها یا مسیر گواهی هیچ‌کدام را حل نمی‌کند.

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

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

واحد مؤثر را بخوانید نه فایلی را که گمان می‌کنید نصب شده است، زیرا drop-inها می‌توانند پوشه کاری را بدون اینکه هرگز واحد اصلی را ویرایش کنید بازنویسی کنند. خروجی show مستقیماً به پرسش پاسخ می‌دهد:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

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

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

مسیر را همان‌گونه که سرویس می‌بیند بررسی کنید

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

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

مالک را درست کنید، سپس انتظار خطای دیگری داشته باشید

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

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

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

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