OSX El Capitan и http_proxy с определенным путем к proxypac

Question

Стандартная корпоративная среда, заставляющая клиентов получать через прокси-сервер через proxypac. В конфигурации OSX в следующем формате:

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

Попытка подключения через CLI, для доморощенной установки, и использование (пока) следующих параметров:

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:mypasswd@www.proxy.server.name:8080/proxy_pac_path_to_package.pac

export http_proxy=http://myusername:mypasswd@www.proxy.server.name:8080

со специальными символами mypasswd, отображаемыми в их шестнадцатеричный код, и с именем пользователя, использующим либо "простую" форму, либо весь путь AD, либо электронную почту и т. д.

Ничто из вышеперечисленного не сработало. Есть идеи о том, чего мне не хватает, из собственного опыта через неочевидные вещи?

Answer 1

Поскольку у меня нет доступа к вашей конкретной корпоративной среде, я не могу поставить точный диагноз, но первое, что я попробую, это экспортировать https_proxy и all_proxy с одинаковым значением (обратите внимание, что https_proxy может не иметь https: URL; он имеет значение http_proxy ). Выбранные вами значения были правильными (хотя я видел очень странные кодировки имени пользователя / пароля, поэтому не стал бы это списывать со счетов). Я хотел бы убедиться, что Safari работает через прокси, и если вам нужно войти в прокси через Safari, вы сделаете это. Если Safari не работает через прокси-сервер, практически нет шансов, что это сделает Homebrew.

Во-вторых, попробуйте (хотя это voodoo и может быть просто кеширование груза), вы можете попробовать установить его, вместо http: schema, в socks5: schema, в противном случае остальная часть URL останется прежней. Я видел эту работу, потому что некоторые прокси больше ориентированы на клиентов Windows и все еще содержат старый код, и из-за плохой записи о совместимости между TCP-стеками версий Windows, SOCKS был более надежным.

Answer 2

Невероятно !!! С моей стороны это была огромная работа: два окна iTerm были открыты одновременно - я выполнял экспорт http_proxy в одном из интерфейса командной строки и тестировал подключение в другом (который, конечно же, не выполнял другой сеанс оболочки, не осознавая этого) из экспортированных переменных в той, в которую я вносил изменения) ... не могу поверить, насколько это глупо. Извините за весь шум ... и благодаря @Trey, что я не был идиотом :-)