Git의 gpg가 PATH에서 이기기 때문에 OpenVPN 설치가 실패합니다

Chocolatey에서 서명 또는 키 오류로 죽는 OpenVPN 설치는 대개 다운로드 문제가 아닙니다. 패키지는 gpg를 호출하는 확인 단계를 실행하고, Windows는 그 맨 이름을 PATH를 통해 해석합니다. Git for Windows가 먼저 설치되었다면 함께 제공되는 gpg.exe가 OpenVPN이 기대하는 GnuPG 빌드보다 앞에 놓이고, 잘못된 프로그램이 호출에 응답합니다. 보이는 오류는 그 다른 프로그램이 불평하기로 결정한 내용이며, 그래서 실제 원인을 결코 언급하지 않습니다.

PATH 순서가 어느 gpg가 실행되는지를 결정합니다

Windows에는 실행 파일 이름의 중앙 레지스트리가 없습니다. 프로세스가 전체 경로 없이 gpg를 요청하면 로더는 PATH 항목을 순서대로 훑고 첫 번째 일치를 실행합니다. Git for Windows는 서명된 커밋이 작동하도록 usr/bin 디렉터리 안에 최소한의 GnuPG 빌드를 제공하며, 설치 관리자는 보통 그 디렉터리를 사용자의 PATH 앞부분 가까이에 둡니다.

GnuPG는 자체 디렉터리, 보통 C:\Program Files (x86)\GNU\GnuPG\pub에 설치되며, 그 항목은 목록 뒤쪽에 있거나 사용자의 PATH에서 완전히 빠져 있을 수 있습니다. 두 프로그램은 이름과 명령줄 인터페이스의 상당 부분을 공유하지만 상태는 공유하지 않습니다—Git 빌드는 키링을 다른 곳에서 찾고, 다른 버전일 수 있으며, 설치 관리자가 전달하는 옵션을 받아들이지 않을 수 있습니다. 이 불일치는 서명 또는 키 오류로 나타나며, 이는 잘못된 바이너리가 본 것에 대한 정직한 보고입니다. 메시지 어디에도 로더를 가리키는 내용은 없습니다—로더는 지시받은 대로 정확히 했기 때문입니다.

어느 셸에서 시작하느냐가 결과를 결정하는 이유

상속 규칙이 바로 내면화할 가치가 있는 부분입니다. 자식 프로세스는 자신을 실행한 셸의 환경을 물려받으므로, 중요한 순서는 Chocolatey가 시작되는 순간의 순서이지 수정한 뒤의 순서가 아닙니다.

설정 창에서 PATH를 편집하고 같은 터미널에서 설치를 다시 실행해도 종종 아무것도 바뀌지 않는 이유입니다—터미널이 이전 환경을 유지했기 때문입니다. 편집 후에는 새 셸을 시작하고, 다시 시도하기 전에 그 새 셸에서 where.exe gpg로 확인하십시오. 머신 수준 항목이 사용자 수준 변경을 이길 수 있는 것도 같은 이유입니다—일부 설치 관리자는 머신 PATH 앞에 추가하며 머신 항목은 사용자 항목보다 먼저 평가되기 때문입니다. 두 수준 모두에 GnuPG 경로가 있다면 실제로 어느 쪽을 유지하는지 결정하십시오.

첫 번째 수정: 항목 순서 바꾸기

정확한 수정은 의도한 GnuPG 디렉터리가 이기게 하는 것입니다. 사용자의 환경 변수를 열고 Path를 편집한 뒤 GnuPG pub 디렉터리를 Git 항목 위로 옮기십시오. 그런 다음 새 PowerShell 창을 여십시오—실행 중인 창은 여전히 이전 목록을 들고 있습니다.

대안은 설치를 위한 임시 깨끗한 환경입니다: Git 항목을 제거하고, 새 셸을 열고, choco install openvpn를 실행한 뒤 다시 복원하십시오.

두 접근 방식 모두 같은 이유로 작동하며, 두 번째는 항목을 실제로 복원할 때만 안전합니다. Git의 usr/bin를 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를 한 번 실행하면 전체 루프를 절약합니다.