Matt Hyclak wrote:
There is, use a baseurl in your config file rather than the mirrorlist.
But that's a per-box per-repo specific change, with per-distro, per-repo
variations for the end users to figure out for themselves. And then it
won't fail over at all if the url you pick goes away. Aren't computers
supposed to work for you instead of the other way around?
You can't please everyone. I'd argue that the majority of people are not
behind a proxy of any sort.
And I'd argue that the majority of Centos installations have more than
one copy in locations that could easily use a common proxy. I'm not
sure how to prove that, but it makes sense for an 'enterprise' OS.
I'm assuming you are using a transparent proxy
such that you don't have to configure proxy settings on every box - so I
won't argue that point.
No, I just let the shell export the setting when it is useful:
http_proxy=http://proxy.domain.com:3128 yum update
I can update one box, test things, then ssh that command in a loop to
any number of boxes in locations where the specified proxy will help.
With Cento3 it works great and the subsequent runs are almost instant.
Regardless, tools like puppet, or simply providing .repo files for folks
makes it fairly painless to make those changes for end-users.
Those look like extra work to me. And you have no fail-over if you
force a single repository url. A better scheme would prefer to use a
one based on location but still retry elsewhere if that fails.
Yes, computers should work for you, however you can't expect the software to
read your mind and do what you think it should do.
Reading 'my' mind wouldn't be all that useful because I don't know the
right answer either - and if I knew something today it would probably be
wrong tomorrow. What we need is a way to compute the best URL that is
repeatable when requested by the same proxy unless that one is no longer
available.
Some amount of
configuration is necessary on *any* computer - why is this different?
This is different because we usually see progress going in the direction
of more and more automatic configuration with better designs. In this
case Centos3 had it right and has since regressed in design. I realize
that there were reasons for the change, but there still has to be a
better way.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos