reduce Hedgehog Linux complexity/duplicate code by running Malcolm in "hedgehog run profile" mode

[mmguero]

Coming along, but here are things I still need to fix/validate:

• specify NetBox site from HH
• default to static IPs for HH (both?)
• make configure-interfaces.py more accessible
• confirm No if they select it in install.py before applying
• auto HD format for HH mode (no opensearch directory)
• "Oldest DB indexes" in prompt for cleanup
• don't require setting for index delete threshold in validation for HH
• test username/password
• arkime-live on HH test/verify (viewer? wise?)
• verify auditd log
• verify custom tags
• port the kiosk interface
  • figure out why fluent-bit doesn't start/stop from the kiosk
• verify nginx access and error log
• verify netbox site
• verify arkime capture stats
• allow specifying malcolm host in one place rather than 4
• raspberry pi hedgehog-iso build (going to punt this to a future release, with release notes to indicate it won't be included in this one)
• update all documentation
• [2025-11-20T21:04:27,777][WARN ][logstash.filters.mutate ] Exception caught while applying mutate filter {:exception=>"Invalid FieldReference: [zeek][%{[log_source]}]"}
• add /malcolm paths to aide exceptions (otherwise working and tested)
• expose arkime-live PCAP compression settings in installer
• make sure malcolm ext- settings (ACL already is...) get put in exported config file
• test "capture but don't forward" use case
• update youtube video descriptions (after release)

---

Today hedgehog linux is not running anything containerized: tcpdump, arkime, netsniff, etc., is all run as regular processes that are built/packaged up at build time.

However, on Malcolm we have the "hedgehog run profile" which basically does the same thing.

We would have 1) a lot less duplicate code 2) a simpler build process and 3) a simpler upgrade process (#351) if we just had hedgehog linux run "Malcolm" just like the Malcolm ISO does, with the only difference being that it runs the hedgehog profile. We could rip out almost everything that's specific to the Hedgehog Linux ISO.

We'd need to do quite a bit here though:

• We need to determine, exactly, that we have feature parity across both. I'm like 90% sure we do.
• There should be no reason there are any performance differences (one of our big partners is essentially using hedgehog mode and they're doing high-volume) but we should verify that all the tuning stuff is the same
• What about upgrade from previous hedgehog versions? Honestly, that is already abysmal so I think it's probably just a clean break, like this is a whole new thing from the previous hedgehog. We can even use the new installer (Malcolm configuration overhaul #766) to configure everything and almost completely scratch the hedgehog-specific configuration code
  • that being said, there are a few things that are different:
    • network interfaces/etc. configuration on hedgehog is different than Malcolm (which uses NetworkManager). We could get rid of that too and switch to network manager, but we do need to change the default behavior to not be DHCP on the sensor, if we decide to go that way
    • the new Malcolm installer can do the setup for the forwarding too, but we'd need to expose the "Transfer self-signed client certificates to a remote log forwarder" stuff which we don't currently expose
    • some of the stuff that sets up the default paths for storing artifacts would need to change a little bit (we already support this on Malcolm, so not a huge amount)
• there's the raspberry pi build we'd have to adapt as well
• there are probably other things as well

Code wise, I don't think I'd even muck with stuff in hedgehog-iso. I'd probably either try to integrate it right into the malcolm-iso with some different build flags. Then basically we have ONE iso installer code base, but we could still build different flavors of it based on a flag for malcolm vs. hedgehog (not package ALL the docker images in the hedgehog one, just the ones we need, the different "branding" and labels, etc.).

For the most part though this would massively reduce the amount of code in the repository and cut down code maintenance a ton. I think it's the way to go.