OpenVPN kurulumu başarısız oluyor çünkü Git’in gpg’si PATH’te kazanıyor
Git for Windows kendi gpg.exe’sini getirir ve PATH sırası OpenVPN kurulumunun hangisini çalıştıracağını belirler. where.exe ile denetleyin, sonra silmek yerine sıralamayı değiştirin.
Chocolatey altında imza veya anahtar hatasıyla ölen bir OpenVPN kurulumu genellikle indirme sorunu değildir. Paket, gpg çağıran bir doğrulama adımı çalıştırır ve Windows bu çıplak adı PATH üzerinden çözer. Git for Windows önce kurulduysa, beraberindeki gpg.exe OpenVPN’in beklediği GnuPG derlemesinin önünde durur ve çağrıya yanlış program yanıt verir. Gördüğünüz hata, o diğer programın şikâyet etmeye karar verdiği şeydir, bu yüzden gerçek nedeni asla belirtmez.
PATH sırası hangi gpg’nin çalışacağını belirler
Windows’ta çalıştırılabilir adların merkezi bir kaydı yoktur. Bir süreç tam yol olmadan gpg istediğinde yükleyici PATH girdilerini sırayla dolaşır ve ilk eşleşmeyi çalıştırır. Git for Windows imzalı commit’lerin çalışması için usr/bin dizini içinde minimal bir GnuPG derlemesi getirir ve kurucusu genellikle o dizini kullanıcının PATH başlangıcına yakın bir yere koyar.
GnuPG kendi dizinine, genellikle C:\Program Files (x86)\GNU\GnuPG\pub konumuna kurulur ve bu girdi listede daha sonra olabilir veya kullanıcının PATH listesinden tamamen eksik olabilir. İki program bir adı ve komut satırı arayüzünün büyük bir bölümünü paylaşır ama durumlarını paylaşmaz: Git derlemesi anahtarlık dosyasını başka yerde arar, farklı bir sürüm olabilir ve kurucunun geçirdiği seçenekleri kabul etmeyebilir. Bu uyumsuzluk imza veya anahtar hatası olarak ortaya çıkar, bu da yanlış ikili dosyanın ne gördüğüne dair doğru bir rapordur. Mesajda hiçbir şey yükleyiciyi işaret etmez, çünkü yükleyici kendisine söyleneni aynen yapmıştır.
Hangi kabuktan başladığınız sonucu neden belirler
Miras kuralı, özümsenmeye değer kısımdır. Alt süreç onu başlatan kabuğun ortamını alır, bu nedenle önemli olan sıra Chocolatey başladığı andaki sıradır, siz düzelttikten sonraki sıra değil.
Bu yüzden ayarlar penceresinde PATH düzenleyip kurulumu aynı terminalde yeniden çalıştırmak çoğu zaman hiçbir şeyi değiştirmez: terminal eski ortamı korumuştur. Her değişiklikten sonra yeni bir kabuk başlatın ve yeniden denemeden önce o yeni kabukta where.exe gpg ile doğrulayın. Makine düzeyindeki bir girdinin kullanıcı düzeyindeki değişikliği yenebilmesi de aynı nedenledir, çünkü bazı kurucular makinenin PATH başlangıcına ekler ve makine girdileri kullanıcı girdilerinden önce değerlendirilir. Her iki düzeyde de GnuPG yolu varsa, gerçekte hangisini sürdürdüğünüze karar verin.
Birinci düzeltme: girdileri yeniden sıralayın
Kesin düzeltme, amaçlanan GnuPG dizininin kazanmasını sağlamaktır. Kullanıcının ortam değişkenlerini açın, Path öğesini düzenleyin ve GnuPG pub dizinini Git girdilerinin üstüne taşıyın. Ardından yeni bir PowerShell penceresi açın, çünkü çalışan pencere hâlâ eski listeyi tutuyor.
Alternatif, kurulum için geçici temiz bir ortamdır: Git girdilerini kaldırın, yeni bir kabuk açın, choco install openvpn komutunu çalıştırın ve sonra bunları geri yükleyin.
Her iki yaklaşım da aynı nedenle çalışır ve ikincisi yalnızca girdileri gerçekten geri yüklerseniz güvenlidir. Git’in usr/bin dizinini PATH listesinden kaldırmak imzalı commit’leri kalıcı olarak bozar ve çalışan bir gpg bekleyen sonraki araç, OpenVPN ile hiç ilgisi olmayan kendi mesajıyla başarısız olur. Geçici yolu seçerseniz, geri yüklemenin yeniden inşa değil yapıştırma olması için Path öğesinin özgün değerini kayıtta saklayın. Girdileri sıralamak kalıcı düzeltmedir; onları silmek son kullanma tarihi olan bir geçici çözümdür.
Doğrulayın, sonra geri koyun
Chocolatey’nin kullanacağı aynı kullanıcı bağlamında önce ve sonra doğrulayın. where.exe gpg her eşleşmeyi çözümleme sırasına göre listeler, yani ilk satır çalışacak olandır; Get-Command gpg -All PowerShell’de aynı yanıtı daha ayrıntılı verir. Ardından gpg --version hangi derlemenin yanıt verdiğini doğrular.
Eğer where.exe hâlâ önce Git kopyasını listeliyorsa, yeniden sıralama o oturuma ulaşmamıştır ve ne kadar yeniden kurarsanız kurun yardımcı olmaz. Hem makine hem kullanıcı PATH listesini [Environment]::GetEnvironmentVariable('Path','Machine') ile ve aynı çağrıyı 'User' ile denetleyin, çünkü etkin liste ikisinden oluşturulur. Başarılı bir kurulumdan sonra openvpn --version ile yeniden denetleyin ve hizmeti veya GUI’yi bir kez başlatın, çünkü bir paket temiz kurulup yine de başlamayan bir hizmet bırakabilir.
Doğru sıralanmış PATH hâlâ başarısız olursa, kalan değişken paket sürümüdür. Sabitlenmiş bir Chocolatey paketi, makinenizde olmayan belirli bir GnuPG derlemesi veya kurulum yolu bekliyor olabilir.
Paketin kendi günlüğünü okuyun başka bir şeyi değiştirmeden önce. C:\ProgramData\chocolatey\logs\chocolatey.log başarısız olan komut satırını ve çalıştırıldığı dizini kaydeder, bu da başarısız çağrının imza denetimi, çıkarma veya kurulum sonrası betik olup olmadığını söyler. Bu ayrım, hâlâ gpg hata ayıklayıp ayıklamadığınızı belirler.
Tekrarı önleyen alışkanlık, PATH öğesini dizin torbası değil, belgelenmiş sırası olan paylaşılan durum olarak ele almaktır. Yaygın bir ikili adı getiren bir araç kurduğunuzda, açtığınız sonraki kabukta neyi gölgelediğini denetleyin. Ardından vardığınız sırayı yazın, çünkü sonraki kurucu ona ekleyecek ve sonraki kişi hiçbir şeyin değişmediği bir makinede imza denetiminin neden başarısız olduğunu merak edecek. Kurulumdan önce bir where.exe tüm döngüyü kurtarır.