RAM'de çalışan VPN çalışma zamanı günlükler hakkında hiçbir şey söylemez

Salt okunur bir imajdan önyüklenen ve çalışma durumunu tmpfs üzerinde tutan bir VPN sunucusu gerçek ve yararlı bir tasarımdır. Onu günlük yok diye tanımlamak da kolaydır, ki tasarım bunu kanıtlamaz. Depolama konumu bir kopyanın nerede yaşadığını belirler; toplama ve saklama bir kaydın var olup olmadığını belirler ve yeniden başlatma yalnızca ilkini etkiler. Bu ikisini ayrı tutmak tüm incelemedir.

Durum yazabilen her süreci listeleyerek başlayın: arka plan programı, kimlik doğrulama hizmeti, günlük, herhangi bir izleme aracısı ve yönetim araçları.

Depolama ve toplama farklı sorulardır

Her yazıcının kendi hedefi ve kendi politikası vardır. VPN arka plan programı durum dosyaları yazar, kimlik doğrulama arka ucu hesap olaylarını yazar, günlük hizmet çıktısını toplar ve bir izleme aracısı metrikleri tamamen başka bir yere gönderir. Bunlardan birini yeniden başlatmada yok eden bir tasarım diğer üçü hakkında hiçbir şey söylememiştir. Her yazıcıyı hedefine kadar izleyin ve o hedefin makinede olup olmadığını not edin.

Uygulamaya özgü dosyalar, yüklenen tanılama ve dış hizmetler aynı muameleyi gerektirir. Tanıdık bir yerel günlüğün yokluğu, bağlantı veya hesap kayıtlarının hiçbir yerde olmadığını kanıtlamaz; nereye gittiklerini henüz bulamadığınızı kanıtlar.

tmpfs bir garanti değildir

Linux tmpfs fiziksel bir RAM diski değildir. Çekirdek belgeleri, bağlama izin verdiğinde sayfaların swap'a yazılabileceğini açıkça belirtir, bu yüzden bir tmpfs dosyası uygulama onu oraya hiç kopyalamadan diske ulaşabilir. mount swap destekli bir tmpfs'in iş başında olup olmadığını gösterir ve diğer bellek dosya sistemleri yine farklı davranır. /run altındaki bir yolun uçuculuk anlamına geldiğini varsaymak yerine gerçek bağlama seçeneklerini okuyun.

Ardından yeniden başlatmayı insanların unuttuğu şekillerde atlatan şeyleri envanterleyin: kalıcı bir üst katman, bağlı depolama, hazırda bekletme imajları, çökme dökümleri ve tüm VM'in altyapı anlık görüntüleri. Her biri geçici saydığınız durum için olası bir hedeftir. Bu liste kontrol edilecek bir şeydir, her ana makinede hepsinin bulunduğu iddiası değildir.

Journald'in iki hedefi ve bir ileticisi vardır

Journald bu ayrımı düzgünce gösterir. Uçucu depolama girdileri /run/log/journal altında, kalıcı depolama /var/log/journal altında tutar ve otomatik mod ikisi arasında seçer; yürürlükteki mod çalışan sistemden gelir, imajın açıklamasından değil. Uçucuya geçmek zaten kalıcı olarak yazılmış olanı silmez. İletim de ayrı bir kanaldır: yerel olarak hiçbir şey tutmayan bir depolama ayarı bile mesajları başka bir hedefe teslim edebilir.

Yürürlükteki modu günlüğün kendisinden veya yapılandırma dosyasından okuyun, ardından iletim hedeflerini ayrı ayrı kontrol edin, çünkü bir ayar diğerini denetlemez.

Yeniden başlatmayı ne atlatmalı

Durumsuz bir çalışma zamanı yinelenebilir değişimi destekler ve hizmetin kendi uyduramayacağı yapılandırma, yetkilendirme ve kurtarma malzemesi için bilinçli kaynaklara ihtiyaç duyar. Yerel yazımlar yok olsun diye tek çalışan kayıt veya iptal durumunu kaybetmek kötü bir alışveriştir ve yaygındır. Neyin bilinçli olarak hayatta kalması gerektiğine karar verin, sonra hayatta kaldığını doğrulayın.

Aynı akıl yürütme operasyonel kayıtlar için de geçerlidir. Güvenlik ve hizmet yönetiminin gerçekten hangi olaylara ihtiyaç duyduğuna, gerekçeli bir kapsam ve saklama ile karar verin ve geri kalanı en aza indirin. En aza indirmek her tanılamayı kapatmakla aynı şey değildir.

Yürürlükteki depolama ve iletim yapılandırmasını birkaç zararsız olayla karşılaştırın, ardından makineyi yeniden başlatın veya değiştirin ve neyin kaldığını ve hizmetin durumunu nereden kurtardığını yeniden kontrol edin.