Comments 12
Это же фактичеки, настройки для использования для любой программы под linux. При чем тут wsl ?
sudo cat <<<EOF >>/etc/apt/apt.conf.d/proxy.conf Acquire::http::Proxy "http://user@example.com:somePassword@http://proxy.example.com:7777";` EOF
А вы уверены, что apt обрадуется такому количеству http в параметре? И для apt (и системы в целом) рекомендуют указывать ещё и https proxy, а не только http. Как для apt, так и для системы. В теории, в .profile можно взять имя пользователя в кавычки — это решит проблему с символом @. Ну и для добавления одной строки извращение с cat проще заменить на простейший echo.
И да. Зачем эта статья на хабре и чем не устроили прошлые?
Вы несколько раз написали «Если логин не содержит @», но вариант «если пароль не содержит символ @» как-то пропустили. А чедь грабли будут одинаковыми, @ поломает схему url-а и в том, и в другом случае.
И, да, wsl из заголовка и текста надо убирать, ничего wsl-особенного вы не написали. Я, уж и правда, ожидал увидеть указание прокси в каком ключе реестра, или еще что-то неожиданное и сакральное.
Не нужно настраивать прокси внутри wsl. Это ужасная практика, потому что когда инструментов внутри wsl станет много, а пароль поменяется — будет больно.
У себя в команде мы почти сразу пришли к сетапу, когда на win-хосте работает cntlm, а внутри wsl определены переменные окружения HTTP_PROXY и HTTPS_PROXY, смотрящие на cntlm. Те инструменты, которые в 2020 игнорируют эти переменные, настраиваются смотреть на cntlm вручную, но их довольно мало.
Согласен. Предлагаемый в статье подход подразумевает ручную замену значений в достаточно большом количестве мест. Предлагаемый вами подход представляется перспективным. Но не смог найти примеров и/или реализовать самостоятельно определение и использование нужных переменных окружения для настройки wget и curl в случае наличия спецсимволов в логине или пароле.
А зачем Вам спецсимволы в пароле? По сути, речь идёт о том, чтобы на win-хосте поднять локальный прокси, на котором авторизация не требуется вовсе, и ходить из wsl на него. И уже на локальном прокси проходить аутентификацию на внешнем.
В случае доменной инфраструктуры внешний прокси скорее всего поддерживает NTLM, и здесь отлично подходит cntlm, который в своем конфиге пароля от доменной учётной записи вовсе не содержит.
Если уж совсем невмоготу, то спецсимволы в пароле можно заменять на hex-значения (url encode), то есть вместо @ будет %40 и так далее.
Было бы прикольно ещё разобрать подробности работы с корпоративным прокси где есть mitm и собственный сертификат
Настройка прокси для WSL (Ubuntu)