Honor oldstable repo config for Debian 10 Buster

[conorsch]

Status

Ready for review

Description of Changes

Unbreaks clean installs by respecting the renaming of Debian Buster apt sources to "oldstable" by upstream Debian. Additionally, cleans up some of the apt repo config to resolve some long-standing issues.

• Closes Templates fail to update due to buster "oldstable" status #721
• Closes Configure FPF apt repo early in provisioning #651
• Closes fpf-apt-test-repo.sls state name is misleading #572

Testing

It's critical to remove the TemplateVM RPM prior to confirming resolution. That's the "dnf remove" action below. Because the template RPM will need to be re-downloaded, expect ~600MB download to dom0.

make clone && make clean
sudo dnf remove qubes-template-securedrop-workstation-buster # necessary because make clean doesn't remove TemplateVM
sudo dnf clean all
make dev

If you see no errors and the provisiong completes successfully, then the issue is resolved.

Deployment

So far, testing shows that the updater runs are not affected, so existing installs do not appear to be at risk. I don't quite understand why that is, unfortunately, other than the age of the apt lists in use.

[sssoleileraaa]

i see 17 errors during make dev provisioning that i am now looking into... looks like the first error just says that the qubes-template-securedrop-workstation-buster package failed to install/update during the dom0-install-securedrop-workstation-template step, so time to hunt through the logs!

[conorsch]

@creviera That sounds an awful lot like the original problem reported in #721. Scroll up to the top of the provisioning output and find the first error. If any failure happens during configuration of the base template, then that error will cascade into a whole slew of errors, such as the 17 you mentioned.

[eloquence]

I was able to reprovision a workstation without issues with these changes (including removal of the template), and the dom0 tests ran without errors. I am no longer able to observe the issue when running apt update in sd-small-buster-template manually, either.

The change to running the fpf-apt-repo state in the updater is significant; it looks like this will also help towards #653 since it will run autoremove on each updater run, correct?

[eloquence]

Completed another run without errors (I did hit an issue with make clean due to rsyslog being masked - looks like this is both interfering with logging, which you added a card for @conorsch, and at least sometimes with cleanup as well).

[sssoleileraaa]

Sorry, was out sick and just got back to this. I lost the

Completed another run without errors (I did hit an issue with make clean due to rsyslog being masked - looks like this is both interfering with logging, which you added a card for @conorsch, and at least sometimes with cleanup as well).

I created an issue with a workaround to capture this: #723

Second time around this worked as expected.

[conorsch]

The change to running the fpf-apt-repo state in the updater is significant; it looks like this will also help towards #653 since it will run autoremove on each updater run, correct?

Yes, that's the intention! There's also #442, which I haven't closed, pending confirmation of the new behavior on a staging setup.