Okay! So after a lot of trouble I decided to go manual for a while longer, but I couldn’t stop myself from trying to figure this out and having this semi-ready in case I want to script automatic monthly updates in the future. So here is some kind of a resolution in case people want that (monthly or “your own schedule” updates), maybe they can learn from some of my pain (at their own risk, of course - preferably you’re running on a VM, in the cloud, etc. and can shut things down and make a clean snapshot backup before messing with any of this).
So, I couldn’t find a good way to script certain fwconsole commands (mainly fwconsole reload and fwconsole restart) except for running them as root with a runuser command, and putting them inside of their own bash script, and then calling that script from the root user cron.
I’ve noticed that reloads (and sometimes restarts, or sometimes even full server reboots) are needed after certain module and system updates, respectively. Restarting things like that can also help in the event of an automatic Let’s Encrypt security certificate update, to have things settle and make sure the correct certificate is loaded and being used (it sends notifications about every quarter when it updates saying to restart things), but if you’re running monthly updates and rebooting the server along with it, then the problem should theoretically be solved there as well…provided nothing else breaks along the way here.
Without getting a ton into it, there were permissions or path issues every other way when trying to run all of the fwconsole commands needed from a single place - when run directly from the asterisk crontab fwconsole reload or fwconsole restart will have problems (which is fine since FreePBX manages that - I’d rather not be messing with the asterisk crontab anyway) or when run directly from the root crontab there are some other issues, maybe because the crontab (I think) uses /usr/bin/sh instead of /usr/bin/bash. Anyway, if you put this in your own separate script, say, /opt/mystuff/myscript.sh and make it executable with a chmod +x /opt/mystuff/myscript.sh then you can call this script from the root user crontab (which is empty by default, and a reasonable place to put your own cron jobs since the asterisk one is heavily managed by the system) - or like it was earlier stated cron.monthly, or systemd.timer may be a better route.
I’m still not entirely sure about wrapping these in runuser commands since I think fwconsole uses runuser some itself, but things appeared to work and exit with a successful exit code. Read on though because I did have some major problems at one point during testing, and was glad I had a snapshot backup on hand.
So, your script could look something like this:
[ -e /usr/sbin/fwconsole ] \
&& /usr/sbin/runuser -l root -c ‘/usr/sbin/fwconsole ma listonline --sendemail -q’ > /dev/null 2>&1 && sleep 90 \
&& /usr/sbin/runuser -l root -c ‘/usr/sbin/fwconsole ma upgradeall --sendemail -q’ > /dev/null 2>&1 && sleep 90 \
&& /usr/sbin/runuser -l root -c ‘/usr/sbin/fwconsole reload -q -n’ > /dev/null 2>&1 && sleep 90 \
&& /usr/bin/yum update -y > /dev/null 2>&1 && sleep 90 \
&& /usr/sbin/shutdown -r now > /dev/null 2>&1
of course instead of the yum update line you could use (if your system allows it, I think it either has to be activated or have sysadmin pro module or both - I can’t remember)
&& /usr/sbin/runuser -l root -c ‘/usr/sbin/fwconsole sys upgradeall --sendemail -q’ > /dev/null 2>&1 && sleep 90 \
but I just hated to wrap the system updater inside of another runuser command (but still the only way it would work - I tested by turning off all of the -q tags and > /dev/null 2>&1 and receiving the output via a crontab MAILTO= line), which you may or may not want to figure out a way to get output, such as scripting in an email to yourself with status on either success or failure.
I noticed that it is often recommended to do module updates before system updates, and even when enabled in the GUI FreePBX puts system ahead of module updates in the asterisk crontab, so the order is module then system here, and also I noticed that by not doing either an fwconsole restart or rebooting the server after updates sometimes there can be some minor firewall issues (at least there was for me) so I have a full restart in here at the end.
Be sure and back up with a snapshot before you try any of this. At some point in my testing things seemed to fry and no amount of restarts would hold a phone call. It seems like testing these commands should never have caused that, but maybe it had something to do with path and permissions issues not being correct when running these from different accounts and etc. as a test before I figured out I had to use my own bash script and runuser as root. I was glad to have a snapshot to quickly fall back on and I wouldn’t recommend for a second testing this without having some sort of snapshot backup system in place to grab a “known good” snapshot a few days before this runs, that way if something breaks you can roll back.
And then of course I almost forgot, to call such a script from the root user’s crontab (crontab -e -u root will let you edit it, just be ready to use vi)
0 0 1 * * [ -e /opt/mystuff/myscript.sh ] && /opt/mystuff/myscript.sh
(Of course that’s midnight on the first of every month - probably best to find another time that is more random than that)
Again, please note that I did come up with MAJOR problems during testing, which I think (but can’t verify) was due to many reloads and restarts with all of the permissions issues and things not being able to finish - this script appears to execute cleanly and properly in my testing so far. However, appearances and reality may be two different things, so if you are interested have a snapshot backup ready to go and use it or parts of it knowing the risks.