[ebpf] Check for bpftool presence before running plugin

[jcastill]

The plugin was running even when the bpftool was
not present, throwing an exception when it tried to parse a json output:

INFO: [plugin:ebpf] Could not parse bpftool prog list as
JSON: Expecting value: line 1 column 1 (char 0)

It now checks if the program is present before running any command at all.

Related: RH SUPDEV-151

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3413
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[pmoravec]

commands mean the plugin will be enabled any time some command from the tuple is present. So the line will be a new independent way how the plugin will be enabled by default.

If your aim is to enable the plugin automatically only when the binary is present, I think you need to test it in overwritten check_enabled method..?

[TurboTurtle]

Sorry this one definitely slipped through the cracks over the last few months.

commands mean the plugin will be enabled any time some command from the tuple is present. So the line will be a new independent way how the plugin will be enabled by default.

If commands is the only enablement trigger defined, then it will only enable the plugin when the command is present. The commands check resolving False if bpftool is not installed will cause _check_plugin_triggers() to return False. If no triggers are defined, like what is currently written, then it enables all the time which is not desired here.

@jcastill sorry for the churn here, but the original change was correct - just add the commands tuple. The check_enabled() override is unnecessary.

[pmoravec]

Good point, my mistake. I hadn't realized the commands is the first enablement trigger to be added.

[jcastill]

@TurboTurtle @pmoravec it's ok :) I'll revert this change and push again in a bit.