They are the same thing.
My “notes” are just that - notes, (usually to accompany training), not a guide.
In 4.1 it’s trivial to make any qube in to one that provides
network.
If you compare this with the salt in GitHub - unman/shaker,
or the packaged solution, you’ll see that by default the caching qube
is set to provide netvm.
This means that it can enforce Qubes firewall for any attached qubes,
as you would expect.
If you make the cacher provide network, then you can use it for any
qube, as well as templates, just by setting it as update proxy using the
normal Fedora/Debian mechanism.
I tend not to set the cacher in place of sys-firewall, because I
usually have it set to update over Tor.
Separating the functions also allows you to switch the proxy to Tor, or
VPN, or clear, on the fly, as you need.
You can.
Since the aim of the proxy is to store packages, then it seems somewhat
pointless.
I can think of a scenario where you might want to do this.
Let’s say you have 5 Debian templates, and you want to see how they run
under testing, or sid. You clone the templates, and set the clones to update
using the disposable cacher.
Now you have the benefit of cached updates for that session, so you have
saved a good deal of bandwidth and time. When you close the disposable
the stored packages are lost. That doesn’t matter because (particularly
for sid) you’re trying to hit a fast moving target.
Either use a browser in the cacher, or connect from any connected qube.
You can restrict access to the admin page by setting AdminAuth in the
config file.
It’s a great tool that works out of the box for Debian.
The salt package is reconfigured to work for Debian, Arch, Ubuntu, and
Fedora, but you can get to that same configuration on your own.
You should be able to run it maintenance free.
You can add support for other update mechanisms with some fiddling
about.
Enjoy.