Hello! Where is the best place to read about what "--update-url" is used for, when building a package? While I am quite keen for my fleetdm server (--fleet-url) to check for any updates to Orbit (I guess that is what the --update-url is for?), I don't really want all my other clients making (or attempt to make) outbound connections. If they need an update, I'd rather push this myself. (Caveat: I have made an assumption/guess about --update-url)

One option is to run not Orbit but plain osquery.

That’s true!

One of the benefits of Orbit is the auto-update/auto-config (useful when managing thousands of hosts).

@Tor Houghton, the

--update-url

option is used to specify a location for an update server. Fleet Free users do not have to set this option. By default it is set to https://tuf.fleetctl.com which is the Fleet team’s autoupdate server. The

--update-url

option is part of the Self-managed agent updates feature. This feature is available for Fleet Premium customers. Paid users of Fleet can point Fleet’s osquery installers (Orbit) at their own update server.

Thanks for all this information; indeed, the first time around of installing fleetdm, I did run plain old osquery but I thought I'd give the installer package a go as well, to see how that worked (which worked fine on all my linux hosts, but had weird MAC tls errors when installing the .pkg on MacOS). So .. I may go back to what @Lucas Rodriguez suggests. I was just curious as to what --update-url was for and if I could avoid using it on my client machines (e.g. with a "--manual-update" option ;)).

@Tor Houghton we haven't yet added functionality to disable autoupdate completely in Orbit (since autoupdate is one of the primary benefits), but we do intend to do so. As a workaround you could set

--orbit-channel

and

--osqueryd-channel

to specific versions, which would not turn off the checks but would result in no updates being performed. Would you mind sharing what is motivating your use of Orbit if you are not interested in autoupdates? This could help us understand your use case and prioritize adding that feature.

While I can (for the most part) mitigate against the autoupdate by blocking the domain in our outbound proxy and/or provide NXDOMAIN replies in our resolvers, I would rather the client hosts just stay quiet; several do not have any business making outbound connections and any attempts either trigger alerts or skew the flow data. So I guess that's the first reason. The second is probably not likely, but I would still like to further reduce it (or at least reduce the impact): the effects of a supply chain attack, should it happen.

Nice, thank you for the context there. That all makes sense.