gpg ของ Git ชนะบน PATH ทำให้การติดตั้ง OpenVPN ล้มเหลว
Git for Windows มาพร้อม gpg.exe ของตัวเอง และลำดับใน PATH เป็นตัวตัดสินว่าจะรันตัวไหนโดยตัวติดตั้ง OpenVPN ตรวจสอบด้วย where.exe แล้วจัดลำดับใหม่แทนการลบ
การติดตั้ง OpenVPN ที่ตายใต้ Chocolatey ด้วยข้อผิดพลาดเรื่องลายเซ็นหรือคีย์มักไม่ใช่ปัญหาการดาวน์โหลด แพ็กเกจรันขั้นตอนตรวจสอบที่เรียก gpg และ Windows แก้ชื่อเปล่า ๆ นั้นผ่าน PATH ถ้าติดตั้ง Git for Windows ก่อน gpg.exe ที่มาด้วยจะอยู่หน้า GnuPG ที่ OpenVPN คาดหวัง และโปรแกรมผิดตัวคือตัวที่ตอบการเรียก ข้อผิดพลาดที่คุณเห็นคือสิ่งที่โปรแกรมอีกตัวตัดสินใจจะบ่น จึงไม่เคยเอ่ยถึงสาเหตุจริง
ลำดับใน PATH ตัดสินว่า gpg ตัวไหนทำงาน
Windows ไม่มีทะเบียนกลางของชื่อไฟล์ที่รันได้ เมื่อโปรเซสขอ gpg โดยไม่มีพาธเต็ม ตัวโหลดจะไล่รายการใน PATH ตามลำดับและรันตัวแรกที่ตรงกัน Git for Windows แถม GnuPG ขนาดเล็กไว้ในไดเรกทอรี usr/bin เพื่อให้คอมมิตที่ลงนามทำงานได้ และตัวติดตั้งมักวางไดเรกทอรีนั้นไว้ใกล้ต้น PATH ของผู้ใช้
GnuPG ติดตั้งในไดเรกทอรีของตัวเอง ปกติคือ C:\Program Files (x86)\GNU\GnuPG\pub และรายการนั้นอาจอยู่ท้ายรายการหรือหายไปทั้งหมดจาก PATH ของผู้ใช้ ทั้งสองโปรแกรมใช้ชื่อและอินเทอร์เฟซบรรทัดคำสั่งร่วมกันมาก แต่ไม่ใช้สถานะร่วมกัน ตัวของ Git มองหาพวงกุญแจที่อื่น อาจเป็นอีกเวอร์ชัน และอาจไม่รับออปชันที่ตัวติดตั้งส่งมา ความไม่ตรงกันนั้นปรากฏเป็นข้อผิดพลาดลายเซ็นหรือคีย์ ซึ่งเป็นรายงานตามจริงของสิ่งที่ไบนารีผิดตัวเห็น ไม่มีอะไรในข้อความชี้ไปที่ตัวโหลด เพราะตัวโหลดทำตามที่สั่งทุกประการ
ทำไมเชลล์ที่คุณเริ่มจึงกำหนดผลลัพธ์
กฎการสืบทอดคือส่วนที่ควรทำความเข้าใจให้ลึก โปรเซสลูกได้รับสภาพแวดล้อมของเชลล์ที่เปิดมัน ลำดับที่สำคัญจึงเป็นลำดับ ณ วินาทีที่ Chocolatey เริ่ม ไม่ใช่ลำดับหลังคุณแก้
นี่คือเหตุผลที่แก้ PATH ในหน้าตั้งค่าแล้วรันตัวติดตั้งซ้ำในเทอร์มินัลเดิมมักไม่เปลี่ยนอะไร เพราะเทอร์มินัลเก็บสภาพแวดล้อมเก่าไว้ เริ่มเชลล์ใหม่หลังการแก้ไขทุกครั้ง และยืนยันด้วย where.exe gpg ในเชลล์ใหม่นั้นก่อนลองอีกครั้ง นี่เป็นเหตุผลเดียวกันที่รายการระดับเครื่องอาจชนะการเปลี่ยนระดับผู้ใช้ เพราะตัวติดตั้งบางตัวเติมไว้ต้น PATH ของเครื่อง และรายการระดับเครื่องถูกประเมินก่อนรายการของผู้ใช้ ถ้าทั้งสองระดับมีพาธ GnuPG ให้ตัดสินว่าคุณดูแลตัวไหนจริง ๆ
วิธีแก้แรก: จัดลำดับรายการใหม่
วิธีแก้ที่แม่นยำคือทำให้ไดเรกทอรี GnuPG ที่ต้องการชนะ เปิดตัวแปรสภาพแวดล้อมของผู้ใช้ แก้ Path แล้วย้ายไดเรกทอรี pub ของ GnuPG ขึ้นเหนือรายการ Git จากนั้นเปิดหน้าต่าง PowerShell ใหม่ เพราะตัวที่รันอยู่ยังถือรายการเก่า
ทางเลือกคือสภาพแวดล้อมสะอาดชั่วคราวสำหรับการติดตั้ง เอารายการ Git ออก เปิดเชลล์ใหม่ รัน choco install openvpn แล้วคืนรายการเหล่านั้น
ทั้งสองวิธีได้ผลด้วยเหตุผลเดียวกัน และวิธีที่สองปลอดภัยเฉพาะเมื่อคุณคืนรายการจริง ๆ การลบ usr/bin ของ Git ออกจาก PATH ทำให้คอมมิตที่ลงนามเสียหายถาวร และเครื่องมือถัดไปที่คาดหวัง gpg ที่ใช้งานได้จะล้มเหลวด้วยข้อความของมันเองซึ่งไม่เกี่ยวกับ OpenVPN ถ้าเลือกทางชั่วคราว ให้เก็บค่าเดิมของ Path ไว้ในตั๋ว เพื่อให้การคืนค่าเป็นการวาง ไม่ใช่การสร้างใหม่ การจัดลำดับรายการคือการแก้ที่ยั่งยืน การลบคือทางลัดที่มีวันหมดอายุ
ตรวจสอบ แล้วคืนกลับ
ตรวจสอบก่อนและหลังในบริบทผู้ใช้เดียวกับที่ Chocolatey จะใช้ where.exe gpg แสดงทุกจุดที่ตรงกันตามลำดับการแก้ปัญหา บรรทัดแรกคือตัวที่จะรัน Get-Command gpg -All ให้คำตอบเดียวกันพร้อมรายละเอียดมากกว่าใน PowerShell จากนั้น gpg --version ยืนยันว่าไบนารีตัวไหนตอบ
ถ้า where.exe ยังแสดงสำเนาของ Git เป็นตัวแรก การจัดลำดับยังไปไม่ถึงเซสชันนั้น และการติดตั้งซ้ำกี่ครั้งก็ไม่ช่วย ตรวจทั้ง PATH ระดับเครื่องและผู้ใช้ด้วย [Environment]::GetEnvironmentVariable('Path','Machine') และเรียกแบบเดียวกันด้วย 'User' เพราะรายการที่มีผลประกอบจากทั้งสอง หลังติดตั้งสำเร็จ ให้ตรวจซ้ำด้วย openvpn --version และเริ่มบริการหรือ GUI หนึ่งครั้ง เพราะแพ็กเกจอาจติดตั้งสะอาดแต่ทิ้งบริการที่ไม่ยอมเริ่ม
ถ้า PATH ที่จัดลำดับถูกต้องยังล้มเหลว ตัวแปรที่เหลือคือเวอร์ชันแพ็กเกจ Chocolatey ที่ปักหมุดไว้อาจคาดหวัง GnuPG หรือพาธติดตั้งเฉพาะที่เครื่องคุณไม่มี
อ่านล็อกของแพ็กเกจเอง ก่อนเปลี่ยนอย่างอื่น C:\ProgramData\chocolatey\logs\chocolatey.log บันทึกบรรทัดคำสั่งที่ล้มเหลวและไดเรกทอรีที่มันรัน ซึ่งบอกคุณว่าการเรียกที่ล้มเหลวเป็นการตรวจลายเซ็น การแตกไฟล์ หรือสคริปต์หลังติดตั้ง ความต่างนี้ตัดสินว่าคุณยังดีบัก gpg อยู่หรือไม่
นิสัยที่กันการเกิดซ้ำคือมอง PATH เป็นสถานะร่วมที่มีลำดับบันทึกไว้ ไม่ใช่ถุงไดเรกทอรี เมื่อติดตั้งเครื่องมือที่พกชื่อไบนารีทั่วไป ให้ตรวจว่ามันบังอะไรในเชลล์ถัดไปที่คุณเปิด จากนั้นจดลำดับที่คุณลงเอยไว้ เพราะตัวติดตั้งถัดไปจะต่อท้าย และคนถัดไปจะสงสัยว่าทำไมการตรวจลายเซ็นล้มเหลวบนเครื่องที่ไม่มีอะไรเปลี่ยน where.exe หนึ่งครั้งก่อนติดตั้งประหยัดทั้งวง