ข้อผิดพลาด Python ของ OpenVPN 3: ซ่อมเครื่องมือ ไม่ใช่ Python ของระบบ

Traceback ปรากฏขึ้นเมื่อคำสั่งจัดการ VPN เริ่มทำงาน และสัญชาตญาณแรกก็วิ่งไปที่การติดตั้ง Python อีกตัวหรือชี้ค่าเริ่มต้นของระบบไปที่อื่น สัญชาตญาณนั้นผสม runtime สองตัวที่ไม่เกี่ยวข้องกันเลย ตัวหนึ่งเป็นของระบบปฏิบัติการและเครื่องมือที่แพ็กเกจมา ส่วนอีกตัวเป็นของโปรเจกต์ใดก็ตามที่คุณกำลังสร้าง การเปลี่ยนตัวแรกเพื่อตอบสนองตัวที่สองคือวิธีที่เดสก์ท็อปที่ใช้งานได้สูญเสียตัวจัดการแพ็กเกจของมัน

การเปรียบเทียบที่คุ้มค่าคือระหว่างองค์ประกอบที่ล้มเหลวจริงกับ runtime ที่คุณมีสิทธิ์เปลี่ยน ทั้งสองแทบไม่เคยเป็นวัตถุเดียวกัน

สองคำถามเกี่ยวกับ Python ที่ดูเหมือนคำถามเดียว

คำถามแรกคือ interpreter ตัวไหนที่รันโปรแกรมที่พิมพ์ Traceback ออกมา คำถามที่สองคือโปรเจกต์ของฉันควรใช้ interpreter ตัวไหน ใน terminal ทั้งสองดูเหมือนกันเพราะตอบทั้งสองด้วยการพิมพ์ python3 แต่มีเจ้าของต่างกัน เส้นทางการอัปเกรดต่างกัน และรัศมีผลกระทบต่างกัน

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

มีเพียงการกระทำเดียวเท่านั้นที่ย้อนกลับได้ในหนึ่งนาที มันไม่ใช่ตัวแรก

องค์ประกอบใดสร้างข้อผิดพลาด

อ่านบรรทัดแรกของ Traceback และไฟล์เรียกทำงานที่สร้างมันก่อนจะอ่านอย่างอื่น frontend ของบรรทัดคำสั่ง บริการที่มีสิทธิ์พิเศษ และ binding ของ API เป็นชิ้นส่วนแยกกัน และมีเพียงบางส่วนเท่านั้นที่เป็น Python

command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager

บรรทัดแรกของสคริปต์บอกชื่อ interpreter ที่มันจะใช้ และ Traceback มาจาก interpreter นั้น การสอบถามแพ็กเกจบอกคุณว่าใครเป็นเจ้าของไฟล์ ซึ่งกำหนดว่าใครได้รับอนุญาตให้เปลี่ยนมัน สถานะของบริการตอบคำถามที่ต่างออกไปโดยสิ้นเชิง คือ backend ที่มีสิทธิ์พิเศษซึ่งเปิดเซสชันจริงนั้นกำลังทำงานอยู่หรือไม่

ข้อผิดพลาดในการนำเข้าโมดูล การปฏิเสธการเปิดใช้งาน D-Bus และข้อมูลรับรองที่ถูกปฏิเสธเป็นสามขั้นตอนที่ต่างกัน ข้อผิดพลาดในการนำเข้าเกิดขึ้นก่อนที่เซสชันใดจะดำรงอยู่ ดังนั้นการกำหนดค่า VPN มากเท่าไรก็ไม่แก้มัน และบริการที่ทำงานอยู่ก็ไม่แก้มันเช่นกัน การจัดข้อความให้อยู่ในหนึ่งในสามขั้นตอนนั้นคือก้าวแรกที่แท้จริง

environment ของโปรเจกต์แก้อะไรได้และแก้อะไรไม่ได้

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

uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'

คำสั่งที่สองแสดงว่า interpreter ที่กำหนดมองเห็นสำเนาของ binding ชุดไหน ซึ่งเป็นวิธีเร็วที่สุดในการแยกแพ็กเกจที่หายไปออกจากแพ็กเกจที่ถูกบดบัง เรียกใช้ด้วย interpreter ที่สคริปต์ที่ล้มเหลวใช้ ไม่ใช่ด้วยตัวอื่นที่บังเอิญทำงานได้

สิ่งที่ environment ของโปรเจกต์ทำไม่ได้คือซ่อม frontend ที่ดิสทริบิวชันแพ็กเกจมา dependency ของโปรแกรมนั้นสร้างขึ้นสำหรับ interpreter ที่ตัวจัดการแพ็กเกจเลือก และการเรียกมันใน environment ของโปรเจกต์คุณไม่ล้มเหลวก็สร้างส่วนผสมที่ไม่มีใครรองรับ การฉีดพาธเข้าไปด้วยตัวแปร environment คือความผิดเดียวกันกับขั้นตอนเพิ่มเติม คุณเปลี่ยนสิ่งที่เครื่องมือโหลดโดยไม่เปลี่ยนสิ่งที่มันถูกทดสอบด้วย การแลกเปลี่ยนนั้นดูเหมือนการแก้ไขเพียงจนกว่าจะเจอการนำเข้าครั้งถัดไป

ทำไมการหันเห interpreter ของระบบจึงเป็นกับดัก

การเปลี่ยน interpreter ค่าเริ่มต้นดึงดูดเพราะดูเหมือนแก้ Traceback ด้วยคำสั่งเดียว มันยังทำลายสมมติฐานที่เครื่องมือ Python ที่แพ็กเกจมาทุกตัวบนโฮสต์สร้างขึ้นมา และความล้มเหลวจะปรากฏช้าลงและในที่ที่ไม่เกี่ยวข้อง

กลไกการเลือกทางเลือกถูกออกแบบมาเพื่อสลับระหว่าง implementation ที่เทียบเท่ากัน ไม่ใช่เพื่อติดตั้งภาษาใหม่กว่าภายใต้โมดูลที่คอมไพล์แล้วเก่ากว่า ส่วนขยายที่คอมไพล์แล้วสร้างสำหรับ ABI ที่เฉพาะเจาะจง ดังนั้นโมดูลที่นำเข้าได้เมื่อวานอาจโหลดไม่ได้วันนี้โดยไม่มีแพ็กเกจใดถูกถอดออกเลย

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

การทดสอบการยอมรับที่แยกกัน

ตอนท้ายควรมีสองการทดสอบ และการผ่านอย่างหนึ่งไม่บอกอะไรเกี่ยวกับอีกอย่าง อย่างแรกคือคำสั่งไคลเอนต์ที่รองรับทำงานกับ interpreter ที่มันถูกแพ็กเกจมา อย่างที่สองคือบริการที่มีสิทธิ์พิเศษสร้างเซสชันและ tunnel ขนส่งทราฟฟิก

openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0

รักษาช่องทางอิสระเข้าสู่เครื่องขณะทำงาน โดยเฉพาะถ้า VPN ขนส่งการเข้าถึงของผู้ดูแลระบบเพียงช่องทางเดียวของคุณ การเปลี่ยน interpreter ของระบบเป็นชนิดของการแก้ไขที่สามารถพรากการเข้าถึงนั้นกลางทาง

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