I think this is a common problem, with no easy answer. This is what I do for our 50-60 workstations: I configure all the clients to [main] include=http://my.site/site-config.conf Depending your your distro, getting rid of stuff out of /etc/yum.repos.d can be a PITA because when there are updates, the files come back. I ended up making my own dummy yumconf rpm which did not have any files in it. Once you have this, you can easily change things in one place. I then point some repos to local mirrors maintained with rsync and (a hacked version of ) createrepo, and others point to external repos (via squid). You can use proxy= to set the proxy for just these external sites. You want to point to a local mirror. If the mirror is down, you can alter the mirror manually in the central config file. The performance of squid is not very good. It always seems to cache the metadata too long and the packages not log enough. It is better than mirroring all of rpmforge for just a few packages. Our main servers still run CentOS-2 so most python based solutions are not suitable. I cifs mount the directory to a CentOS-4 box to run createrepo. I do not recommend mirroring the header info because it is frequently incorrect. Generating it yourself is the way to go. John. Larry Dillon wrote: > Dear Yum list: > > I've search the 'net and haven't found a clear answer regarding the > "best practices" regarding Squid. > > We use yum to update a few different Linux distro's. > For FC4 and FC5, we have created local repos as many machines want the > updates. > For less popular distro's, squid seems like a good idea (until I figured > out that one gets a different, random mirror each time and all it really > does is pollute the cache) > > Obviously, minimal client configuration would be a plus. > > It the best approach: > > 1. Don't use squid, even though it puts extra burden on the mirrors. > 2. Edit every .repo definition to use one site (baseurl=). > 3. Make a local mirrorlist, perhaps in conjunction with the > failovermethod=priority setting. > 4. Some marvelously elegant solution that I have failed to consider. > > (Oh, please let it be #4) > -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin
