The infoblock mechanism now works slightly differently. Here is an example:
Notice the 'false' at the end of the print_info_box? That is a new argument that suppresses the 'X' close button that is normally present in a text box.
is exactly the same, except that the information block is initially open.
It is now possible to have more than one infoblock on a page. A numerical suffix is automatically added to the infoblock class for you, ensuring that the correct block is toggled.
FWIW, I have been using Samsung SSDs with TRIM enabled (mSata drives specifically) with Centos and Debian Linux for 3+ years on high-use production equipment with no problems. If I remember correctly, there was a specific firmware version that potentially corrupted Sammy drives when TRIM was enabled under Linux and specific kernels, I was never bitten by this, but know others who were.
If you are not writing and deleting a bunch of data on the drive over and over enabling TRIM is an arguable benefit, and in my specific use case for pfSense, it is only my OCD that makes me enable it, I use a ram disk and offload all the logging to a remote syslog server which keeps the amount of disk writes/rewrites to a minimum.
That's expected, Unity is most often undesirable and it being enabled by default caused problems more than it helped. There isn't a sure-fire way to determine post-upgrade whether people are relying on it. Now that you have it enabled, it'll stay that way.
I re-read my reply and it sort of sounds like a rant and that was not the intent. It's just that this is a somewhat frequent complaint/request that I have answered a number of times.
If you consider that the vast majority of actual malicious attacks from the Internet are going to be using the equivalent of "throw away" IP addresses, then maintaining say 100,000 or more previously blocked IP addresses won't be very productive. The attacker will abandon one and just switch to some other IP address to spoof. So that attack yesterday from one address is likely to come from a new and different one today. So why burden your firewall with storing thousands and thousands of old blocked IPs? Also, what if this month 100 of the ones you blocked last month are now in use by legitimate web sites/users that mysteriously can't reach your system because of the block from last month?
If Snort (or Suricata) was smart enough to catch the attack and block it today from IP address 22.214.171.124, then why would you think it can't detect and block the same attack tomorrow from IP address 126.96.36.199? Why should it keep a running list of previous blocks? And so long as you don't reboot the firewall (and if you have the Clear Blocked Hosts parameter set to Never), then the IP will stay in the snort2c table and remain blocked until a reboot. However, I don't recommend folks run Snort that way. You want the blocked hosts to clear out on a fairly frequent basis. I personally have mine set to one hour. What if the block was just a false positive? Would you want the false positive to stay blocked forever? Likely not. So I recommend choosing a reasonably short interval for the Clear Blocked Hosts parameter, but not Never.
here's something weird, .. so i started to look into this dns thing, and what i found out was it was because the dns server didnd't work that dpinger settled down, .. i recently changed the first dns server to 172.16.1.10 which apparently didn't respond to everything except the firewall, probably some gateway issue, however but since it didn't respond, cpu usage went down!?
When the interface comes up, it goes through the same process as a dynamic gateway, it doesn't matter that it's static. The fact it's logging those things just means it's checking whether anything needs to be done. Yes you can bind a dyndns update to a gif tunnel if you want, you must not, so it just checked and did nothing.
The dhcpv6 process started on its own after a power outage during the time I was on vacation and worked until there was maintenance done by the ISP last night causing PPPoE to go down again. I have now changed the two instance of pppoe and updated them to pppoe0. Then rebooted and everything came up fine, upgraded to the latest snapshot and it is working right now. I will leave it for the night to ensure it is stable and will try disconnecting the modem a couple of times to see if I can simulate what has been happening or confirm that the interface name change has fixed it.
Okay my installation work fine and my Interface config run..
But, i have a enconding problem or some think else.. (see attachment)
Where are you located (country)? It may well be that gettext() is not being called to translate some values. That page should be simply outputting 10% 20% 30% … 100% showing progress.
The whole GUI for manual rules updates in Snort and Suricata needs some work since the move to Bootstrap. The old system calls for a progress bar output no longer are available, and so I quickly cobbled something together to let the user see some progress. I am still searching for a better solution.
Well something went bad. My connection went down yesterday morning and hasn't returned. WAN status is "pending" but shows an IP from the modem. I can't remove or add any widgets. dpinger is down. The menus work on pages except for the dashboard. Problems consistent on any browser any platform. Also noticed the option to manually install updates was gone.
I don't know if this is related to the pfblocker widget or not, but last thing I did was edit the pfblocker files.
I've had to reinstate my old Asus router and mothball my pfsense router till this weekend when I can do a complete reinstall & hardware check. I hope this isn't a reoccurring pattern..
Remembered today when seeing it on a nanobsd system, that's the platform name there. It is redundant for full installs, but nano shows -nanobsd there instead. Probably some fluff to clean up in the future, it's OK for now.
The error in the original post mentioned cd1, that is likely what the USB modem presents itself as. If it shows cd1 in the console/system log, use cd1 in the command and not cd0.
Some of those, when issued an 'eject' command, will switch to modem mode.
i removed it in the meantime. :-X
camcontrol eject cd1
camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
cam_lookup_pass: No such file or directory
cam_lookup_pass: either the pass driver isn't in your kernel
cam_lookup_pass: or cd1 doesn't exist
cu -s 115200 -l cuaU0.0 Connected
Is there any way to stop the dashboard from doing a refresh every so many seconds? I periodically will scroll done to watch bandwidth graphs but it resets back to the top of the page after a few seconds.
A workaround would be to simply drag the titlebar for the bandwidth graphs higher on the page so that they're always visible.