On Thu, 2005-11-24 at 13:12 -0700, Collins Richey wrote:
> On 11/24/05, Bryan J. Smith <thebs413@xxxxxxxxxxxxx> wrote:
> > On Thu, 2005-11-24 at 12:00 -0600, Johnny Hughes wrote:
> > > It's called a local mirror
> >
> > I have to agree with Johnny. If you're maintaining any number of
> > systems, take it upon yourself to maintain a local mirror and rsync.
> > Tag updates in your YUM (or other) repository appropriately until you
> > have tested them. Then retag them appropriately when you have found a
> > release with packages that are all inter-working well.
> >
>
> Comments for this and the preceding post:
>
> 1. Paying for Red Hat does not resolve the problem as I described it.
> The Red Hat service provides for big bucks very slow, low bandwith
> access to it's updates. It's like watching paint dry when I have to
> download updates at work. I'll stick with free but erratic delivery if
> those are the choices. YOU DO NOT GET WHAT YOU PAY FOR.
>
> 2. The local mirror and sync process is certainly an approach if you
> have the patience (or the right parameters? I have no experience) to
> keep retrying until you eventually get past the stuck point. Also, I
> don't have a lot of machines to maintain, and this is only an
> occasional pain. It's only a real pain when I let a machine (like my
> laptop) get very back level on maintenance.
>
> 3. I started my rant with praise, and I continue the praise. CentOS is
> one of (if not the) best enterprise Linux offerings. That being said,
> the software delivery (including Dag which is not a part of CentOS but
> which is relied on by a lot of folks) is not up to the reliability
> level that I have experienced elsewhere. For example, I ran Gentoo for
> years, and I seldom found this type of problem getting updates even
> though the volume of downloads (source) is much higher than for CentOS
> and Dag (binary).
You would be very surprised. We are serving on the mirror.centos.org
about 1 TiB of data per day now.
We rank very close to Mandriva and Ubuntu for total traffic on our
domain.
> For example, I've been maintaining a Ubuntu system
> for several months alongside of CentOS. I very rarely encounter this
> type of problem with Ubuntu updates.
OK, I never have problems with updates, but if you do, try a mirror that
might be closer to you. My downloads usually happen at 400-800kb/sec
and I never have time outs using the standard mirror.centos.org mirrors.
Yum has problems with transparent web proxies and alot of ISPs are
starting to use them, maybe that is an issue for you.
There is a list of mirrors here:
http://www.centos.org/modules/tinycontent/index.php?id=13
Modify you /etc/yum.repos.d/CentOS-Base.repo
Change the http://mirror.centos.org/centos/ to a link on one of the
mirrors that is close to you ... add a second or third mirror for fail
over to each repo.
>
> Please don't waste your breath saying I should go elsewhere. I will
> continue to use CentOS and to recommend it to my friends. It's a great
> product.
>
> IMO, this is purely a mechanical problem. Whatever the methods, other
> FOSS providers manage to avoid this type of erratic delivery. I don't
> have a clue how. I have no experience setting up or maintaining a
> system of mirrors.
>
> I'm on the fifth attempt this morning to get through about 200
> packages, and I don't think the results would have been much different
> if I were trying to sync a local mirror. This isn't even the
> post-new-update-rush, for $DEITY sake.The first 3 attempts hung
> totally at retrieving a man update. The next attempt waded through
> about 80 more packages and then hung. The final attempt is trying many
> mirrors again and not getting there again.
>
> I've changed my mirror settings a few times, but there does not appear
> to be an ideal solution. Thus my frustration.
>
As I have said, I do not have any issues (except during the 4.2 upgrade)
with getting updates.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20051124/4019983e/attachment.bin
