On Sun, Nov 11, 2012 at 02:17:13PM +0100, Eduard Bloch wrote:
Hi,
> > > code is generated by the code that attempts to detect a mirror with
> > > missing architecture. The skipping of other Packages files would also be
> > > enforced by that code. But this method only becomes active if you have
> > > used the keyfile=... keyword in your config. Have you?
> >
> > Yes, see above.
>
> I see. The keyfile= feature is actually a kludge, a bad workaround for a
> problem of detecting which architecture the client might to need and
> whether the particular mirror can deliver it. There is no need for this
> thing if you only have complete mirrors in your backend list.
Once more, one of my reasons for using apt-cacher-ng is that I want to
protect my clients from problems caused by bad mirrors. I'd like
apt-cacher-ng to automatically try fetching files from different mirrors if
they're not found on the preferred one(s).
This is because the mirrors that are topologically closest to me are
sometimes incomplete - not in the sense of missing entire architectures but
missing one or two files that should really be there.
> And in the long term this problem should be tackled by something with
> real checks of package's architecture vs. what the particular mirror
> provides. In fact, I have a pretty good idea of where to get and how to
> handle that information, it's just a little bit tricky to implement.
This sounds good, but I don't think it'll solve my problem.
> > > > This is what happens when I query it directly instead of going through
> > > > Squid. I suppose Squid discards "Bad mirror" and returns "Internal
> > > > Server
> > > > Error" based on an internal table of HTTP status codes.
> > > >
> > > > Is there a good reason why the client is not allowed to see the 404
> > > > error?
> > >
> > > Please ask Squid or APT guys!
> >
> > What do they have to do with this? It's ACNG that sends the client a 500
> > error instead of a 404 error.
>
> It sends a 500 for a reason - misconfiguration - why should it send a
What misconfiguration?
> wrong 404 code instead?
Wrong? How is passing a 404 error code received from an upstream mirror
through to a client wrong? FWIW, I think acng's behaviour is wrong, for the
following reasons:
1. it masks the real error (404) and replaces it with a bogus one (500).
2. clients would be able to cope with the real error, but they barf on
receiving the bogus error.
So instead of increasing robustness (as I'd say it's supposed to do), acng
actually makes matters worse.
> And squid replaces my message with a hard-coded string from squid's
> internal table of error codes.
Yes, that's regrettable. OTOH, the "500" HTTP status code does have a well
defined, standard meaning ("Internal server error"), codified RFC2616. I'm
not sure you can legitimately make up alternative meanings for standard HTTP
status codes. I suppose there might be less harm in inventing completely new
codes, like 555 Bad Mirror; or maybe use 502 Bad Gateway which is a closer
match to what you want.
> As said, keyfile= thing is a kludge and only works if the client sends
> the request in the exact order from exactly the same connection.
> Intermediate squid proxy does not follow that rules and also does not
> report the outcome correctly, so ATM this is basically a dead end.
OK, maybe I'm Doing It Wrong.
My goals are:
1. cache apt downloads.
2. remap attempted accesses to far-away mirrors to closer ones (or the local
cache).
3. fall back to other mirrors if the preferred ones are temporarily
incomplete.
ACNG does a good job of #1, a pretty good job of #2, but apparently it
doesn't do #3 -- I had thought that's what keyfile= was for, but you seem to
say it isn't. So what about #3? Is that not something ACNG will ever do for
me?
Thanks
Andras
--
Andras Korn <korn at elan.rulez.org>
bogosort dad*.dna mom*.dna >baby.out
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
