This is very similar to: https://bugs.mageia.org/show_bug.cgi?id=4156 but I believe it's not the same. The easiest way to replicate this is to set up two Mageia boxs with a local repo(s). They would have M2 or M3 or both repos on both boxes. I put the repos in user "mageia". My repo source is mirrors.kernel.org. So my local repo will be at: /home/mageia/distrib/ LAN IP is: 192.168.1.2 Lets make the password: linux I have also installed Apache on two ( M2 & M3 ) drives such that: /http://192.168.1.2/~mageia/ exists. In the mageia public_html directory I have created the directory /public_html/repo and in that repo directory I have created a soft link back to /home/mageia/distrib/ So what that creates is the same repo at both: ftp://mageia:linux@192.168.1.2//distrib http://192.168.1.2/~mageia/repo/distrib But getting to the ftp repo requires an ID & PW Authentication. My test server features a removable replaceable HD system so I can A <-> B HD's with either M2 or M3. I have created two such drives with working repos for both M2 and M3. Both drives have user mageia ID:mageia PW:linux. The server LAN IP is: 192.168.1.2. The M2 drive is actually the one I have been using since M2 was released. The M3 HD I created right after M3 was released. I copied the M2 & M3 repos from the M2 HD to the M3 HD and rsync'd that up with the mirror at: mirrors.kernel.org Using a client workstation I turned off its HD and am using only the Live-CD's: M2 Live-CD 32-bit KDE M3 Live-CD 32-bit KDE Boot the server with M2 on it. Boot the client with the M2 Live-CD. You can set up the clients repo with either of the following commands: First in an su terminal execute a: urpmi.removemedia -a Then execute either of the following commands: urpmi.addmedia core http://192.168.1.2/~mageia/repo/distrib/2/i586/media/core/release with media_info/hdlist.cz urpmi.addmedia core ftp://mageia:linux@192.168.1.2//distrib/2/i586/media/core/release with media_info/hdlist.cz The client will make contact with the server and properly set up the repo. You can set up the entire repo set using either the http or ftp process. This process works for both the M2 & M3 Live-CD's. Remove the M2 drive from the server and replace it with the M3 drive. Reboot the Client using either the M2 or M3 Live-CD. In an su terminal execute a: urpmi.removemedia -a Then execute the following command: urpmi.addmedia core http://192.168.1.2/~mageia/repo/distrib/2/i586/media/core/release with media_info/hdlist.cz The client will make contact with the server and properly set up the repo. You can set up the entire repo set using the http process. This process works for both the M2 & M3 Live-CD's. In an su terminal execute a: urpmi.removemedia -a Then execute the following command: urpmi.addmedia core ftp://mageia:linux@192.168.1.2//distrib/2/i586/media/core/release with media_info/hdlist.cz This will result in the error: ...retrieving failed: curl failed: exited with 9 no metadata found for medium "core" Effectively indicating that "The server denied login or denied access to the particular resource or directory you wanted to reach" If you replace curl with wget then the command will be: urpmi.addmedia --wget core ftp://mageia:linux@192.168.1.2//distrib/2/i586/media/core/release with media_info/hdlist.cz This will result in the error: ...retrieving failed: wget failed: exited with 8 no metadata found for medium "core_" Effectively the same access error. The same error will be with both the M2 & M3 Live-CD's so long as the server is running M3. But if the server is running M2 everything is fine. I believe that bug 4156 was in the boot.iso code. This time it looks to be in the OS's code itself. Sorry, I do not have another M2/3 repo source that requires authenticaton available to me to test. I suppose you could set this up using Vbox but that would be huge as the repos are over 50GB in size. Using the boot.iso for either M2 or M3 will have the same results. An M2 server will be fine, and M3 server won't work. Reproducible: Steps to Reproduce:
Summary: M3 not responding to urpmi requests requiring a login:password authentication => M3 repo not responding to urpmi requests requiring a login:password authentication
Component: Installer => RPM PackagesSource RPM: (none) => urpmi
This continues to be a problem. Somewhat related to: https://bugs.mageia.org/show_bug.cgi?id=4156 but that was in the boot.iso code. This appears to be in the M3 side code. I've been living with this since M3 released. It's not a biggee as I use HTTP as a fallback. Could someone take a look at it and see if it can be resolved before M4 releases. The present status of M3 boot iso works just fine with ftp servers using anonymous logins. It may be that it is just not accepting numbered IP addresses. This also does not work: ftp/http servers: 192.168.1.2 mageia directory: /mageia/distrib/4/i586 or mageia directory: /~mageia/distrib/4/i586 ftp/http servers: 192.168.1.2 mageia directory: /mageia/distrib/3/i586 or mageia directory: /~mageia/distrib/3/i586 M2 worked just fine and accepted user/password ftp logins Thanks.
This issue continues in M4.
Keywords: (none) => TriagedVersion: 3 => 4Assignee: bugsquad => thierry.vignaudWhiteboard: (none) => MGA3TOO
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: NEW => RESOLVEDResolution: (none) => OLD