Messages

The GUI does not check what you select.  It will let you select options or tests that do not work.  You will only find out when it won't start up.  Again, you need to read the Monit Manual (and look at the examples), for guidance as to what will work.

I think the 'changed' switch is for checking the output status of shell scripts, not the status of the system.

This is what I have under 'check system':

Code Select Expand

check system $HOST
   if memory usage is greater than 75% then alert
   if cpu usage is greater than 75% then alert
   if loadavg (1min) is greater than 8 then alert
   if loadavg (5min) is greater than 6 then alert

I haven't changed it; this was what Opnsense installed.

Make sure you have the service tests CPUUsage, LoadAvg1, LoadAvg5 and LoadAvg15 set up under Service Test Settings - they are installed by default, so should be there.

O.K. Thanks for the replies.

The Jetway does not have a HDD Activity LED, so it's hard to know it's alive.  Next time, I will leave a console connected to see what is happening  :-[

Yes, after the web interface said the was system rebooting, the web interface did not change for a long, long time. I tried to ping the box, but it would not respond.  In the end I forced it off by holding the power button.  Took the box away for a closer inspection...

There was no console monitor on the box, so I had no idea what it was doing.  I had an SSH session open, but it closed when the web interface said rebooting.

Box is a Jetway NUC with 3160 processor.  Disk is a SSD SATA with ZFS.

Hmmm... I should have waited longer?

Well, this may not much use, but here goes.  This is the .upgrade.log file that I have after running opnsense-bootstrap.sh.  Looking at the creation time, it may have been created at the first upgrade attempt - I just can't remember when I started exactly.

The file cuts off prematurely.  I don't why; it's the file that I have.

Just adding:  My usual mirror (Australia) gave the bad sig message and stopped immediately, and I then tried the San Francisco mirror, guessing it was a server issue.  Same thing.  I then tried again, and it didn't give an error; the upgrade continued, but the upgrade failed.

On upgrade, I saw Opnsense 20.7 being 'installed', and the installer said something along with  'Nothing to do!'. The installer moved onto FreeBSD 12 (which did install), then proceeded to reboot. 

Let me know if you need any more information.

Yes, been through this too.  There is also another topic here https://forum.opnsense.org/index.php?topic=18361.0 which sounds like the same issue.

In my case the upgrade continued and FreeBSD 12 was successfully installed, but Opnsense 20.7 failed to install (bad sig) (Opnsense 20.1 remained).  This, of course, left quite a mess.

I did fix it by using the opnsense-bootstrap.sh script on Github, though I had to change FreeBSD 11 --> 12 and 20.1 --> 20.7 in the script.  I also had to play with the routing to get the files to download through the LAN, since WAN was borked.  Then I uploaded a backup to get it all working again.

It probably would have been easier to just re-install.

O.K., so now Line 14 is working.

But there is now an error on Line 17,  Monit doesn't like the 'change' syntax.  Should there be another term here - what status changed? 

I've learnt that Monit is very picky about syntax and constructs and I have found this a struggle.  I think you need to study the Monit Manual.

Looking at the Monit Manual, the syntax on line 14 is wrong.

https://mmonit.com/monit/documentation/monit.html#ALERT-MESSAGES

The 'not on' should be followed by an 'event', and it is not.

On the web GUI, I think you need to uncheck 'not on', or choose an event (or events) from the drop down box.  I am not sure that the help text of 'leave empty for all events' is correct. 

It's worth reading this forum post https://forum.opnsense.org/index.php?topic=12267.0, particularly posts 14 and 15.

I installed to ZFS  a few weeks ago, and the same note on the documentation gave me some concerns, but all went smoothly.

You do have to use the same FreeBSD version as Opnsense (that's 11.2 for for 20.1).  Newer versions of FreeBSD work until you reboot, giving a mount error.  I think this is because the ZFS package in Opnsense is older than the installed filesystem in later versions of FreeBSD and therefore incompatible.

Poking around the directory structure, Opnsense seems to have all the support for installed ZFS, and it's working nicely.  Thanks to the developers!

Yes, I think I have the same problem.

I upgraded from 20.1.7 to 20.1.8-1 today. The package manager only seemed apply the hotfix, and not all the packages in 20.1.8.

The package manager says I have 20.1.8-1, but it's also aborting with internal errors quite a lot of the time.  Haven't tried audit health.     

My ISP only provides IPv4 connectivity, no IPv6.  It's annoying, but apart from that they are a good ISP.

After a upgrade to 18.7, I had the same problem.  I found that the DNS was returning an IPv6 address and an IPv4 address.  I think that Opnsense 18.7 was favouring the IPv6 address - which clearly wouldn't work.

DNSMasq or Unbound are the same result.

After much searching, I found the following fixed the issue for firmware updates:

System --> Settings  --> General --> Prefer IPv4 over IPv6 --> (tick)

I also have found that apt-get on Debian/Ubuntu is trying to use IPv6 lookups (Had to force IPv4 in apt configuration).  Same for fetchmail, which was fixed by giving IP addresses instead of hosts in the .fetchmailrc file.  This only seems to be since 18.7.  The above setting in Opnsense has no affect.

I thought I could probably limit lookups in DNSMasq or Unbound to IPv4, but Google does not think so.

To fix dnsmasq after the upgrade for 18.1 to 18.7:
Services --> Dnsmasq DNS --> Settings.  Change 'Interfaces' from 'ALL' to 'LAN'

With 'ALL' you will see a message in the log about not able to listen on 127.0.0.1, and DNS won't work.  Local hosts won't resolve either because of the lack of DNS.  Yes, it took me a long while to find.  I suspect this could be a bug?

Unbound also worked for me.  I think it uses root DNS servers though, and I prefer to use my ISP DNS servers, because they point to local caches for Netflix etc.