hi y'all
Oh I know some people might say you have no business running servers on Fedora because the Cores are so short lived and yes, it's not an ideal position but sometimes you have to just grin and bear it. ...hard to beat for the money huh?
Well, I would like some views on this, if you just want to say don't run fc then please just don't respond k? What we have here is a new core coming out bout every six months and then probably a year and it's in legacy. This seems to be the pattern. Now then you experienced hands w/this have seen what happens as soon as it is released from testing. I have not that much experience there.
I saw remarks by Alexander Dalloz and others whom I respect all greatly. They seemed to instill in me that just because the core is released does not mean that there are above avg problems w/it right then. The main public (not just the testers) get a hold of it and bugzilla gets it's share of activity. Given all this, when you think is ideal time to upgrade??? Do it right away...wait a couple months...when???
I don't have a bench test machine anymore...and I have 3 fedora boxes 2 servers synced together backing each others availability, and another box also running fc3 that mainly holds backups for the 3 fedora boxes and 2 windows and also will be the box I want to settle in as my pc, for doing dev. work and what not.
thx for listening
john rose
rado wrote:
hi y'all
Oh I know some people might say you have no business running servers on Fedora because the Cores are so short lived and yes, it's not an ideal position but sometimes you have to just grin and bear it. ...hard to beat for the money huh?
I'm running several FC3 machines in production, primarily as MX servers running Sendmail, ClamAV, and SpamAssassin. They're very stable. I'll upgrade them to FC4 about two to three weeks after the first big batch of updates comes out for FC4 stable.
I feel a bit differently about some of our app servers that have more complicated setups, not due to stability but to the fact that we've done a poor job of documenting ongoing changes, so rebuilding them from scratch would be a very unpleasant few days. They'll stay on RHES for now.
On Tuesday 26 April 2005 18:32, rado wrote:
I saw remarks by Alexander Dalloz and others whom I respect all greatly. They seemed to instill in me that just because the core is released does not mean that there are above avg problems w/it right then. The main public (not just the testers) get a hold of it and bugzilla gets it's share of activity. Given all this, when you think is ideal time to upgrade??? Do it right away...wait a couple months...when???
I don't think there's a "one size fits all" answer to your question. The best suggestion I can give you is to follow a release right from the start. That is, jump in to the testing phase at some point with a spare computer, follow the discussion on the fedora-test list and poke at the system to see what problems you can find. This will give you a good feeling for quality of the software. At some point, probably after the "official release" you'll be comfortable with the system enough to know if it's ready for your own "production" usage.
Regards, Mike Klinke
rado wrote:
hi y'all
Oh I know some people might say you have no business running servers on Fedora because the Cores are so short lived and yes, it's not an ideal position but sometimes you have to just grin and bear it. ...hard to beat for the money huh?
Well, I would like some views on this, if you just want to say don't run fc then please just don't respond k? What we have here is a new core coming out bout every six months and then probably a year and it's in legacy. This seems to be the pattern. Now then you experienced hands w/this have seen what happens as soon as it is released from testing. I have not that much experience there.
I saw remarks by Alexander Dalloz and others whom I respect all greatly. They seemed to instill in me that just because the core is released does not mean that there are above avg problems w/it right then. The main public (not just the testers) get a hold of it and bugzilla gets it's share of activity. Given all this, when you think is ideal time to upgrade??? Do it right away...wait a couple months...when???
I don't have a bench test machine anymore...and I have 3 fedora boxes 2 servers synced together backing each others availability, and another box also running fc3 that mainly holds backups for the 3 fedora boxes and 2 windows and also will be the box I want to settle in as my pc, for doing dev. work and what not.
I'd not use FC on a server.
I maintain several machines, some running Debian, a couple run FC3.
I maintain the software remotely - where remotely varies from across the LAN to via dialup Internet.
apt-get works well and I run it nightly in a cron job to download from a local mirror. It's easy to configure apt-get to use a particular mirror, and the initial configuration is done at install time.
I've not discovered a good way to make yum download "hands off." I _could_ make it download and install, but that's not my style. I like to control when updates go in.
By default, yum uses a selection of mirrors in convenient locations such as .fi. .il and goodness knows where else. I'm in Australia, and there are few locations further away than those.
I see an enormous volume of updates for FC. I've not checked on what they fix, but I suspect they're mostly not security-related.
I'd not like such a volatile selection of software on my server, I'd be perpetually worried that something will break, and if a server breaks then the whole enterprise (school in my case) is affected.
If you want a Red Hat-based solution then look at the free download versions of RH's Enterprise Linux. I have not used one, but I might. I have been downloading the source updates, and they're relatively few as compared with FC.
I don't think Debian is a good solution atm: the stable version is about as ancient as RHL 7.3, and the next stable version is very late. I'm running Sarge (the next Stable version), but there are hazards and worries about crucial software (eg firewall, vpn) updates breaking the systems and locking me out.
Between FC3 and EL there is the Debian-based Ubuntu. I'm running that too, and he volume of updates is low - security only, and only for a subset of what's available. The release cycle is six months - October and April, and the support is (I think) eighteen months or so.
On Thu, 2005-04-28 at 13:32 +0800, John Summerfied wrote:
I'd not use FC on a server.
I maintain several machines, some running Debian, a couple run FC3.
I maintain the software remotely - where remotely varies from across the LAN to via dialup Internet.
apt-get works well and I run it nightly in a cron job to download from a local mirror. It's easy to configure apt-get to use a particular mirror, and the initial configuration is done at install time.
I've not discovered a good way to make yum download "hands off." I _could_ make it download and install, but that's not my style. I like to control when updates go in.
By default, yum uses a selection of mirrors in convenient locations such as .fi. .il and goodness knows where else. I'm in Australia, and there are few locations further away than those.
It's very easy to make yum use a local mirror. I do this both at home at at work. Just point each repo at your local mirror using the "baseurl" directive in your yum repository configuration instead of using the default mirrorlist.
I see an enormous volume of updates for FC. I've not checked on what they fix, but I suspect they're mostly not security-related.
I think most are usability improvements for the desktop, and probably not really needed on servers.
I'd not like such a volatile selection of software on my server, I'd be perpetually worried that something will break, and if a server breaks then the whole enterprise (school in my case) is affected.
Yes, for example there was a recent util-linux update that "broke" (though there was a workaround that could be used) client-side NFS mounts to older servers, though an updated update was released the day after.
If you want a Red Hat-based solution then look at the free download versions of RH's Enterprise Linux. I have not used one, but I might. I have been downloading the source updates, and they're relatively few as compared with FC.
Agreed. Centos looks a good bet.
Paul.
Paul Howarth wrote:
apt-get works well and I run it nightly in a cron job to download from a local mirror. It's easy to configure apt-get to use a particular mirror, and the initial configuration is done at install time.
I've not discovered a good way to make yum download "hands off." I _could_ make it download and install, but that's not my style. I like to control when updates go in.
By default, yum uses a selection of mirrors in convenient locations such as .fi. .il and goodness knows where else. I'm in Australia, and there are few locations further away than those.
It's very easy to make yum use a local mirror. I do this both at home at at work. Just point each repo at your local mirror using the "baseurl" directive in your yum repository configuration instead of using the default mirrorlist.
It may be "very easy" but only when you know how. I've installed a few Debian systems, and it's impossible to avoid the opportunity to choose a local mirror.
First, it asks "What country..." and that promptly weeds out .fi, .il, .ru and .mx.
In contrast, nothing in FC asked me what to use, and I've not seen any documentation on the topic. Nor, it happens, do I know a near-by mirror.
It seems some of the mirrors used by Yum are beorkn - I often get 404 errors.
I'm not a fan on Yum.
I see an enormous volume of updates for FC. I've not checked on what they fix, but I suspect they're mostly not security-related.
I think most are usability improvements for the desktop, and probably not really needed on servers.
I note that there have been several kernel updates, and that he latest is broken (on my laptop it doesn't shut down, gets an oops instead). Not good for transporting.
I'd not like such a volatile selection of software on my server, I'd be perpetually worried that something will break, and if a server breaks then the whole enterprise (school in my case) is affected.
Yes, for example there was a recent util-linux update that "broke" (though there was a workaround that could be used) client-side NFS mounts to older servers, though an updated update was released the day after.
This justifies my hands-on update policy.
The option to log software updates would be good - email (preferably to another box) and a printed report are good options.
On Wed, 2005-05-04 at 07:54 +0800, John Summerfied wrote:
Paul Howarth wrote:
apt-get works well and I run it nightly in a cron job to download from a local mirror. It's easy to configure apt-get to use a particular mirror, and the initial configuration is done at install time.
I've not discovered a good way to make yum download "hands off." I _could_ make it download and install, but that's not my style. I like to control when updates go in.
By default, yum uses a selection of mirrors in convenient locations such as .fi. .il and goodness knows where else. I'm in Australia, and there are few locations further away than those.
It's very easy to make yum use a local mirror. I do this both at home at at work. Just point each repo at your local mirror using the "baseurl" directive in your yum repository configuration instead of using the default mirrorlist.
It may be "very easy" but only when you know how. I've installed a few Debian systems, and it's impossible to avoid the opportunity to choose a local mirror.
First, it asks "What country..." and that promptly weeds out .fi, .il, .ru and .mx.
In contrast, nothing in FC asked me what to use, and I've not seen any documentation on the topic. Nor, it happens, do I know a near-by mirror.
It seems some of the mirrors used by Yum are beorkn - I often get 404 errors.
I'm not a fan on Yum.
You can find a list of mirrors organised geographically at: http://fedora.redhat.com/download/mirrors.html
An example of how to set up your own mirrorlist: http://fedoranews.org/tchung/yum-mirrorlist/
The Fedora installer, in contrast to Debian's, asks as few questions as it can reasonably get away with. For some people this is an advantage, and for others it's a disadvantage.
Cheers, Paul.
Paul Howarth wrote:
I'm not a fan on Yum.
You can find a list of mirrors organised geographically at: http://fedora.redhat.com/download/mirrors.html
An example of how to set up your own mirrorlist: http://fedoranews.org/tchung/yum-mirrorlist/
The Fedora installer, in contrast to Debian's, asks as few questions as
Which Debian installer? I recall installing Ubuntu answering 2-3 questions with the (almost) current Debian installer.
it can reasonably get away with. For some people this is an advantage, and for others it's a disadvantage.
yum could be installed unconfigured and ask when first used. Kickstarters would, of course, edit the config files as they can edit so many others.
Am Mi, den 04.05.2005 schrieb Paul Howarth um 2:01:
You can find a list of mirrors organised geographically at: http://fedora.redhat.com/download/mirrors.html
Cheers, Paul.
A very simple way to restrict the automatic mirror selection is to slightly edit the yum repo file. An example:
In /etc/yum.repos.d/fedora.repo change
mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever
to become
mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever.us.east
and you will only get US east coast mirror servers. This works too with .uk or .de.
Alexander
Alexander Dalloz wrote:
Am Mi, den 04.05.2005 schrieb Paul Howarth um 2:01:
You can find a list of mirrors organised geographically at: http://fedora.redhat.com/download/mirrors.html
Cheers, Paul.
A very simple way to restrict the automatic mirror selection is to slightly edit the yum repo file. An example:
You and Paul seem to be missing the point; while one _can_ do this, it's not obvious that one can nor is it obvious what the allowable values are.
It _should_ be, it _could_ be easier. It is something that should be set on every installation, values that suit Aussies won't suit Canucks. There is not a good default.
John Summerfied wrote:
Alexander Dalloz wrote:
Am Mi, den 04.05.2005 schrieb Paul Howarth um 2:01:
You can find a list of mirrors organised geographically at: http://fedora.redhat.com/download/mirrors.html
Cheers, Paul.
A very simple way to restrict the automatic mirror selection is to slightly edit the yum repo file. An example:
You and Paul seem to be missing the point; while one _can_ do this, it's not obvious that one can
It's not obvious that yum exists, either. I would guess that the inexperienced user would be hitting the flashing red !.
nor is it obvious what the allowable values are.
I think it is pretty obvious that a 404 error isn't a mirror list.
It _should_ be, it _could_ be easier. It is something that should be set on every installation, values that suit Aussies won't suit Canucks. There is not a good default.
Sure there is a good default. One that works, which is what we have now.
Heck, most people that post here don't like the mirror list (out of sync rhn-applet, different results on different runs while mirror are syncing, etc.) and end up hard coding the mirror they want anyway. If you have the ability to choose a mirror to download the ISOs from, you have the ability to set the appropriate mirror the yum and up2date configurations.
William Hooper wrote:
It's not obvious that yum exists, either. I would guess that the inexperienced user would be hitting the flashing red !.
Likely. I then tried up2date commandline (acually, I know about that). I don't recall now my objections to that.
nor is it obvious what the allowable values are.
I think it is pretty obvious that a 404 error isn't a mirror list.
That's one way of cataloguing a large number of wrong values.
It _should_ be, it _could_ be easier. It is something that should be set on every installation, values that suit Aussies won't suit Canucks. There is not a good default.
Sure there is a good default. One that works, which is what we have now.
hey, my Navara (Pathfinder to yanks) only fires on two cilinders, what's the problem?
It can do better,
A default selection based on time zone would work for many people. I select "Australia/Perth" and that self-same selection should give me WAIX-connected mirrors plus Optus and Telstra to choose from. Or for yum to roll around.
Heck, most people that post here don't like the mirror list (out of sync rhn-applet, different results on different runs while mirror are syncing, etc.) and end up hard coding the mirror they want anyway. If you have the ability to choose a mirror to download the ISOs from, you have the ability to set the appropriate mirror the yum and up2date configurations.
"most people here" not "most users" nor "prospective users." I wish to see a soln that works for those. Myself, I can defeat most difficulties and have been doing so for years. Check my name at googlism.com - those mentioning OS/2 are me. Have some fun with your own name while youre at it.
John Summerfied wrote:
William Hooper wrote:
It's not obvious that yum exists, either. I would guess that the inexperienced user would be hitting the flashing red !.
Likely. I then tried up2date commandline (acually, I know about that). I don't recall now my objections to that.
Up2date uses the same mirror list.
[snip]
A default selection based on time zone would work for many people. I select "Australia/Perth" and that self-same selection should give me WAIX-connected mirrors plus Optus and Telstra to choose from. Or for yum to roll around.
You just got done complaining that the Australian mirrors aren't in the mirror list.
William Hooper wrote:
John Summerfied wrote:
William Hooper wrote:
It's not obvious that yum exists, either. I would guess that the inexperienced user would be hitting the flashing red !.
Likely. I then tried up2date commandline (acually, I know about that). I don't recall now my objections to that.
Up2date uses the same mirror list.
It was more than that; if that was the problem up2date would win every time - I can use a cronjob to keep its local repository current.
[snip]
A default selection based on time zone would work for many people. I select "Australia/Perth" and that self-same selection should give me WAIX-connected mirrors plus Optus and Telstra to choose from. Or for yum to roll around.
You just got done complaining that the Australian mirrors aren't in the mirror list.
Isn't it part of the same problem? If I were Jason (the bloke who administers PlanetMirror) I'd not want it on the list as it stands now because PM only serves Australia.
OTOH, PM does mirror Debian. I presume the sigficant difference is that Debian allows even the inexpert to choose by location, such as Australia/Perth.
Of course, it could all be a communication problem that I'm reading too much into, but were I administrator of PM, I would not want my site listed. Or, I'd firewall off PM from the rest of the world and the Fedora people wouldn't list me because there'd be too many breakages.
John Summerfied wrote:
It may be "very easy" but only when you know how. I've installed a few Debian systems, and it's impossible to avoid the opportunity to choose a local mirror.
First, it asks "What country..." and that promptly weeds out .fi, .il, .ru and .mx.
In contrast, nothing in FC asked me what to use, and I've not seen any documentation on the topic. Nor, it happens, do I know a near-by mirror.
It seems some of the mirrors used by Yum are beorkn - I often get 404 errors.
I'm not a fan on Yum.
It's not a yum related problem. If the server is incomplete , it means that apt , yum and any other other app that does something like yum/apt do , they'll have issues with broken mirrors. There's no easy way to fix this. If you find one , please post it , since keeping several mirrors in synch is certainly something very difficult, specially when you dont have control over them.
I think most are usability improvements for the desktop, and probably not really needed on servers.
I note that there have been several kernel updates, and that he latest is broken (on my laptop it doesn't shut down, gets an oops instead). Not good for transporting.
For a good description of the updates , subscribe to fedora-announce-list. Usually the security updates are listed with the [SECURITY] tag in the subject , but sometimes a security update goes by without any special mention besides the entry in the changelog saying something like "Fixed CAN #.... ".
I'd not like such a volatile selection of software on my server, I'd be perpetually worried that something will break, and if a server breaks then the whole enterprise (school in my case) is affected.
Yes, for example there was a recent util-linux update that "broke" (though there was a workaround that could be used) client-side NFS mounts to older servers, though an updated update was released the day after.
This justifies my hands-on update policy.
The option to log software updates would be good - email (preferably to another box) and a printed report are good options.
Then the approach you need is something different: configure your machines to download from a local mirror. And only put in that mirror the packages that you have already tested on your network.
-- Pedro Macedo
Pedro Fernandes Macedo wrote:
I'm not a fan on Yum.
It's not a yum related problem. If the server is incomplete , it means that apt , yum and any other other app that does something like yum/apt do , they'll have issues with broken mirrors. There's no easy way to fix this. If you find one , please post it ,
Drop unreliable mirrors. It happens often enough that they should be identifiable.
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
since keeping several mirrors in synch is certainly something very difficult, specially when you dont have control over them.
I think most are usability improvements for the desktop, and probably not really needed on servers.
I note that there have been several kernel updates, and that he latest is broken (on my laptop it doesn't shut down, gets an oops instead). Not good for transporting.
For a good description of the updates , subscribe to fedora-announce-list. Usually the security updates are listed with the [SECURITY] tag in the subject , but sometimes a security update goes by without any special mention besides the entry in the changelog saying something like "Fixed CAN #.... ".
I'm on the list, what am I supposed to see? I didn't ask _why_ there have been several kernel updates, I merely observed there have been several.
I'd not like such a volatile selection of software on my server, I'd be perpetually worried that something will break, and if a server breaks then the whole enterprise (school in my case) is affected.
Yes, for example there was a recent util-linux update that "broke" (though there was a workaround that could be used) client-side NFS mounts to older servers, though an updated update was released the day after.
This justifies my hands-on update policy.
The option to log software updates would be good - email (preferably to another box) and a printed report are good options.
Then the approach you need is something different: configure your machines to download from a local mirror. And only put in that mirror the packages that you have already tested on your network.
I've not noticed that Yum can be configured to do that. I can make it update but not download, but I don't think it can download and not update.
up2date can do that, and that's what I did with Taroon beta.
On Wed, 2005-05-04 at 07:05, John Summerfied wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now? I run several machines through the same caching http proxy and when I first started it seemed like most files would be cached. Now, with no change at my end it seems like there is never a cache hit even when another machine just performed the same update. Is there a way to force the order of mirror attempts to be the same so the cache will work again?
Les Mikesell wrote:
On Wed, 2005-05-04 at 07:05, John Summerfied wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
I run several machines through the same caching http proxy and when I first started it seemed like most files would be cached. Now, with no change at my end it seems like there is never a cache hit even when another machine just performed the same update. Is there a way to force the order of mirror attempts to be the same so the cache will work again?
Remove the mirror list and set yum to use the mirror you prefer. Or set up a local yum repo and point them all to that.
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
I run several machines through the same caching http proxy and when I first started it seemed like most files would be cached. Now, with no change at my end it seems like there is never a cache hit even when another machine just performed the same update. Is there a way to force the order of mirror attempts to be the same so the cache will work again?
Remove the mirror list and set yum to use the mirror you prefer.
If they are identical, how would I determine a preference? Or if they aren't identical, how would I know?
Or set up a local yum repo and point them all to that.
That would mean (a) knowing all the versions that need to pull updates and (b) copying a lot of stuff in the repo that nobody has installed which seems a lot worse than letting a cache do its job.
Wouldn't this be better-handled by round-robin DNS, assuming that the target hosts are not configured as name-based virtual hosts or that they have the appropriate configuration to respond to the same name?
Les Mikesell wrote: [snip]
I run several machines through the same caching http proxy and when I first started it seemed like most files would be cached. Now, with no change at my end it seems like there is never a cache hit even when another machine just performed the same update. Is there a way to force the order of mirror attempts to be the same so the cache will work again?
Remove the mirror list and set yum to use the mirror you prefer.
If they are identical, how would I determine a preference? Or if they aren't identical, how would I know?
Huh? What are "they" in this context?
Or set up a local yum repo and point them all to that.
That would mean (a) knowing all the versions that need to pull updates and (b) copying a lot of stuff in the repo that nobody has installed which seems a lot worse than letting a cache do its job.
Depends on the situation. A local yum repo gives you greater control in what updates are applied and win. I just presented it as another option.
Wouldn't this be better-handled by round-robin DNS, assuming that the target hosts are not configured as name-based virtual hosts or that they have the appropriate configuration to respond to the same name?
Not all mirrors have the same directory layout. Also, since the mirrors are community run, it is impossible to know if they are virtual hosts or not.
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
On Wed, 4 May 2005 14:25:59 -0400 (EDT) "William Hooper" whooperhsd3@earthlink.net wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
Is there any way to easily configure *which* mirrors get looked at? I notice that seemingly every other yum run I end up accessing an overseas mirror at a very slow connection speed. It'd probably be better if my US-based machines tried to access US-based mirrors rather than European ones.
Or would it be best to just (in the ,repo files) choose a close mirror as "baseurl" and comment out "mirrorlist" entirely?
Charles E Taylor IV wrote:
On Wed, 4 May 2005 14:25:59 -0400 (EDT) "William Hooper" whooperhsd3@earthlink.net wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
Is there any way to easily configure *which* mirrors get looked at? I notice that seemingly every other yum run I end up accessing an overseas mirror at a very slow connection speed. It'd probably be better if my US-based machines tried to access US-based mirrors rather than European ones.
Or would it be best to just (in the ,repo files) choose a close mirror as "baseurl" and comment out "mirrorlist" entirely?
Looking at http://fedora.redhat.com/download/up2date-mirrors/ there are a number of options to pick from. Editing /etc/sysconfig/rhn/sources and adding .us.east to the end of both yum-mirror lines would force up2date to only use mirrors on the US East Coast. Looks like there's indiv lists for other countries to. Of course, you could just pick a mirror you prefer, comment out the yum-mirror and yum lines and add one directly to your preferred mirror.
Jay
Jay Lee wrote:
Looking at http://fedora.redhat.com/download/up2date-mirrors/ there are
Take a look at the Australian selection. There are Australian murrors not listed, the one mirror listed is wrongly said to not carry FC3....
Surely someone at fedora.redhat.com knows who are the accredited mirrors?
Charles E Taylor IV wrote: [snip]
Is there any way to easily configure *which* mirrors get looked at?
Answered previously in this thread.
https://www.redhat.com/archives/fedora-list/2005-May/msg00550.html
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
Marc
On Wed, 4 May 2005, Marc M wrote:
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
For some people the debian model is more appropiate than for others... There is room for a continuium of solutions.
even debian unstable isn't really agressive enough to meet my needs in some cases.
Marc
Marc M wrote:
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
Please create a new thread for your distro flamewar. That way I can delete it without missing things that may be useful in this tread.
My question is relevant to the discussion. This is in *no way* a distro flame war. A flame war would be if I was advocating one over another. I am not trying to bait people, either, just honestly asking people's opinions. It *should* be possible to discuss something like that, without it devolving into a flamethrowing contest.
Marc M wrote:
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
There are various meansings atributable to "stable." An important one is "unchanging," and in that sense Debian beats everyone else hands-down.
Debian fixes security problems, nothing else.
Debian Stable is Woody and is some years old. Its default kernel is 2.2.something, 2.4.18 is available as an option, KDE 2.x (I forget which x) etc. selinux is included but doesn't actually work and the selinux developers are unable to get fixes into the oficial tree.
Debian Testing (Sarge) has just been frozen - this means only fixes critical to getting it out the door (and little else) go in.
Debian, despite its claims to the contrary, is too inclined to release package updates that break previous releases. I have in mind openvpn which has bitten me in the past few days and shorewall; but have the potential to sever remote admins from the boxes they maintain.
In the sense of change, FC is too unstable for serious safe use on servers etc.
RHEL is another matter.
On Wed, 2005-05-04 at 16:06, Marc M wrote:
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
I'd ask them to explain the Debian release schedule. My take on it is that what they call stable is not what you want to run - and if you run something that isn't in stable, it is your fault, not theirs if it has problems.
Les Mikesell wrote:
On Wed, 2005-05-04 at 16:06, Marc M wrote:
I am curious as to what some of you guys say to Debian snobs who look down on Fedora/RH as being less stable. I find that a pretty esoteric argument/to each their own, but how do you counter that sort of statement or attitude?
I'd ask them to explain the Debian release schedule. My take on it is that what they call stable is not what you want to run - and if you run something that isn't in stable, it is your fault, not theirs if it has problems.
Oh, the Debian release schedule is pretty simple. It's released when it's ready.
_nothing_ in Debian is secret, just browse www.debian.org for all the information about packages (there are lots), standards, bugs, help fo users, help for developers and the fine command of language which they use to describe each other as needs arise. And their insistance on freedom and the deficiencies in the GFDL.
To see what Debian could be, see www.ubuntu.com. Canonical sponsors Ubuntu, and the Ubuntu release schedule is simple too. April and October. This year, next year.... Its first release had Gnome 2.8 when Sarge had 2.6.
Or mephis, but I don't have a link atm.
On Wed, 4 May 2005 17:01:48 -0400 (EDT) "William Hooper" whooperhsd3@earthlink.net wrote:
Answered previously in this thread. https://www.redhat.com/archives/fedora-list/2005-May/msg00550.html
Thanks. Missed that post in the flood.
I can't find it in bugzilla (which doesn't mean it's not there :) ), but has anyone suggested as an RFE that the yum mirror list should be configured correctly when yum is installed in the first place? Could an install script be devised that would, say, look at the user's time zone and automattically set the .repo files to point to the correct mirrors?
This would save people from bugs like 152395, at least.
William Hooper wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use. Squid would then cache that mirror link as well as the rpms and headers from that mirror resulting in less traffic to all mirrors. The scripting on fedora.redhat.com could be further enhanced to return a mirror close to where the requesting IP address is. I really hate it when I fire up up2date only to have it start pulling from a mirror in Bulgaria or somewhere else thousands of miles away. This would be both cache and mirror friendly to do. Of course this may be easy for me to say and difficult to implement...
Jay
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On Wed, 2005-05-04 at 16:04, William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically, caching proxies would do the right thing, you wouldn't have to keep redistributing the mirror list, and failing over could be handled by the application (even IE does this nicely so it can't be that hard...). The down side is that the participating target sites all have to be configured so the URLs can be the same.
Les Mikesell wrote:
On Wed, 2005-05-04 at 16:04, William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically,
For that to work, all sites must have the same structure. And still, it excludes murrors that don't serve the whole world.
I believe the DNS now allows different answers in different parts of the world - that might help; Australians would _only_ see Australian mirrors.
Les Mikesell wrote:
On Wed, 2005-05-04 at 16:04, William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc 3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically,
Which happens now.
caching proxies would do the right thing,
I'm sure that would depend on the proxy and your definition of "the right thing". Caching metadata is a hinderence, not a feature.
you wouldn't have to keep redistributing the mirror list,
It's 2K, not that big of a deal.
and failing over could be handled by the application (even IE does this nicely so it can't be that hard...).
Yum handles fail over now, by going to the next mirror if it contact the current one, and going to the next mirror if you hit Ctrl-C.
The down side is that the participating target sites all have to be configured so the URLs can be the same.
Which is a pretty big downside looking at the existing mirror list.
William Hooper wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 16:04, William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc 3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically,
Which happens now.
caching proxies would do the right thing,
I'm sure that would depend on the proxy and your definition of "the right thing". Caching metadata is a hinderence, not a feature.
This morning I updated Linux on eight or so boxes, most on a single LAN, all remote from me.
Where the machines share an Internet connexion, why would I want them to refetch the metadata regarding the remote sites? What _I_ want is all machines to use one mirror, one set of metadata, one collection of packages.
Most of the machines have most packages in common.
So long as the packages describedby the metadata exist, I don't have a problem with caching the metadata. I perform my software maintenance at times convenient to me and my users; I don't care a lot if a package has been replaced in the past few minutes or hours, my next maintenance run will get it.
you wouldn't have to keep redistributing the mirror list,
It's 2K, not that big of a deal.
The current implementation is.
I ran yum, update twice consecutively to quantify this. There were no updates available at the time. [summer@echidna ~]$ time sudo yum -y update Password: Setting up Update Process Setting up Repos base 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 updates-re: ################################################## 885/885 No Packages marked for Update/Obsoletion
real 4m5.094s user 0m23.007s sys 0m5.761s [summer@echidna ~]$ time sudo yum -y update Password: Setting up Update Process Setting up Repos base 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 updates-re: ################################################## 885/885 No Packages marked for Update/Obsoletion
real 2m56.149s user 0m22.863s sys 0m5.332s [summer@echidna ~]$
I suspect that most of the improvement in the second run occured because the disk data was mostly cached.
The nearest equivalent I have using apt-get is a Ubuntu system. On that system, the second run took less than nine seconds.
If you're being paid to look after these systems, those three and four minutes are quite a charge - if you cost 100 Currency Units/hour, that's five to seven CU for each system, each time.
and failing over could be handled by the application (even IE does this nicely so it can't be that hard...).
Yum handles fail over now, by going to the next mirror if it contact the current one, and going to the next mirror if you hit Ctrl-C.
_I_ have a robustness problem with yum. I like to use links (not elinks) for some stuff because it does graphics on framebuffers (and under X), but elinks conflicts with links and something requires elinks.
Consequently having both causes some conflicts, and yum can't handle it and won't do any updates.
Using, apt-get I could configure to leave certain packages (eg links and elinks) alone and it will get on with updating other stuff.
_I_ can and will when it bugs me anough, handle the problem by tracking elinks source rpm and building my own corrected package.
John Summerfied wrote: [snip]
you wouldn't have to keep redistributing the mirror list,
It's 2K, not that big of a deal.
The current implementation is.
[snip]
I suspect that most of the improvement in the second run occured because the disk data was mostly cached.
What does this have to do with fetching the mirror list?
[snip]
_I_ have a robustness problem with yum. I like to use links (not elinks) for some stuff because it does graphics on framebuffers (and under X), but elinks conflicts with links and something requires elinks.
Consequently having both causes some conflicts, and yum can't handle it and won't do any updates.
Using, apt-get I could configure to leave certain packages (eg links and elinks) alone and it will get on with updating other stuff.
The same can be done with Yum by using "Exclude".
William Hooper wrote:
John Summerfied wrote: [snip]
you wouldn't have to keep redistributing the mirror list,
It's 2K, not that big of a deal.
The current implementation is.
[snip]
I suspect that most of the improvement in the second run occured because the disk data was mostly cached.
What does this have to do with fetching the mirror list?
It was doing _something_ during all that time. What it was it didn't show, whether it was the mirror list or the metadata from yet another mirror or both, I could not see.
Whatever, it's slow.
The same can be done with Yum by using "Exclude".
Thanks.
On Mon, 2005-05-09 at 20:30, John Summerfied wrote:
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically,
Which happens now.
Except that a lot more of it happens than necessary. I pull about 20 copies of everything myself that previously would have been cached nicely. And others update their own systems here too, using the same proxy. This is a small office so that's probably not unusual at all.
caching proxies would do the right thing,
I'm sure that would depend on the proxy and your definition of "the right thing". Caching metadata is a hinderence, not a feature.
The 'right thing' turns out to be the same right thing as for generic http proxies: get a new copy only if the one on the target site is newer than the one in the cache.
Where the machines share an Internet connexion, why would I want them to refetch the metadata regarding the remote sites? What _I_ want is all machines to use one mirror, one set of metadata, one collection of packages.
More to the point, why refetch if the cached copy is identical? If you haven't checked recently, let the proxy do a 'get if newer' and let the server reply with a '304 Not modified' response like the http protocol was designed to do...
William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. A
I don't care. My experience with Debian's setup suggest that, while this happens, it's rare.
It could reduce the load on FRC - yum could continue to use the one it has until it does break.
I actually don't think Red Hat can do this; it can't know which Western Australians should ose WAIX and which should not. Potentially, that answer can change from one day to the next.
In contrast, FRC doesn't even publish a current list of Australian mirrors Australians might consider.
William Hooper wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
It's hopeless. Mirrors that only serve their country or smaller geographic region are excluded. Such as Planetmirror, Australia's larget, AARNET that serves Australia's education community, WAIX that serves select Western Australian IAPs (those who contribute) along with eqquivalents in other Australian states.
Enzed has Enzed-only mirrors too.
It's hopeless. I'm on dialup, There is no possibility of my well-configured Squid caching stuff, and there is too much to realistically download stuff multiple times.
In contrast, Debian uses several of Australia's mirrors, with no drama at all.
For folk in my position, apt-get has an option to print the URIs for required packages. Its not good for "the average user" but itbeats not having the capability.I don't see a way of doing that with yum.
My laptop, I update at work. For home, _I_ could set a local repository, but that is not a good general solution. It's only one a geek would think good.
John Summerfied wrote:
William Hooper wrote:
Les Mikesell wrote:
On Wed, 2005-05-04 at 08:32, William Hooper wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now?
It is configured to do that be default now, yes.
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
It's hopeless. Mirrors that only serve their country or smaller geographic region are excluded. Such as Planetmirror, Australia's larget, AARNET that serves Australia's education community, WAIX that serves select Western Australian IAPs (those who contribute) along with eqquivalents in other Australian states.
Nothing is stopping you from either using your own mirror list, or not using a mirror list at all and configuring a single mirror.
It's hopeless. I'm on dialup, There is no possibility of my well-configured Squid caching stuff, and there is too much to realistically download stuff multiple times.
Both the above will fix that problem.
For folk in my position, apt-get has an option to print the URIs for required packages.
Perhaps you should watch this RFE: https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=396
William Hooper wrote:
Ouch - that is very cache-unfriendly.
It is much, much more mirror friendly, though.
It's hopeless. Mirrors that only serve their country or smaller geographic region are excluded. Such as Planetmirror, Australia's larget, AARNET that serves Australia's education community, WAIX that serves select Western Australian IAPs (those who contribute) along with eqquivalents in other Australian states.
Nothing is stopping you from either using your own mirror list, or not using a mirror list at all and configuring a single mirror.
While that is so, it's not a good general solution, and a good general solution is what I prefer.
If I fix it as you suggest for me, that helps one user (or the set of users I support). A general solution will work well for everyone; the current setup does not.
Les Mikesell wrote:
On Wed, 2005-05-04 at 07:05, John Summerfied wrote:
Update lists mirrors; it seems that Yum downloads a fresh list each time (yuck, I'd rather see the list in an rpm that's updated as needed), so that should be a quick fix. Once a mirror fixes its problems, relist it.
Does yum pick a mirror at random now? I run several machines through the same caching http proxy and when I first started it seemed like most files would be cached. Now, with no change at my end it seems like there is never a cache hit even when another machine just performed the same update. Is there a way to force the order of mirror attempts to be the same so the cache will work again?
Try adding:
failovermethod=priority
in your yum repo configuration.
Paul.
-
Alexander Dalloz -
Charles E. "Rick" Taylor, IV -
Jay Lee -
Joel Jaeggli -
John Summerfield -
Les Mikesell -
Marc M -
Mike Klinke -
Paul Howarth -
Pedro Fernandes Macedo -
rado -
SternData -
William Hooper