Suricata management

[CyrilBrulebois]

Here's what pirogue-eve-collector.postinst looks like after the initial pirogue-admin-ification:

#!/bin/bash

set -e

#DEBHELPER#

# NOTE/FIXME: suricata is only getting configured (suricata.yaml) when
# pirogue-admin kicks in.
#
# TODO: Clarify whether those should be done in all cases (those probably don't
# make sense if suricata is conditionally skipped?), and if that should only be
# done once or every time.
#
# Clarifications:
#  - The condition applies to all instructions, they should only be called once,
#    during the first installation/configuration.
#  - TO TEST: Does that depend on having configured suricata.yaml beforehand? In
#    which case we might need some callback, once pirogue-admin has done its work.

if systemctl show suricata.service | grep -qs ^ConditionResult=yes$; then
  suricata-update --no-check-certificate update-sources
  suricata-update --no-check-certificate enable-source et/open || true
  suricata-update --no-check-certificate enable-source oisf/trafficid || true
  suricata-update --no-check-certificate enable-source sslbl/ssl-fp-blacklist || true
  suricata-update add-source PTS https://piroguetoolsuite.github.io/suricata-rules/suricata.rules || true

  suricata-update --no-check-certificate
fi

Given the initial deployment at least on Pi 4 and Pi 5 (AP mode), and in a VM with a single interface (VPN mode) gives successful results, it seems we don't need to wait until pirogue-admin has set up a specific suricata.yaml before running those commands.

It seems weird in 2024 to have to disable certificate checks, and those commands seem fine without it, so I'm tempted to remove that option.

I'm filing this issue to make sure the changes staged in the virogue branch aren't forgotten about when everything ends up being merged into the debian-12 branch…

Cc: @U039b

[CyrilBrulebois]

Here are the changes I'm about to test again with a fresh installation on Pi 4 / Pi 5 / ViRogue (VPN):

pirogue-eve-collector (1.2.1) bookworm; urgency=medium

  * Restrict suricata-update calls (when the suricata.service isn't
    condition-skipped) to the initial installation.
  * Delete --no-check-certificate option.
  * Add suricata-update to Depends explicitly: it's used in postinst and
    is only pulled by suricata via Recommends.
  * Call `pirogue-admin --redeploy --commit` from postinst when upgrading.
  * Add pirogue-admin to Depends accordingly.
  * Sync ConditionMemory bump (1.5GB → 2.5GB) from the debian-12 branch,
    as published in pirogue-eve-collector 1.1.1.

 -- Cyril Brulebois <cyril@debamax.com>  Sun, 25 Aug 2024 02:45:15 +0200

The matching postinst:

#!/bin/bash

set -e

#DEBHELPER#

# All of the following are needed once, during the initial installation, and
# that can happen before our own suricata.yaml is deployed by pirogue-admin:
if [ "$1" = configure ] && [ -z "$2" ]; then
  if systemctl show suricata.service | grep -qs ^ConditionResult=yes$; then
    echo "I: performing suricata configuration (initial installation)" >&2
    suricata-update update-sources
    suricata-update enable-source et/open || true
    suricata-update enable-source oisf/trafficid || true
    suricata-update enable-source sslbl/ssl-fp-blacklist || true
    suricata-update add-source PTS https://piroguetoolsuite.github.io/suricata-rules/suricata.rules || true

    suricata-update
  else
    echo "I: skipping suricata configuration (initial installation, condition failed)" >&2
  fi
fi

# Poke pirogue-admin, only when upgrading:
if [ "$1" = "configure" ] && [ -n "$2" ]; then
  pirogue-admin --redeploy --commit
fi

[CyrilBrulebois]

That's been doing the trick on Pi 4, Pi 5, and other systems.

Marking as in-progress.

Cc: @U039b for a possible review, @TontonSancho for a possible test on low-memory Pi 4.

[U039b]

It looks good to me, thanks :)

[CyrilBrulebois]

OK, closing then; thanks!

It can always be reopened (or another issue opened with details) if runtime is KO for someone.