kitzyandAllen Houchins
7837b8ec8f
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** #50020 # What this does Adds **AOMEI Backupper Standard** as a Windows Fleet-maintained app. One of the 11 apps split out of #48501 that failed the FMA validator; #50016 shipped the 6 that passed. ## Why it was failing Install and detection were already fine on the SYSTEM-context Windows runner — the validator installed it and osquery found `AOMEI Backupper` 8.4.0. **Uninstall** was the failure: ``` ERROR msg="Error uninstalling app: exit status 1" app="AOMEI Backupper Standard" ERROR msg="Output: Uninstaller for 'AOMEI Backupper Standard' not found." ``` AOMEI unified the ARP `DisplayName` across editions around v7.4 — the registry entry reads `AOMEI Backupper`, with no `Standard` suffix. The uninstall script searched for the catalog name and matched nothing. `unique_identifier` was already corrected to `AOMEI Backupper`; this fixes the uninstall script to match. ## Notes - **Edition matching.** `AOMEI Backupper` also matches the paid Pro/Workstation/Server editions — AOMEI shares the DisplayName across editions and no registry value distinguishes them. Detecting the free edition specifically isn't possible from inventory. - **Non-pinned installer URL.** `https://www2.aomeisoftware.com/download/adb/AOMEIBackupperStd.exe` is a "latest" URL, so the pinned SHA will drift when AOMEI ships a new build until the FMA auto-update bumps it. - x86-only installer, so it lands in `C:\Program Files (x86)`. The validator's "no changes detected in `C:\Program Files`" line is an expected warning, not a failure. # Checklist for submitter - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] FMA CI validator (install → detect → uninstall) **passes** on the SYSTEM-context Windows runner — [run 30383902487](https://github.com/fleetdm/fleet/actions/runs/30383902487) (`All checks passed`) - [x] Generated output verified locally: manifest SHA matches the winget manifest, exists/patched queries reviewed for name + publisher correctness, `apps.json` is valid JSON with a description filled in. - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added **AOMEI Backupper Standard** (version **8.4.0.0.0**) to the Windows software catalog, including verified installer download (SHA-256). - Introduced dedicated silent **install** and **uninstall** support, with version gating and idempotent uninstall behavior when the app isn’t present. - Added a **new software icon** and updated the listing so the correct icon now appears for this product. <!-- 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!