นโยบายรีสตาร์ตที่เพิ่มให้อุโมงค์เดียวเริ่มมีผลกับทุกอุโมงค์บนเครื่อง นี่ไม่ใช่บั๊กของ systemd แต่เป็นความต่างระหว่าง drop-in ของอินสแตนซ์กับ drop-in ของเทมเพลต เส้นทางที่คุณเขียนไฟล์ไว้ใต้เส้นทางนั้นเป็นตัวกำหนดว่าจะมีบริการกี่ตัวที่รับช่วงต่อ

เลือกขอบเขตก่อนตั้งค่า ไดเรกทอรีทั้งสองดูแทบเหมือนกัน และมีเพียงตัวเดียวที่จำกัดอยู่เฉพาะอินสแตนซ์ที่คุณตั้งใจ

อาการ: แก้ครั้งเดียว ทุกอุโมงค์

drop-in เฉพาะอินสแตนซ์อยู่ใต้ไดเรกทอรีที่ตั้งชื่อตามอินสแตนซ์เต็ม เช่น [email protected] ส่วน drop-in ของเทมเพลตอยู่ใต้ [email protected] โดยมีเครื่องหมาย @ และไม่มีชื่ออินสแตนซ์คั่นกลาง ตัวแรกใช้กับ office เท่านั้น ตัวที่สองใช้กับทุกบริการที่สร้างจากเทมเพลตนั้น

รูปแบบเทมเพลตไปไม่ถึงเทมเพลต [email protected] แยกต่างหาก และไปไม่ถึงบริการที่ไม่เกี่ยวข้องซึ่งมี openvpn อยู่ในชื่อ

เลือกไดเรกทอรีที่ตรงกับขอบเขต

ไดเรกทอรีทั้งสองอยู่ใต้ /etc/systemd/system/ การละส่วนประกอบ system ตัวสุดท้ายทำให้เกิดเส้นทางที่ systemd ไม่ได้อ่านเป็นการแทนที่ระดับระบบ ซึ่งเป็นวิธีเงียบๆ ที่ทำให้ไฟล์ที่ดูถูกต้องไม่ทำอะไรเลย เขียนเส้นทางเต็มครั้งเดียวแล้วใช้ซ้ำ

drop-in ยังต้องมีหัวข้อส่วนที่ถูกต้อง การตั้งค่าบริการอยู่ใต้ [Service] ไฟล์ที่มีการตั้งค่าแต่ไม่มีส่วนจะถูกเพิกเฉยหรือถูกปฏิเสธ และยูนิตยังคงทำงานเหมือนเดิมในขณะที่ไฟล์วางอยู่ตรงนั้นดูน่าเชื่อถือ

เก็บวัตถุประสงค์ไว้ในชื่อไฟล์หากคุณเพิ่ม drop-in มากกว่าหนึ่งตัว ลำดับตามพจนานุกรมเป็นตัวตัดสินการผสาน และชื่อที่บอกว่าไฟล์ทำอะไรทำให้ลำดับนั้นอ่านได้

อ่านยูนิตที่ผสานแล้วก่อนเขียน

อ่านยูนิตที่ผสานแล้วก่อนเขียนอะไรทั้งนั้น systemctl cat [email protected] พิมพ์ยูนิตหลักและทุก drop-in ที่ใช้ได้ตามลำดับการผสาน เปรียบเทียบกับอินสแตนซ์ที่สองเมื่อคุณพิจารณาการเปลี่ยนเทมเพลต การเปรียบเทียบนั้นแสดงว่าบริการใดจะรับช่วงการแก้ไข

ไฟล์อินสแตนซ์ไม่ได้ลบการตั้งค่าของเทมเพลต ทั้งสองถูกผสาน ดังนั้นค่าจากเทมเพลตที่คุณลืมอาจยังมีผลอยู่

drop-in อื่นที่มีชื่อ การตั้งค่าเวลารัน และคอนฟิกูเรชันที่แพ็กเกจให้มาก็มีส่วนด้วย อย่าคิดว่าไฟล์ที่คุณแก้ล่าสุดคือยูนิตทั้งหมด เอาต์พุตที่ผสานแล้วคือยูนิต

เก็บนโยบายของยูนิตไว้นอกโปรไฟล์

แยกนโยบายของยูนิตกับการตั้งค่า VPN ออกจากกัน คำสั่งในโปรไฟล์ไม่กลายเป็นวากยสัมพันธ์ systemd ที่ถูกต้องเพียงเพราะอยู่ใต้ [Service] การตั้งค่ารีสตาร์ตก็ไม่ควรอยู่ในไฟล์ .ovpn เช่นกัน

การแยกนี้ยังเป็นเหตุผลว่าทำไมนโยบายรีสตาร์ตจึงไม่ใช่สิ่งเดียวกับOpenVPNการกู้คืนเพียร์ของตัวเอง ตัดสินใจว่าต้องการพฤติกรรมแบบไหนก่อนเลือกขอบเขต

นำไปใช้และตรวจสอบอินสแตนซ์

หลังการเปลี่ยนแปลง ให้โหลดนิยามของผู้จัดการใหม่ด้วย systemctl daemon-reload การโหลดใหม่นั้นไม่ได้รีสตาร์ตอุโมงค์ แต่แค่อ่านไฟล์ยูนิตใหม่ จากนั้นใช้การดำเนินการวงจรชีวิตที่คุณตั้งใจกับอินสแตนซ์ที่แน่นอน

ตรวจสอบโดยอ่านยูนิตที่โหลดแล้วอีกครั้งและเฝ้าดูพฤติกรรมที่คุณเปลี่ยน การรีสตาร์ตที่แบกงานที่ใช้งานอยู่ควรได้รับการหยุดชั่วคราวตามแผน ไม่ใช่การทดสอบเร็วบนอุโมงค์โปรดักชัน บันทึกวัตถุประสงค์และขอบเขตของการแทนที่ไว้ข้างการติดตั้ง เพื่อให้คนถัดไปรู้ว่าไฟล์นั้นตั้งใจให้แชร์หรือไม่

หากนโยบายถูกแชร์จริง ให้ย้ายไปยังเทมเพลตอย่างตั้งใจและตรวจสอบอินสแตนซ์ที่สองก่อนบอกว่าเสร็จเอกสารอ้างอิงยูนิตของ systemdอธิบายลำดับความสำคัญของ drop-in และลำดับการผสาน

บทความที่เกี่ยวข้อง