kitzyandAllen Houchins
3ce3e238ed
**Related issue:** N/A — Windows Fleet-maintained app (FMA) coverage for apps found deployed in a customer's ManageEngine SDP environment but missing from Fleet. ## What this does Adds **6** Windows Fleet-maintained apps — the subset of a larger batch that passes the FMA validator cleanly. Each has a winget-sourced input, a generated output manifest, and a catalog icon. Detection identity was verified against each app's real registry DisplayName; apps whose DisplayName carries a version suffix use fuzzy name matching, the rest match exactly. **MSI (clean, auto upgrade-code uninstall):** - **Git Extensions** — versioned ARP name (`Git Extensions 7.2.0.92`) → fuzzy match - **TightVNC**, **Yarn**, **SonicWall NetExtender** (WiX), **Zoom Outlook Plugin** — clean ARP names → exact match **EXE — NSIS (custom `/S` install + registry-lookup uninstall):** - **Spyder** — versioned ARP name (`Spyder 6`) → fuzzy match ## Notes - **Detection verification.** Every app's `unique_identifier` (registry DisplayName / osquery `programs.name`) and publisher were verified per the `new-fma` skill against winget `AppsAndFeaturesEntries`, MSI Property tables (`msiinfo`), and vendor installer scripts — not assumed. Git Extensions' MSI `ProductName` is `Git Extensions 7.2.0.92` and Spyder's ARP entry is `Spyder 6`, so both need `fuzzy_match_name`; the four exact-match apps were confirmed clean (e.g. TightVNC registers as `TightVNC`, not a versioned string). - **Validated on a real Windows host.** All six pass the FMA CI validator (install → detect → uninstall) on the SYSTEM-context Windows runner. - **Icons.** Git Extensions, SonicWall NetExtender, TightVNC, Yarn, and Zoom Outlook Plugin ship new catalog icons + website assets; Spyder reuses the existing `Spyder` icon. ## Testing - [x] FMA CI validator (install → detect → uninstall) on the SYSTEM-context Windows runner. - Generated outputs verified locally: all 6 produce valid manifests; MSI apps carry the correct UpgradeCode-based uninstall; exists/patched queries reviewed for name + publisher correctness; `go test ./ee/maintained-apps/...` passes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added maintained Windows catalog entries for Git Extensions, SonicWall NetExtender, Spyder, TightVNC, Yarn, and Zoom Outlook Plugin, including silent install, version upgrade detection, and maintenance-ready uninstall flows. * Added new software icons for these apps and expanded icon matching so they display correctly in the catalog. * **Bug Fixes** * Improved Spyder Windows uninstall targeting and command/argument handling for more reliable removals. * **Documentation** * Refreshed Spyder supported version details to 6.1.5. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Allen Houchins <allenhouchins@mac.com>
fleetdm.com
This is where the code for the public https://fleetdm.com website lives.
Bugs
To report a bug or make a suggestion for the website, create an issue in the fleet GitHub repository.
Testing locally
See https://fleetdm.com/handbook/engineering#test-fleetdm-com-locally
Deploying the website
To deploy changes to the website to production, merge changes to the main branch. If the changes affect the website's code, or touch any files that the website relies on to build content, such as the query library, osquery schema, docs, handbook, articles, etc., then the website will be redeployed.
Wondering how this works? This is implemented in a GitHub action in this repo. Check out the code there to see how it works! For help understanding what
sails runandnpm runcommands in there do, check the scripts inwebsite/package.jsonand inwebsite/scripts/.
Changing the database schema
To deploy new code to production that relies on changes to the database schema or other external systems (e.g. Stripe), first put the website in "maintenance mode" in Heroku. Then, make your changes in the database schema. Next, if you have a script to fix/migrate existing data, go ahead and run it now. (e.g. sails run fix-or-migrate-existing-data). Then, merge your changes and wait for the deploy to finish. Finally, switch off "maintenance mode" in Heroku.
Note that entering maintenance mode prevents visitors from using the website, so it should be used sparingly, and ideally at low-traffic times of day.
Warning: Doing an especially sensitive schema migration? There is a potential timing issue to consider, thanks to an infrastructure change that eliminated downtime during deploys by using Heroku's built-in support for hot-swapping. Read more in https://github.com/fleetdm/fleet/issues/6568#issuecomment-1211503881
Wiping the production database
I hope you know what you're doing. The "easiest" kind of database schema migration:
sails_datastores__default__url='REAL_DB_URI_HERE' sails run wipe
Then when you see the sailboat, hit CTRL+C to exit. All done!