No Fedora 26, quando faço sudo dnf -v update , recebo o erro
> Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache,
> needs-restarting, playground, repoclosure, repograph, repomanage,
> reposync, system-upgrade
> DNF version: 2.6.3
> cachedir: /var/cache/dnf
> Cannot download 'http://download.fedoraproject.org/pub/fedora/linux/updates/26/x86_64/':
> Cannot download repomd.xml: Cannot download repodata/repomd.xml: All
> mirrors were tried.
> Error: Failed to synchronize cache for repo 'updates'
Eu configurei meu proxy para todo o sistema e o proxy no dnf.conf. Outras conexões, como o navegador, funcionam com esse proxy. O proxy requer autenticação - defini os valores necessários em dnf.conf proxy_username e proxy_password .
Eu também tenho um .bashrc que define http_proxy=http://username:password@proxy:port/ . Então, se eu executar curl http://download.fedoraproject.org/pub/fedora/linux/updates/26/x86_64/repodata/repomd.xml , ele falhará com o HTTP 407. Funcionará se eu adicionar --proxy-ntlm . De acordo com o bugzilla , dnf já foi corrigido para permitir NTLM ao chamar libcurl .
No entanto, yum adicionalmente usado para desativar a autenticação Kerberos / "negociar", porque, em alguns casos, seria a primeira opção oferecida e falharia onde o NTLM funcionaria. Um patch foi oferecido para este segundo, mas o bug foi fechado depois de resolver apenas o primeiro problema ...
Como posso fazer com que dnf update funcione?
Eu finalmente encontrei uma solução. O problema é esse bug, que ainda não está corrigido: link
Eu tive que editar /usr/lib/python3.6/site-packages/dnf/repo.py e mudar o seguinte:
- h.setopt(librepo.LRO_PROXYAUTH, True)
+ h.setopt(librepo.LRO_PROXYAUTHMETHODS, 8)
De acordo com o bugzilla , o dnf já foi corrigido para permitir o NTLM ao chamar em libcurl .
No entanto, yum adicionalmente usado para desativar a autenticação Kerberos / "negociar", porque, em alguns casos, seria a primeira opção oferecida e falharia onde o NTLM funcionaria. Um patch foi oferecido para este segundo problema, mas o bug foi fechado depois de resolver apenas o primeiro problema ... Considerando que o NTLM funciona para você, é bem provável que esse seja o seu problema. (Você pode ver o bug para ver mais detalhes sobre como os cabeçalhos de resposta HTTP se pareceriam nessa situação, por exemplo, se você os capturou com o Wireshark).
Neste caso, parece que a única solução atualmente disponível é configurar um proxy em seu computador local, que converte autenticação básica em autenticação NTLM ou algo parecido. Veja NTLM-APS .
no dnf.conf adicione
proxy=http://cisco-wsa.internal.net:3128
proxy_username=myusername
proxy_password=VeryStrongPassword