Messages

The system rebooted after 23.1.11 was installed.  I rebooted once more for good measure.


I retried this after the reboot and I see this line in the backend logs from configd.py:


   [4690383d-0125-4ef7-926f-6a45db14121e] returned exit status 1

This isn't meaningful to me but maybe to someone else.  I can see the record in the /conf/config.xml file, but it is in the wrong domain in the /conf/config.xml file.  In other words, when modifying this via the GUI, the record is added to the last domain in the list instead of the selected domain in the GUI.


Brian

Only thing I could find.  Happened around the time I was working too, but not sure if it is directly related.  I tried the operation a few times, but this appears only once in the log.


Script action failed with Command '/usr/local/opnsense/scripts/firmware/read.sh ' died with <Signals.SIGBUS: 10>. 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/opnsense/scripts/firmware/read.sh ' died with <Signals.SIGBUS: 10>


--Brian

Hello,


Starting with 23.1.10_1 and continuing with 23.1.11, I am unable to add entries into BIND.  I can see the entries are written into the config.xml (multiple entries for the same A record are allowed as well), but they do not make into the .db files under either master/ or primary/.  The entries also do not appear on the GUI.


It appears that the entries are being written into the .db file for the last zone in the list instead of the selected zone.


Brian

Makes sense.  Not sure how much of the user base uses Bind, but I find it the best way to create and manage my own domain(s).

Good lord, I don't really understand why bind/isc devs are trying to break their configuration so hard on upgrades:

https://github.com/opnsense/plugins/commit/7205ea00948f

# opnsense-patch -c plugins 7205ea00948f

(and reapply your configuration)


Cheers,
Franco

Looks like that fixed it thanks.

Hello,


The Bind service (NAMED) will not start after upgrading to 23.1.  Attempting to start the service from the GUI, the screen comes back almost immediately and the service does not start.  There are no logs.


I tried this from the command line (service named start) and I see the following error:

/usr/local/etc/namedb/named.conf:92: /usr/local/lib/named/filter-aaaa.so: plugin check failed: failure
/usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed


On that line of the file, I see the following:


plugin query "/usr/local/lib/named/filter-aaaa.so" {
                   filter-aaaa-on-v4 yes;
           };

I can remove those three lines and the service starts.

Clicking on Services > Bind > Configuration > Disable IPV6 brings back the problem of the service not starting, but removing (unchecking) it does not fix the problem.

Anyone seen anything similar?

This has been fixed.  See https://forum.opnsense.org/index.php?topic=28695.0 for information on how to configure USB quirks to make this work.

I see what may be a related error introduce around 22.1.7 or 22.1.8(_1)


Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
libusb1: Could not open any HID devices: no USB buses found
No matching HID UPS found
Driver failed to start (exit status=1)

Guessing maybe there was a change in the usb library that could be causing the issue, but not sure how to confirm.

Hi All,

Starting with the 22.8 update, I started getting this error when OPNSense tries to start nut_daemon:

Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
libusb1: Could not open any HID devices: no USB buses found
No matching HID UPS found
Driver failed to start (exit status=1)
/usr/local/etc/rc.d/nut: WARNING: failed precmd routine for nut

My configuration specifies to use the USBHID driver with port=auto for configuration.  I don't see any other errors.  USB keyboard works fine, so I know the USB system is working.  Anyone seeing the same?

Brian

Have you tried the USBHID driver with "port=auto" in the extra arguments field?  I'm running a Tripp Lite UPS and this works for me.

Thank you so much for looking into this and fixing it.  Look forward to the next #patchday.

How is the information loaded for these?  I haven't been able to track that down yet.

Hello,


Looks like after the upgrade to 22.1 that the DNSBL feature of Bind isn't working.  I looked in /usr/local/etc/namedb and I don't see anything in dnsbl.inc to indicate anything from the selected types of DNSBL (if this is where it would even be).


I looked in the logs and all appears normal -- no mention of anything related to this, and I can't find anything to indicate that the lists are being updated.


Any ideas where to go next?


Brian

See if you can access the web interface via IP address only and see if that makes it go faster.  What I've found is that DNS replies with two IP addresses and sometimes the VLAN IP address comes first.  If the web interface isn't bound to the IP address on your VLAN then it will definitely be slow to respond since it will try that IP address first and then fall to the LAN IP address.

This afternoon I can't get syslog-ng to come back online to forward to splunk. I've tried disabling syslog, upgrading to the latest version. Any other ideas? All I am seeing is core dumps.

I'm seeing the same thing.  I can't seem to start the syslog-ng service.  This is what I see in the logs when I try to start the service:
kernel: pid 78934 (syslog-ng), jid 0, uid 0: exited on signal 11 (core dumped)


I have a core file for this attempt to start syslog-ng.  Let me know if there is someplace I should upload it.