[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When should we https our mirrors?

On Thu, Oct 27, 2016 at 10:05:56PM +0200, Tollef Fog Heen wrote:
> ]] David Kalnischkies 
> > I would kinda like to avoid encoding the entire answer and sending that
> > in for display because it would be a lot of noise (and bugreporters will
> > truncate it if it is too long trying to be helpful), so if people who
> > actually know what they would need to deal with issues (I don't) would
> > decide upon a set and report a bug against apt to implement it, we will
> > see what we can do.
> It would be great if we could have all of it (dropped in a log file
> would probably be ok, we can then ask for it from the user).

I feared you would say that, but I would very much like to avoid that as
it complicates everything: The acquire system has roughly 3 usecases:
Download indexes, download packages and download "random" files
(sources, changelogs, …). The later two can be done as root and as
a 'normal' user. We couldn't let the individual transport log on their
own as they have no idea where to. So I would need them to tell the
system the stuff they want logged which also doesn't really know what it
does (and especially when it switches jobs at runtime in interactive
tools) so I would need the individual callers (apt, aptitude,
packagekit, …) to decide where to log to (+ multiple acquires could be
running at the same time all over the place which shouldn't battle for
logfiles – there are even situations in which an acquire system runs as
part of another one…) which pretty much rules out stretch to have it.
And given the world adapts very slowly to apt changes I wouldn't hold my
breath for buster either. We would also need a rotation setup as the
first thing someone does on an 'update' failure is to run it again (or
a process in the background does like packagekit without the user
realizing that the manual invocation was superseded), …

[Having "stuff" (not limited to acquire) logged to a file might be
a good idea anyhow eventually, but that project is at least as boring as
it is big, so…]

Showing a few more lines is trivial by comparison, effects everyone
instantly and is hence oh so much more appealing from an apt POV… ala:

| Transport-Debug:
|  Connected-To: http.fastly.debian.example.org:8080 (
|  Via: 1.1 varnish, 1.1 varnish
|  Fastly-Debug-Digest: b6ea737814cc1feed0f9205c8ee1338025c8d316c1029a16c6f4365c6a7c6cdd
|  X-Served-By: cache-ams4141-AMS, cache-fra1222-FRA
|  X-Cache: MISS, MISS
|  X-Timer: S1477471085.983025,VS0,VE27


| Transport-Debug:
|  Connected-To: http.cloudfront.debian.example.org:8080 (
|  X-Cache: Miss from cloudfront
|  Via: 1.1 b74a7a3f7ddfd685212e870d027c332d.cloudfront.net (CloudFront)
|  X-Amz-Cf-Id: OWWfvAJ_et1_QVyPiP07-bodyCenkWtGTz8OeRW041eyeRDuvmGgCA==

(assuming these headers would tell you anything, they just look good to me)

> > P.S.: Fastlys Via response header seems to be important, given that it
> > is sent twice, but apart from that…
> Not really, it's just that it passes through multiple caches on the way.

[Ill-attempt at humor – to the untrained eye it just looks like Via
should be what X-Served-By contains. Especially merged as above it
looks like a mistake but so be it.]

Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature

Reply to: