#10766 dl.fedoraproject.org serves qcow2 disk images as application/x-troff-man instead of application/octet-stream
Closed: Fixed 2 years ago by smooge. Opened 2 years ago by berrange.

For some reason, when fetching qcow2 disk images from dl.fedoraproject.org they are served with the application/x-troff-man mimetype:

$ wget  https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/aarch64/images/Fedora-Cloud-Base-30-1.2.aarch64.qcow2
--2022-06-14 11:31:33--  https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/aarch64/images/Fedora-Cloud-Base-30-1.2.aarch64.qcow2
Resolving dl.fedoraproject.org (dl.fedoraproject.org)... 38.145.60.23, 38.145.60.24, 38.145.60.22
Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.60.23|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 326107136 (311M) [application/x-troff-man]
Saving to: ‘Fedora-Cloud-Base-30-1.2.aarch64.qcow2’

There is no specific qcow2 disk image mime type, but picking x-troff-man is pretty bizarre.

More typically servers will offer disk images up as application/octet-stream

Describe what you would like us to do:

Check the configuration of dl.fedoraproject.org to see if there's a reason why disk images are being served claiming they're man pages. Ideally serve them as application-octet-stream instead.

This isn't a particularly troublesome problem. It is just something wierd we noticed when writing functional tests in libosinfo to validate that URLs for disk images we track are still valid (https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/470).


When do you need this to be done by? (YYYY/MM/DD)

Not time critical



This comes from the mailcap mime.types file

application/x-troff-man                         man 1 2 3 4 5 6 7 8

there isn't an entry for qcow so it sees the file ends with 2 and goes with that.

Metadata Update from @smooge:
- Issue assigned to smooge

2 years ago

Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: downloads, low-gain, low-trouble, ops

2 years ago

Fix 95c6eea54ae007b1df88fa1b0042434f687844d9 ansible seems to have worked on the box you were having problems with earlier:

[smooge@linode01 post]$ wget  https://dl03.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/aarch64/images/Fedora-Cloud-Base-30-1.2.aarch64.qcow2
--2022-06-14 12:33:41--  https://dl03.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/aarch64/images/Fedora-Cloud-Base-30-1.2.aarch64.qcow2
Resolving dl03.fedoraproject.org... 38.145.60.24
Connecting to dl03.fedoraproject.org|38.145.60.24|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 326107136 (311M) [application/octet-stream]
Saving to: “Fedora-Cloud-Base-30-1.2.aarch64.qcow2”

100%[====================================================================================================================================================>] 326,107,136 28.3M/s   in 7.3s    

2022-06-14 12:33:49 (42.4 MB/s) - “Fedora-Cloud-Base-30-1.2.aarch64.qcow2” saved [326107136/326107136]

I am pushing this to all dl servers

That's great, thank you very much for such a quick response :-)

This should be fixed on all dl servers.

Metadata Update from @smooge:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Log in to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog