Proxy for packages

[Salmiakki]

Has anybody managed to set up a proxy or mirror of sorts in the net-vm or firewall-vm or something similar to avoid downloading all the packages several times for updating all the templates?

My connection is a bit slow and also data limited so it would be great to save those repeated downloads.

[PhR]

Hello Salmiakki,

On 07/15/2017 10:45 PM, Salmiakki wrote:
> Has anybody managed to set up a proxy or mirror of sorts in the net-vm or firewall-vm or something similar to avoid downloading all the packages several times for updating all the templates?
>
> My connection is a bit slow and also data limited so it would be great to save those repeated downloads.
>

Yes, I have setup a local CentOS Repository Server which is holding all
packages for other VMs in this datacenter.
The repository is synchronized with an upstream repository via rsync.
All packages are located on a NFS share which is connected to the other VMs.
Basically the same could be done in Qubes.
If you are interested drop me an email and I send you the Howto I've
written for CentOSm which would also work for Fedora.

But this would require that the AppVMs see the repository-Server and
AFAIK there shouldn't be inter-VM-trafiic.

- PhR

[Noor Christensen]

On Sat, Jul 15, 2017 at 11:16:28PM +0200, 'PhR' via qubes-users wrote:
> Hello Salmiakki,
>
>
> On 07/15/2017 10:45 PM, Salmiakki wrote:

> [...]

>
> But this would require that the AppVMs see the repository-Server and AFAIK
> there shouldn't be inter-VM-trafiic.

Just a thought:

Create a ProxyVM and set it to be the NetVM for the file server and all
those VMs that need access to it. Now you have a single point where
all traffic to the file server comes through, and iptables can be set up
to allow specific AppVMs to access it.

-- noor

|_|O|_|
|_|_|O| Noor Christensen
|O|O|O| no...@fripost.org ~ 0x401DA1E0

[Noor Christensen]

On Sun, Jul 16, 2017 at 12:03:49AM +0200, PhR wrote:
> Hello,

>
> On 07/15/2017 11:53 PM, Noor Christensen wrote:
> > Just a thought:
> >
> > Create a ProxyVM and set it to be the NetVM for the file server and all
> > those VMs that need access to it. Now you have a single point where
> > all traffic to the file server comes through, and iptables can be set up
> > to allow specific AppVMs to access it.

> I don't get it...
>
> [AppVM] -> [Repository ProxyVM] -> [Firewall ProxyVM] -> [NetVM]

More like:

[RepositoryVM] \
|---> [Repository ProxyVM] ---> system fw and netvm etc
[AppVM] /

Repository ProxyVM is where you do your iptables config to allow traffic
from AppVM to reach RepositoryVM. See the docs[0] for some examples on how
to configure proxies.

Please reply to the mailing list next time.

[0] https://www.qubes-os.org/doc/

[Salmiakki]

On Saturday, 15 July 2017 23:16:35 UTC+2, PR wrote:
> Yes, I have setup a local CentOS Repository Server which is holding all
> packages for other VMs in this datacenter.

Thinking about it that would work but does not actually help me as that will sync all packages even the ones that I do not have installed, right?

[Unman]

There's been some discussion of this in qubes-issues.
Some people use squid on an upstream proxy.
I only use Debian/Ubuntu so use apt-cacher-ng installed on upstream
proxy. It installs out of the box, and all you need is a new rule in the
nat table to capture traffic for the proxy. That way there's no
difficulties with routing or configuration on the templates.
iptables -t nat -I PR-QBS-SERVICES -d 10.137.255.254 -j DNAT --to-destination XXX:3142

NB, apt-cacher-ng plays reasonably well with Fedora despite the
maintainer's comments, as far as I remember.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Salmiakki:

> Has anybody managed to set up a proxy or mirror of sorts in the
> net-vm or firewall-vm or something similar to avoid downloading all
> the packages several times for updating all the templates?

https://github.com/rustybird/qubes-updates-cache

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZa4bTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf81gP/jzqTkT6Yw+2kwDaLmNr/Pg1
srRoPL2s/gTt/0MVapJ2XjsrxyoSX1FSjiVjtZ4yA1QQJUa+8TyzJsxeXd8TMqeL
YbNaA+/vkzZT6eAxnniZfm2tZsCKZj72Q8jftQNz7ppQqwkMPOmI4U4r5o/pjzoL
Ra50TMssSr1lf2rAJzjjduX7gN1en1bg4ycukuDTKxiNP06rO12E7ed3g75LnEo4
MrtcWi4u0/R6fX9sO8DHlu2gJx3NDo4mdqGyxVsLb2ampInegiSAv5MluqLZPMFr
YNVNaiarvPw4IISZT3FB+KUPC2lN1XUmziYByFdYOEE5OIEYrMmAQ6B+W2oFGJ5k
M0h74z3uM4B2csq/m2meW3yINgh7e8anECE/Z+73UTNMpgvYrJYsgmPfiSQ/B/Fw
f+SMUHvoxFWdc+T/qMRn4znd5nyoLFOlE/ps+HWVdDGDSjBhqTZoFmOnSMRob8J7
Y2lowhS0MztGz1Ngoyt2lIkguD+tIRT/pdr7Z5W5VDSoFEhu8vq6LXxPgufM/z6V
zqAFaZU1XhnAhBT8fe558P//nyRq3OV0Uni4B9fc6kvAIM/9A92snrrbE4LOKZhj
b+xMZDOaBz844qP5G2udu3fLL+pQk16KRXDjHY9wkz/ZwZ89vgxhZxt/cZQquHrb
Ycw6KKeTSeiGNslB1Tjx
=j5YK
-----END PGP SIGNATURE-----