Entorno corporativo estándar, que obliga a los clientes a acceder a un servidor proxy a través de un proxypac. En la configuración de OSX está en el siguiente formato:
http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac
Intenté conectarme a través de CLI, para una instalación casera, y usé (hasta ahora) las siguientes opciones:
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
con los caracteres especiales mypasswd asignados a su código hexadecimal y con el nombre de usuario utilizando el formulario "simple", la ruta AD completa, el correo electrónico, etc.
Nada de lo anterior funcionó. ¿Alguna idea de lo que me puedo estar perdiendo, desde la propia experiencia a través de cosas no obvias?
Respuesta1
Como no tengo acceso a su entorno corporativo particular, no puedo hacer un diagnóstico definitivo, pero lo primero que intentaría es exportar https_proxyy all_proxycon el mismo valor (tenga en cuenta que puede https_proxyno tener https:URL; tiene lo que sea). el http_proxyes). Sus diversas selecciones de valores fueron las correctas para probar (aunque he visto codificaciones muy extrañas de nombre de usuario/contraseña, así que no lo descartaría). Me aseguraría de que Safari funcione a través del proxy y, si necesita iniciar sesión en el proxy a través de Safari, hágalo. Si Safari no funciona a través del proxy, básicamente hay cero posibilidades de que Homebrew lo haga.
Como segunda cosa que puedes intentar (aunque esto es vudú y puede ser simplemente un culto a la carga), podrías intentar configurarlo, en lugar de hacerlo en el http:esquema, en el socks5:esquema; de lo contrario, dejar el resto de la URL igual. He visto que esto funciona porque ciertos servidores proxy están más orientados a clientes de Windows y todavía tienen código antiguo, y debido al pobre historial de interoperabilidad entre las pilas TCP de las versiones de Windows, SOCKS era más confiable.
Respuesta2
¡¡¡Increíble!!! Un gran DUH de mi parte: tenía dos ventanas de iTerm abiertas al mismo tiempo: estaba exportando http_proxy en una, desde la CLI, y probando la conectividad en la otra (que estaba ejecutando otra sesión de shell, por supuesto, sin conocimiento). de las variables exportadas en aquella en la que estaba haciendo cambios)... no puedo creer lo estúpido que fue esto. Perdón por todo el ruido... y gracias a @Trey por asumir que no era un idiota :-)