23.05.1 : cron not disabled
-
@Gertjan thats exactly what I was thinking - but was too lazy to check into the code ;)
-
@johnpoz I am also trying to disable automatic updates for pfBlocker. I want to do this because if it automatically updates and an update has a defect in it, it's difficult to troubleshoot why something suddenly stopped working. It's much easier to troubleshoot if something breaks immediately after I manually execute a change.
This happened once already when somehow 9.9.9.9 dns service got put into a blocklist. That was a very disruptive defect after an automatic update. I don't want it happening again.
I have disabled cron like @focheur91300 did, and it runs hourly and does nothing, however, it also still runs daily at 1am as configured on the disabled cron setup page:
The logs show it automatically updates daily (one example from this morning shown):
UPDATE PROCESS START [ v3.2.0_7 ] [ 12/15/23 00:00:25 ] ===[ DNSBL Process ]================================================ Loading DNSBL Statistics... completed Loading DNSBL SafeSearch... disabled Loading DNSBL Whitelist... completed [ EasyList ] Downloading update .. 200 OK. Whitelist: adsafeprotected.com|amazon-adsystem.com| ---------------------------------------------------------------------- Orig. Unique # Dups # White # TOP1M Final ---------------------------------------------------------------------- 31576 31570 2 2 0 31566 ---------------------------------------------------------------------- [ EasyPrivacy ] Downloading update [ 12/15/23 00:00:36 ] .. 200 OK.Is this a bug in the cron configuration page I should report in redmine?
How do I effectively disable the cron update job?
Thanks for your help.
-
This is broken, and has been for some time.
It is somewhat related to this
https://redmine.pfsense.org/issues/7146What is happening is this,
If you mark the cron job as disabled on the GUI (the general settings page),
The sequence the code uses is briefly this:
-
remove the entry for this from the config
-
remove the crontab
-
reconfigure the crontab based on the config
if you look at the system log after marking it as disabled and saving you will notice that it says it is removed (step 2), but then that it is added (step 3) .
like this
if you cat /etc/crontab you will see the job is still there.
Next if you manually execute the function that is removing it from the crontab (step 2) - and you can actually go to diagnostics - command and run it in the php window.
install_cron_job('pfblockerng.php cron', false);Doing so will get you a log entry similar to this
and now if you cat /etc/crontab the job is actually gone and therefore won't run.
However, it is still in the config as the (step 2) here does not remove that. only step 1 could, So anything that runs the config sync will put the job back in crontab (see the redmine)
Of course there is code that should remove it from the config (step 1) when disabled and that appears to be the fail point.if you now go back to the general settings and save the the page again, you will log the save install without the corresponding remove
Step 1 is the fail point
Step 2 is the remove line from crontab which is the command above (works)
Step 3 runs as part of the save (and clearly works as intended, refreshing the crontab as it should based on the current config)Due to other commitments it is unlikely I will pursue this further at this time, as you can also simply disable all the actual feeds, and yes the cron job will still run, but it won't do anything.
But yes, that is the short description of the issue you are describing.
I'd be really curious to know which feed blocked 9.9.9.9 for you if you know.
-
-
@Mission-Ghost said in 23.05.1 : cron not disabled:
I want to do this because if it automatically updates and an update has a defect in it
What about :
Even better : really, using a list with 'defect' ? What about not using it at all ?
Or : whitelisting 9.9.9.9 ?
Or, IMHO, you want to use "EasyPrivacy" (the name says it all) as a DNSBL, but you also want to use 9.9.9.9. That's ..... strange.The cron jobs : Stopping them - and continuing to use pfBlockerng is a very bad idea.
One of the cron tasks also rotates the pfblockerng log files. Not rotating them, and they will fill up the drive space eventually. This will have bad consequences, most wind up re installing everything and "one more lesson learned". -
@Gertjan said in 23.05.1 : cron not disabled:
What about
yes, that screen shot exactly when
@jrey said in 23.05.1 : cron not disabled:
as you can also simply disable all the actual feeds and yes the cron job will still run, but it won't do anything.
but also yes, the code to disable the cron job itself is broken
specifically the many places that, like step 1 they call the
config_del_path function << the call to this is not removing the config - that I have confirmedStep 1 fails to adjust the config
therefore step 2 deletes the crontab entry as it should
and step 3 immediately puts it back.it is also based on the fact that on the general page the "interval" value is always 1 regardless of the selected item. The expectation later in the code here is that as far as the process is concern it is "always" enabled. Disabled is actually ignored at that level, but so are all the other selections for specific hour selections are always simply a 1.
the call to
install_cron_job('pfblockerng.php cron', false);does specifically remove the crontab entry (again confirmed)
but step 3 gets a oh "this is enabled" when rebuilding the cron and it is still in the config, and puts the crontab entry back.Later specific hour selections are handle when the cron runs, however in that regard "disabled" is handled exactly the same as 1 hour
switch($freq) { case 'Disabled': case 1: case '01hour':simple put, Disabled is not a 1 hour frequency,
So there are in fact two errors here in the code
first being the the config doesn't get updated to remove the cron job as it should
and second because of that cron does run, when it looks at Disabled is handled the same as 1 hour. which is why the OP sees the job running at the timestamp it is.the first error is likely and actually more serious, because it impacts other packages as well, (so if they are all failing to remove their config they think they are removing that's really bad)
the second item can likely be corrected by a break; located between
switch($freq) { case 'Disabled': break; case 1: case '01hour':But I don't have time to check either in detail and adding the break; looks like it will cause issues further down the code. So it needs work / testing.
Have fun.
-
@jrey thank you for the detailed response and analysis. This is very helpful at aiding my understanding.
I have now gone through all the feeds and disabled automatic updates there too. I haven't yet had a deep look, but it appears they're not automatically updating anymore.
In a later comment, someone noted that stopping the cron will prevent the logs from being pruned. Is this:
-
true?
-
since my cron job appears to still be running hourly, even though it's saying there are no updates to do, is it still pruning the logs?
Thanks again.
-
-
I actually have a fix (it is "testing" now) It allows you to mark the cron job as disabled, and still allows the log files to do their rotation without processing any of the lists.
Which I believe was the intent. It just doesn't work that way in the current system.
IMHO it would be far better if the Selection said "Log Rotation Only" or could still provide options for doing that on a different frequency, but that is a completely different issue.
It certainly doesn't need to go through all the steps it does.
Trying to change the config and remove the cron entry and add it back in. But that is for another day. -
@Gertjan said in 23.05.1 : cron not disabled:
Even better : really, using a list with 'defect' ? What about not using it at all ?
Or : whitelisting 9.9.9.9 ?
Or, IMHO, you want to use "EasyPrivacy" (the name says it all) as a DNSBL, but you also want to use 9.9.9.9. That's ..... strange.Thank you for your response.
The primary issue is no longer with the specific instance, but that this can and did happen and could happen again. To my dns service.
It was disruptive. It was easily bypassed once I saw what had happened, but it was then time consuming to troubleshoot. Ultimately I did whitelist it.
I contacted quad9 support, which was responsive and helpful. The helped rule out their service. I found that on June 16, 2023, CINS_army_v4 added 9.9.9.9 to it’s blacklist for no apparent reason. I believe they later backed this out but not before it caused problems.
This is not an obscure feed, so far as I can tell, but the issue isn't the specific feed.
It's that any feed, not matter how good a reputation, can blacklist a reputable key infrastructure site and break my network and with automatic updating there's no notice and no immediate, clear indication of what broke the network.
A feed would also be an interesting way to conduct a DDoS attack. Attack the feed and put blocking in for DNSs, Google, AWS or other widely used sites and then let the automatic update process use the infrastructure pull it in to many networks and you're off to the races, reminiscent of the Solar Winds attack.
If I manually apply the updates on my schedule, it is pretty easy to correlate an immediate failure with the update and makes backing out the update and troubleshooting the issue much easier than starting from scratch.
I try to do this with other updates already, as I've found the risk of a zero-day to me is a lot lower than the risk of an update breaking something.
In response to another post, I don't understand why it's logically inconsistent to use quad9 and pfBlocker. This is basic defense in depth: no one service is likely to completely duplicate another or afford complete protection, right? Plus, quad9 doesn't block advertising that I can tell.
I don't want to waste my resources with ads if I can easily help it.
Thanks again to everyone who contributed to this question. I may try to put the updates on the longest possible cycle and on a specific time and put it on my calendar so if it breaks something I can get some kind of reminder of what's going on. A longer cycle such as monthly rather than weekly would be helpful if there are no plans to fix this.
It might also be useful to pull the pfBlocker's general menu's "update disable" option until it's fixed. Right now having it there and not work is a distraction, at best.
-
@jrey said in 23.05.1 : cron not disabled:
I actually have a fix (it is "testing" now) It allows you to mark the cron job as disabled, and still allows the log files to do their rotation without processing any of the lists.
Which I believe was the intent. It just doesn't work that way in the current system.
IMHO it would be far betting if the Selection said "Log Rotation Only" or could still provide options for doing that on a different frequency, but that is a completely different issue.
It certainly doesn't need to go through all the stops it does.
Trying to change the config and remove the cron entry and add it back in. But that is for another day.This is good to hear. I'll be looking for the update in due course.
A prior response of mine notes in more detail why being able to do this can be a helpful thing. It really comes down to maintaining network configuration management and allow quality assurance processes to take place on routine changes before they're applied.
-
@jrey oh, one more thing: assuming the automatic updates are disabled, then if I run the update manually from the Update menu, will it prune the logs?
Thank you again for your reply. It's great to be able to correspond with developers.
-
In the current system if each of the lists are disabled there is no concern about pruning logs it will still happen
the change I am testing, based completely on the one setting that cron is set to disabled - there is no concern about pruning logs it will still happen.
The only change being made is that setting the cron job to disabled, will do exactly as the setting implies, which is not run the lists.CRON PROCESS START [ v3.2.0_7 ] [ 12/16/23 14:12:54 ] List processing disabled by cron setting 'Disabled' No Updates required. CRON PROCESS ENDED UPDATE PROCESS ENDED
