Geoff Teale wrote:
I do agree that some dynamic look-up of mirrors would be a much better solution than having users edit files in /etc.
Considering that the default urls pointing back to redhat.com are actually redirects, it seems plausible to me that there is some intent to be able to provide some dynamic mirror rotation behind those default redirect urls...though i've seen no actually discussion confirming my deductive powers. And if the right people haven't already thought that far ahead, i hope they don't have me /dev/null'd in their procmail filters and have a light bulb moment. I certainly don't take credit for the idea...but it seems a pretty obvious use of the redirect urls. Though I have no idea if 'infrastructure' is in place for that, nor do I claim a full comprehensive of any ancillitory concerns like security or syncing issues and what the current view from the official mirror maintainers about being part of a round robin redirect. It could be more complicated than i think it is....but I'd love to here informed opinion on the matter..even if its just a chorus of rasberries.
Of course a client side selection of mirrors would also be useful. But here you have decisions to be made about when the user gets presented a choice, is this first boot worthy?...and whether the mirror list you get to choose from is a static one or is pulled from a central location at selection time. I'd imagine the specifics about how a client would actually negotiate a mirror list would be best left to the specific mailinglist associated with the client tool in question. Though having an official mirrorlist xml file format or equivalent for tools to parse would be a trivial but noteworthy discussion. Having all the tools agree to use the same mirror file format would be nice.
Then there is the 3rd option..which i think is going to be a much more lively debate. About having a point and click way for people to go to a website of mirrors (or even 3rd party repos) click a link..and configure their update tool. This opens up things to have community webpages of 'unofficial' lists of repositories like livna which cant be official spoken of in the distro because of US legal constraints. But I bet someone has a rational argument saying this sort of things presents a higher security risk. But I certainly don't know how to evaluate the risk of this in a selinux powered FC2 world(okay I admit i wouldn't know how to evaluate the security risk in an un-selinux FC1 world...but I hope selinux affects the security of this sort of action.) I don't expect all the tool writers to agree that this sort of thing is appropriate...but it seems to fit in with how up2date is suppose to be used, so it seems appropriate for consideration for whatever is going to be the up2date gui equivalent in fc2.
-jef
Le mer 14/01/2004 à 04:29, Jef Spaleta a écrit :
Geoff Teale wrote:
I do agree that some dynamic look-up of mirrors would be a much better solution than having users edit files in /etc.
Considering that the default urls pointing back to redhat.com are actually redirects, it seems plausible to me that there is some intent to be able to provide some dynamic mirror rotation behind those default redirect urls...
1. Redirects are useless for most repositories out there - they mostly get their stuff on an http/ftp server they don't control so they can not do this kind of magic
2. There is absolutely no need for the procedure to be interactive, except for rare cases where there is a need for a manual override. Just feed the download manager a list of mirrors and let it handle it, just like you can feed ntpd a list of servers and it will select by itself the best server to use for syncs. When non-technical considerations like price of international downloads (in some countries) must be taken into account, allow the user to express mirror preferences (just like ntp.conf allows the prefer keyword). The user often does not have any specific knowledge of what mirror will be best for him - in fact he will do a poorer job than a software helper, since he will be too lazy to keep exact stats of download speeds/mirror freshness/corruption occurrences and these are the factors to take into account when you choose a mirror (not the pretty url).
Cheers,