Q: Is there a minimum version of osquery and orbit...
# fleet
a
Q: Is there a minimum version of osquery and orbit that fleetctl v4.26.0 requires in order to be able to build a package? I’m working on our very outdated setup which has a self-maintained TUF repo with the most recent targets of orbit 0.0.3 and osquery 5.2.2, but I’m getting an actual SIGSEGV from the golang packaging code (will include in thread). When I just use the defaults for
--update-url
and
--update-roots
, everything works great! So I figure maybe fleetctl needs a minimum version or something? Which means I just need to get newer binaries of orbit and osquery from….somewhere?
The error in question. The
&data.TargetFileMeta
bit is from a debug log that we stuck in the go code:
fmt.Printf("%#v\n", osquerydMeta)
in the file
orbit/pkg/packaging/packaging.go
in the function
func InitializeUpdates(updateOpt update.Options) (*UpdatesData, error)
--host-id
is a custom argument that we added for passing the host-identifier to osquery during packaging
z
Hi Andrew, self-hosted TUF servers using Fleet's tooling is a Premium feature that you need a license to use or get support for. Would you like me to put you in touch with our sales team so that you can get your usage back under a valid license and we can support you in these issues?
a
Sure thing, my email is
<mailto:andrew.zick@secureframe.com|andrew.zick@secureframe.com>
, I’m just a dev but I bet I can find the right person for sales to talk to 🙂 What exactly does “self-hosted TUF servers using Fleet’s tooling” mean? E.g. are you’re talking about using fleetctl? Updating via
<http://tuf.fleetctl.com|tuf.fleetctl.com>
? Something else?
z
Thanks! Let's try to understand what you're doing here and whether it's even the Premium feature. Then I'll connect you to the relevant folks if necessary 🙂
Specifically the premium feature is using the
fleetctl updates
subcommands to generate and maintain a TUF repo.
Copy code
fleetctl updates --help                                                                                                                         
NAME:
   fleetctl updates - Manage client updates

USAGE:
   fleetctl updates command [command options] [arguments...]

DESCRIPTION:
   fleetctl updates commands provide the initialization and management of a TUF-compliant update repository.

   This functionality is licensed under the Fleet EE License. Usage requires a current Fleet EE subscription.
a
Ahhh, oh that’s cool, I didn’t know the help printed out which features were premium 😮
z
If you are just packaging and using our server tuf.fleetctl.com then that's all free.
Most features are actually gated by a license check with the Fleet server, but this one is only documented and doesn't enforce because it's intended to work in offline environments.
a
Oddly enough, I think my situation might be in-between these two things?
fleetctl package
works when I let it use the defaults for
--update-url
and
--update-roots
which are Fleet’s TUF repo + root key metadata. But when I try using my own TUF repo that lives in S3, I get the weird error. My TUF repo probably hasn’t been touched in over a year so all the targets are very old (versions in op). Which is why I was wondering if the issue was a newer
fleetctl
that can’t package really old orbit/osqueryd binaries. Totally reasonable if that’s the case! Also totally reasonable if debugging this weird custom case requires paying for support, people’s time isn’t free 👍
z
Ah, if you are using
update-url
and
update-roots
it sounds like you are trying to use a self-hosted TUF repo which would be generated with the premium licensed
fleetctl updates
commands. Let me work on getting the right folks connected. Thanks!
a
Sounds good! I don’t see anything in our internal docs about
fleetctl updates
but that definitely doesn’t mean it wasn’t used initially and then just not documented. edit: fixed the double negative, woops