[Bug 284377] security/suricata: fix suricata-update baked in paths to JustWork on FreeBSD

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 26 Jan 2025 23:52:14 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284377

            Bug ID: 284377
           Summary: security/suricata: fix suricata-update baked in paths
                    to JustWork on FreeBSD
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: yds@Necessitu.de
                CC: franco@opnsense.org
             Flags: maintainer-feedback?(franco@opnsense.org)
                CC: franco@opnsense.org

Created attachment 257020
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257020&action=edit
fix suricata-update baked in paths to JustWork on FreeBSD

add new `files/patch-suricata.yaml.in` to always enable
`/var/run/suricata/suricata-command.socket` expected by `suricata-update` and
`suricatasc`

`files/patch-suricata.yaml.in` also uncomments and fixes the path for
`magic-file: /usr/share/misc/magic`

the Makefile is patched to further `sed` the `suricata.yaml.in` file to set the
correct path for GeoIP db

post-patch-PYTHON-on: target then edits all the requisite `suricata-update` and
related docs to reference the actual paths and files installed by this port/pkg

post-install-PYTHON-on: and the pkg-plist are fixed up to install all the
config files expected by `suricata-update` to $ETCDIR as .sample files.

with the fixes in this patchset `suricata-update` can be run by a nightly
cronjob and everything JustWorks including the reload-command:
sudo /usr/local/bin/suricatasc -c reload-rules

throughout the edits suricata's `data` dir is normalized to `/var/db/suricata/`
-- this dir is created as needed by the scripts.

the startup is bumped up to:
# REQUIRE: FILESYSTEMS defaultroute resolv
# BEFORE: NETWORKING
the reason for this is suricata knocks the interface it connects to via netmap
offline for many many seconds -- this disruption is better tolerated by
FreeBSD's startup sequence /before/ NETWORKING is expected to already be
working.  the final result is the startup is happens much faster with fewer
disruptions from the netmap interface going down while suricata binds to the
interface.

-- 
You are receiving this mail because:
You are the assignee for the bug.