2db26cd44e
Closes: #14847 Changes: - Added two new pages: - `/try-fleet/explore-data`: A page where users can select a host, and be taken to a page where they can see query results for that host. - `try-fleet/explore-data/:platformName/:tableName`: A page where users can see the contents of osquery tables on hosts. - The view-action for this page will: - Redirect unauthenticated users to the /try-fleet/login page. (With a query parameter that will tell the login/register pages to redirect users back to this page) - Get information for hosts on a specified team. - Build a filtered list of osquery tables that are compatible with the host and have queries that will run on a specified host. - Get the latest query results for a specified query/osquery table for the specified host, and reorder the results to match the order of the columns in the osquery schema. - Updated build-static-content to add information about osquery tables for the /explore-data pages to `sails.config.builtStaticContent.osqueryTables`. - Added 5 new config variables: - `sails.config.custom.fleetBaseUrlForQueryReports`: The URL of the Fleet instance used for the /explore-data pages - `sails.config.custom.fleetTokenForQueryReports`: An API token for the Fleet instance used for the /explore-data pages - `sails.config.custom.teamApidForQueryReports`: the API ID of the team that the hosts listed on the explore-data page are in. - `sails.config.custom.queryIdsByTableName`: A dictionary containing key:value pairs where each key is the name of an osquery table, and the value is the API ID of the query that gets results for this table in a Fleet instance. This is stored in the custom configuration to make it easily editable (If we ever need to add or remove queries - `sails.config.custom.hostIdsByHostPlatform`: A dictionary containing key:value pairs where each key is a type of operating system, and the value is the API ID of a Host. - Updated the `/try-fleet` redirect to go to `/try-fleet/explore-data` - Updated the "try it out" button links to go to `/try-fleet` - Updated /try-fleet/login and /try-fleet/register to send users who are redirected to the page via the /explore-data page to the page they had tried to navigate to when they log in/create an account. I'm creating this as a PR as a draft. It will be ready to merge when we: - [x] Add hosts to the "Explore data (fleetdm.com) [DO NOT DELETE]" team - [x] Create queries for every compatible osquery table for the "Explore data (fleetdm.com) [DO NOT DELETE]" team. - [ ] Add a `sails.config.custom.queryIdsByTableName` config variable with the query IDs for the queries created in the previous step - [ ] Add `sails.config.custom.hostIdsByHostPlatform` config variable with the real host IDs/platforms |
||
|---|---|---|
| .. | ||
| api | ||
| assets | ||
| config | ||
| generators/landing-page | ||
| scripts | ||
| tasks | ||
| views | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc | ||
| .gitignore | ||
| .htmlhintrc | ||
| .lesshintrc | ||
| .npmrc | ||
| .sailsrc | ||
| app.js | ||
| Gruntfile.js | ||
| package.json | ||
| Procfile | ||
| README.md | ||
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, click here.
Testing locally
Run the following commands to test the site locally:
npm install -g sails
cd website/
npm install
sails run scripts/build-static-content.js
sails lift
Your local copy of the website is now running at http://localhost:2024!
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!