Hello! Where is the best place to read about what ...
# fleet
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.
Fleet supports plain osquery.
That’s true!
One of the benefits of Orbit is the auto-update/auto-config (useful when managing thousands of hosts).
But Fleet server supports plain osquery, Orbit is a relatively new addition.
💐 1
@Tor Houghton, the
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
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.
💯 1
Fleet Free users have several options for deploying osquery like Lucas explains above. These are… • Deploy Fleet’s osquery installer (Orbit). The Fleet team’s autoupdate server will automatically update osquery on your hosts to the latest stable release of osquery. • Deploying plain osquery. When an update to osquery is released you’ll have to deploy a new binary.
ty 1
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 ;)).
Thanks so much for your time + input.
Just to understand what @Noah Talerman says: "Fleet Free users do not have to set this option."; can I initialise --update-url with "something" (or "")? I am no go programmer so I wouldn't know if putting "something" into --update-url that resulted in a socket not being opened would cause orbit to die (in update.go): remoteStore, err := client.HTTPRemoteStore(opt.ServerURL, nil, httpClient) if err != nil { return nil, fmt.Errorf("init remote store: %w", err) }
@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
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.
For now, though, I can go with @Lucas Rodriguez solution 🙂
But as for orbit, I liked the idea of being able to get the package direct from the GUI.
(With all the configuration etc. bundled, so all it needs is a dpkg -i/whatnot, instead of apt install of osquery+a push of /etc/osquery w/flagfile,secret,pem)
Nice, thank you for the context there. That all makes sense.