Hi all, Happy Friday! Is there a way to see why c...
# fleet
m
Hi all, Happy Friday! Is there a way to see why certain scripts fail to run, or fail in gathering the requested data? For example, I see a high number of failures for interfaces.cpp where it is failing to retrieve network statistics for an interface. Another one is "Failed to retrieve DHCP and DNS information for interface 1". I'd like to see if this is due to a network timeout, device being offline, policy block, etc. Is there somewhere I can gather more data on this from Fleet?
g
Hey @Mike S., what version would you be running again? And are you using fleetd or standalone osquery? Going off a hunch- Would the packages on your endpoints be running with the
--insecure
flag?
m
Hi Grant! Fleet version is 4.42.0 - Using Fleetd. As for the --insecure flag, I'm not aware of any flagging - how would I best verify that?
I don't have that set as a command line flag in my agent options.
g
Do not think shows up in agent options or flagfile. Is an fleetctl flag when using
fleetctl package
. Think can check in the local logfile/process for a
--tls_server_certs C:\\Windows\\TEMP\\fleet.crt
line (or something similar based on OS).
m
Ahh right - I can check that, one moment.
g
Asking this cause have seen
--insecure
flag being used and has the behavior you're describing about, "Failed to retrieve..." This flag sets a "self-signed" temp certificate and "proxies" to pass data from osqueryd to Fleet.
m
So in the script I built for configuring agent packages, I only have --type, --fleet-url and --enroll-secret.
I don't see any references to insecure in my workstation Orbit logs.
g
Ah okay, was a hunch. Will keep digging into then 🙂
m
Awesome, thank you!
I do see one issue related to what you mentioned: When running curl.cpp we are getting certificate validation errors, which suggests some of these systems may not have the necessary certs to run some of these queries.
Not sure if this would affect network-based queries, but thought it was worth mentioning.
But I do see the interfaces query working on hosts where curl fails, so this appears to be a separate issue.