Channels
android_tests
apple-silicon
arm-architecture
auditing-warroom
aws
carving
code-review
community-feeds
core
darkbytes
doorman
ebpf
eclecticiq-polylogyx-extension
extensions
file-carving
fim
fleet
fleet-dev
fleetosquery
foundation
fuzzing
general
golang
goquery
infrastructure
jobs
kolide
linen-dev
linux
macos
officehours
osctrl
plugins
process-auditing
querycon
queryhub
random
selfgroup
sql
tls
uptycs
vendor-feeds
website
windows
zeek
zentral
zercurity
Title
s
seph
01/14/2019, 3:42 PMI’ve uploaded that to the nightly channel. Try building with
--launcher_version nightlylauncher --versionn
nick.taylor
01/20/2019, 10:24 PMI 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
stableI’m not trying to be a jerk, I love Fleet & Launcher I’m just trying to understand the difference between
stablebetanightlyz
zwass
01/20/2019, 11:05 PMI'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
launchern
nick.taylor
01/20/2019, 11:07 PMIt’s rare for someone to runThewithout argumentslauncher
launchdpackage-builderg
groob
01/20/2019, 11:19 PMThat’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 PMThanks @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 PMFile 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 PMIt’s been solved by https://github.com/kolide/launcher/pull/402
s
seph
01/21/2019, 2:47 AMThe 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 AMBut the rat hole gets very deep.CI on OS X, that way lies madness
s
seph
01/21/2019, 2:50 AMI’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 AMThanks 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 AMYep.
The linux and darwin stuff should be a lot cleaner now. And I’ve been starting on the MSI side