Allen Houchins
f96cb9d6c7
**Related issue:** N/A — part of the ongoing Windows Fleet-maintained apps (FMA) parity workstream (letter I). ## What this does Adds **17** Windows Fleet-maintained apps for the letter-I batch. apps.json descriptions follow the house `"<Name> is a …"` convention. **IBM Semeru Runtime Open Edition (Java) — 8 apps** (MSI, machine, x64): JDK 8/11/17/21 and JRE 8/11/17/21. Per-major detection follows the Eclipse Temurin pattern — `name LIKE 'IBM Semeru Runtime Open Edition (JDK|JRE)%' AND publisher = 'Semeru' AND version LIKE '<major>.%'` — so majors and JDK/JRE never cross-match. All 8 share the IBM Semeru logo. **Other apps (9):** - **IronPython 3** — MSI; fuzzy `IronPython 3%` (excludes the EOL v2) - **ImageGlass** — dual-scope MSI, custom `ALLUSERS=1` install - **install4j** — install4j installer (bundled JRE), `-q` - **IrfanView** — custom installer `/silent /allusers=1`; versioned+arch name → fuzzy `IrfanView%` - **iMazing HEIC Converter**, **IsoBuster**, **ImpExpPro** — Inno Setup (`/VERYSILENT`) - **Infix PDF Editor** — Inno, x86 - **Ibis Calculeren voor Bouw** — InstallShield wrapper; uninstall via the MSI UpgradeCode (`uninstall_type: msi`) ## Dropped from this batch (recorded in the workstream tracker) - **IBM Aspera Connect** — MSI installs per-user by default (`ALLUSERS=2`/`MSIINSTALLPERUSER=1`, no machine switch in the manifest) + a rolling `/latest/` URL that 404s on the next release. - **IcedTea-Web** (Azul and AdoptOpenJDK) — both declare a hard, unbundled JRE dependency; it's a JNLP launcher that's dead-on-arrival without Java the FMA won't install (AdoptOpenJDK variant is also archived). - **IronPython 2** — EOL (Python 2). **install4j 9** — legacy 2022 build. **IrfanView PlugIns** — add-on that drops DLLs with no independent ARP entry (undetectable) and depends on the base app. - **Intermedia Unite** and its **Teams Desktop Plugin** — both use non-versioned "latest" URLs (winget-bot auto-updated; the pinned SHA rots each release); the plugin also depends on Teams + Unite. ## Notes - **Ibis Calculeren voor Bouw**, **ImpExpPro**, and **Infix PDF Editor** ship without a catalog icon — no clean ≥256px first-party logo exists for these niche apps (they fall back to the generic icon). - **Ibis** carries some risk: its DisplayName couldn't be verified offline (compressed InstallShield payload) and its installer URL is non-versioned — flagging for the validator; will drop if detection/version fails. - **IsoBuster** uses a non-versioned URL that currently matches the pinned 5.8, so no `ignore_hash`; winget re-ingestion tracks future drift. - Verification (installer type/scope/arch, ProductCode/UpgradeCode, dependencies, silent switches, URL stability, en-US locale) was done per the `new-fma` skill against the winget-pkgs manifests, with several DisplayNames confirmed via `innoextract`/`msitools`. ## Testing - [ ] FMA CI validator (install → detect → uninstall) on the SYSTEM-context Windows runner — pending. - Generated outputs verified locally: all 17 produce valid manifests; per-major Semeru queries and MSI UpgradeCode uninstalls confirmed; all apps.json descriptions present and convention-compliant.
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!