cache for UpdateProxy?

[Sven Semmler]

I have several template VMs that are based on the same distro but with
different software installed.

tpl-ubu-18-apps ... for offline / disposable qubes ... lots of apps
tpl-ubu-18-web ... for online / disposable qubes ... just firefox
tpl-ubu-18-email ... fetchmail / postfix / mutt
tpl-ubu-18-base ... just the basics for all kinds of qubes

Even though those templates have all their special purposes and contents
there are lots and lots of packages that are installed in all of them.

If I now run my update scripts, each of those will download identical
packages. All of them will do so through the Qubes UpdateProxy
(tinyproxy?).

Is there a way for me to configure this proxy to hold a very short term
cache? Something like 30 minutes? Meaning if an identical download was
requested within the last 30 minutes a locally cached copy is served
instead of downloading it again from a remote server.

/Sven

--
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

[unman]

On Fri, Mar 06, 2020 at 01:32:55AM -0600, Sven Semmler wrote:
> I have several template VMs that are based on the same distro but with
> different software installed.
>
> tpl-ubu-18-apps ... for offline / disposable qubes ... lots of apps
> tpl-ubu-18-web ... for online / disposable qubes ... just firefox
> tpl-ubu-18-email ... fetchmail / postfix / mutt
> tpl-ubu-18-base ... just the basics for all kinds of qubes
>
> Even though those templates have all their special purposes and contents
> there are lots and lots of packages that are installed in all of them.
>
> If I now run my update scripts, each of those will download identical
> packages. All of them will do so through the Qubes UpdateProxy
> (tinyproxy?).
>
> Is there a way for me to configure this proxy to hold a very short term
> cache? Something like 30 minutes? Meaning if an identical download was
> requested within the last 30 minutes a locally cached copy is served
> instead of downloading it again from a remote server.
>

No. There's a patch that *would* allow caching, but tinyproxy natively
is not caching proxy.
Drop in apt-cacher-ng in its place to get lightweight caching proxy.

[Sven Semmler]

On Fri, Mar 06, 2020 at 12:38:45PM +0000, unman wrote:
> Drop in apt-cacher-ng in its place to get lightweight caching proxy.

Thank you! A keyword is all I needed ...

- https://github.com/QubesOS/qubes-issues/issues/1957
- https://github.com/unman/notes/tree/master/config/cacher

[Sven Semmler]

On Fri, Mar 06, 2020 at 03:43:00PM -0600, Sven Semmler wrote:
> On Fri, Mar 06, 2020 at 12:38:45PM +0000, unman wrote:
> > Drop in apt-cacher-ng in its place to get lightweight caching proxy.

> - https://github.com/unman/notes/tree/master/config/cacher

For others reading this now or later... making the salt in the above
link work is more then I could handle* (there were some dependencies on
other salt scripts I didn't have). However, unman also has a super
helpful step-by-step instruction:

https://github.com/unman/notes/blob/master/apt-cacher-ng

This worked as described with the following restrictions:

-> debian templates did not work unchanged due to the https:// URIs but
once I changed those to http://HTTPS/// it worked just fine

-> ubuntu did work out of the box as the URIs are http://

-> some 3rd party repos needed the http://HTTPS/// change (e.g.
Signal)

-> I couldn't get it to work with the one Fedora qube I have
(qubes-builder) and wasn't in the mood to tinker. Since it's the only
Fedora instance (besides dom0 which is an entirely different version)
having a cache would bring me no benefit.

I don't quite understand why repos would be hosted on https:// URI in
the first place. The contents is hardly confidential, the authenticity
is checked via signatures ... why the overhead? Might be off-topic for
this list though.

/Sven

*salt along with Python is something I know I have to learn, but right
now just don't have the mental bandwidth for