On Wed, Jul 28, 2021 at 10:18:45PM +0200, Trust me I am a Doctor wrote:
> unman <un...@thirdeyesecurity.org> writes:
> > The repository was unavailable for a while. Was that the issue?
> Yes. I panicked.
> > Yes, apt-cacher-ng  works for Fedora updates.
> Thanks for the details. I finally took the time to look at it.
> > You have to make some changes -
> > First, on the client side, comment out "metalink" lines, and uncomment
> > "baseurl" lines.
> The cisco repository of the codec openh264 does not have a baseurl, I
> found that I could use
> http://HTTPS///codecs.fedoraproject.org/openh264/$releasever/$basearch
> in place, I assume this can be safely added to
> /etc/apt-cacher-ng/fedora_mirrors
> Also fedora ships with
> #baseurl=https://download.example/[...]
> in /etc/yum.repos.d conf files, I assume I had to replace them with
> baseurl=http://HTTPS///downloads.fedoraproject.org/[...]
> Then don't forget to
> $ dnf clean all
> > This is because the metalink will keep loading new https://
> > repositories, and apt-cacher-ng cant cache those requests, as you
> > know.
> I think we could also specify &protocol=http on metalinks as explained in
> https://unix.stackexchange.com/questions/240010/how-to-create-an-on-demand-rpm-mirror/426331#426331
> I have not tested it thought.

I have seen that, but generally I dont want clear traffic, so its not a
good option for me.

> > Second, watch the caches in /var/cache/apt-cacher-ng , and add
> > any new ones to the fedora_mirrors file - this is because that file
> > doesn't contain all Fedora repositories.
> It is maybe too soon to see, I don't know yet if having manipulated the
> url to use downloads.fedoraproject.org will effectively lead to mirrors
> to manage. What I know is, it was creating a directory named
>   downloads.fedoraproject.org
> before I add
>   https://downloads.fedoraproject.org/pub/fedora/linux/
> to
>   /etc/apt-cacher-ng/fedora_mirrors
> And that downloads.fedoraproject.org is supposed to redirect to mirrors...
> In the doubt I run a script to duplicate all http url of fedora_mirror
> to https.
> I put a systemd timer to watch new directories on /var/cache/apt-cacher-ng/
> I also put a timer to run /etc/cron.daily/apt-cacher-ng that manage
> expired files and make the html report.
> Interestingly enough debian ships with scripts in
> /usr/share/doc/apt-cacher-ng/examples/dbgenerators.gz
> that may take care to update the mirrors files list at the cost of a
> lengthy cycle of queries ... That could be triggered weekly.
> Do you known about it?

Yes, but I've never(?) used it - the default lists are pretty good, and
it takes nothing to check if there are any rogue mirrors being fetched.

> Your instruction didn't said anything for the AppvM so I figured out
> that I could put an instruction in /rw/config/rc.local to switch back
> the repositories files to their initial values so I can still test out
> packages there before really installing them in a template.
> Lastly, whonix-* will fail to update with, in 
> dom0:/etc/qubes-rpc/policy/qubes.UpdatesProxy
> $type:TemplateVM $default allow,target=cacher
> Because whonix ensure updates comes from the tor network. I didn't
> figured yet if it is desirable to search to do something here.

I dont use Whonix.
Since you can configure cacher to fetch across the Tor network, this
looks brain dead to me. I think you must mean that Whonix ensures that
updates run through Whonix.

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to