Runtime VPN dalam RAM tidak berkata apa-apa tentang log

Pelayan VPN yang but daripada imej baca sahaja dan menyimpan keadaan runtime-nya pada tmpfs ialah reka bentuk yang nyata dan berguna. Ia juga mudah digambarkan sebagai tanpa log, yang tidak dibuktikan oleh reka bentuk itu. Lokasi storan menentukan tempat salinan hidup; pengumpulan dan pengekalan menentukan sama ada rekod wujud, dan but semula hanya menjejaskan yang pertama. Memisahkan kedua-duanya ialah keseluruhan semakan.

Mulakan dengan menyenaraikan setiap proses yang boleh menulis keadaan: daemon, perkhidmatan pengesahan, jurnal, mana-mana ejen pemantauan dan alat pengurusan.

Storan dan pengumpulan ialah soalan berbeza

Setiap penulis mempunyai destinasi dan dasar sendiri. Daemon VPN menulis fail keadaan, backend pengesahan menulis peristiwa akaun, jurnal mengumpul output perkhidmatan, dan ejen pemantauan menghantar metrik ke tempat yang sama sekali lain. Reka bentuk yang melenyapkan salah satu daripadanya semasa but semula tidak berkata apa-apa tentang tiga yang lain. Ikuti setiap penulis ke destinasinya dan catat sama ada destinasi itu ada pada mesin.

Fail khusus aplikasi, diagnostik yang dimuat naik dan perkhidmatan luaran memerlukan layanan yang sama. Ketiadaan log tempatan yang biasa tidak membuktikan bahawa rekod sambungan atau akaun tiada di mana-mana; ia membuktikan anda belum menemui ke mana ia pergi.

tmpfs bukan jaminan

Linux tmpfs bukan cakera RAM fizikal. Dokumentasi kernel menyatakan dengan jelas bahawa halaman boleh ditulis ke swap apabila mount membenarkannya, jadi fail tmpfs boleh sampai ke cakera tanpa aplikasi pernah menyalinnya ke sana. mount menunjukkan sama ada tmpfs yang disokong swap sedang digunakan, dan sistem fail memori lain berkelakuan lain lagi. Baca pilihan mount sebenar daripada menganggap laluan di bawah /run bermaksud kemeruapan.

Kemudian inventori perkara yang bertahan melalui but semula dengan cara yang orang lupakan: lapisan atas berterusan, storan terpasang, imej hibernasi, dump ranap dan syot kilat infrastruktur seluruh VM. Setiap satu ialah destinasi calon untuk keadaan yang anda sangkakan sementara. Senarai itu ialah sesuatu untuk diperiksa, bukan dakwaan bahawa setiap hos mempunyai semuanya.

Journald mempunyai dua destinasi dan satu penghantar

Journald menggambarkan pemisahan itu dengan rapi. Storan meruap menyimpan entri di bawah /run/log/journal, storan berterusan di bawah /var/log/journal, dan mod automatik memilih antara keduanya; mod yang berkuat kuasa datang daripada sistem yang berjalan, bukan daripada penerangan imej. Bertukar kepada meruap tidak memadam apa yang sudah ditulis secara berterusan. Penghantaran juga saluran berasingan: malah tetapan storan yang tidak menyimpan apa-apa secara tempatan boleh menyerahkan mesej kepada sasaran lain.

Baca mod berkesan daripada jurnal itu sendiri atau fail konfigurasinya, kemudian semak sasaran penghantaran secara berasingan, kerana satu tetapan tidak mengawal yang lain.

Apa yang mesti bertahan melalui but semula

Runtime tanpa keadaan menyokong penggantian berulang, dan ia memerlukan sumber yang disengajakan untuk konfigurasi, kebenaran dan bahan pemulihan yang perkhidmatan tidak dapat cipta sendiri. Kehilangan satu-satunya keadaan pendaftaran atau pembatalan yang berfungsi supaya tulisan tempatan lenyap ialah pertukaran yang buruk, dan biasa. Tentukan apa yang mesti bertahan secara sengaja, kemudian sahkan bahawa ia bertahan.

Hujah yang sama terpakai kepada rekod operasi. Tentukan peristiwa mana yang benar-benar diperlukan oleh keselamatan dan pengurusan perkhidmatan, dengan skop dan pengekalan yang wajar, dan minimumkan selebihnya. Meminimumkan bukan sama dengan mematikan semua diagnostik.

Bandingkan konfigurasi storan dan penghantaran yang berkesan dengan beberapa peristiwa tidak berbahaya, kemudian but semula atau ganti mesin dan semak semula apa yang tinggal dan dari mana perkhidmatan memulihkan keadaannya.