چرخش گزارش نگهبان VPN بدون شکستن نویسنده

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

مقصد را پیش از سیاست چرخش انتخاب کنید

واحد systemd که از پیش خروجی خود را به ژورنال می‌فرستد، نگه‌داری را در یک جا حفظ می‌کند. journald محدودیت‌هایی مانند SystemMaxUse و MaxRetentionSec را اعمال می‌کند، بنابراین نگهبانی که آنجا ثبت می‌کند مرزی را بدون هیچ کار اضافه به ارث می‌برد. افزودن یک فایل نامحدود دوم در کنار آن، نگهداری را بدون سود دو برابر می‌کند.

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

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

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

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

راهنمای logrotate تعداد را به‌عنوان شمار نسخه‌های چرخیدهٔ نگه‌داشته‌شده تعریف می‌کند، نه به‌عنوان تضمین هفت روز تاریخچه، و کلیدواژهٔ daily هنگام اجرای کار ارزیابی می‌شود نه اینکه مانند زمان‌بند خودش عمل کند. در بیشتر توزیع‌ها یک تایمر systemd یا یک ورودی cron از پیش مالک آن فراخوانی است، پس پیش از افزودن دومی بررسی کنید کدام وجود دارد. تطابق مالکیت مهم‌تر از شمار نگه‌داری است. کپی کردن حالتی که فقط برای root است روی فایلی که حساب سرویس می‌نویسد، ثبت را در چرخش بعدی متوقف می‌کند، و شکست ساعت‌ها بعد به‌صورت مهر زمانی کهنه ظاهر می‌شود نه به‌صورت خطا. پیش از کپی کردن بلوک از جای دیگر، کاربر نویسنده را تأیید کنید.

نویسنده‌ای که هرگز دوباره باز نمی‌کند به اصلاح دیگری نیاز دارد

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

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

برای واحدهایی که systemd راه‌اندازی می‌کند، StandardOutput را به ژورنال یا به یک فایل نشانه بگیرید و بگذارید واحد چرخهٔ عمر را در اختیار داشته باشد. حلقهٔ shell که بدون هیچ محدودیت اندازه از طریق tee -a اضافه می‌کند، همان چیدمانی است که هنگام قطعی یک پارتیشن را پر می‌کند، زیرا بررسی ناموفق اغلب بسیار بیشتر از یک بررسی سالم ثبت می‌کند.

چرخش را بدون انتظار برای تایمر آزمایش کنید

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

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

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

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

بازگشت و سابقهٔ نوشتاری را نگه دارید

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

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

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