[PlanetCCRMA] YUM chews up my karma, and spits out evil

[Fernando Lopez-Lezcano]

On Fri, 2007-08-24 at 10:37 -0700, Ken Dawson wrote:
> Hello,
> 
> (sorry that this reply got a bit lengthy. I am stuck currently by this)
> As referenced in another thread, I am seeing this problem as well -- 
> pretty much continuously in the last couple of weeks.

I imagine some big isp has turned on something that is affecting caching
of pages (comcast in your case)... I seem to have seen more problems
recently. 

> I have two systems, one with f6 + planetccrma and another onto which 
> I want to install f7 + planetccrma. On both systems I experience these 
> mismatch problems wrt/ planetccrma's packages, but also, I suspect, 
> wrt/ fedora packages as well. 
> But, it seems that, whereas fedora has a couple dozen backup mirrors 
> to jump to, so far as I know, the planet has just itself (I tried 
> looking at the ircam site, but it is not current).  And a failure 
> there is pretty much the end.
> 
> I did an experiment ("which is not scientific", as they say in the ads):
> 
> First, I sat at home, and tried to do a "yum clean all", "yum upgrade", 
> and bombed out with alsa, ardour2 and supercollider consistency issues.
> 
> Then, I hopped in my trusty minivan and headed to Googleland (the streets 
> of Mountain View), and tried the same thing sitting in the 90ish heat 
> some 30 yards from a wireless access point.

Hi neighbour! :-)

> It was slower, but the second attempt, the lamppost upgrade, worked perfectly.
> 
> Suggestive.

Yup, different isp I guess. 
Google wireless (not evil) vs. comcast cable (evil)...

> I am new to this concept of ISPs caching content. Wouldn't the preponderance 
> of some other OS's traffic tend to flush humble little planetccrma's information 
> from that cache very quickly?
> 
> Otherwise, the mechanism doesn't seem to be behaving much like the cache 
> I studied in school.  If the source of the information changes, the cache 
> version should be flushed in favor of the new information.  Right?

Apparently it depends on the configuration of the server as well as the
cache itself. I hit the books, oh well, the web, and came up with:

  http://www.mnot.net/cache_docs/

(and other links)
Which explains the behavior and how to control it. 

> I believe that if I were to use rsync to suck over the planetccrma-f7 
> repository (to then install it locally), the cache would not be involved, 
> and the proper information would be obtained.  Maybe I'm dreaming.

Yes, that would probably work. 

> I don't have a workplace to VPN into, nor an available http proxy to 
> work through, so I am dead in the water.  My f7 install languishes, 
> ready to capture the planet packages, but awaiting some new approach 
> to make it at least even odds that it will succeed. (Did a complete f7 
> + planetccrma install a few days ago, and it was very ugly.)
> 
> Does anyone with more Internet sophistication have any insights into 
> this problem and possible work-arounds or solutions?  I would really 
> appreciated them.

I just added a:

  Header append Cache-Control "nocache"

header to the /planetccrma/mirror/ directory in our web server.
Hopefully caches will respect its wishes and information should be
checked against the source before serving a file from the cache:

"* no-cache: forces caches to submit the request to the origin server
for validation before releasing a cached copy, every time. This is
useful to assure that authentication is respected (in combination with
public), or to maintain rigid freshness, without sacrificing all of the
benefits of caching."

I tested it and the server is sending out the cache-control directive in
the headers of the requests, so hopefully this will work. Please let me
know if you still see the problem (I guess it might take a while for
things to percolate through the still valid caches). 

-- Fernando


> Fernando Lopez-Lezcano wrote:
> > On Thu, 2007-06-21 at 14:30 -0400, Jason Russler wrote:
> >> # yum clean all
> >>
> >> However, that doesn't work sometimes because, where I am, !$#@ Comcast
> >> is caching stuff somewhere and screwing up the package/checksum pairs.
> >>  So nothing works unless I a) wait or b) VPN into work and then use
> >> yum (there's probably a better way of getting around the caching
> >> mechanisms but that works for me.)  Could ISP caching be the culprit
> >> here?
> > 
> > I guess that could be a problem if different file types are cached for
> > different amount of time, then you could get inconsistent results for
> > the downloads. 
> > 
> > -- Fernando
> > 
> > 
> >> On 6/21/07, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> wrote:
> >>> On Thu, 2007-06-21 at 19:12 +0200, Fredrik Vang wrote:
> >>>> YUM's got a bad day with my CCRMA. When I try to install on FC6, yum
> >>>> fails after downloading certain packages, with the error message
> >>>> "Package does not match intended download". Am I missing something
> >>>> very obvious on my side, or is there something wrong on the repository
> >>>> side?
> >>>>
> >>>> (1/6): alsa-firmware-1.0. 100% |=========================| 3.5 MB
> >>>> 00:14
> >>>> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/6/i386/alsa-firmware-1.0.13-1.fc6.ccrma.i386.rpm: [Errno -1] Package does not match intended download
> >>>> Trying other mirror.
> >>>> (2/6): planetccrma-core-2 100% |=========================| 4.7 kB
> >>>> 00:00
> >>>> (3/6): rtirq-20070101-1.f 100% |=========================| 7.6 kB
> >>>> 00:00
> >>>> (4/6): alsa-tools-1.0.13- 100% |=========================| 333 kB
> >>>> 00:01
> >>>> (5/6): kernel-rt-2.6.21-0 100% |=========================|  16 MB
> >>>> 01:07
> >>>> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/6/i386/kernel-rt-2.6.21-0182.rt17.1.fc6.ccrma.i686.rpm: [Errno -1] Package does not match intended download
> >>>> Trying other mirror.
> >>>> (6/6): alsa-oss-1.0.12-3. 100% |=========================|  36 kB
> >>>> 00:08
> >>>>
> >>>> The same thing happens when I try to install certain other packages
> >>>> individually (e.g. supercollider)
> >>> I had not seen this error before. The repository appears to be fine, at
> >>> least from here. I just did a mock install in a mach chroot (after doing
> >>> a yum clean all so that everything would be downloaded again) and the
> >>> install proceeded just fine.
> >>>
> >>> The error appears to indicate that somehow the packages were not
> >>> completely downloaded or were corrupted during the download so that the
> >>> checksum does not match.
> >>>
> >>> Is this in a new install from scratch? Have you tried installing other
> >>> packages that do not come from the Planet CCRMA repo?
> >>>