Find a way for RESTAPI install to survive pfSense Updates

[Rudio-Engineering]

The title kind of says it. We all know that on a pfsense update, unless it is in the official repo, it gets removed. Is there a way to have the API survive an update? If this has already been asked and answered in another area, just point me there, and I will go RTFM.

[rpaal10]

I'm in the same situation. I updated a test VM to beta version 2.9, and the API package has disappeared.

[jaredhendrickson13]

This has been looked into quite extensively and unfortunately there still is no great solution without resulting to hacks. The official stance is still that it is inherent behavior during pfSense updates that cannot be safely avoided. It would be nice if Netgate would provide a supported channel for third-party packages, but their concerns seem to be in having control over the whole package ecosystem.

Here's what has been tried so far:

Creating a third-party pkg repo for pfREST packages
This worked sometimes and is the most promising solution. But some updates would completely wipe out the repo config or would ignore it entirely. It also did not guarantee the package would get reinstalled after the update. This would be the ideal solution, but the behavior has been too inconsistent when pfSense meddles with the repo configs and packages.

Distribution outside of pkg (e.g. tarball/shell installer)
This did allow the package to survive updates in most cases, but it completely broke core features that tie into pfSense's package hook systems like web server configurations and logging. It also poses the risk of leaving incompatible code installed on pfSense after the update as it doesn't directly offer any mechanism to update the API code to a version compatible with that pfSense version.

Persistent package install via cron
This is probably the closest to reality option we have today. But it doesn't ensure the update completes with the package installed. There are security and compatibility concerns with this approach as well, mainly with update distribution which would require some work before it would be considered as a built-in feature. Regardless, this remains an option that users can configure already via the cron API and a carefully written version identification/package installation script.

Post-update hooks
pfSense does not provide a drop-in post update hook where the package could be re-installed. This solution would require patching core pfSense files or injecting code via non-conventionally means. The risk and maintenance required for this is just too high to consider.

---

There are also operational challenges behind updates that are often overlooked. Just because pfSense has an update does not necessarily mean the API works, builds for and/or has been tested on that version of pfSense. It often takes a few days to a few weeks to verify API compatibility with new pfSense releases and to push a build for them. Even if an old build does install on a new version of pfSense, it doesn't mean the underlying codebase is compatible with that version. Updating too early could result in an incompatible build being installed, or again the API not getting reinstalled at all. Stability is more important than convenience in these situations.

All that being said, I'm always evaluating the changes in new CE releases for new possibilities. The third-party repo approach I do periodically re-evaluate to see if anything has changed where that could become a more reliable option. In the meantime, there are options that allow the package to re-installed programmatically without pre-existing system configuration, namely pfsense-vshell and more recently the Ansible collection's system_restapi_install module. I personally have all my updates fully scripted so the correct package just get's re-installed automatically after the updates complete.