Pemasangan OpenVPN gagal kerana gpg Git menang pada PATH
Git for Windows membawa gpg.exe sendiri, dan susunan PATH menentukan yang mana dipasang oleh pemasang OpenVPN. Semak dengan where.exe, kemudian susun semula dan bukannya padam.
Pemasangan OpenVPN yang mati di bawah Chocolatey dengan ralat tandatangan atau kunci biasanya bukan masalah muat turun. Pakej menjalankan langkah pengesahan yang memanggil gpg, dan Windows menyelesaikan nama kosong itu melalui PATH. Jika Git for Windows dipasang dahulu, gpg.exe bawaannya terletak di hadapan binaan GnuPG yang dijangka oleh OpenVPN, dan program yang salah menjawab panggilan itu. Ralat yang anda lihat ialah apa yang program lain itu putuskan untuk diadukan, sebab itu ia tidak pernah menyebut punca sebenar.
Susunan PATH menentukan gpg mana yang berjalan
Windows tidak mempunyai daftar pusat nama boleh laku. Apabila proses meminta gpg tanpa laluan penuh, pemuat menelusuri entri PATH mengikut susunan dan menjalankan padanan pertama. Git for Windows membawa binaan GnuPG minimum dalam direktori usr/bin-nya supaya komit yang ditandatangani berfungsi, dan pemasangnya biasanya meletakkan direktori itu berhampiran permulaan PATH pengguna.
GnuPG memasang ke direktori sendiri, biasanya C:\Program Files (x86)\GNU\GnuPG\pub, dan entri itu mungkin lebih jauh dalam senarai atau langsung tiada daripada PATH pengguna. Kedua-dua program berkongsi nama dan sebahagian besar antara muka baris arahan tetapi tidak berkongsi keadaan: binaan Git mencari gegelung kunci di tempat lain, mungkin versi berbeza, dan mungkin tidak menerima pilihan yang dihantar oleh pemasang. Ketidakseragaman itu muncul sebagai ralat tandatangan atau kunci, yang merupakan laporan jujur tentang apa yang dilihat oleh binari yang salah. Tiada apa-apa dalam mesej itu menunjuk kepada pemuat, kerana pemuat melakukan tepat apa yang diberitahu.
Mengapa shell tempat anda bermula menentukan hasilnya
Peraturan pewarisan ialah bahagian yang wajar dihayati. Proses anak menerima persekitaran shell yang melancarkannya, jadi susunan yang penting ialah susunan pada saat Chocolatey bermula, bukan susunan selepas anda membetulkannya.
Itulah sebabnya menyunting PATH dalam tetingkap tetapan dan menjalankan semula pemasangan dalam terminal yang sama selalunya tidak mengubah apa-apa: terminal mengekalkan persekitaran lama. Mulakan shell baharu selepas setiap suntingan, dan sahkan dengan where.exe gpg dalam shell baharu itu sebelum mencuba lagi. Itulah juga sebab entri peringkat mesin boleh mengalahkan perubahan peringkat pengguna, kerana sesetengah pemasang menambah pada permulaan PATH mesin dan entri mesin dinilai sebelum entri pengguna. Jika kedua-dua peringkat mengandungi laluan GnuPG, tentukan yang mana sebenarnya anda selenggara.
Pembetulan pertama: susun semula entri
Pembetulan tepat ialah membiarkan direktori GnuPG yang dimaksudkan menang. Buka pemboleh ubah persekitaran untuk pengguna, sunting Path, dan alihkan direktori pub GnuPG ke atas entri Git. Kemudian buka tetingkap PowerShell baharu, kerana yang sedang berjalan masih memegang senarai lama.
Alternatifnya ialah persekitaran bersih sementara untuk pemasangan: buang entri Git, buka shell baharu, jalankan choco install openvpn, kemudian pulihkannya.
Kedua-dua pendekatan berfungsi atas sebab yang sama, dan yang kedua hanya selamat jika anda benar-benar memulihkan entri itu. Membuang usr/bin Git daripada PATH merosakkan komit yang ditandatangani secara kekal, dan alat seterusnya yang mengharapkan gpg yang berfungsi gagal dengan mesejnya sendiri yang tiada kaitan dengan OpenVPN. Jika anda mengambil laluan sementara, simpan nilai asal Path dalam tiket supaya pemulihan menjadi tampal dan bukan pembinaan semula. Menyusun entri ialah pembetulan yang tahan lama; memadamnya ialah jalan pintas yang mempunyai tarikh luput.
Sahkan, kemudian letakkan semula
Sahkan sebelum dan selepas dalam konteks pengguna yang sama yang akan digunakan oleh Chocolatey. where.exe gpg menyenaraikan setiap padanan mengikut susunan penyelesaian, jadi baris pertama ialah yang akan berjalan; Get-Command gpg -All memberikan jawapan yang sama dengan lebih terperinci dalam PowerShell. Kemudian gpg --version mengesahkan binaan mana yang menjawab.
Jika where.exe masih menyenaraikan salinan Git dahulu, susunan semula itu belum sampai ke sesi tersebut, dan berapa kali pun memasang semula tidak akan membantu. Semak PATH mesin dan pengguna dengan [Environment]::GetEnvironmentVariable('Path','Machine') dan panggilan yang sama dengan 'User', kerana senarai berkesan dibina daripada kedua-duanya. Selepas pemasangan berjaya, semak semula dengan openvpn --version dan mulakan perkhidmatan atau GUI sekali, kerana pakej boleh memasang dengan bersih dan masih meninggalkan perkhidmatan yang tidak akan bermula.
Jika PATH yang disusun dengan betul masih gagal, pemboleh ubah yang tinggal ialah versi pakej. Pakej Chocolatey yang dipinkan mungkin mengharapkan binaan GnuPG atau laluan pemasangan tertentu yang tiada pada mesin anda.
Baca log pakej itu sendiri sebelum menukar apa-apa lagi. C:\ProgramData\chocolatey\logs\chocolatey.log merekodkan baris arahan yang gagal dan direktori tempat ia dijalankan, yang memberitahu anda sama ada panggilan yang gagal itu semakan tandatangan, pengekstrakan atau skrip selepas pemasangan. Perbezaan itulah yang menentukan sama ada anda masih menyahpepijat gpg.
Tabiat yang mencegah pengulangan ialah memperlakukan PATH sebagai keadaan dikongsi dengan susunan yang didokumenkan dan bukannya sebagai beg direktori. Apabila anda memasang alat yang membawa nama binari biasa, semak apa yang dilindunginya dalam shell seterusnya yang anda buka. Kemudian catat susunan yang anda tetapkan, kerana pemasang seterusnya akan menambah padanya dan orang seterusnya akan tertanya-tanya mengapa semakan tandatangan gagal pada mesin yang tiada apa berubah. Satu where.exe sebelum pemasangan menjimatkan keseluruhan gelung.