Standardmäßige Unternehmensumgebung, die Clients dazu zwingt, über einen Proxypac über einen Proxyserver zu gelangen. In der OSX-Konfiguration ist das folgende Format:
http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac
Ich habe versucht, für eine Homebrew-Installation eine Verbindung über die CLI herzustellen und habe (bisher) die folgenden Optionen verwendet:
export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac
export http_proxy=http://www.proxy.server.name:8080
export http_proxy=http://myusername:[email protected]:8080/proxy_pac_path_to_package.pac
export http_proxy=http://myusername:[email protected]:8080
wobei die Sonderzeichen von mypasswd in ihren Hex-Code umgewandelt werden und wobei der Benutzername entweder die „einfache“ Form, der gesamte AD-Pfad, die E-Mail-Adresse usw. verwendet.
Nichts davon hat funktioniert. Irgendeine Idee, was ich möglicherweise übersehen habe, aus eigener Erfahrung durch nicht offensichtliche Dinge?
Antwort1
Da ich keinen Zugriff auf Ihre spezielle Unternehmensumgebung habe, kann ich keine definitive Diagnose stellen, aber als Erstes würde ich versuchen, https_proxyund all_proxymit demselben Wert zu exportieren (beachten Sie, dass das https_proxymöglicherweise keine https:URL hat; es hat, was auch immer das http_proxyist). Ihre verschiedenen Werteauswahlen waren die richtigen, die ich ausprobieren sollte (obwohl ich sehr seltsame Kodierungen von Benutzername/Passwort gesehen habe, also würde ich das nicht abtun). Ich würde sicherstellen, dass Safari über den Proxy funktioniert, und wenn Sie sich über Safari beim Proxy anmelden müssen, tun Sie das. Wenn Safari nicht über den Proxy funktioniert, besteht praktisch keine Chance, dass Homebrew funktioniert.
Als zweites können Sie es versuchen (obwohl das Voodoo ist und vielleicht nur Cargo-Kult ist), indem Sie es statt auf das http:Schema auf das socks5:Schema setzen und den Rest der URL unverändert lassen. Ich habe gesehen, dass das funktioniert, weil bestimmte Proxys eher auf Windows-Clients ausgerichtet sind und noch alten Code haben, und weil die Interoperabilität zwischen den TCP-Stacks der Windows-Versionen schlecht ist, war SOCKS zuverlässiger.
Antwort2
Unglaublich!!! Ein riesiges DUH meinerseits: hatte zwei iTerm-Fenster gleichzeitig geöffnet - ich habe in einem den Export von http_proxy über die CLI durchgeführt und in dem anderen die Konnektivität getestet (in dem natürlich eine andere Shell-Sitzung lief, ohne die exportierten Variablen in der Sitzung zu kennen, in der ich Änderungen vorgenommen habe)... ich kann nicht glauben, wie dumm das war. Tut mir leid für den ganzen Lärm... und danke an @Trey, dass er angenommen hat, ich sei kein Idiot :-)