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. > 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? 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. -- -- 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 https://groups.google.com/d/msgid/qubes-users/871r7it5uy.fsf%40riseup.net.
