Plug SG-1100 being updated into LAN switch for Internet access?
-
Here.
edit :
@NGUSER6947 said in Plug SG-1100 being updated into LAN switch for Internet access?:
pfBlockerNG
Even with minimal logging, if the resolver gets smacked with DNS requests, then pfBlockerNG will keep up the pace, and keep these log files /var/log/pfblockerng/ up to date = a lot of writes.
After all, they are needed so it can create :
To really reduce the number of write cycles :
- No pfSense packages that need a lot of write cycles. For example, pfblockerng by itself does nothing. But wait .. add a lot of DNSBL and throw a lot of DNS requests at it, and it will make 'big' logs.
- Go RAM disk mode.
Or : get a descent 'SSD' drive (if possible).
-
@Gertjan Yeah I just spent an hour reading through some of these threads.
Also I disabled IPv4 logging hoping that will help the other 1100 I'm running now live longer.
I think I'm going to do the USB drive mod for the failed 1100 to get it going again.
-
@Gertjan Yeah, I only have the default DNSBL(s) enabled (the ones the package installer for pfBlockerNG installs).
-
Yup using a USB drive to boot from is really the only option on the 1100 if the eMMC has failed.
-
@stephenw10
Samsung USB drive already ordered for the original 1100.Back to my spare (now-active) 1100, I've disabled IPv4 logging but I still need to disable logging on the rules that pfBlocker created.
Disabling any of that logging won't prevent it from functioning, is that correct? I like seeing the reports showing what was blocked along with what LAN IPs are being targeted but I can live without that visibility if it reduces load on the eMMC.
-
How much RAM do you have spare? By far the most significant thing you can do there to reduce write is enable RAM disks. But running pfBlocker in 1GB usually doesn't leave much. You might be able to do it if you have only a small set of lists.
-
@stephenw10 I only have 2 feeds enabled (Abuse Feodo Tracker and ADs_Basic).
Memory-wise, I'm seeing it run at around 30% used (of 957MB).
Looking at the RAM disk setup page, it appears it's not using much storage currently (if I'm reading it correctly, looking at 'Current usage' numbers) so the minimums should be fine?
-
You will probably need more than 60MB for /var. I usually set it to 120MB to start. If you try that I would monitor it for a few days to be sure it's not filing that when pfBlocker updates.
-
@stephenw10 What would be the indications that it was filling up during an update? I.e. how do I monitor it?
-
You can see it on the disks widget on the dashboard:
-
@stephenw10 Ok, well I enabled the RAM disks.
Interestingly, the Dashboard shows that only 60MB are being used for /var:
Update: I watched it during a pfBlocker update which just ran at Noon. It had been sitting at 17%, jumped up to a high of 73%, and seems to be staying there.
-
That's running 24.11?
There was an issue setting the RAM disk size at one point. But if it's only using 73% at update that's good.
-
@stephenw10 Yes, 24.11. I'll keep an eye on it but it seems to be stable at 73% (after going through 3 hourly updates).
FWIW, I tried modifying the RAM disk size again for /var and restarting the device but with it set for 120MB it only creates a 60MB disk. Is there some flaw in the GUI interface or something else that limits it?
Would it be beneficial to cut back on some of the log settings for pfBlocker?
Like cut some of them down to 10,000 entries instead of 20,000?
-
Yes you can certainly reduce those if the logs start getting too large.
That RAM disk issue is fixed in 25.03.
-
@stephenw10 So, after a few days /var is holding steady at 77% used. Would you recommend I hold tight until 25.03 is formally released (stable) so I can bump the RAM disk up to 120MB or should I update to the beta now?
-
The beta is pretty stable. I'm running it as my edge here without issue. If you are running ZFS so you can roll back then I would try it.
