Strange log entry after update

bmeeks

@fireodo said in Strange log entry after update:

As I investigated I found this error "Failed to extract a rules-update archive." began early at begin of the month of march 2022 (the last update without error was 25.02.2022 and the first with error was 02.03.2022)
My update to pfsense 2.6.0 was on 14.02.2022.

That's probably when they changed the directory name in the rules tarball from FreeBSD 12 to FreeBSD 13. It's named "FreeBSD-13" now. I'm testing some solutions.

fireodo

@bmeeks said in Strange log entry after update:

It's named "FreeBSD-13" now

Hope the rules are not compiled only for FreeBSD 13 ...

I'm testing some solutions.

Oh, many thanks!

bmeeks

I've created a Redmine Issue to track this: https://redmine.pfsense.org/issues/12979. I assigned it to myself. I'm working on the fix and will submit a Pull Request for the pfSense to review and merge in the very near future. Thank you for the report.

fireodo

@bmeeks said in Strange log entry after update:

Thank you for the report.

You're welcome - and thank you for your work!

Kind regards,
fireodo

bmeeks

I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.

fireodo

@bmeeks said in Strange log entry after update:

I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.

Thank you!
PS. I can confirm it works! :-)

bmeeks

The fix for the issue reported in this thread has been merged into Snort package version 4.1.5_2. This build should show up in the 2.6.0 CE and pfSense Plus 22.01 package repos as an available update shortly. The new version will appear in the DEVEL tree after the next snapshot rebuild happens there (likely overnight).

fireodo

@bmeeks

Hi Bill,

the error returned this morning but I can see any directory name change in the recent snapshot archive snortrules-snapshot-29190.tar.gz (like the FreeBSD-13 change). Needles to say that I dont have change anything in Snort since the last update and there is plenty of free disk space (df -h = zroot/tmp zfs 9.8G 396K 9.8G 0% /tmp).
"[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz"
Is there a possibility to start a update with more detailed log output to see whats the real problem? Because this error message is identic whit the one when the Snort Team has changed the denomination of the directory (FreeBSD-12 -> FreeBSD-13).

Kind regards,
fireodo

fireodo

Hello,

Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")

Thanks,
fireodo

bmeeks

@fireodo said in Strange log entry after update:

Hello,

Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")

Thanks,
fireodo

I confirmed it. The Snort VRT has changed part of the pathname inside the tarball. They changed x86_64 to x86-64 in part of the path.

Here is a quick fix while I work on submitting a Pull Request to update the package.

Use your favorite text editor for Unix and edit the following file at the lines shown. Making a backup copy of the file prior to editing is recommended!

/usr/local/pkg/snort/snort_check_for_rule_updates/php

Find lines 631 and 632 in the file. They look like this:

if(snort_untar("xzf", "{$tmpfname}/{$snort_filename}", "{$tmpfname}", "so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/")) {
	snort_copy("{$tmpfname}/so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/*.so", "{$snortlibdir}/snort_dynamicrules/");

Change the two instances of x86_64 to x86-64 (one per line) and save the change.

fireodo

@bmeeks said in Strange log entry after update:

They changed x86_64 to x86-64 in part of the path.

Oha - my bad - that I have overlooked! Thanks a lot!

fireodo

@bmeeks said in Strange log entry after update:

Use your favorite text editor for Unix and edit the following file at the lines shown. Making a backup copy of the file prior to editing is recommended!
/usr/local/pkg/snort/snort_check_for_rule_updates/php

Done and confirm it works as expected!

Thank you!

bmeeks

Pull Requests have been submitted to correct this issue in both the DEVEL and RELENG_2_6_0 branches of pfSense. I attempted to make the code a little more tolerant of any future path name changes in the Snort Rules update archive file. Look for a Snort package update to version 4.1.5_3 in the near future. The requests are here:

https://github.com/pfsense/FreeBSD-ports/pull/1161
https://github.com/pfsense/FreeBSD-ports/pull/1162

In the meantime, if you hit this bug before the package update is posted, the quick fix is shown in an earlier post of mine above.

UPDATE: the pull requests listed above have been merged into their respective pfSense branches.