"Supported Platforms" update for the Suricata era

[philrz]

Up until now, our Supported Platforms statement has been primarily expressed in terms of where we run CI runs as well as the support statements from Go/Electron. However, the work on Suricata reminded us how there can be additional sensitivities in terms of shared libraries that may or may not be present in platforms and hence will determine whether Brim can install and operate out-of-the-box on them.

Now that the Suricata support is pretty well established, this issue will be used to capture a point-in-time snapshot of where we stand on the various platforms. The information can then be used as the basis for a revised support statement we can use going forward.

The approach I'm taking is largely a binary search: Establish the oldest & newest revisions in a given platform that seem to pass a smoke test, which can be combined with our CI statement.

[philrz]

Smoke testing has been performed with the Brim rc-v0.21.0-suricatav5.0.3-brimpre2 draft release candidate. Each smoke test consists of:

1. Install the base OS/distro while accepting the defaults on any offered install-time config options. No additional software is added.
2. Install the Brim app using standard package install procedure for the OS/distro (e.g. double-clicking the install artifact acquired from Brim releases in the platform's default "file explorer" utility).
3. Import a test pcap into Brim and use ZQL fuse | count() by _path,event_type to confirm the embedded Zeek and Suricata both produced records.

Windows

Getting easy access to common desktop versions has been a challenge, as Google Cloud only offers Server versions. However, as part of this exercise I found https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ where Microsoft makes dev VMs available from as far back as Windows 7 in the name of testing IE compatibility. Therefore I used these in smoke testing.

Windows 7: Fail

We'd had anecdotal evidence that some users had limited success running Brim on this EOL platform, though we also had some bugs reported that we couldn't really pursue due to lack of access to the platform. However, smoke testing with the rc-v0.21.0-suricatav5.0.3-brimpre2 artifact, it fails out-of-the-box, so it seems appropriate for us to claim no support for Windows 7 at this time.

Windows 8.1: Pass

Microsoft articles consistently reinforce that "regular" Windows 8 reached end-of-support years ago and customers have been getting pushed to upgrade to Windows 8.1 or Windows 10 for some time. Since we can't even seem to get access to "regular" Windows 8 to smoke test with, I've tested with Windows 8.1 and found it did pass.

Windows 10: Pass

This is no surprise, since this is expected to be roughly equivalent to the Windows 2019 Server our CI runs on, plus several of us run Windows 10 laptops and smoke test on it regularly. Still, this does validate that Brim has all its dependencies met in an out-of-the-box install.

macOS

For starters, we know we'll have to update our support statement for the moment to explain that we lack support for Macs based on the new M1 (ARM-based) chip. For this to happen we'll need to start shipping a build that uses the separate Electron that has Apple Silicon Support, and in order to do this we'd ideally have the use of GitHub Actions Runners that support the chipset.

As for the Intel-based Macs, for these smoke tests I had the use of a spare Mac laptop that I could "reset factory" back to High Sierra. After testing on each older release, I upgraded to the following release.

High Sierra 10.13.6: Fail

Our support statement was already setting expectations that pcap import would not work on this platform, and indeed this is still the case.

Mojave 10.14.6: Pass

Catalina 10.15.7: Pass

Bug Sur 11.0.1: Pass

Linux

Clearly there's more distros and versions-of-them that we could feasibly test. Even as we speak of "Ubuntu/Debian" or "Fedora/RedHat" in the same breath, these have differences that may be significant. Therefore I've done my best to binary search to the oldest rev where Brim seems to start working, then confirmed the same with the most recent release. While we couldn't rule out that it may have stopped working in some release in between the two endpoints, we can likely set expectations that it will work and be prepared to investigate should a user report otherwise.

Debian

Debian v8.11.1: Fail

Brim appeared to install without complaint, but then silently failed to launch, showing no error message. The icon just spun for several seconds. It also silently refused to launch when running brim from the Terminal.

The contents of /var/log/messages point to a possible library issue, which is unsurprising.

Debian 9.13.0: Fail

Debian 10.0.0: Pass

Debian 10.7.0 (latest): Pass

Ubuntu

Ubuntu 12.04.5: Fail

Ubuntu 16.04.7: Fail

Ubuntu 17.04: Fail

Clicking "Install" on the .deb installer in the Files utility didn't seem to do anything, so I installed it via dpkg.

Ubuntu 17.10.1: Fail

Ubuntu 18.04: Pass

Ubuntu 20.10 (latest): Pass

Fedora

Fedora 21: Fail

This shows the symptom we first spotted regarding boolean dependencies in RPM that we first spotted in #1008.

While dnf was present as a possible command line alternative way to install, this revealed other missing depdendencies. Therefore it's surely safest to not claim any out-of-the-box support.

$ sudo yum install brim_x86_64-rc-v0.21.0-suricatav5.0.3-brimpre2.rpm 
	[sudo] password for phil: 
	Loaded plugins: langpacks
	Examining brim_x86_64-rc-v0.21.0-suricatav5.0.3-brimpre2.rpm: brim-0.20.0-1.x86_64
	Marking brim_x86_64-rc-v0.21.0-suricatav5.0.3-brimpre2.rpm to be installed
	Resolving Dependencies
	--> Running transaction check
	---> Package brim.x86_64 0:0.20.0-1 will be installed
	Error: Invalid version flag: or

	$ sudo dnf install brim_x86_64-rc-v0.21.0-suricatav5.0.3-brimpre2.rpm 
	Error: nothing provides (kde-cli-tools or kde-cli-tools5 or kde-runtime or trash-cli or glib2 or gvfs-client) needed by brim-0.20.0-1.x86_64

Fedora 25: Fail

Fedora 27: Fail

Fedora 28: Pass

Fedora 29: Pass

Fedora 33 (latest): Pass

CentOS

As explained in the CentOS FAQ, CentOS "aims to be functionally compatible with Red Hat Enterprise Linux" (RHEL) and therefore provides the basis for our RHEL supportability expectations.

CentOS v7.8 2003: Fail

We already were aware of this via #1008. Double-clicking the .rpm installer in the Files utility gives a general error.

Dropping to the Terminal and trying with yum we see the symptom of the known issue regarding boolean dependencies in RPM.

CentOS v7.9 2009: Fail

The results are much the same as what we saw for CentOS v7.8.

CentOS v8.0 1905: Pass

Centos 8.3 2011 (latest): Pass

[philrz]

The Supported Platforms article has been updated to reflect the findings shown above. They are considered accurate as of the GA pairing of Brim v0.21.0 and zq v0.25.0 that we're just about to release.