Messages

In the UI settings.  Read the docs as suggested above.

ZFS on opnsense already defaults to 90 sec async flush interval to help wear, I agree with the others, use a ram disk when using SSD storage.

Hi, will chime in here.

One thing I always considered a strength of opnsense was its dashboard, and will admit was surprised to read in the changelog when it changed, the "modern" phrase as I already considered it modern.

I updated and now have had a moment to generate some thoughts on it, I will try to be as respectable as possible as I respect the work that will have gone in to it.

I think that you can drag stuff around, resize and such is nice.  I cant remember if you could do all of that on the old dash, but that is nice.

I also like seeing interrupt usage on the cpu graph.

But some of the widgets have regressed on the information they provide.  I will give some examples.

Old dash widgets, you had all memory usage view on the screen, could quickly eye ball it, now have to move mouse over a half pie chart, and get some very limited information. 
Same issue with interface stats, although I think all the info is still there when mouse is in right place, I still have to move the mouse to see it.
The firewall widget, I am not sure is working, previously I would see live log entries flow in the widget box, now if I hover over it is just a number 1, and if I click it, then takes me to firewall log.
Disk usage widget used to show partition info, now its a generic used and free.

I think the main dash is ok, just I think the widgets need to be able to do what the old widgets did, no lost functionality.

Did ISC reveal the reason they abandoning software that works in favour of something thats incomplete and buggy?

I am guessing they have a new generational of developers who dont want to work on the old code so its the typical solution of rewriting.

Please dont remove ISC DHCP from future builds of opnsense.

I am just giving you an answer which might explain why it sits there for a long time on the installer boot.  I could I guess revert the assignments on the host and see if it speeds things up.

Well your case is a local install, if OPNsense is remote you need to at the very least have some kind of initial WAN access.  Even if its to setup a VPN.

Strange. What sort of WAN are we talking about here?


Cheers,
Franco

In my case its not even WAN as the auto assignment wrongly assigns the port.

OPNsense running in VM, two nic's one for WAN and one for LAN, it assigns the LAN port as WAN, and vice versa and I have to wait quite a while on the live system boot, interestingly the first boot post install is much quicker.

Output when vmstat -m ran manually.

# /usr/local/bin/vnstat -m

vtnet0  /  monthly

        month        rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       Mar '24      1.23 MiB |    8.28 MiB |    9.50 MiB |   32.96 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated    726.49 MiB |    4.79 GiB |    5.50 GiB |

Code Select Expand

[bf40d3d6-8e4f-4c8e-9815-621df3882190] Script action failed with Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1.

The stats are accumulating.

Thanks, that does work.

So what happened with this? is a bit bizarre each icmp type needs its own rule.

I think OPNsense could do with an option on the console for punching an initial hole through to the UI for a specific WAN IP, I think a rule that specifically whitelists an IP is fine.  The default LAN only assumes one is running the firewall local to them so they can just access over a LAN, but this falls apart on remote installations, and adding a firewall rule in the console, when the whole software is designed to be managed from the UI is clearly not a clean way of doing it, hopefully a solution can be found.

As it stands now it is pfctl -d disable the entire firewall, then going into the UI to add some kind of management IP ACL rule for access the UI and finally turning the firewall back on with apply.

Is there a way to just boot into the installer without it attempting a live boot?

It pauses on WAN for about 15 minutes, and then stops on starting ntp service.  These problems are likely that because I am booting in a test environment where is no working WAN connection.

I have tried giving it 2 hours, and its still sitting on starting ntp service.

I think the ISP maybe has to support it, also if you using a modem as a bridge, that also needs to support baby jumbo frames.  So basically all intermediate devices.

Dont worry about ECC, I have a lot of experience with ZFS, was an early adopter with it on FreeBSD, and I dont commonly use ECC based hardware.

Yes a lack of ECC adds an extra risk factor in terms of data corruption, but this isnt exclusive to ZFS, it can happen on any filesystem, if anything ZFS is more likely to detect it.

Also memory reliability now days isnt what it was like decades ago, keep temperatures reasonable, dont overclock and you will be fine.

Also I dont mind contributing to a snapshots feature, but my request would be if I contribute its in the normal build of opnsense.  If not I can post some how to's on how to do it via CLI.

Scrub of death rumour seems sourced from freenas/truenas users who commonly run extremely wide risky raidz arrays.