we chose a separate directory specifically so you ...
# kolide
g
we chose a separate directory specifically so you can install the osquery package on your own
n
I'm torn on how to handle this then. Do I just use munki deploy non-launcher osquery and configure it with munki to talk with fleet, and stop using launcher all together. Seems like overhead to have osquery essentially installed twice.
I like the goals of launcher with the auto config and auto update
maybe I just ship my own package that symlinks to the launcher location
g
i’m not sure what you’re trying to accomplish
why do you want osqueryi
n
My main goal is the deploy osquery to my managed machines, and launcher seems like the right mechanism for that. But in deploying osquery, I'd still like to be able to run queries at the terminal if i'm at a local computer.
I could just run
/usr/local/launcher/bin/osqueryd -S
but it seems clunky if the standard install of osquery makes
osqueryi
available.
g
why do you want osqueryi
n
mostly because that's what a lot of what i've been exposed to says to use. If you take fleet and launcher out of the equation, you end up with using
osqueryi
. I guess I was under the impression (originally) that Launcher did nothing more than install exactly what you would download from https://osquery.io/downloads/
but it appears that launcher is actually doing a "custom" install instead
c
it's easier to remember
osqueryi 'select hardware_model from system_info'
g
launcher puts osqueryd for its own use into a directory
it’s there not to interfere with your own osquery install
it’s questionable that you need laucnher vs your own config, but launcher does offer some benefits
osqueryi
is only useful to a human though
and it’s fine to install it on your machine for things
it’s questionable that you would want to deploy osqueryi to every machinein the fleet
that’s what the daemon is for
and that’s why live query exists as a feature 🙂
anyway.. not trying to persuade you one way or another, just giving context about the launcher