If osquery tried to create it on startup. it might...
# macos
s
If osquery tried to create it on startup. it might make some things simple for end users. But, it would mean that an error in the config would results in a bunch of logs somewhere perhaps unexpected. It might also have some bootstrapping weirdness. If you’re testing osquery, and you invoke it with a log path from the command line, you might get directories created instead of an error. Not really sure what people would find least confusing. ¯\_(ツ)_/¯
z
I've often thought it would be nice to create it on startup.
a
it seems like the kind of implementation-specific thing where deployments may prefer to choose a different directory, though - my current idea is to let osqueryctl be a 'fixer' tool since it's a proof-of-concept-only-ish tool in my mind?
s
If you thought osquery should create it’s log directory. it would create what it was configured with. Which would be solely in the site’s control.
I am, generally, apprehensive about pushing complexity into additional tools. I think I’d be unhappy with an install process that amounted to “Run osqueryctl to prep the machine, then run osquery”. It raises lots of questions about why not have osqueryd do the work
Anyhow, I think I’d onboard for osquery create the log directory if the filesystem output is configured.