Missing custom.rules.rules on startup



  • I am getting this error on a reboot of pfSense:
    FATAL ERROR: /usr/local/etc/snort/snort_29882_xl0//usr/local/etc/snort/snort_29882_xl0/rules/custom.rules.rules(0) Unable to open rules file "/usr/local/etc/snort/snort_29882_xl0//usr/local/etc/snort/snort_29882_xl0/rules/custom.rules.rules": No such file or directory.

    The snort process for that interface does not start. A stop and start of the snort service no error and all the interfaces come up. There are no custom rules defined or set for any of the interfaces. I tried a reinstall of the package and cleaning up the log files. This appeared after upgrading to 2.3-RELEASE.



  • @nfr:

    I am getting this error on a reboot of pfSense:
    FATAL ERROR: /usr/local/etc/snort/snort_29882_xl0//usr/local/etc/snort/snort_29882_xl0/rules/custom.rules.rules(0) Unable to open rules file "/usr/local/etc/snort/snort_29882_xl0//usr/local/etc/snort/snort_29882_xl0/rules/custom.rules.rules": No such file or directory.

    The snort process for that interface does not start. A stop and start of the snort service no error and all the interfaces come up. There are no custom rules defined or set for any of the interfaces. I tried a reinstall of the package and cleaning up the log files. This appeared after upgrading to 2.3-RELEASE.

    Hmm…that extra "rules" on the end of the file custom.rules should not be there.  It reads custom.rules.rules and should instead read as just custom.rules.  I have not seen that one before.  I'm about to fire up a test virtual machine and see if I can reproduce.  Was this from a fully functional Snort install prior to the upgrade.

    Bill



  • Yes, it was working fine until the upgrade. I looked up the version of snort from the config backup and it was at 3.2.9.1 before the upgrade. It now shows 3.2.9.1_10 which is different. The error shows up on the second interface in the list. The third loads fine.



  • @nfr:

    Yes, it was working fine until the upgrade. I looked up the version of snort from the config backup and it was at 3.2.9.1 before the upgrade. It now shows 3.2.9.1_10 which is different. The error shows up on the second interface in the list. The third loads fine.

    Is the interface with the error the only one using custom rules?

    Bill



  • There are no custom rules. On all three interfaces.



  • Also just noticed that the entire path in the error message is strange.  It's like it is doubled up or something (notice the repeating section of the path).  I will send you a PM with my e-mail address and ask that you send me a couple of files off your system.

    Thanks,
    Bill



  • This is now fixed since 3.2.9.1_11. I also had some old information in the configuration from years ago when when using squid proxy. I removed a bunch of lines that were related to that and did a restore configuration from file. When the system rebooted everything came up correctly as well as upgrading to 3.2.9.1_11 from 3.2.9.1_10.

    On a unrelated item I noticed that the <blockoffendersip>both</blockoffendersip> setting got cleared when comparing configuration files. I was able to change this back in the web interface and it created a <blockoffendersip>2</blockoffendersip> .



  • @nfr:

    This is now fixed since 3.2.9.1_11. I also had some old information in the configuration from years ago when when using squid proxy. I removed a bunch of lines that were related to that and did a restore configuration from file. When the system rebooted everything came up correctly as well as upgrading to 3.2.9.1_11 from 3.2.9.1_10.

    On a unrelated item I noticed that the <blockoffendersip>both</blockoffendersip> setting got cleared when comparing configuration files. I was able to change this back in the web interface and it created a <blockoffendersip>2</blockoffendersip> .

    Whoa.  The <blockoffiendersip>setting is not correct.  It should be "both".  Looks like another Bootstrap conversion boo-boo due to how combo select boxes are coded in Bootstrap.  That might explain what some other folks are seeing.  I will investigate the code to be sure.  In the meantime, that value in your config.xml really should be the string "both".

    UPDATE:  I found the source of that incorrect setting. The fix will be out soon.

    Thanks for reporting this to me.

    Bill</blockoffiendersip>


Log in to reply