https://github.com/osquery/osquery logo
Powered by
#kolide
Title
# kolide
s

seph

01/14/2019, 3:42 PM
I’ve uploaded that to the nightly channel. Try building with 
--launcher_version nightly
and see how it does? 
launcher --version
should show a build today, version 0.7.0-4-ga3b6e0d
n

nick.taylor

01/20/2019, 10:24 PM
I was also seeing this issue with a panic caused by the argument parsing code, fixed in the nightly, thank you. But how does a bug like this make it into the 
stable
channel unnoticed? I don’t think I’m doing anything different that would trigger it.
I’m not trying to be a jerk, I love Fleet & Launcher I’m just trying to understand the difference between 
stable
, 
beta
, & 
nightly
channels.
z

zwass

01/20/2019, 11:05 PM
I'm not super familiar with that bug, but my understanding was that it may have actually existed for quite some time (in stable). It's rare for someone to run 
launcher
without arguments and it may have just slipped through the cracks.
n

nick.taylor

01/20/2019, 11:07 PM
It’s rare for someone to run 
launcher
without arguments
The 
launchd
file built by 
package-builder
runs it without options…
g

groob

01/20/2019, 11:19 PM
That’s not true. The options are just provided via env var instead of flag.
They are still parsed by the flag package
Sometimes software is released with bugs. The stable, beta and nightly flags are what we use to push auto updates of launcher to our SAAS customers. You’re welcome to trust us with them, or to roll your own notary server and tag packages yourself. The guarantees for stable is that launcher deployments downloaded from our SAAS will continue working for customers. They might not necessarily work for a deployment you created yourself which makes different assumptions from ours. Of course, we do a best effort to ensure we don’t break anyone who relies on our software.
Hopefully that clears up the tag usage for you.
n

nick.taylor

01/20/2019, 11:25 PM
Thanks @groob, I totally understand that your SAAS customers are your priority. I’m just trying to figure out why my previously working build process now generates broken deployments & how to stop this happening again 🙂
g

groob

01/20/2019, 11:27 PM
File a issue on GitHub. Note that @zwass said, we assume you provide some arguments for launcher to run. There are defaults, env vars and flags which override configs
Likely a default that used to be there was accidentally removed.
n

nick.taylor

01/20/2019, 11:28 PM
s

seph

01/21/2019, 2:47 AM
The bug was there ~forever, and my recent changed to package builder shift more things to from command lines flags to ENVs.
To some degree, this sort of thing exists, because there’s not a great way to test all permutations of software.
I’ve been pondering whether it’s feasible to create enough of a CI framework to launch a VM, and test init scripts. But the rat hole gets very deep.
n

nick.taylor

01/21/2019, 2:49 AM
But the rat hole gets very deep.
CI on OS X, that way lies madness
s

seph

01/21/2019, 2:50 AM
I’ve been working more on adding unit tests to the underling lib functions in package builder. But, ultimately, it’s really hard to test this kind of infrastructure stuff.
n

nick.taylor

01/21/2019, 2:51 AM
Thanks for the explanation though, I understand what happened now, I was just very puzzled as to why the bug only manifested now, but your mentioning changes to the package-builder generated launchd file makes sense.
s

seph

01/21/2019, 2:54 AM
Yep.
The linux and darwin stuff should be a lot cleaner now. And I’ve been starting on the MSI side
5 Views
Powered by