apply_patches.php is not part of pfSense_BASE. its is part of the system_patches package.
you could try reinstalling/installing system_patches

if you really wish to manually copy:
https://github.com/pfsense/FreeBSD-ports/tree/RELENG_2_3_0/sysutils/pfSense-pkg-System_Patches/files/usr/local/bin

Same discovered here  8)

I can't help with the package creation part of your post, but thought I'd mention that one of the pfSense developers is working on the return of vnstat. A promising screen capture was posted the other day in this post of the graphing, but the caveat is that the developer working on it doesn't have a timeline for completion, and the level of effort depends on workload of other more important items.

But there is work in progress to bring vnstat back to pfSense. :)

@cmb:

@NOYB:

Thanks Jim.  So is there a use case for doing the rrddump in the reboot/shutdown/periodic backup for ram disk instead of the *.rrd files directly?  Would make that process cleaner, and straight forward without the rrddump.

Wouldn't be a good idea. That's a lot of processing for no reason in that case. It's fast and low-resource to copy the rrd files, doing a dump and restore chews up CPU and RAM. In the past, at times enough RAM that it runs an ALIX out of RAM and kills off the process. Good chance of data issues on low RAM systems if you did a dump on every shut down and restore at boot up.

That's how it's currently being done.  So should it be changed?  Just tar the *.rrd files and do away with the rrdtool dump at shutdown and rrdtool restore at boot up?

In the ram disk management commit/pr submitted it should be pretty easy eliminate the rrdtool dump/restore on shutdown/boot up.

Just continuing to answer my own questions here. It looks like the <dns>system_services entry is likely related to a pull requests here https://github.com/pfsense/pfsense/pull/679/commits/513d61a8934989be0b9332d29d0f80926302344e#diff-163d9a46abf34586e1f87297c7670978R193 that was never actually merged.
So basically it does nothing at this time.

But it would be really great if that function would exist as mentioned in the pull request. Instead of hard coding a check for specifically unbound or dnsmasq if any package that provides the DNS system service is enabled then those triggers would apply.

Since pfSense is open source I may send a new pull request myself at some point when I'm done my current port.

What I've done in my package is I wrote some code that configures unbound on a non-standard port and makes it enabled while making sure dnsmasq is disabled. Just so that any pfSense functions that depend on the DNS Resolver/Forwarder (which we've replaced) being enabled will work.</dns>

@heper:

-https://forum.pfsense.org/index.php?topic=103481.0
-creating pull requests for them on https://github.com/pfsense/FreeBSD-ports
-creating a redmine ticket for feedback

there is also the chance that someone of the coredevs is already working on a pkg for NUT …

Thanks.

I have created the pull requests + tickets in redmine.

With the change to pkg to fully manage installs and uninstalls of packages, the old _<custom_php_deinstall_command></custom_php_deinstall_command>_still gets called, but the problem now is it gets called after pkg has already deleted all the PHP and INC files from the system.  So naturally your deinstall routines can't be called because they no longer exist.  I hit the same problem in one of my packages.

The command BBcan177 referenced gets called before pkg removes all the files, so your uninstall routine can run.

Bill

Oh, thank you very much ! :)

Thanks for the report, I can confirm it is a problem and I opened a ticket for it here https://redmine.pfsense.org/issues/6010 – I also pushed a fix to 2.3 for it, so it won't be a problem in the future.

They are OK at boot time, so once you have the interface saved it's OK from then on if you have to reboot.

GIF interfaces also had the same problem for interface flags so I applied the same fix there.