Messages

If you had issues with the service start/stop during the package upgrade or at any other time, it would help if you run "cscli support dump" and send the output to support@crowdsec.net. It includes log files and part of the configuration (passwords removed ofc).

Done, thanks in advance!

I recently reinstalled a system with the 24.7 image, and it was still set to disabled in that release.
IIRC, the historical reason for having autotrim disabled by default was that it allowed system administrators to schedule it more effectively, avoiding potential random performance drops caused by automatic triggering.

Same here, crowdsec didn't fully shutdown when stopping the service, requiring a kill -9 (this had been going on for some time). It wouldn't startup after that as well, spewing some rather cryptic messages (this started after upgrade to 24.7.12).
After removing the appsec collection the weird behaviour was gone.

Done: https://github.com/opnsense/core/issues/8176

I believe I have found the cause, in this file:

Code Select Expand

/usr/local/opnsense/mvc/app/controllers/OPNsense/Nginx/forms/settings.xml
this section is incorrect:

Code Select Expand

<field>
    <id>nginx.http.enabled</id>
    <label>Enable sendfile</label>
    <type>checkbox</type>
    <help>Enable sendfile support (faster).</help>
  </field>
it should read:

Code Select Expand

<field>
    <id>nginx.http.sendfile</id>
    <label>Enable sendfile</label>
    <type>checkbox</type>
    <help>Enable sendfile support (faster).</help>
  </field>
This naming mismatch causes the checkbox to be ineffective.
Would reporting it here be sufficient, or is official bug report in order?

I have been playing around with nginx as a reverse proxy, and noticed something peculiar: every time I enable sendfile support in the main config page, it gets disabled automatically after some time. Is this expected behavior?
I have it enabled in the individual HTTP server entries as well.

I chastised my browser, but this made no difference. This gave me an idea, because I access my OPNsense install through a Caddy reverse proxy. So I tried to access directly, bypassing the proxy, and now it works. So Caddy is the culprit here. Thanks for the suggestion!

Code Select Expand

root@77-164-16-61:~ # pkg update -f
Updating OPNsense repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.pkg: 100%  245 KiB 250.8kB/s    00:01
Processing entries: 100%
OPNsense repository update completed. 861 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.pkg: 100%   22 KiB  22.5kB/s    00:01
Processing entries: 100%
SunnyValley repository update completed. 66 packages processed.
All repositories are up to date.

The tabs Changelogs, Plugins, Packages all remain empty.

Further info: this is a fresh install because of hardware changes. I installed 24.7 from USB and restored config.xml during install, upgraded to 24.7.10, reinstalled missing plugins, and after reconfiguring things because of changes in network adapter naming everything worked. It is after the upgrade to 24.7.11 that things started to go wrong.

I noticed that starting with 24.7.11, the plugins and packages tabs are not populating anymore. Another thing I noticed, is the 'status' tab wheelie thing keeps spinning.
Are other people seeing this?

That's the default package message (not from OPNsense but the package itself), you can safely ignore it and configure using the GUI.

For now, either close the ssh connection after initiating a restart, or use "configctl caddy stop" since it has a mechanism that will kill caddy after 20 seconds.

Many thanks!

I have caddy configured as a reverse proxy for the OPNsense GUI and as a SSH multiplexer, more or less according to the docs found here: https://github.com/opnsense/docs/blob/11e66816989bb12633e01e144ebf42b11508755a/source/manual/how-tos/caddy.rst

Unfortunately, I am having an issue where it prevents system reboots, both from the GUI and from the CLI menu (option 6). The rebooting hangs on shutting down caddy, which apparently never happens. The only thing that currently works is issue a 'shutdown -r now' from the CLI. The log files aren't giving me much direction how to go about investigating this. Any tips or advice?

Maybe it's better to submit a call with their support department so they can investigate more thoroughly because they have access to your log files and such. I submitted a similar issue and I'm currently running the 1.18 beta which has fixes for this, as well as for the same devices being recognized multiple times with different IP addresses due to DHCP (both private range and 169.254.x.x).

Seems to work fine here, hardware is I211/igb https://bsd-hardware.info/?probe=85f998d2ab

I recently came across the website https://www.unibet.nl/ which is apparently one the larger gambling websites in my country. Unfortunately this wasn't recognized by Zenarmor.
Every once in while I come across an URL which isn't categorized or is categorized wrongly.
This leads me to the more general question: what is the preferred way of submitting these cases for (re)classification?