Auto update check, checks for updates to base system + packages and sends email alerts
-
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.
-
G Gertjan referenced this topic on
-
@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.phpfrom 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
curlfrom 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 -Cto 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.
