Hey all, I was wondering using

fleetctl package

to create a package, does it also automatically enable the update channels or are they disabled by default? I want to create a static package that does not use the update channels

Hi SK! The update mechanism is always enabled by default. Here's a similar question in this channel and Zach proposes a way to workaround it: https://osquery.slack.com/archives/C01DXJL16D8/p1638555957251100?thread_ts=1638535962.237900&cid=C01DXJL16D8

I want to create a static package that does not use the update channels

We are interested to hear the user story for a "disabled auto-update" for fleet-osquery.

if you don't mind my barging in - is there a way to "gate" the auto updates? I can see this being a possible (no offense) supply chain vulnerability and it would be good to be able to vet the update package before widespread deployment.

@Lucas Rodriguez Thanks for the link, didn't find it when I was searching. We are thinking of using a CICD pipeline to create static packages as not all our host instances are allowed to auto-update, the new

fleetctl package

function is great for creating packages in that pipeline, but making auto-updating optional would be great

Right, a disabled "auto-update" would allow for a manual check of new updates (vs. the option we currently provide to set a custom TUF endpoint, which is more involved).

Good questions. @SK the closest you can get at the moment is to use something like

--osqueryd-channel=5.0.1 --orbit-channel=0.0.5

. It will still check for updates but no updates will be pushed on those channels. We plan to add a "disable entirely" option. @Jason Two things that will help to address this: 1) We intend to add the ability to change the "update channel" from Fleet itself. This way you can do a phased rollout of a new version or any other sort of vetting process you like. 2) Fleet Premium users can (currently) operate their own update server where you push your own artifacts (which you can build from source if you like).

ah ok great! Both are excellent options @zwass

We plan to add a "disable entirely" option.

@zwass Do we have an issue? If not I can create one.

@Lucas Rodriguez I'm not sure. Please file one if not.