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

Question

Ambiente corporativo padrão, forçando os clientes a passarem por um servidor proxy por meio 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 se 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 os caracteres especiais mypasswd sendo mapeados em seu código hexadecimal e com o nome de usuário usando o formulário "simples" ou o caminho completo do AD ou o email, etc.

Nenhum dos itens acima funcionou. Alguma idéia sobre o que eu possa estar perdendo, da própria experiência através de coisas não óbvias?

    

Answer 1

Como não tenho acesso ao seu ambiente corporativo específico, não posso fazer um diagnóstico definitivo, mas a primeira coisa que tento é exportar https_proxy e all_proxy com o mesmo valor (observe que o https_proxy pode não ter uma https: URL; tem o que for 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 eu não escreveria isso). Eu me certificaria de que o Safari funcionasse através do proxy e, se você precisar fazer o login no proxy através do Safari, faça isso. Se o Safari não está trabalhando através do proxy, há basicamente uma chance zero de que o Homebrew vá.

Como uma segunda coisa a tentar (embora isso seja voodoo e pode ser apenas o cultivo de carga), você poderia tentar configurá-lo, em vez de usar o http: schema, para o socks5: schema, senão deixar o resto do URL o mesmo. Eu vi este trabalho porque certos proxies são mais voltados para clientes Windows e ainda têm código antigo, e por causa do fraco registro de interoperabilidade entre as pilhas TCP das versões do Windows, o SOCKS era mais confiável.

    

Answer 2

Inacreditável !!! Um enorme DUH da minha parte: tinha duas janelas iTerm abertas ao mesmo tempo - eu estava fazendo a exportação do http_proxy em uma, da CLI, e testando a conectividade na outra (que estava executando outra sessão shell, claro, sem consciência das variáveis exportadas no que eu estava fazendo mudanças) ... não posso acreditar como isso foi estúpido. Desculpe por todo o barulho ... e agradeço a @Trey por ter assumido que eu não era idiota: -)