Charm doesn't report values if megacli is installed from repository

[Dariusz Smigiel]

In a case of megacli installed from repo, charm doesn't return a valid response.

Operator receives an information
> WARNING: controller not found
The file is empty

root@compute-server-7:/var/lib/nagios# cat megacli.out
root@compute-server-7:/var/lib/nagios#

root@compute-server-7:/var/lib/nagios# which megacli
/usr/sbin/megacli

[Drew Freiberger (afreiberger)]

This is probably a won't fix. The tools resource checksum validation is for security of running binary processes as root, ensuring we've approved the binaries run as root by the charm.

[Drew Freiberger (afreiberger)]

To make the point another way.

While it's valid that we can install megacli separately, I'm not sure we should approve use of random paths to megacli found on the system to be run by a root cronjob this charm creates. We should consider longer term if this is still a requirement of our charm to use a determinate path for megacli to ensure we've vetted it through the checksums. If checksum checking is required, the path to megacli should be hard-coded only to where we install that binary, instead of using any copy of megacli in the $PATH.

[Gustavo Sanchez (gustavosr98)]

Hey,

So, the long term solution would be to have megacli as a snap and as a quick solution for now in a deployment would be to add /usr/sbin to $PATH?

Or is there already a way to install megacli in one of the paths that the cron_megacli.sh has?

[Andrea Ieri (aieri)]

The currently supported method for deploying megacli is via the attached resource, provided the megacli binary is among the whitelisted versions hardcoded in the charm.
Going forward, I think we should consider supporting installing vendor tools from repositories, but only if the installation is managed via the hw-health charm; I do not think we should support using binaries that the charm has not itself installed.