OSX El Capitan e http_proxy com caminho específico para proxypac

OSX El Capitan e http_proxy com caminho específico para proxypac

Ambiente corporativo padrão, forçando os clientes a passar por um servidor proxy através de um proxypac. Na configuração do OSX está no seguinte formato:

http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

Tentando conectar via CLI, para uma instalação homebrew, e usei (até agora) as seguintes opções:

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

com caracteres especiais mypasswd sendo mapeados em seu código hexadecimal e com nome de usuário usando o formato "simples", ou todo o caminho do AD, ou o e-mail, etc.

Nenhuma das opções acima funcionou. Alguma idéia do que posso estar perdendo, por experiência própria por meio de coisas não óbvias?

Responder1

Como não tenho acesso ao seu ambiente corporativo específico, não posso fazer um diagnóstico definitivo, mas a primeira coisa que tentaria é exportar https_proxye all_proxycom o mesmo valor (observe que https_proxypode não ter uma https:URL; tem o que quer que seja o http_proxyé). Suas várias seleções de valores foram as corretas para tentar (embora eu tenha visto codificações muito estranhas de nome de usuário/senha, então não descartaria isso). Eu garantiria que o Safari funcionasse por meio do proxy e, se você precisar fazer login no proxy via Safari, faça-o. Se o Safari não estiver funcionando por meio do proxy, basicamente não há chance de o Homebrew funcionar.

Como segunda coisa a tentar (embora isso seja vodu e possa ser apenas culto à carga), você pode tentar configurá-lo, em vez de para o http:esquema, para o socks5:esquema, caso contrário, deixe o resto da URL igual. Eu vi isso funcionar porque certos proxies são mais voltados para clientes Windows e ainda possuem código antigo, e devido ao baixo histórico de interoperabilidade entre as pilhas TCP das versões do Windows, o SOCKS era mais confiável.

Responder2

Inacreditável!!! Um grande DUH da minha parte: tinha duas janelas do iTerm abertas ao mesmo tempo - eu estava exportando http_proxy em uma, da CLI, e testando a conectividade na outra (que estava executando outra sessão de shell, é claro, sem consciência das variáveis ​​exportadas naquela em que eu estava fazendo alterações)... não posso acreditar como isso foi estúpido. Desculpe por todo o barulho... e obrigado ao @Trey por presumir que eu não era um idiota :-)

informação relacionada