Get currently applied opnsense-patch list?

[Greelan]

Dumb question. I have applied various patches over time to apply fixes or for testing. I want to reverse some of them but can't necessarily remember them all. Is there a way of listing what is currently applied so that I can figure out what to reverse? opnsense-patch -l only gives the content of the local cache, which as I understand it does not necessarily represent what is currently applied

[Greelan]

Alternatively, if I can't get such a list, had do I get my system back to a "clean" state? Thanks

[Maurice]

Check the documentation for 'opnsense-revert' options: https://docs.opnsense.org/manual/opnsense_tools.html

Cheers

Maurice

[Greelan]

Which I of course did  :)

I didn't see how that would help with a specific patch, although I guess I could do the following to revert to a clean state?

Code Select Expand

opnsense-revert opnsense

or

Code Select Expand

opnsense-revert -r 21.1.3_3 opnsense

[Maurice]

Yes, sorry, this was only meant as a response to your second question. If you've lost track of the applied patches, I would revert to a clean state and then reapply the patches which you still require.

[franco]

I would always recommend the manual pages although I agree that this needs to be documented in a high-level fashion regard the available toolset and when to use what.

https://github.com/opnsense/update/blob/master/patch/opnsense-patch.8

opnsense-patch -l will list all previously cached patches. That only means that it doesn't have to be downloaded again (e.g. for easy revert when your internet connection is down after a reboot test), not that it tracks which patches are applied or superseded by the releases.

opnsense-revert is the correct tool for the clean revert just as each firmware update is as soon as you have Internet access. Any time a package is updated or reinstalled its files are reset to the correct state. That also means opnsense-revert is available from the firmware packages GUI as the reinstall button... :)

Note that opnsense-revert -r xxx selects a directory on the mirror that normally doesn't include hotfixes and stops working when we clean up the incremental update directory, i.e. https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/MINT/

To make sure you don't have any other patches active the health audit can track files modified.


Cheers,
Franco

[Maurice]

That also means opnsense-revert is available from the firmware packages GUI as the reinstall button... :)

I never noticed that... neat!

Have a nice weekend!

Maurice

[Greelan]

@franco, I did look at both the OPNsense docs and the man page (I always try to RTFM and self-help first). But they didn't readily identify what I needed. And that is because it seems there is no way of listing applied patches.

The health audit is probably the closest to help identifying what patches are applied - at least what packages are affected by those patches, if not the details of the patches themselves. I will just have to be a bit more diligent about tracking what I do to the system. [emoji23]

As an aside, what is the pattern of when patches that are accepted into OPNsense master making it into the official updates? Some seem to be applied in the next update. Others (such as my WireGuard widget timestamp patch 8f66033 in plugins) seem to be delayed. Just curious.

[franco]

I wasn't trying to suggest that you didn't see it and missed something, yet since I saw no mention of the manual page I recommended it first. If the question was if "-l" option could show more things we could directly jump into probability of implementation especially WRT lines of code and confidence in the results. We still can if you want. :)

Right now opnsense-patch is a bit under 300 lines of code and the main mission is to keep it as small as possible. That already isn't working when git diverges from normal patch(1) functionality for example or to manage the caching of patches so it doesn't have to refetch always.

As I said the high level motivation for these tools is mostly towards rapid test deployment especially between opnsense-patch and opnsense-revert. opnsense-patch is a tool that uses the patch(1) utility to deliver patches from GitHub. Even if we could track patch state we really don't have to since we have a general update mechanism through opnsense-update and for all else opnsense-revert ("ok that didn't work") or even opnsense-bootstrap ("really screwed here, let's reinstall all at once").

As for backporting/stable policy it depends a lot on the scope of the patches applied, current time lines and workloads. The general rules of thumb are that patches go into development release once before being released in the next one as a stable patch. There are a number of reasons to not adhere to this principle though.

In plugins / wireguard the maintainer gives the ok for the merge of the next stable version or we backport fixes with revision bumps. Cosmetics mostly wait for the next stable version and I know that Michael is swamped with private things due to the pandemic situation on top of day job workload.

That being said I think os-wireguard 1.5 will be included in 21.1.4 with all the latest changes from master.


Cheers,
Franco

[Greelan]

Thanks, appreciate the detailed explanations!