Tip in the newsletter
I tried the tip in the newsletter about redirecting the updates to the MUUG site. I updated today. It took less than 30 seconds (as opposed to an hour and a bit). It took a bit to figure out how to manually edit the file rather than use patch. The whole thing turned out to be really simple. Just replace two URLs. Thanks guys... Later Mike P.S. I'm going to be looking into what Gilbert said here pretty soon. ;-) -- +----------------------------------------------------------------------+ | Digital Civilization magazine: http://www.digitalcivilization.ca | |Call-A.P.P.L.E. and the Digital Civilization http://www.callapple.org | | http://members.shaw.ca/pfaiffer = Mike Pfaiffer (B.A., B.Sc.) | +----------------------------------------------------------------------+ ----- BEGIN GEEK CODE BLOCK ----- Version: 3.12 GCS/G/IT/PA/SS d s+:- a? C++ UL L++ W++ N++ o+ K- w(---) O+@ M++@ V PS+ PE !PGP t+ 5+ X R tv b+ DI+++ D++ G e++* h! r-- !y-- UF++ ------ END GEEK CODE BLOCK ------
According to Mike Pfaiffer:
I tried the tip in the newsletter about redirecting the updates to the MUUG site. I updated today. It took less than 30 seconds (as opposed to an hour and a bit).
Glad to hear it worked, and that you got very good response time. Let's hope that lasts! As of this morning, 150 unique host addresses have been loading yum header information from our HTTP server, and I'm expecting that number to rise quickly! Why's that? Well, I noticed a lot of hits to my fedora-updates.html article on the web server were coming from Google searches. I ran a Google search for the string "fedora updates" myself, and found that my article was ranked in second place, behind the updates page on the official Fedora Project web site! Yikes! Open the floodgates! Those 150 unique addresses I mentioned above are coming in from all over the world, too. (Only 15 are from within the umanitoba.ca domain, and those are all from machines I configured myself. It's actually 17 machines, but 3 are behind a NAT router. Interestingly, an address on mts.net has as high a hit count on our header.info files as that NAT router, tying it for first place!)
It took a bit to figure out how to manually edit the file rather than use patch. The whole thing turned out to be really simple. Just replace two URLs.
Yup, the change is pretty easy. BTW, if you visit the article online... http://www.muug.mb.ca/fedora-updates.html ... you can download the patches by clicking on the sub-header for each patch. That will save you some typing and the reduce the chances of a typo. Of course, if our mirror gets bogged down from overuse, you may want to point to a different mirror. Fortunately, there are a few others right in Canada now... http://fedora.redhat.com/download/mirrors.html
Thanks guys...
You're welcome.
P.S. I'm going to be looking into what Gilbert said here pretty soon. ;-)
I'm assuming you mean my earlier message about multimedia support? I haven't actually tried any of the tips in Eric Raymond's HOW-TO yet, but it all looks fairly straightforward. Unfortunately, I had already set up multimedia support the hard way (with lots of trial and error, and lots of Google searches) on my home machine. It's working for me now, so I'm not in a rush to change it (don't fix it if it ain't broke), but I may redo parts of it, e.g. to use RPM packages as much as possible, rather than downloading source and binaries from the source sites and hand-installing things. It's much cleaner if all the installs are contained within RPM packages, especially if you can automatically update them later, via yum or up2date. -- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg, MB, CANADA R3T 2N2 Fax: (204)474-7609
On Sat, 7 Feb 2004, Gilbert E. Detillieux wrote:
Of course, if our mirror gets bogged down from overuse, you may want to point to a different mirror. Fortunately, there are a few others right in Canada now...
I just tried it out last night, and it worked great. Reading a bit in the manual, though, you can put a list of mirror sites in, and they will be tried sequentially: ie baseurl=http://site1/path http://site2/path http://www.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO/yum_HOWTO-10.html#s... So, it might be best to leave the original mirror site in as a backup, or pick another server. Another curiousity... The CDs I had on hand were for Fedora Core Test 3, so I installed it anyway. Edited yum.conf to point to the MUUG site, but the core 1 base and updates. "yum update", and I had myself a Core 1 box at the end of it! Not sure if I'm brave enough to try the same starting at RH 9. :) Sean -- Sean A. Walberg <sean@ertw.com> http://www.ertw.com
According to Sean A. Walberg:
On Sat, 7 Feb 2004, Gilbert E. Detillieux wrote:
Of course, if our mirror gets bogged down from overuse, you may want to point to a different mirror. Fortunately, there are a few others right in Canada now...
I just tried it out last night, and it worked great. Reading a bit in the manual, though, you can put a list of mirror sites in, and they will be tried sequentially:
ie
baseurl=http://site1/path http://site2/path
http://www.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO/yum_HOWTO-10.html#s...
So, it might be best to leave the original mirror site in as a backup, or pick another server.
Yes, I came across that HOWTO soon after writing my article. I thought of updating things to mention this, but... 1) It doesn't work with up2date, where you can only specify a single URL per repository. 2) It doesn't work with yum 1.x, which is what we use on earlier Red Hat systems. There, the above would just give you a syntax error. 3) It doesn't even seem to work as advertised with yum 2.0.4 under Fedora. I tried it out, using MUUG as the primary site, and the official Fedora download site as the fallback. When this seemed to slow down the "yum update", I got suspicious and checked the MUUG web logs. Sure enough, yum was only contacting the fallback site, and not the MUUG server.
Another curiousity... The CDs I had on hand were for Fedora Core Test 3, so I installed it anyway. Edited yum.conf to point to the MUUG site, but the core 1 base and updates. "yum update", and I had myself a Core 1 box at the end of it!
Yes, that's not too surprising, since the changes between the test releases and the subsequent official release should be minor and incremental.
Not sure if I'm brave enough to try the same starting at RH 9. :)
As you pointed out in your later message, "yum upgrade" (rather than update) does a better job when upgrading across versions or releases. However, the man page points out that this option is deprecated and may disappear in future versions of yum. Fortunately, the changes between RH 9 and Fedora Core 1 were not so drastic that "yum upgrade" does a reasonable job. I wasn't brave enought to try that, though, and instead opted for upgrading from the Fedora installer. -- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg, MB, CANADA R3T 2N2 Fax: (204)474-7609
According to Gilbert E. Detillieux:
Why's that? Well, I noticed a lot of hits to my fedora-updates.html article on the web server were coming from Google searches. I ran a Google search for the string "fedora updates" myself, and found that my article was ranked in second place, behind the updates page on the official Fedora Project web site! Yikes! Open the floodgates!
You don't suppose your article has been "Google-bombed"? You may want to add a link or so from your article to the list of other mirror sites. Also, if the MUUG web site really does get overloaded, you could also add a note pleading for mercy, and urging visitors to pick an appropriate mirror site for their location. Don't wait till it gets too desparate, though, because once a large number of people have your web site configured into their yum.conf, they may not get around to changing it later unless things get really, really slow for them (and everyone else). -- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
participants (4)
-
gedetil＠cs.umanitoba.ca -
Gilles Detillieux -
Mike Pfaiffer -
Sean A. Walberg