Can anyone think of a good reason why we should not make fastestmirror a direct dep for yum ? Its something that is well worth having and in 90%[1] of the cases, it will improve the user experience.
- KB
[1] Number pulled out of thin air - I have no facts or numbers to back that up.
On 6/12/08, Karanbir Singh mail-lists@karan.org wrote:
Can anyone think of a good reason why we should not make fastestmirror a direct dep for yum ? Its something that is well worth having and in 90%[1] of the cases, it will improve the user experience.
- KB
[1] Number pulled out of thin air - I have no facts or numbers to back that up.
nope would save me once less configuration step on every new install
mike
On 12/06/2008, Michael Simpson mikie.simpson@gmail.com wrote:
nope would save me once less configuration step on every new install
Seconded.
Alan.
Alan Bartlett wrote:
On 12/06/2008, *Michael Simpson* <mikie.simpson@gmail.com mailto:mikie.simpson@gmail.com> wrote:
nope would save me once less configuration step on every new installSeconded.
Alan.
Third'eded ;-)
I would love to see fastestmirror (along with skip-broken) automatically included, however we should probably mention in the release notes that if you share kickstart files between upstream and CentOS (as I do), you will receive a warning box on screen during the automated installing you that the "yum-fastestmirror" is not a recognised package "would you like to skip it and continue, or cancel the installation?", which breaks the un-attended nature of an un-attended install.
I still think it should be included, but mentioned in the release notes.
Jason_Meers
on 6-12-2008 6:10 AM Jason_Meers spake the following:
Alan Bartlett wrote:
On 12/06/2008, *Michael Simpson* <mikie.simpson@gmail.com mailto:mikie.simpson@gmail.com> wrote:
nope would save me once less configuration step on every new installSeconded.
Alan.
Third'eded ;-)
I would love to see fastestmirror (along with skip-broken) automatically included, however we should probably mention in the release notes that if you share kickstart files between upstream and CentOS (as I do), you will receive a warning box on screen during the automated installing you that the "yum-fastestmirror" is not a recognised package "would you like to skip it and continue, or cancel the installation?", which breaks the un-attended nature of an un-attended install.
I still think it should be included, but mentioned in the release notes.
Jason_Meers
But if it was automatically included, you could leave it out of your kickstart scripts and no more messages. A plus for you!
On Thu, Jun 12, 2008 at 3:10 PM, Jason_Meers jason_meers@blueyonder.co.uk wrote:
Alan Bartlett wrote:
Third'eded ;-)
I would love to see fastestmirror (along with skip-broken) automatically included, however we should probably mention in the release notes that if you share kickstart files between upstream and CentOS (as I do), you will receive a warning box on screen during the automated installing you that the "yum-fastestmirror" is not a recognised package "would you like to skip it and continue, or cancel the installation?", which breaks the un-attended nature of an un-attended install.
I still think it should be included, but mentioned in the release notes.
Jason_Meers
yum-fastestmirror does not work behind some restrictive (oppresive?) firewall configuration. Also, at least some time ago, fastestmirror was very address-space hungry, and caused yum to die if ulimit on address-space or stack-spaceset set to anything below 1Gig or more (well, that was on fedora with a very long list of mirrors, and fastestmirror created a large number of thread, perhaps one for a mirror).
I would second that mentioning in release notes is needed.
Wojtek
Wojciech Pilorz wrote:
yum-fastestmirror does not work behind some restrictive (oppresive?) firewall configuration.
if yum itself is able to make http/ftp connects to a remote host, I dont see why yum-fastestmirror might have an issue, can you provide some specifics about what broke and how ?
Also, at least some time ago, fastestmirror was very address-space hungry, and caused yum to die if ulimit on address-space or stack-spaceset set to anything below 1Gig or more (well, that was on fedora with a very long list of mirrors, and fastestmirror created a large number of thread, perhaps one for a mirror).
Well, this isnt Fedora. So if you have an issue on CentOS with something similar its worth looking at.
I would second that mentioning in release notes is needed.
Thats on the wiki, so feel free to add it there :D Although I'd imagine there is already something there about yum and the fact that it now depends on yum-fastestmirror.
- KB
On Tue, Jun 17, 2008 at 4:12 PM, Karanbir Singh mail-lists@karan.org wrote:
Wojciech Pilorz wrote:
yum-fastestmirror does not work behind some restrictive (oppresive?) firewall configuration.
if yum itself is able to make http/ftp connects to a remote host, I dont see why yum-fastestmirror might have an issue, can you provide some specifics about what broke and how ?
I have an environment where access to Internet is filtered, and only allowed through a squid proxy (and DNS queries only to a local DNS server). yum needs proxy line in config file to work at all.
If I run yum-fastestmirror in such environment, /var/cache/yum/timedhosts.txt contains 99999999999 in each entry (as direct connect to remote site always fails). So yum still does work, just the timing information is useless.
Also, at least some time ago, fastestmirror was very address-space hungry, and caused yum to die if ulimit on address-space or stack-spaceset set to anything below 1Gig or more (well, that was on fedora with a very long list of mirrors, and fastestmirror created a large number of thread, perhaps one for a mirror).
Well, this isnt Fedora. So if you have an issue on CentOS with something similar its worth looking at.
Fedora had at some moment over 100 mirrors in mirrorlist returned to yum. So when yum-fastestmirror decided it needs to create / recreate timedhosts file, it started that many threads at once, each allocating some 15 MB of stack space, IIRC. It seems CentOS mirrorlist returned to yum contains not more than 10-15 entries, so this should not be a problem (if the number of mirrors yum gets is always that low on CentOS).
Thank you,
Wojtek
Wojciech Pilorz wrote:
If I run yum-fastestmirror in such environment, /var/cache/yum/timedhosts.txt contains 99999999999 in each entry (as direct connect to remote site always fails). So yum still does work, just the timing information is useless.
This is interesting, so fastest mirror is unable to connect to a remote host where yum itself is able to connect to the same machine with no change in proxy knowledge ?
Is that what you are saying here. If so, I'd really like to look into this.
It seems CentOS mirrorlist returned to yum contains not more than 10-15 entries, so this should not be a problem (if the number of mirrors yum gets is always that low on CentOS).
The centos mirrorlist side will try and give you a small set of mirrors, all of which should work for your given IP.
On Wed, Jun 18, 2008 at 1:05 AM, Karanbir Singh mail-lists@karan.org wrote:
Wojciech Pilorz wrote:
If I run yum-fastestmirror in such environment, /var/cache/yum/timedhosts.txt contains 99999999999 in each entry (as direct connect to remote site always fails). So yum still does work, just the timing information is useless.
This is interesting, so fastest mirror is unable to connect to a remote host where yum itself is able to connect to the same machine with no change in proxy knowledge ?
Is that what you are saying here. If so, I'd really like to look into this.
Yes. It seems fastestmirror tries to just open connection to the host machine, without using proxy protocol , while yum connects to the proxy server as proxy config lines defines. And the firewall does not allow direct connections to the outside world.
It seems CentOS mirrorlist returned to yum contains not more than 10-15 entries, so this should not be a problem (if the number of mirrors yum gets is always that low on CentOS).
The centos mirrorlist side will try and give you a small set of mirrors, all of which should work for your given IP.
That is very cool!
Best regards,
Wojtek
Wojciech Pilorz wrote:
On Tue, Jun 17, 2008 at 4:12 PM, Karanbir Singh mail-lists@karan.org wrote:
Wojciech Pilorz wrote:
yum-fastestmirror does not work behind some restrictive (oppresive?) firewall configuration.
if yum itself is able to make http/ftp connects to a remote host, I dont see why yum-fastestmirror might have an issue, can you provide some specifics about what broke and how ?
I have an environment where access to Internet is filtered, and only allowed through a squid proxy (and DNS queries only to a local DNS server). yum needs proxy line in config file to work at all.
If I run yum-fastestmirror in such environment, /var/cache/yum/timedhosts.txt contains 99999999999 in each entry (as direct connect to remote site always fails). So yum still does work, just the timing information is useless.
right ... and we are going to look at that. But, in that case, all the mirrors have the same time. This means that the "yum selection method" that is called out in the config file (random or in order) will be used as if you did not have fastestmirror installed.
<snip>
On Wed, Jun 18, 2008 at 2:37 PM, Johnny Hughes johnny@centos.org wrote:
Wojciech Pilorz wrote:
On Tue, Jun 17, 2008 at 4:12 PM, Karanbir Singh mail-lists@karan.org wrote:
Wojciech Pilorz wrote:
yum-fastestmirror does not work behind some restrictive (oppresive?) firewall configuration.
if yum itself is able to make http/ftp connects to a remote host, I dont see why yum-fastestmirror might have an issue, can you provide some specifics about what broke and how ?
I have an environment where access to Internet is filtered, and only allowed through a squid proxy (and DNS queries only to a local DNS server). yum needs proxy line in config file to work at all.
If I run yum-fastestmirror in such environment, /var/cache/yum/timedhosts.txt contains 99999999999 in each entry (as direct connect to remote site always fails). So yum still does work, just the timing information is useless.
right ... and we are going to look at that. But, in that case, all the mirrors have the same time. This means that the "yum selection method" that is called out in the config file (random or in order) will be used as if you did not have fastestmirror installed.
As a workaround for fastestmirror problems, I used to copy timedhosts.txt file from another machine with similar connectivity and authorised to have direct connections to mirror sites. Then I had to touch it periodically to avoid recreating with useless contents by fastestmirror on affected machine.
Wojtek
Michael Simpson wrote:
On 6/12/08, Karanbir Singh mail-lists@karan.org wrote:
Can anyone think of a good reason why we should not make fastestmirror a direct dep for yum ? Its something that is well worth having and in 90%[1] of the cases, it will improve the user experience.
- KB
[1] Number pulled out of thin air - I have no facts or numbers to back that up.
nope would save me once less configuration step on every new install
Likewise for yum-downloadonly. I nearly always run updates with the --downloadonly option unattended, then baby-sit the actual update which happens quickly with everything already cached.
On Thu, 12 Jun 2008, Les Mikesell wrote:
would save me once less configuration step on every new install
Likewise for yum-downloadonly.
I think that it's worth asking the more general question: if the plugins don't modify at all (like downloadonly) or only make better (like fastestmirror) the behaviour of yum, shouldn't they be in by default ?
Bogdan Costescu wrote:
On Thu, 12 Jun 2008, Les Mikesell wrote:
would save me once less configuration step on every new install
Likewise for yum-downloadonly.
I think that it's worth asking the more general question: if the plugins don't modify at all (like downloadonly) or only make better (like fastestmirror) the behaviour of yum, shouldn't they be in by default ?
Absolutely, its a discussion worth having.
However, for the sake of 5.2, i think we'll just go with the fastestmirror added in.
Maybe we can work out a list of the others that are recommended by the users, and decide on those for the future ?
- KB
Karanbir Singh wrote:
Bogdan Costescu wrote:
On Thu, 12 Jun 2008, Les Mikesell wrote:
would save me once less configuration step on every new install
Likewise for yum-downloadonly.
I think that it's worth asking the more general question: if the plugins don't modify at all (like downloadonly) or only make better (like fastestmirror) the behaviour of yum, shouldn't they be in by default ?
Absolutely, its a discussion worth having.
However, for the sake of 5.2, i think we'll just go with the fastestmirror added in.
Maybe we can work out a list of the others that are recommended by the users, and decide on those for the future ?
- KB
How about Priorities preconfigured too?
Then maybe external repos like RPMForge's RPM for CentOS could come preconfigured with priorities=x already set to compliment the core CentOS repos and not overwrite base packages.
Ned Slider wrote:
How about Priorities preconfigured too?
Then maybe external repos like RPMForge's RPM for CentOS could come preconfigured with priorities=x already set to compliment the core CentOS repos and not overwrite base packages.
that would be, imho, too dramatic a change in expected yum behavior to push in during the release cycle. its something you should make a note of and bring up when we are beta testing c6 for sure.
Karanbir Singh wrote:
Can anyone think of a good reason why we should not make fastestmirror a direct dep for yum ? Its something that is well worth having and in 90%[1] of the cases, it will improve the user experience.
- KB
[1] Number pulled out of thin air - I have no facts or numbers to back that up.
I have no problem with it, since if you have only one mirror listed with "baseurl=" it works fine too.
-
Alan Bartlett -
Bogdan Costescu -
Jason_Meers -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Michael Simpson -
Ned Slider -
Phil Schaffner -
Scott Silva -
Wojciech Pilorz