اجرای VPN در RAM هیچ چیزی درباره گزارش‌ها نمی‌گوید
یک محیط اجرا روی tmpfs و ادعای نبود گزارش‌ها دو ادعای متفاوت‌اند. هر نویسنده را تا مقصدش دنبال کنید و پیش از باور کردن، swap و ارسال گزارش را بررسی کنید.
یک سرور VPN که از تصویری فقط‌خواندنی بالا می‌آید و وضعیت اجرای خود را روی tmpfs نگه می‌دارد، طراحی واقعی و سودمندی است. توصیف آن به‌عنوان بدون گزارش هم آسان است، چیزی که طراحی آن را اثبات نمی‌کند. محل ذخیره‌سازی تعیین می‌کند نسخه کجا زندگی می‌کند؛ جمع‌آوری و نگهداری تعیین می‌کند اصلاً سابقه‌ای وجود دارد یا نه، و راه‌اندازی مجدد فقط بر اولی اثر می‌گذارد. جدا نگه داشتن این دو، تمام بررسی است.
با فهرست کردن هر فرآیندی که می‌تواند وضعیت بنویسد شروع کنید: دیمن، سرویس احراز هویت، ژورنال، هر عامل پایش و ابزارهای مدیریت.
ذخیره‌سازی و جمع‌آوری دو پرسش متفاوت‌اند
هر نویسنده مقصد و سیاست خودش را دارد. دیمن VPN فایل‌های وضعیت را می‌نویسد، بک‌اند احراز هویت رویدادهای حساب را می‌نویسد، ژورنال خروجی سرویس‌ها را جمع می‌کند و عامل پایش معیارها را به جایی کاملاً دیگر می‌فرستد. طراحی‌ای که یکی از این‌ها را در راه‌اندازی مجدد ناپدید می‌کند، درباره سه مورد دیگر چیزی نگفته است. هر نویسنده را تا مقصدش دنبال کنید و توجه کنید آیا آن مقصد اصلاً روی ماشین هست.
فایل‌های مخصوص برنامه، عیب‌یابی‌های بارگذاری‌شده و سرویس‌های بیرونی همین رفتار را نیاز دارند. نبود یک گزارش محلی آشنا اثبات نمی‌کند که سوابق اتصال یا حساب هیچ‌جا وجود ندارند؛ اثبات می‌کند هنوز پیدا نکرده‌اید که به کجا می‌روند.
tmpfs تضمین نیست
tmpfs لینوکس یک دیسک RAM فیزیکی نیست. مستندات کرنل صریح است که صفحه‌ها می‌توانند وقتی سوارکردن اجازه دهد به swap نوشته شوند، پس یک فایل tmpfs می‌تواند بدون اینکه برنامه هرگز آن را کپی کند به دیسک برسد. mount نشان می‌دهد آیا tmpfs متکی به swap در کار است، و سایر فایل‌سیستم‌های حافظه رفتار دیگری دارند. گزینه‌های واقعی سوارکردن را بخوانید، نه اینکه فرض کنید مسیری زیر /run یعنی ناپایداری.
سپس چیزهایی را که به روش‌هایی از راه‌اندازی مجدد جان سالم به در می‌برند که مردم فراموش می‌کنند فهرست کنید: لایه رویی پایدار، حافظه متصل، تصاویر خواب زمستانی، دامپ‌های خرابی و عکس‌های زیرساختی کل VM. هر یک مقصدی نامزد برای وضعیتی است که آن را زودگذر می‌پنداشتید. آن فهرست چیزی برای بررسی است، نه ادعای اینکه هر میزبان همه آن‌ها را دارد.
ژورنال‌دی دو مقصد و یک ارسال‌کننده دارد
ژورنال‌دی این تقسیم را خوب نشان می‌دهد. حافظه ناپایدار مدخل‌ها را زیر /run/log/journal نگه می‌دارد، حافظه پایدار زیر /var/log/journal، و حالت خودکار میان آن دو انتخاب می‌کند؛ حالتی که در جریان است از سیستم در حال اجرا می‌آید نه از توصیف تصویر. تغییر به ناپایدار چیزی را که پیش‌تر به‌طور پایدار نوشته شده پاک نمی‌کند. ارسال نیز کانالی جداگانه است: حتی تنظیم ذخیره‌سازی‌ای که محلی چیزی نگه نمی‌دارد می‌تواند پیام‌ها را به مقصد دیگری بسپارد.
حالت مؤثر را از خود ژورنال یا فایل تنظیماتش بخوانید، سپس مقصدهای ارسال را جداگانه بررسی کنید، چون یک تنظیم دیگری را کنترل نمی‌کند.
چه چیزی باید از راه‌اندازی مجدد جان سالم به در ببرد
محیط اجرای بی‌حالت جایگزینی تکرارپذیر را پشتیبانی می‌کند و به منابع عامدانه برای پیکربندی، مجوزدهی و مواد بازیابی نیاز دارد که سرویس نمی‌تواند از خود بسازد. از دست دادن تنها وضعیت ثبت‌نام یا لغو کارآمد برای ناپدید شدن نوشته‌های محلی معامله بدی است، و رایج. تصمیم بگیرید چه چیزی باید عمداً باقی بماند، سپس بررسی کنید که باقی می‌ماند.
همین استدلال درباره سوابق عملیاتی صدق می‌کند. تصمیم بگیرید امنیت و مدیریت سرویس واقعاً به کدام رویدادها نیاز دارند، با دامنه و نگهداری توجیه‌شده، و بقیه را کمینه کنید. کمینه کردن با خاموش کردن همه عیب‌یابی‌ها یکسان نیست.
پیکربندی مؤثر ذخیره‌سازی و ارسال را با چند رویداد بی‌خطر مقایسه کنید، سپس ماشین را دوباره راه‌اندازی یا تعویض کنید و دوباره بررسی کنید چه چیزی ماند و سرویس وضعیتش را از کجا بازیابی کرد.