Auto update check, checks for updates to base system + packages and sends email alerts
-
Here's an "automatic update checker" for pfSense. The script will check for major updates to the base pfSense system, as well as updates to any builtin or installed packages. If any updates are found, an email summary will be sent out with the details.
I wanted to put this out there now, get feedback, comments etc. My goal is to make this into an actual pfSense package to make it simpler to install, but I'm still learning how to create packages. This should still be useful as-is. (Any pointers anyone has on getting this cobbled together into a real package would be greatly appreciated!)
To install:
- Save the script below as
pkg_check.php
in your/root
directory - Set it up to run on whatever schedule you like using the Cron package. A sample screenshot* of how to configure the script is below.
- Make sure you have valid SMTP (or Pushover) settings defined on your firewall so you can get the alerts!
- For a Pushover version, use this gist instead (n.b: if you just want to send alerts to all of your configured targets, see the note on line 89 and make that small change)
*if you want to copy/paste the Cron command, use:/usr/local/bin/php -q /root/pkg_check.php
pkg_check.php: (I also have a gist up at github if you find that easier to read/copy)
<?php require_once("pkg-utils.inc"); require_once("notices.inc"); require_once("util.inc"); $msg = null; $pmsg = null; $p = 0; log_error("Starting update check"); // pfSense base system check $system_version = get_system_pkg_version(false, false); if ($system_version === false) { printf("%s\n", 'Unable to check for updates'); log_error("Unable to check for updates, exiting"); exit; } if (!is_array($system_version) || !isset($system_version['version']) || !isset($system_version['installed_version'])) { printf("%s\n", 'Error in version information'); log_error("Error in version information, exiting"); exit; } switch ($system_version['pkg_version_compare']) { case '<': //printf("%s%s%s\n", "pfSense version ", $system_version['version'], " is available"); $msg = "An update to pfSense version " . $system_version['version'] . " is available\n\n"; break; case '=': //printf("%s%s%s\n", "pfSense version ", $system_version['version'], " (installed) is current"); break; case '>': printf("%s%s%s\n", "pfSense version ", $system_version['installed_version'], " is NEWER than the latest available version ", $system_version['version']); $msg = "pfSense version " . $system_version['version'] . " is available (downgrade)\n\n"; break; default: printf("%s\n", 'Error comparing installed with latest version available'); log_error("Error comparing installed with latest version available"); break; } // package check $package_list = get_pkg_info('all', true, true); $installed_packages = array_filter($package_list, function($v) { return (isset($v['installed']) && isset($v['name'])); }); if (empty($installed_packages)) { printf("%s\n", 'No packages installed'); log_error("No packages installed, exiting"); exit; } foreach ($installed_packages as $pkg) { if (isset($pkg['installed_version']) && isset($pkg['version'])) { //printf("%s%s%s\n", $pkg['shortname'], ': ', $pkg['installed_version']); $version_compare = pkg_version_compare($pkg['installed_version'], $pkg['version']); if ($version_compare != '=') { $p++; $pmsg .= "\n".$pkg['shortname'].': '.$pkg['installed_version'].' ==> '.$pkg['version']; if ($version_compare == '>') { $pmsg .= ' (downgrade)'; } printf("%s%s%s%s%s\n", $pkg['shortname'], ': ', $pkg['installed_version'], ' ==> ', $pkg['version']); } } } if ($p > 0) { $msg = $msg . "The following updates are available and can be installed using System > Package Manager:\n" . $pmsg; } // check for updates to builtin packages exec("/usr/sbin/pkg upgrade -n | /usr/bin/sed -ne '/UPGRADED/,/^$/p'", $output, $retval); if (($retval == 0) && (count($output))) { $msg .= "\n\n" . "Some packages are part of the base system and will not show up in Package Manager. If any such updates are listed below, run `pkg upgrade` from the shell to install them:\n\n"; array_shift($output); $msg .= implode("\n", array_map('ltrim', $output)); } if (!empty($msg)) { log_error("Updates were found - sending email"); notify_via_smtp($msg); // to send alerts to ALL configured targets // (email, Pushover, Slack etc) use the line below instead: // notify_all_remote($msg); } log_error("Update check complete"); ?>
- Save the script below as
-
Needs more blinkenlight action!
Steve
-
Pkg update notification has been at the top of my wish list for a while. I’ll difinately give this a try.
-
This works great btw. Only problem I had getting it setup was a typo due to the fact that I missed a space in your cron screenshot.
-
Glad to hear you got it working! I added a little text block below the screenshot to make it copy/pasteable.
-
Nice job, like the way you set out the easy copy & paste also
-
@luckman212 Thanks for this it works great!
I notice the email notification mentioned updating packages that are not in the package manager via pkg update. There were a few packages not in the package manager which had new versions. I did the update and all went well. However, I was reading that the pkg update (FreeBSD method?) is not a supported pfSense update method.
https://forum.netgate.com/topic/118626/pkg-update-upgrade-vs-console-webgui-updates
In there it mentions the only methods supported are the GUI update and option 13 from console/SSH. This particular thread did not mention the GUI method for updating packages but that must be supported as well.
My guess is as long as updates to the actual pfSense version and installed packages are done via the GUI and/or option 13, then updating the remaining packages via pkg update should not be an issue?Thanks,
Raffi -
@raffi_ said in Auto update check, checks for updates to base system + packages and sends email alerts:
I notice the email notification mentioned updating packages that are not in the package manager via pkg update.
Probably those: https://forum.netgate.com/topic/140637/update-pfsense-packages-to-protect-against-nginx-libzmq4-and-curl-vulnerabilities you better update them.
-
@Grimson Thanks for the link. Yes, those were the exact updates which came up. I went ahead and updated them when I got the email notification thanks to the script. I'm on 2.4.4-p2. Wow they were major security updates I wouldn't have known about with this script. You learn something new everyday.
Thanks for the help and education guys.
Raffi -
@raffi_ The post you linked to was pretty old. Updating via console should be safe as long as you have not messed with the repos. It's basically the same process that occurs when you update via the GUI, as
pkg
is always used anyway. -
@luckman212 Awesome, thanks for the explanation. You're being too modest :)
I learned your script is not the same as the GUI update, it's actually better! The GUI didn't tell me about those vulnerabilities in the packages which required updating, but your script did.Raffi
-
This post is deleted! -
Nice plugin - has anybody made an Nagios or CheckMK plugin out of it?
-
Will this script work with the built in pushover notifications enabled or do I need to still use SMTP?
-
@raidflex Not the original one, but here's a quick modified version that should work, I haven't tested it so please give it a try.
-
@luckman212 said in Auto update check, checks for updates to base system + packages and sends email alerts:
@raidflex Not the original one, but here's a quick modified version that should work, I haven't tested it so please give it a try.
Looks to be working properly, thank you for the updated script!
-
-
-
I love this script but I modified it ever so slightly to notify all configured methods setup in pfSense. If you find the line "notify_via_smtp($msg);" and replace it with "notify_all_remote($msg);" it will send out notifications to ALL configured methods. I've tested this and it works well.
Thanks for all the hardwork!
-
-
-
-
-
-
-
Will this get wiped out from /root/ when a system update is installed?
-
Fast answer :
Yes.
No.
Maybe.Fill in the condition that will apply in the future' and then one of the 3 answers will be valid.
I'll explain : when you upgrade to "MFS" (Marvelous File System, the next file system version that will be sued after the current ZFS) then the drive partitions will get reset : that's a total content loss.
And when you drive dies : that's a Yes.An usual (up until now) GUI or console upgrade/update : That's a No.
(IMHO : I will never presume this No for granted)Maybe : Netgate can decide that /root/ will be cleaned out in the future. Call them for more precise answers.
But the question was wrong ^^ Nothing lasts forever.
So, all that counts is : how to get back to a known working situation in case of emergency ?Easy.
Install the pfSense Notes package.
It's identical to the Notes app in your phone.Copy paste in there the source of the script.
Copy also the setting for the cron package (and thus the reminder that cron package needs to be installed also).
A link to this forum post so you can find the online "manual" right away, if needed.Btw : keep on using Notes for any setting changes that you might want to remember after xx days/months/years.
Now your set up for pretty any situation
Or use the Filer package. never used that one myself, but you can make backups with that package.
-
-
@DominikHoffmann said in Auto update check, checks for updates to base system + packages and sends email alerts:
Will this get wiped out from /root/ when a system update is installed?
This has been working for me since day one when I first posted in this thread in 2019 and it is still working after all the system updates since then.
-
@Gertjan: Thanks! Using Notes like that is a great idea. I will implement that. I am already in the habit of saving a backed up configuration, which I rename to include the data an a few words describing the modification.
-
Yes I would expect it to be kept across almost all updates.
Yes the filer package allows you to keep that in the config so it would be restore after an upgrade even if it was removed. Unless the filer package itself is removed.
-
I personally use System Patches to store files in. It's easy to manage, and I'm pretty sure it's not going away.
FWIW, to my mind, the filer package is a bit sketchy. It wants to delete newlines from the end of files that it creates. Even if the lack of a newline isn't a problem for the particular type of file (loader.conf.local or ntp-boot-time-servers), it still drives me nuts because the checksums don't match. And the "Leave blank to load an existing file from file system" functionality has been broken for years.
-
I always learn something new on here. I didn't realize there were so many ways to skin the same cat in terms of file level backups. I have been using the backup package for backing up my script. I didn't see that one mentioned.
-
@Raffi_ It's a personal preference. The reason I prefer the System Patches or Filer package approach is that the information ends up being contained in the XML configuration file used for backup and restore.
I store the XML configuration file (sans RRD and lease data) in a revision control system. I have firewall configs going back to 2013. Just in case.
-
@dennypage said in Auto update check, checks for updates to base system + packages and sends email alerts:
I have firewall configs going back to 2013.
Nice.
-
Does not work for me (pfSense+ 23.05.1).
-
When I run
/usr/local/bin/php -q /root/pkg_check.php
from the ssh console, it returns "Unable to check for updates".
-
The system log has no entry for the cronjob created, wheras it shows entries for others.
Seems as if two things went wrong.
-
-
@pFence Now it works (pfSense+ 23.09).
-
During the run of this script my ntopng is restarting. I got this mail at the same time this script is running:
22:02:00 Service Watchdog detected service ntopng stopped. Restarting ntopng (ntopng Network Traffic Monitor)
-
Hmm, odd. Do you see that if you manually run it?
-
That just a coincidence.
See your system log for the reason.The script "/root/pkg_check.php" as shown above basically runs this command
"pkg update".
That command doesn't flap interfaces, doesn't kill "random process" , or things like that. -
@luckman212: I have been running you pkg_check.php for quite some time now. Most recently, it alerted me to an update of
curl
from 8.4.0 to 8.5.0.I have been relying on your script exclusively to alert me to updates being available. For some reason, however, it missed the release of pfSense 23.09.1. Any idea, why?
Looking into this further, I have these in System → Update:
and
I am wondering, whether it has something to do with which branch is selected. Currently it is “Previous Stable Version (23.09).” The other option is “Current Stable Version (23.09.1).” If so, this merits a separate post.
-
AFAIK, the script uses the same PHP lines that shows this :
I can't remember if I had received a mail from pfSense about "23.09.1" is available .... I' not sure, and already wiped notification mails from last month.
edit : that a negative : 23.09.1 was last week ( ! ) : that means no mail from this script about "23.09.1". That's new, indeed. Something changed in the packet handling ? Not that I wasn't aware, as I've also the RSS feed mailing me if a new Netgate pfSense blog post is posted :
... the forum and github are also good indicators ;)
For me it's the other way around : I can't select the "Previous Stable version 23.09" :
which is a don't care for me, as, if needed, I'll do the ZFS-magic-click and I'm back into "23.09" after reboot.
-
It's because the upgrade scheme has changed. Previously we pushed the updated repo pkg and it changed the default pkg repo to the new branch. That then allowed the update check to see the new version and show it on the dashboard. But it also meant that users who didn't see it or ignored it and then tried to install pkgs could end up with bad pkgs and a broken install. We added numerous things to prevent this but none were infallible.
In the the new upgrade scheme pfSense can check for release updates in all configured branches. That means we can show 23.09.1 as an available upgrade without switching the selected repo branch. When you click on the upgrade you have to select the new repo branch from the drop down to upgrade to it. You have to opt-in.But that also means that this script doesn't see that update since it only checks for available pkg upgrades in the current branch.
It would need to run
pfSense-upgrade -C
to see available upgrades for all branches which i9s what the dashboard check now does.Steve
-
I'm in the process of upgrading my systems to 23.09.1 and will update this script shortly (if it's possible) to handle the new update mechanism.
-
This post is deleted! -
@luckman212: Looking forward to the update! Would you include a reply in this thread, when you’re done with that?
-
@luckman212 said in Auto update check, checks for updates to base system + packages and sends email alerts:
to handle the new update mechanism.
It did tell me (mail) that the 'curl' package was available, a coupe of days ago. So, for me, it works
Also : if the pfSense GUI doesn't show others pfSense version, like : Current ..., Previous .... or Development ... then this script can't do more neither.
-
The dashboard uses the new
-C
switch for pfSense upgrade to check all configured branches for newer release versions. -
-