`current​_instance​_checks` setting does not work as documented.

[rfairburn]

Fleet version: v4.43.3

Web browser and operating system: N/A

---

💥  Actual behavior

https://fleetdm.com/docs/configuration/fleet-server-configuration#current-instance-checks describes this as the flag to use to limit vulnerability scanning to a single host.

However, when setting this to no on an instance, if it tries to run vulnerabilities, it will skip because it is set to no AND still mark the cron_stats table in the DB as completed. This prevents the instance marked as yes from ever getting a chance to run vulnerabilities.

Vuln scans can still happen infrequently but they will only happen 1/num_fleet_containers times assuming only one instance is set to yes as it is borderline random which instance will actually win the race to see if it runs the vuln processing.

🧑‍💻  Steps to reproduce

1. Have more than 1 fleet container. Having several is better
2. Have one with current​_instance​_checks set to yes and the rest with no.
3. Wait for vuln scans to run and check the logs.

🕯️ More info (optional)

This can be worked around by using https://fleetdm.com/docs/configuration/fleet-server-configuration#disable-schedule on all but one instance, but this is not how the other setting is documented to work.

[JoStableford]

Related to a Slack conversation

[getvictor]

@noahtalerman Can we deprecate current_instance_checks in favor of disable_schedule? I don't see why we need it.

Looks like current_instance_checks full functionality was removed in @gillespi314's refactor https://github.com/fleetdm/fleet/pull/7650

UPDATE: Another idea -- simply make current_instance_check be an alias for disable_schedule?

[sharon-fdm]

cc: @rachaelshaw

[noahtalerman]

@getvictor unless I'm missing something, I think we should make current_instance_checks work as documented.

Because we document current_instance_checks (docs here) I think we're stuck w/ supporting it until we release a major version of Fleet.

[getvictor]

@noahtalerman I don't see the difference in behavior for current_instance_checks vs disable_schedule

Setting:

• 1 server to current_instance_checks = yes/auto
• 10 servers to current_instance_checks = no

will be the same as setting:

• 1 server to disable_schedule = false
• 10 servers to disable_schedule = true.

[getvictor]

@noahtalerman Can I proceed making current_instance_check be an alias for disable_schedule? I don't see a functional difference between the two. See my previous comment.

[noahtalerman]

Looks like current_instance_checks full functionality was removed in @gillespi314's refactor https://github.com/fleetdm/fleet/pull/7650

I don't see the difference in behavior for current_instance_checks vs disable_schedule

making current_instance_check be an alias for disable_schedule

@getvictor if current_instance_checks and disable_schedule function the same, I'm in favor of making current_instance_check be an alias for disable_schedule.

If I'm understanding correctly, this means that if a user sets current_instance_checks to yes/auto, this will set disable_schedule to false under the hood.

And, current_instance_checks to no will set disable_schedule to true.

I think let's also remove current_instance_checks from the docs so no new Fleet users use it. And, update the disable_schedule docs to describe the use case of limiting vulnerability scanning to a single server.

@rfairburn any concerns with this? I think the Fleet system administrator UX doesn't change. Please let me know if we're wrong here.

[rfairburn]

@noahtalerman no concerns. Given that current_instance_checks doesn't do the thing, we use disable_schedule for our terraform modules already in our external-vuln-scans terraform module: https://github.com/fleetdm/fleet/blob/main/terraform/addons/external-vuln-scans/outputs.tf#L3

[fleet-release]

Fleet's gentle fix, A single host now secure, Cloud city breathes easy.

[efasel]

Hi, current_instance_checks is still mentioned in the docs in an example yaml file: https://fleetdm.com/docs/configuration/fleet-server-configuration#example-yaml17

vulnerabilities:
  databases_path: /some/path
  current_instance_checks: yes
  disable_data_sync: true