VPN ที่รันบน RAM ไม่ได้บอกอะไรเกี่ยวกับบันทึก
สภาพแวดล้อม tmpfs กับการอ้างว่าไม่มีบันทึกเป็นสองข้ออ้างที่ต่างกัน ติดตามผู้เขียนแต่ละรายไปถึงปลายทางและตรวจสอบ swap และการส่งต่อบันทึกก่อนจะเชื่อ
เซิร์ฟเวอร์ VPN ที่บูตจากอิมเมจแบบอ่านอย่างเดียวและเก็บสถานะการทำงานไว้บน tmpfs เป็นการออกแบบที่จริงและมีประโยชน์ การบรรยายว่าไม่มีบันทึกก็ทำได้ง่าย ซึ่งการออกแบบไม่ได้ยืนยัน ที่เก็บข้อมูลกำหนดว่าสำเนาอยู่ที่ไหน การรวบรวมและการเก็บรักษากำหนดว่ามีบันทึกอยู่หรือไม่ และการรีบูตมีผลต่ออย่างแรกเท่านั้น การแยกสองเรื่องนี้ออกจากกันคือการทบทวนทั้งหมด
เริ่มจากการระบุทุกกระบวนการที่เขียนสถานะได้: เดมอน บริการยืนยันตัวตน บันทึกระบบ เอเจนต์ตรวจสอบใด ๆ และเครื่องมือจัดการ
การจัดเก็บกับการรวบรวมเป็นคนละคำถาม
ผู้เขียนแต่ละรายมีปลายทางและนโยบายของตัวเอง เดมอน VPN เขียนไฟล์สถานะ แบ็กเอนด์ยืนยันตัวตนเขียนเหตุการณ์บัญชี บันทึกระบบรวบรวมเอาต์พุตของบริการ และเอเจนต์ตรวจสอบส่งเมตริกไปที่อื่นโดยสิ้นเชิง การออกแบบที่ทำให้หนึ่งในนั้นหายไปเมื่อรีบูตไม่ได้พูดอะไรเกี่ยวกับอีกสามรายเลย ติดตามผู้เขียนแต่ละรายไปถึงปลายทางและบันทึกว่าปลายทางนั้นอยู่บนเครื่องหรือไม่
ไฟล์เฉพาะแอปพลิเคชัน การวินิจฉัยที่อัปโหลด และบริการภายนอกต้องการการปฏิบัติแบบเดียวกัน การไม่มีบันทึกภายในที่คุ้นเคยไม่ได้พิสูจน์ว่าไม่มีบันทึกการเชื่อมต่อหรือบัญชีอยู่ที่ไหนเลย แต่พิสูจน์ว่าคุณยังไม่พบว่ามันไปที่ไหน
tmpfs ไม่ใช่หลักประกัน
tmpfs ของลินุกซ์ไม่ใช่ดิสก์ RAM จริง เอกสารเคอร์เนลระบุชัดว่าหน้าหน่วยความจำสามารถเขียนลง swap ได้เมื่อการเมานต์อนุญาต ดังนั้นไฟล์ tmpfs จึงไปถึงดิสก์ได้โดยที่แอปพลิเคชันไม่เคยคัดลอกไปไว้ที่นั่น mount แสดงว่ามี tmpfs ที่หนุนด้วย swap อยู่หรือไม่ และระบบไฟล์หน่วยความจำอื่นก็ทำงานต่างออกไปอีก อ่านตัวเลือกการเมานต์จริงแทนที่จะสรุปว่าเส้นทางใต้ /run หมายถึงความไม่คงทน
จากนั้นทำบัญชีสิ่งต่าง ๆ ที่อยู่รอดข้ามการรีบูตในแบบที่ผู้คนหลงลืม: เลเยอร์บนแบบถาวร พื้นที่จัดเก็บที่เชื่อมต่อ อิมเมจไฮเบอร์เนต ดัมป์จากการขัดข้อง และสแนปช็อตโครงสร้างพื้นฐานของ VM ทั้งเครื่อง แต่ละอย่างเป็นปลายทางที่เป็นไปได้สำหรับสถานะที่คุณคิดว่าเป็นของชั่วคราว รายการนั้นคือสิ่งที่ต้องตรวจสอบ ไม่ใช่ข้ออ้างว่าทุกโฮสต์มีครบ
Journald มีสองปลายทางและตัวส่งต่อ
Journald แสดงการแยกได้อย่างเรียบร้อย พื้นที่เก็บแบบไม่ถาวรเก็บรายการไว้ใต้ /run/log/journal แบบถาวรไว้ใต้ /var/log/journal และโหมดอัตโนมัติเลือกระหว่างสองแบบ โหมดที่ใช้จริงมาจากระบบที่กำลังทำงาน ไม่ใช่จากคำอธิบายของอิมเมจ การเปลี่ยนไปแบบไม่ถาวรไม่ได้ลบสิ่งที่เขียนแบบถาวรไว้แล้ว การส่งต่อก็เป็นช่องทางแยกต่างหาก แม้การตั้งค่าพื้นที่เก็บที่ไม่เก็บอะไรไว้ในเครื่องก็ยังส่งข้อความไปยังเป้าหมายอื่นได้
อ่านโหมดที่ใช้จริงจากบันทึกเองหรือไฟล์กำหนดค่าของมัน แล้วตรวจสอบเป้าหมายการส่งต่อแยกต่างหาก เพราะการตั้งค่าหนึ่งไม่ได้ควบคุมอีกอย่าง
อะไรต้องอยู่รอดข้ามการรีบูต
รันไทม์ที่ไม่มีสถานะรองรับการแทนที่ซ้ำได้ และต้องมีแหล่งที่มาอย่างตั้งใจสำหรับการกำหนดค่า การอนุญาต และวัสดุกู้คืนที่บริการคิดขึ้นเองไม่ได้ การสูญเสียสถานะการลงทะเบียนหรือการเพิกถอนเพียงชุดเดียวที่ใช้งานได้เพื่อให้การเขียนในเครื่องหายไปเป็นการแลกเปลี่ยนที่แย่ และพบได้บ่อย ตัดสินใจว่าอะไรต้องอยู่รอดอย่างตั้งใจ แล้วตรวจสอบว่ามันอยู่รอดจริง
เหตุผลเดียวกันใช้กับบันทึกการปฏิบัติงาน ตัดสินใจว่าเหตุการณ์ใดที่ความปลอดภัยและการจัดการบริการต้องการจริง ๆ โดยมีขอบเขตและการเก็บรักษาที่สมเหตุสมผล และลดส่วนที่เหลือให้น้อยที่สุด การลดน้อยลงไม่เหมือนกับการปิดการวินิจฉัยทั้งหมด
เปรียบเทียบการกำหนดค่าพื้นที่เก็บและการส่งต่อที่ใช้จริงกับเหตุการณ์ไม่กี่อย่างที่ไม่เป็นอันตราย จากนั้นรีบูตหรือเปลี่ยนเครื่องและตรวจสอบอีกครั้งว่าอะไรยังอยู่และการบริการกู้สถานะของตนมาจากที่ใด