Homebrew zet het OpenVPN-binary in sbin, niet in je PATH

De installatie eindigt, brew zegt dat openvpn er is, en de shell antwoordt command not found. Het binary bestaat, het staat in een map waarvan de shell nooit iets is verteld. Homebrew linkt binaries in daemonstijl naar de sbin-map van het prefix, en een standaard macOS-PATH bevat meestal de bin-map en niet de sbin-map. Niets is kapot, en geen herinstallatie zal dat veranderen.

Vier controles bevestigen het mechanisme voordat je welk shellbestand dan ook bewerkt.

Wat de formule werkelijk installeert

De openvpn-formule bouwt een commandoregel-daemon, dus het uitvoerbare bestand belandt onder sbin in plaats van bin. Homebrew linkt dat binary vervolgens naar de sbin-map van het prefix, en daarom werkt "$(brew --prefix)/sbin/openvpn" --version terwijl een kale aanroep dat niet doet. De geversioneerde Cellar-map bevat ook een kopie, en dat pad in een opstartbestand zetten is de manier waarop een machine na een upgrade aan een oude build vast blijft zitten.

De symlink van het prefix is het stabiele pad. Het Cellar-pad is een implementatiedetail met een versienummer erin.

Vraag het Homebrew, niet het bestandssysteem

Begin bij de pakketbeheerder, want die weet welke installatie de formule bezit: command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Als de laatste een pad afdrukt, is de formule aanwezig en gaat de vraag enkel over resolutie. Als hij niets afdrukt, zoekt de shell op de verkeerde plek naar een pakket dat nooit is geïnstalleerd, en dat is een ander probleem met een andere oplossing.

Twee Homebrew-installaties op één machine is waar dit het meest uitmaakt: de brew die antwoordt is niet noodzakelijk de brew die installeerde.

Waarom de shell sbin niet ziet

Een login-shell bouwt PATH uit de systeemstandaarden plus alles wat je opstartbestanden toevoegen. Homebrew bin wordt gewoonlijk toegevoegd en Homebrew sbin gewoonlijk niet, dus elk commando werkt behalve de daemons. command -v openvpn dat niets teruggeeft terwijl het pad met prefix een versie teruggeeft, is de hele diagnose in twee commando's. Bevestig met ls -l "$(brew --prefix)/sbin/openvpn" dat de map de link echt bevat.

Een ontbrekende link is een ander defect dan een ontbrekende PATH-regel, en slechts één van beide wordt verholpen door een shellbestand te bewerken.

Herstel het pad één keer, op één plek

Voor een snelle test in de huidige shell zet eval "$(brew shellenv)" de installatievariabelen en zet beide mappen vooraan. Voor een blijvende regeling zet je de shellenv-regel in het ene opstartbestand dat je shell leest voor de loginmodus die je gebruikt, in plaats van exports over bash- en zsh-bestanden te strooien.

Open daarna een nieuwe terminal en herhaal de versiequery, want een gecachte shell blijft het oude PATH melden.

Houd de ontdekking gescheiden van de dienst

Een binary vinden is niet hetzelfde als een VPN-dienst draaien. Openvpn automatisch starten voegt eisen toe voor profiel, inloggegevens, rechten en levenscyclus die de pakketontdekking nooit heeft aangeraakt. Tunnelblick levert ook zijn eigen engine mee, dus de versie die je net hebt afgedrukt heeft misschien niets te maken met de versie die de toepassing gebruikt.

Noteer welk uitvoerbaar bestand de versie-uitvoer heeft geproduceerd. Die ene regel bespaart een uur de volgende keer dat twee versies het oneens zijn.