This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 503128 - mirrormanager metalink w/ invalid params doesn't return XML
mirrormanager metalink w/ invalid params doesn't return XML
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: mirrormanager (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Matt Domsch
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 00:03 EDT by Matt Domsch
Modified: 2009-08-03 18:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 500439
Environment:
Last Closed: 2009-08-03 18:17:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2009-05-29 00:03:45 EDT
MM should return the "empty" XML document on error if metalink is requested.  Right now it sometimes returns XML (if the directory can't be found), or returns stupid plain text for other invalid parameters (missing one of repo or arch, ...).


+++ This bug was initially created as a clone of Bug #500439 +++

I can't get the traceback because of another bug blocking the save dialog, but the last lines is:

IOError: [Error 2] No such file or directory: '/mnt/sysimage/var/cache/yum/updates/repomd.xml'

tty1 shows:
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-frawhide@arch-x86_64 error was
File /mnt/sysimage/var/cache/yum/updates/metalink.xml.tmp is not XML


So there is multiple problems.  1) the "frawhide" thing, we could probably work with that in mirrormanager.  Release is rawhide so yeah.  The second thing is we shouldn't traceback when this hits, we should fail gracefully.

--- Additional comment from clumens@redhat.com on 2009-05-13 09:15:14 EDT ---

*** Bug 500526 has been marked as a duplicate of this bug. ***

--- Additional comment from clumens@redhat.com on 2009-05-13 14:06:48 EDT ---

This should be fixed in the next build of anaconda, though I think Jeremy's planning on doing something in yum to prevent us from ever getting an IOError.

--- Additional comment from petersen@redhat.com on 2009-05-14 20:37:07 EDT ---

I still see this with -52 btw.

--- Additional comment from petersen@redhat.com on 2009-05-27 19:21:44 EDT ---

When will it say "Fedora 11 Updates" in the anaconda repo list?

Anyway anaconda is still getting confusing with "Fedora development - Updates" with anaconda -56.  No obvious backtrace but hangs.

tty1 still says:

Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-fdevelopment&arch=i386 error was
File /mnt/sysimage/var/cache/yum/updates/metalink.xml.tmp is not XML

Anyway I also opened https://fedorahosted.org/mirrormanager/ticket/12 in the hope the MM might handle this more gracefully too.

--- Additional comment from jkeating@redhat.com on 2009-05-27 19:36:25 EDT ---

It'll say Fedora 11 Updates when it's composed as Fedora 11.

--- Additional comment from matt_domsch@dell.com on 2009-05-28 00:03:24 EDT ---

the updates*-fdevelopment metalinks now point to -f11.

--- Additional comment from petersen@redhat.com on 2009-05-28 03:22:59 EDT ---

Thanks Matt - that helps a lot.

Dunno if we should open another bug for the non-xml case?

--- Additional comment from matt_domsch@dell.com on 2009-05-28 08:31:43 EDT ---

Jens, can you elaborate?  On the mirrorlist=... non-metalink, the behavior will be exactly the same from MM's perspective.  The redirect happens early, long before the output format is decided upon.

--- Additional comment from petersen@redhat.com on 2009-05-28 19:28:34 EDT ---

(In reply to comment #8)
> Jens, can you elaborate?  On the mirrorlist=... non-metalink, the behavior will
> be exactly the same from MM's perspective.  The redirect happens early, long
> before the output format is decided upon.  

Matt, I guess the problem is that the error page was not valid XML, which confused anaconda - so I dunno if MM should output valid XML even if there is an error or anaconda should handle the text error output (non-XML) better - I suspect probably the latter?  Otherwise probably hard to separate them?

--- Additional comment from matt_domsch@dell.com on 2009-05-28 19:36:16 EDT ---

MM returns an "empty" xml document and HTTP 404 in the event of a failed request.

    doc += '<?xml version="1.0" encoding="utf-8"?>\n'
    doc += '<!--\n'
    doc += '%s/%s not found or has no metalink\n' % (directory, file)
    doc += '-->\n'


That's all I could think to do in MM.

--- Additional comment from petersen@redhat.com on 2009-05-28 23:50:06 EDT ---

How about:

https://mirrors.fedoraproject.org/metalink?repo=updates-released-f11
or https://mirrors.fedoraproject.org/metalink?repo=updates-released-flinux&arch=i386
?
Comment 1 Bug Zapper 2009-06-09 12:44:53 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Matt Domsch 2009-08-03 18:17:29 EDT
Fixed in upstream commit 2f698c8027b88597bbdef9712dee43e6e9d48e18

Note You need to log in before you can comment on or make changes to this bug.