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 https://groups.google.com/d/msgid/qubes-users/20210806140841.GC754%40thirdeyesecurity.org.
