Siapa pemilik log OpenVPN: daemon, rsyslog, atau logrotate?

Rotasi log rusak dengan cara yang bisa diprediksi: tiga komponen masing-masing mengira memiliki berkas itu, dan hasilnya adalah log yang diputar terus tumbuh sementara yang baru tetap kosong. Daemon memegang deskriptor, logrotate mengganti nama jalur, dan rsyslog menulis di tempat yang sama sekali lain. Pilih satu penulis dan satu pemutar sebelum menambah aturan lain ke tumpukan. Daftar periksa di bawah bergerak dalam urutan itu karena setiap langkah berikutnya bergantung padanya.

Putuskan siapa yang menulis berkas

Ada dua rancangan yang sah. Pada yang pertama, proses VPN menulis berkas sendiri melalui opsi log atau log-append miliknya. Pada yang kedua, ia mengirim catatan ke pencatat sistem dan rsyslog atau journald memutuskan di mana catatan itu mendarat.

Keduanya alternatif, bukan lapisan. Host yang mengaktifkan keduanya berakhir dengan dua berkas yang tidak sepakat, dan berkas yang Anda baca sering yang sudah usang. Pilih jalurnya dengan sengaja, lalu hapus penulis yang lain.

Baca konfigurasi layanan yang efektif sebelum mengubah apa pun, termasuk berkas drop-in yang mungkin menimpa berkas unit. Arahan yang ada di profil yang Anda sunting bukan bukti bahwa itulah yang dimuat proses yang sedang berjalan. Bandingkan unit dengan argumen proses, lalu dengan berkas yang benar-benar dibukanya.

Beri nama daemon agar filternya sempit

Pada jalur syslog, beri daemon identitas tersendiri dan filter berdasarkan itu. Aturan yang cocok dengan nama program instans VPN ini menjaga catatannya tetap di luar berkas bersama yang kebijakan retensinya milik hal lain.

Aturan sempit juga membuat pertanyaan berikutnya terjawab: layanan mana yang menghasilkan baris ini? Filter yang cocok dengan semua yang memuat kata VPN akan dengan senang hati mengumpulkan lalu lintas terowongan kedua dan mengaburkan keduanya. Cocokkan dengan pengenal persis yang diteruskan unit ke pencatat.

Tutup aturan setelah aksi agar catatan tidak juga jatuh ke tujuan bawaan. Baris ganda di dua berkas tampak seperti bug pencatatan dan sebenarnya adalah penghentian yang hilang. Satu kelalaian itu juga menggandakan biaya disk kebijakan retensi.

Putar tanpa kehilangan deskriptor

Saat daemon menulis berkas, logrotate mengganti nama jalur tetapi proses tetap memegang deskriptor terbukanya. Catatan baru terus masuk ke berkas yang sudah diganti nama sampai sesuatu memaksa proses membuka ulang jalur aslinya; itulah sebabnya rotasi bisa tampak berhasil sementara berkas baru tetap kosong.

Solusinya adalah aksi postrotate yang memicu perilaku muat ulang atau mulai ulang layanan yang didokumentasikan. Mengirim sinyal ke pencatat adalah aksi yang sama sekali berbeda dan tidak melakukan apa pun bagi daemon yang memegang berkasnya sendiri.

Bila pembukaan ulang mustahil, copytruncate adalah cadangannya: salin berkas, lalu pangkas di tempat. Ini menjaga deskriptor tetap sah dengan mengorbankan semua yang ditulis antara penyalinan dan pemangkasan, jadi ini tukar guling, bukan solusi. Di bawah beban, celah itu bisa menelan justru kegagalan yang ingin Anda tangkap.

Pilih salah satu dari keduanya per berkas dan catat pilihannya, karena mencampurnya pada jalur yang sama menghasilkan celah yang sangat sulit diatribusikan nanti. Pembaca yang menemukan kedua pola di satu direktori tidak bisa mengatakan mana yang berwenang.

Tetapkan retensi dari jendela insiden

Retensi, kompresi, dan ukuran maksimum seharusnya mengikuti seberapa jauh Anda benar-benar menyelidiki. Jendela tujuh hari dengan kompresi dan batas ukuran adalah titik awal yang wajar bagi banyak penerapan; angka yang disalin dari tutorial bukan.

Simpan kebijakan di satu tempat. Jika logrotate memutar berkas dan rsyslog juga memutarnya, rotasi kedua menang dan skema penamaan yang pertama bertahan sebagai kekacauan. Pilih pemiliknya, nonaktifkan rotasi yang lain, dan catat keputusan itu di samping kebijakan.

Dokumentasi rsyslog mencakup model perutean dan aksinya, sedangkan dokumentasi layanan OpenVPN tetap berwenang untuk opsi pencatatan daemon itu sendiri. Tidak satu pun dari keduanya memutuskan kebijakan retensi Anda untuk Anda.

Uji satu rotasi dan satu peristiwa baru

Paksa satu rotasi tunggal lalu hasilkan satu peristiwa baru, seperti autentikasi yang gagal. Pastikan catatan baru muncul di berkas baru dan berkas lama berhenti tumbuh.

Periksa juga izin pada berkas baru, karena rotasi yang membuatnya ulang dengan pemilik berbeda mematahkan penulis pada penulisan berikutnya dan menghasilkan celah yang tampak seperti crash. Bandingkan pemilik dan mode dengan akun layanan sebelum Anda pergi. Lalu pastikan arsip terkompresi bisa dibaca, karena arsip yang tidak bisa dibuka siapa pun bukan retensi. Membaca cepat catatan terbaru di berkas lama membuktikan kompresi sekaligus izinnya.

Akhiri dengan mencatat pemilik setiap langkah: komponen mana yang menulis, mana yang memutar, dan di mana kebijakan retensi tinggal. Catatan itulah yang mengubah insiden pencatatan berikutnya menjadi pemeriksaan lima menit alih-alih sepanjang sore menebak lapisan mana yang menjatuhkan baris itu.