hey all - thanks again for your work on this great app! Looking for some feedback. My use case is such that within an organization, there are multiple teams that we want to make use of Stethoscope. However, there are different "checklists" or "profiles" for each of these teams. Rather than deploying multiple different builds of Stethoscope, we would like to deploy one build and allow the user to select the relevant checklist:
When the app initially launches, a popup is displayed, and the user is asked to select a checklist:
Other. Selecting the
Other option would allow the user to key in a unique code given to them by their team. Once the code has been entered and is found to be valid, the app will assess the device based on the team’s unique requirements.
From a technical perspective, Stethoscope would connect to an API and:
-Confirm that the code is valid
-Download and store the checklist definitions for the code
osqueryreplacement) today, published it as a public npm package (
kmd-script), and merged the changes into master. The new version is significantly faster and much more stable. You can review the
kmdsource here: https://github.com/Netflix-Skunkworks/kmd. Please let us know if you have any questions or run into any issues. I'll work on updating the documentation for
kmdin the coming weeks to help you get started writing your own. More good news: we should be able to support Linux soon now that we aren't relying on osquery's chosen methods of deriving system info (many of which require root).
Hi @defenseindepth, glad the new version ran for you! Sure, I'd be happy to provide more context.
TLDR; in our setup, osquery was far more trouble than it was worth.
The first iteration of Stethoscope+osquery was shelling out to
osqueryi for each request (e.g.
osqueryi --json "select * from sharing_preferences"). This provided a fair amount of app stability and data collection reliability, the only problem was resource utilization from spinning up new shells - this was especially problematic on Windows. After engaging with the osquery community, it was recommended that we switch to launching
osqueryd in ephemeral mode when the app starts and utilizing the Thrift socket that is made available for extensions. I was able to get this working after reverse-engineering Node thrift (no real documentation to speak of), but the connection code was super sketchy and once we deployed it we were getting reports of it randomly failing in the wild. After supporting the osqueryd/thrift based setup for 7-8 months, it was becoming obvious that the thrift connection was not reliable and extremely difficult to debug/reproduce issues.
In addition to these technical issues, osquery was not really providing the level of platform abstraction we hoped it would. We had to maintain separate query sets for different platforms (as well as a set of bash/ps scripts for the data osquery doesn't cover), and the results for some of the queries that do work cross-platform were not normalized.
I'm sure osquery works great for "typical" deployments where you just need the queries to run eventually and processes can respawn as needed, but it was not working as well in our on-demand setup.
The vast majority of the system info we care about can be easily found using bash/powershell, so we wrote a little scripting language (
kmd) to make parsing and extracting data from stdout easier.
Some of the benefits to this approach:
Posting my recent experiences with cross-platform builds for Stethoscope-app, in case it helps anyone else:
The Docker-based build suggested here works for Windows and Linux, and should probably be the preferred build option for those platforms: https://www.electron.build/multi-platform-build#build-electron-app-using-docker-on-a-local-machine.
MacOS builds still require a native MacOS machine for DMG build targets, as
electron-builder shells out to
hdiutil, a MacOS binary.
Windows code-signing is still best done via Virtualbox VM, with Stethoscope mounted as a Shared Folder, and using
We're trying to implement the dockerised backed with Jamf but are running into issues when the application is trying to fetch the device details off the user record in Jamf.
The error message is:
[2020-02-19 09:38:27.059517 ERROR stethoscope.api.utils] /code/stethoscope/api/utils.py:59 [get_devices_by_email] failed to retrieve data for 'jamf(email@example.com)': [Failure instance: Traceback: <class 'TypeError'>: the JSON object must be str, not 'bytes' /usr/local/lib/python3.4/site-packages/treq/client.py:61:connectionLost /usr/local/lib/python3.4/site-packages/treq/content.py:36:connectionLost /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:459:callback /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:567:_startRunCallbacks --- <exception caught here> --- /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:653:_runCallbacks /usr/local/lib/python3.4/json/__init__.py:312:loads ]
Have anyone encountered this before of know of a fix?
- name: Google Chrome assertion: ALWAYS paths: win32: HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
paths, but it might help to add something like
platform: win32: ">=81.0.4044"