VPN bekçisi günlüğünü yazıcıyı bozmadan döndürme

Bir VPN sağlık kontrolü dakikada bir satır ekleyerek sessizce ikinci bir görev yaratır: o satırların diskten nasıl çıkacağına karar vermek. Tüneli onarmak bu görev için hiçbir şey yapmaz ve dosyayı yeniden adlandırmak hâlâ eski tanımlayıcıyı tutan bir süreci yönlendirmez. Önce hedef sorusunu yanıtlayın, sonra döndürmeyi yazıcının dosyayı açma biçimine uyarlayın.

Döndürme politikasından önce hedefi seçin

Çıktısını zaten günlüğe gönderen bir systemd birimi saklamayı tek bir yerde tutar. journald SystemMaxUse ve MaxRetentionSec gibi sınırları uygular, bu yüzden orada günlük tutan bir bekçi ek iş olmadan bir sınırı devralır. Yanına ikinci bir sınırsız dosya eklemek kazanç olmadan bakımı ikiye katlar.

Adanmış bir dosya yerini, başka bir şey onu okuduğunda kazanır: bir ayrıştırıcı, bir denetim dışa aktarımı veya kararlı bir yol bekleyen bir sayfa. Bu karar verildikten sonra dosyanın bir sahibi, bir modu ve birlikte yazılmış bir döndürme politikası olmalıdır, çünkü üçü ancak bir küme olarak doğrudur. Herkesin oluşturabileceği bir yol, herkesin değiştirebileceği bir yoldur, bu yüzden dizin izinleri aynı nota aittir. Hepsini kontrolün yanına yazın ve sonraki düzenleme aynı gerçeklerden başlar.

Bloğu yazıcıya uyacak şekilde yazın

Her çağrıda yolu açan, bir satır ekleyen ve çıkan bir yazıcıyla başlayın. Bu desen, süreçten hiçbir işbirliği olmadan döndürmeyi atlatır, çünkü sonraki çalıştırma o yolda şu anda duran dosyayı açar. Aşağıdaki blok bir haftalık sürümü saklar ve dosyayı yazıcının ihtiyaç duyduğu sahip ve modla yeniden oluşturur:

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

logrotate kılavuzu sayıyı saklanan döndürülmüş sürümlerin sayısı olarak tanımlar, yedi günlük geçmişin garantisi olarak değil, ve daily anahtar sözcüğü iş çalıştığında değerlendirilir, kendi zamanlayıcısı olarak davranmak yerine. Çoğu dağıtımda bu çağrının sahibi zaten bir systemd zamanlayıcısı veya cron girdisidir, bu yüzden ikincisini eklemeden önce hangisinin var olduğunu kontrol edin. Sahipliği eşleştirmek saklama sayısından daha önemlidir. Yalnızca root için olan bir modu hizmet hesabının yazdığı bir dosyaya kopyalamak sonraki döndürmede günlüklemeyi durdurur ve hata saatler sonra bir hata olarak değil, eski bir zaman damgası olarak görünür. Bir bloğu başka bir yerden kopyalamadan önce yazıcının kullanıcısını doğrulayın.

Hiç yeniden açmayan yazıcı başka bir çözüm gerektirir

Açık bir tanımlayıcı tutan uzun ömürlü bir süreç, yeniden adlandırılmış inode'a yazmaya devam eder. Alan serbest bırakılmaz ve görünen dosya büyümeyi durdurur, bu da inode'u kontrol edene kadar bozuk bir döndürme gibi görünür. Ya sürece yeniden açmayı öğretin ya da döndürmeyi yeniden adlandırma yerine kopyalayıp kesmeye zorlayın.

Yeniden açma yolu, yazılımın desteklediği yerlerde daha temizdir: belgelenen sinyali gönderin veya belgelenen komutu çalıştırın ve yeni dosyayı süreç kendisi açsın. Alternatif, içeriği döndürülmüş ada kopyalayan ve sonra orijinali yerinde kesen copytruncate , böylece tanımlayıcı geçerli kalır ama kopya ile kesme arasına düşen yazılar kaybolur.

systemd'nin başlattığı birimler için StandardOutput öğesini günlüğe veya bir dosyaya yönlendirin ve yaşam döngüsünün sahibi birim olsun. Boyut sınırı olmadan tee -a üzerinden ekleme yapan bir shell döngüsü, kesinti sırasında bir bölümü dolduran düzendir, çünkü başarısız bir kontrol sağlıklı olandan genellikle çok daha fazlasını günlüğe yazar.

Zamanlayıcıyı beklemeden döndürmeyi test edin

Hata ayıklama modu ne olacağını bildirir ve hiçbir şeye dokunmaz, bu da onu düzenlemeden sonraki güvenli ilk çalıştırma yapar. Memnun kaldığınızda gerçek bir döndürmeyi zorlayın, sonra sonraki günlük satırının yeniden adlandırılmış dosyaya değil yeni dosyaya düştüğünü doğrulayın:

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

Çıktıyı bu sırayla okuyun. Hata ayıklama geçişi dosyayı ve amaçlanan eylemleri adlandırmalıdır; zorunlu çalıştırma beklenen döndürülmüş adı üretmelidir; tail, yazıcı yeniden çalıştıktan sonra yeni bir girdi göstermelidir. Büyüyen bir df değeri ve küçülen görünen dosya, yukarıda açıklanan tanımlayıcı sorununu gösterir.

Sürümler zaten varken saklamanın nasıl davrandığını görmek için zorunlu çalıştırmayı iki kez tekrarlayın. En eski dosyayı silmek beklenen sonuçtur ve silme olmaması genellikle döndürülmüş addaki sayının veya joker karakterin logrotate'nin oluşturduğuyla eşleşmediği anlamına gelir.

Geri alma ve yazılı kayıt tutun

Düzenlemeden önce önceki bloğu kaydedin ve hangi zamanlayıcının çalıştırdığını not edin, çünkü dosyayı geri getiren ama zamanlayıcıyı getirmeyen bir geri alma orijinal sorunun yarısını yeniden üretir. Geri yüklemeden sonra bir kez elle döndürün, sonra yazıcının hesabının günlük yoluna yazabildiğini doğrulayın. Hizmet systemd altında çalışıyorsa, çıktısının yönlendirmesindeki her değişiklikten sonra birimi yeniden yükleyin, çünkü çalışan süreç eski hedefe yazmaya devam eder. Birimin temiz döndüğüne güvenmek yerine sonraki birkaç günlük satırını kendiniz okuyun.

Modu, sahibi, saklama sayısını ve beklenen disk bütçesini kontrolün hemen yanına kaydedin. Daha sonra kontrol tek seferlik bir betikten bir daemon'a dönüştüğünde, döndürme politikası da onunla birlikte değişmelidir ve o not, sonraki kişiye hangi varsayımın kırıldığını söyler.

Son olarak, günlük kararını kurtarma kararından ayrı tutun. Başarısız bir kontrol bağlantının kendi kurtarma politikasını izlemelidir, logrotate içinde saklı bir kuralı değil, ve hiçbir günlükleme düzeni çalışan bir tünelin yeniden başlatılmasının nedeni olmamalıdır.