Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

Hi all. In fleetv3, when Software Inventory was introduced, there was an environment variable “FLEET_BETA_SOFTWARE_INVENTORY” that could be set to true or false. in fleet v4 it's a feature in the fleet_cfg.yml file called "enable_software_inventory: true" - My question is, is there still a supported environment variable flag, like the beta version, in v4 that can still be used as a switch?

While I can use "fleetctl" to modify the feature, I have a request to be able to add the feature flag like the v3 beta variable. So does this, or does this not exist in v4? The docs don't mention it. Thanks!

Hi <@U04KYQZUH55> ! What version of Fleet are you running?

There isn't an environmental variable for that. since the default is now to enable software inventory. Why is fleetctl not an option for you?

Hi <@U02KY9FDA59> Thank you for the quick answer. I knew somebody was going to ask “why not fleetctl” :slightly_smiling_face: . I just didn’t want to get in to details to just get the answer.

Short version is, it *is* an option, but more work than adding an env variable flag would have been.

Longer version: &lt;waves hands vaguely towards automation, CI/CD pipeline, docker compose image that passes command line flag env variables, and doesn’t have fleetctl installed on build machine&gt; Yeah, I could add fleetctl to the build machine with docker and run it after docker has started fleet, but if there were an env variable flag to do this, it would be a one line change to the compose file. And ultimately, it turns out none of this was needed since “Software Inventory” now defaults to “on”.

Our instance didn’t have it on (i used fleetctl to enable it) and we wanted to make sure if we ever had to rebuild from scratch that change wouldn’t be lost. Infrastructure as code, and all that.

Ah. That makes sense. Just to make life easier,, you can apply configs files remotely so you don't necessarily need `fleetctl` on the build machine.

yeah, and I did that, but that becomes an out-of-band manual process. Infra as code is all about change control. everything should be stored in git, triggering builds when PRs merged. poking it from not-the-build-machine with fleetctl requires *that* to be managed/maintained somewhere as well. And if you are going to do that, it might as well be all together on the buildbox, right?