3

On Fedora 26 when I do sudo dnf -v update I get the error

>     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'

I configured both my system-wide proxy and the proxy in dnf.conf. Other connections such as the browser work with this proxy. The proxy requires authentication - I have set the needed values in dnf.conf proxy_username and proxy_password.

I also have a .bashrc which sets http_proxy=http://username:password@proxy:port/. Then if I run curl http://download.fedoraproject.org/pub/fedora/linux/updates/26/x86_64/repodata/repomd.xml, it fails with HTTP 407. It works if I add --proxy-ntlm. According to the bugzilla, dnf has been already patched so that it permits NTLM when calling into libcurl.

However, yum additionally used to disable Kerberos/"negotiate" authentication, because in some cases that would be the first option offered, and it would fail where NTLM would work. A patch was offered for this second, but the bug was closed after resolving only the first problem...

How can I get dnf update to work?

  • I know it's annoying, but could you excerpt a greater amount of the output please, to show that this is the only error dnf gives. IIRC I've had to resorted to wireshark to debug some cases. If you can do that, and show the HTTP request which fails, that might provide useful information. – sourcejedi Sep 6 '17 at 11:43
  • That is the only message printed in the terminal. How can I retrieve more relevant logs? – barq Sep 6 '17 at 11:44
  • 1
    It's also possible you would benefit from editing all the repos to use baseurl (commented by default) and comment out all the metalink= magic. That's useful specifically if dnf is retrying with lots of different repos and you want it to be less noisy. It's also what you want if you want your proxy to cache the updates for sharing between computers. – sourcejedi Sep 6 '17 at 11:44
  • I tried commenting out metalink and using baseurl in /etc/yum.repos.d/fedora-updates.repo. Still the same error message. – barq Sep 6 '17 at 11:46
  • If that is literally the only message printed, you can illustrate that by copying from your terminal and including the dnf command as well as the output. (When I want to emphasize that there is no further output, I also include the following shell prompt). I'm prodding you because I don't remember dnf being quite that terse. My memory might be wrong, and as I say I'm not expecting it to be that much more helpful, but it would show the problem you're having more clearly to other people. – sourcejedi Sep 6 '17 at 11:48
2

I finally found a solution. The problem is this bug, which is still not fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1387622

I had to edit /usr/lib/python3.6/site-packages/dnf/repo.py and change the following:

-        h.setopt(librepo.LRO_PROXYAUTH, True)
+        h.setopt(librepo.LRO_PROXYAUTHMETHODS, 8)
  • This was finally fixed in a newer version of dnf. The lines do not need to be changed manually after every update any longer. – barq Sep 25 '18 at 7:26
1

According to the bugzilla, dnf has been already patched so that it permits NTLM when calling into libcurl.

However, yum additionally used to disable Kerberos/"negotiate" authentication, because in some cases that would be the first option offered, and it would fail where NTLM would work. A patch was offered for this second issue, but the bug was closed after resolving only the first problem... Considering NTLM works for you, it is most likely this is your problem. (You can look at the bug to see more details about what the HTTP reply headers would look like in this situation, e.g. if you captured them with Wireshark).

In this case, it seems the only currently available solution is to set up a proxy on your local computer, which converts Basic authentication to NTLM auth, or something like that. See NTLM-APS.

1

in dnf.conf add

proxy=http://cisco-wsa.internal.net:3128
proxy_username=myusername
proxy_password=VeryStrongPassword

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.