chore: dump sql schema

.github/ISSUE_TEMPLATE/feature-request.md

@@ -2,7 +2,7 @@
 name: 💡  Feature request
 about: Propose a new feature or enhancement in Fleet.
 title: ''
-labels: '~feature fest,:product'
+labels: ':product'
 assignees: ''
 
 ---

.github/workflows/check-tuf-timestamps.yml

@@ -6,7 +6,7 @@ on:
       - '.github/workflows/check-tuf-timestamps.yml'
   workflow_dispatch: # Manual
   schedule:
-    - cron: '0 10 * * *'
+    - cron: '0 10,22 * * *'
 
 # This allows a subsequently queued workflow run to interrupt previous runs
 concurrency:
@@ -38,7 +38,7 @@ jobs:
       run: |
         expires=$(curl -s http://tuf.fleetctl.com/timestamp.json | jq -r '.signed.expires' | cut -c 1-10)
         today=$(date "+%Y-%m-%d")
-        warning_at=$(date -d "$today + 2 day" "+%Y-%m-%d")
+        warning_at=$(date -d "$today + 4 day" "+%Y-%m-%d")
         expires_sec=$(date -d "$expires" "+%s")
         warning_at_sec=$(date -d "$warning_at" "+%s")
         

.github/workflows/render-deploy.yml

@@ -0,0 +1,48 @@
+name: Render deploy
+
+# Re-deploy Fleet servers on Render to update to the latest Fleet release.
+#
+# Render (https://render.com/) is hosting 2 Fleet servers that are used by our gitops repos:
+# - https://github.com/fleetdm/fleet-gitops
+# - https://gitlab.com/fleetdm/fleet-gitops
+#
+# The premium server (fleet-gitops-ci-premium) is used by GitHub CI and the free server (fleet-gitops-ci-free) is used by GitLab CI.
+# Both servers share a MySQL service (fleet-gitops-ci-mysql).
+# - fleet-gitops-ci-premium uses fleet database
+# - fleet-gitops-ci-free uses fleet_free database
+#
+# Both servers share a Redis service (fleet-gitops-ci-redis).
+# - fleet-gitops-ci-premium uses database 0 (the default)
+# - fleet-gitops-ci-free uses database 1
+
+on:
+  workflow_dispatch: # Manual
+  schedule:
+    - cron: '0 2 * * *' # Nightly 2AM UTC
+
+# This allows a subsequently queued workflow run to interrupt previous runs
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id}}
+  cancel-in-progress: true
+
+defaults:
+  run:
+    # fail-fast using bash -eo pipefail. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
+    shell: bash
+
+permissions:
+  contents: read
+
+jobs:
+  render-deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Harden Runner
+        uses: step-security/harden-runner@63c24ba6bd7ba022e95695ff85de572c04a18142 # v2.7.0
+        with:
+          egress-policy: audit
+
+      - name: Trigger deploy
+        run: |
+          curl "${{ secrets.RENDER_GITOPS_FREE_DEPLOY_HOOK }}"
+          curl "${{ secrets.RENDER_GITOPS_PREMIUM_DEPLOY_HOOK }}"

.github/workflows/test-go.yaml

@@ -44,7 +44,7 @@ jobs:
       matrix:
         suite: ["integration", "core"]
         os: [ubuntu-latest]
-        mysql: ["mysql:8.0.36", "mysql:8.4.2"] # make sure to update supported versions docs when this changes
+        mysql: ["mysql:8.0.36", "mysql:8.4.3"] # make sure to update supported versions docs when this changes
     continue-on-error: ${{ matrix.suite == 'integration' }} # Since integration tests have a higher chance of failing, often for unrelated reasons, we don't want to fail the whole job if they fail
     runs-on: ${{ matrix.os }}
 

articles/puppet-module.md

@@ -20,7 +20,7 @@ Install [Fleet's Puppet module](https://forge.puppet.com/modules/fleetdm/fleetdm
 
 ### Step 2: configure Puppet to talk to Fleet using Heira
 
-1. In Fleet, create an API-only user with the global admin role. Instructions for creating an API-only user are [here](./fleetctl-CLI.md#create-an-api-only-user).
+1. In Fleet, create an API-only user with the GitOps role. Instructions for creating an API-only user are [here](./fleetctl-CLI.md#create-an-api-only-user).
 
 2. Get the API token for your new API-only user. Learn how [here](./fleetctl-CLI.md#get-the-api-token-of-an-api-only-user).
 

articles/seamless-mdm-migration.md

@@ -1,20 +1,20 @@
-# Seamless MDM migrations to Fleet
+# Seamless macOS MDM migration
 
-![Seamless MDM migrations to Fleet](../website/assets/images/articles/seamless-mdm-migration-1600x900@2x.png)
+![Seamless macOS MDM migrations to Fleet](../website/assets/images/articles/seamless-mdm-migration-1600x900@2x.png)
 
 Migrating macOS devices between Mobile Device Management (MDM) solutions is often fraught with challenges, including potential gaps in device management, user disruption, and compliance issues. Traditional MDM migrations typically require end-user interaction and leave devices unmanaged for a period, leading to problems like Wi-Fi disconnections due to certificate profile removal and incomplete migrations. These challenges can force organizations to stay with outdated MDM solutions that no longer meet their needs. But there’s a better way.
 
 Seamless MDM migrations are now possible, allowing organizations to transition their macOS devices to Fleet without any downtime or end-user involvement. By leveraging Fleet, you can ensure that your devices remain fully managed and compliant throughout the migration process. This means no more gaps in management, no user disruptions, and a smoother path to a more modern and effective MDM solution.
 
-This guide will walk you through the entire process of migrating your MDM deployment to Fleet. You’ll start by understanding the specific requirements for a seamless migration, followed by configuring Fleet with the necessary certificates and database records. The guide will then take you through the process of installing Fleet’s agent (`fleetd`) on your devices, updating DNS records to redirect devices to the Fleet server, and finally, decommissioning your old MDM server.
+This guide will walk you through the entire process of migrating your MDM deployment to Fleet. You’ll start by understanding the specific requirements for a seamless migration, followed by configuring Fleet with the necessary certificates and database records. The guide will then take you through the process of installing Fleet’s agent (`fleetd`) on your devices, updating domain (DNS) records to redirect devices to the Fleet server, and finally, decommissioning your old MDM server.
 
 Throughout the guide, you’ll find practical advice and best practices to ensure a smooth transition with minimal risk. By the end, you’ll be equipped with the knowledge and tools to execute a seamless MDM migration to Fleet, ensuring that your organization’s devices are securely managed without the typical headaches associated with a traditional MDM switch.
 
 ## Requirements
 
-Note: Deployments that do not meet these seamless migration requirements can still migrate with the [standard MDM migration process](https://fleetdm.com/docs/using-fleet/mdm-migration-guide).
+> Deployments that do not meet these seamless migration requirements can still migrate with the [standard MDM migration process](https://fleetdm.com/docs/using-fleet/mdm-migration-guide).
 
-* Customer controls the DNS used in the MDM server enrollment (eg. devices are enrolled to `*.customerowneddomain.com`, not `*.mdmvendor.com`).
+* Customer owns the domain (DNS) used in the MDM enrollment profile (e.g. devices are enrolled to `*.customerowneddomain.com`, not `*.mdmvendor.com`).
 * Customer has access to the Apple Push Notification Service (APNS) certificate/key and SCEP certificate/key, or access to the MDM server database to extract these values.
 
 These requirements are easily met in self-hosted open-source MDM solutions and may be met with commercial solutions when the customer is self-hosting or otherwise controls the DNS.
@@ -31,7 +31,7 @@ Apple allows changing most values in profiles delivered by MDM, but the `ServerU
 2. Import database records letting Fleet know about the devices to be migrated.
 3. Configure controls (profiles, updates, etc.) in Fleet.
 4. Install `fleetd` on the devices (through the existing MDM).
-5. Update DNS records to point devices to the Fleet server.
+5. Update domain (DNS) records to point devices to the Fleet server.
 6. Decommission the old server.
 
 It is recommended to follow the entire process on a staging/test MDM instance and devices, then repeat for the production instance and devices.

articles/windows-mdm-setup.md

@@ -4,7 +4,7 @@
 
 To control OS settings, updates, and more on Windows hosts follow the manual enrollment instructions.
 
-To use automatic enrollment (aka zero-touch) features on Windows, follow instructions to connect Fleet to Microsoft Azure Active Directory (aka Microsoft Entra). You can further customize zero-touch with Windows Autopilot.
+To use automatic enrollment (aka zero-touch) features on Windows, follow instructions to connect Fleet to Microsoft Entra ID. You can further customize zero-touch with Windows Autopilot.
 
 ## Manual enrollment
 
@@ -34,7 +34,7 @@ Restart the Fleet server.
 
 ### Step 3: Turn on Windows MDM
 
-1. Head to the **Settings > Integrations > Mobile device management (MDM) enrollment** page.
+1. Head to the **Settings > Integrations > Mobile device management (MDM)** page.
 
 2. Next to **Turn on Windows MDM** select **Turn on** to navigate to the **Turn on Windows MDM** page.
 
@@ -48,13 +48,13 @@ With Windows MDM turned on, enroll a Windows host to Fleet by installing [Fleet'
 
 > Available in Fleet Premium
 
-To automatically enroll Windows workstations when they’re first unboxed and set up by your end users, we will connect Fleet to Microsoft Azure Active Directory (Azure AD).
+To automatically enroll Windows workstations when they’re first unboxed and set up by your end users, we will connect Fleet to Microsoft Entra ID.
 
-After you connect Fleet to Azure AD, you can customize the Windows setup experience with [Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/windows-autopilot).
+After you connect Fleet to Microsoft Entra ID, you can customize the Windows setup experience with [Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/windows-autopilot).
 
-In order to connect Fleet to Azure AD, the IT admin (you) needs a Microsoft Enterprise Mobility + Security E3 license. 
+In order to connect Fleet to Microsoft Entra ID, the IT admin (you) needs a Microsoft Enterprise Mobility + Security E3 license. 
 
-Each end user who automatically enrolls needs a Microsoft Intune license.
+Each end user who automatically enrolls needs a [Microsoft license](https://learn.microsoft.com/en-us/mem/intune/fundamentals/licenses.)
 
 ### Step 1: Buy Microsoft licenses
 
@@ -68,25 +68,25 @@ Each end user who automatically enrolls needs a Microsoft Intune license.
 
 5. On the **Enterprise Mobility + Security E3** page, select **Buy** and follow instructions to purchase the license. 
 
-6. Find and buy an Intune license.
+6. Find and buy a license.
 
-7. Sign in to [Azure portal](https://portal.azure.com).
+7. Sign in to [Microsoft Entra ID portal](https://portal.azure.com).
 
 8. At the top of the page search "Users" and select **Users**.
 
 9. Select or create a test user and select **Licenses**.
 
 10. Select **+ Assignments** and assign yourself the **Enterprise Mobility + Security E3**. Assign the test user the Intune licnese.
 
-### Step 2: Connect Fleet to Azure AD
+### Step 2: Connect Fleet to Microsoft Entra ID
 
-For instructions on how to connect Fleet to Azure AD, in the Fleet UI, select the avatar on the right side of the top navigation and select **Settings > Integrations > Automatic enrollment**. Then, next to **Windows automatic enrollment** select **Details**.
+For instructions on how to connect Fleet to Microsoft Entra ID, in the Fleet UI, select the avatar on the right side of the top navigation and select **Settings > Integrations > Mobile device management (MDM)**. Then, next to **Windows automatic enrollment** select **Details**.
 
 ### Step 3: Test automatic enrollment
 
-Testing automatic enrollment requires creating a test user in Azure AD and a freshly wiped or new Windows workstation.
+Testing automatic enrollment requires creating a test user in Microsoft Entra ID and a freshly wiped or new Windows workstation.
 
-1. Sign in to [Azure portal](https://portal.azure.com).
+1. Sign in to [Microsoft Entra ID portal](https://portal.azure.com).
 
 2. At the top of the page search "Users" and select **Users**.
 
@@ -124,7 +124,7 @@ Testing automatic enrollment requires creating a test user in Azure AD and a fre
 
 ### Step 3: Upload your organization's logo
 
-1. Navigate to [Azure portal](https://portal.azure.com).
+1. Navigate to [Microsoft Entra ID portal](https://portal.azure.com).
 
 2. At the top of the page, search for "Microsoft Entra ID", select **Microsoft Entra ID**, and then select **Company branding**.
 

changes/22331-remove-pending-devices

@@ -0,0 +1 @@
+Remove a pending MDM device if it was deleted from current ABM

changes/23174-fix-patch-config-vpp-associations

@@ -0,0 +1 @@
+* Fixed bug where `PATCH /api/latest/fleet/config` was incorrectly clearing VPP token<->team associations.

changes/23183-opentelemetry

@@ -0,0 +1,3 @@
+Updated OpenTelemetry libraries to latest versions. This includes the following changes when OpenTelemetry is enabled:
+- MySQL spans outside of HTTPS transactions are now logged.
+- Renamed MySQL spans to include the query, for easier tracking/debugging.

changes/23215-message-spacing

@@ -0,0 +1 @@
+* Explicitly set line heights on "add profile" messages so they are consistent cross-browser

changes/23219

@@ -0,0 +1 @@
+* Make entire rows of the Disk encryption table clickable

changes/urf-8

@@ -0,0 +1 @@
+* Fixed incorrect character set header on manual Mac enrollment config download

cmd/fleet/serve_test.go

@@ -307,6 +307,7 @@ func TestAutomationsSchedule(t *testing.T) {
 }
 
 func TestCronVulnerabilitiesCreatesDatabasesPath(t *testing.T) {
+	t.Skip() // https://github.com/fleetdm/fleet/issues/23258
 	t.Parallel()
 	ctx, cancelFunc := context.WithCancel(context.Background())
 	defer cancelFunc()
@@ -352,10 +353,15 @@ func TestCronVulnerabilitiesCreatesDatabasesPath(t *testing.T) {
 	}
 	// Use schedule to test that the schedule does indeed call cronVulnerabilities.
 	ctx = license.NewContext(ctx, &fleet.LicenseInfo{Tier: fleet.TierPremium})
+	ctx, cancel := context.WithCancel(ctx)
 	lg := kitlog.NewJSONLogger(os.Stdout)
 	s, err := newVulnerabilitiesSchedule(ctx, "test_instance", ds, lg, &config)
 	require.NoError(t, err)
 	s.Start()
+	t.Cleanup(func() {
+		cancel()
+		<-s.Done()
+	})
 
 	assert.Eventually(t, func() bool {
 		info, err := os.Lstat(vulnPath)
@@ -660,9 +666,14 @@ func TestCronVulnerabilitiesSkipMkdirIfDisabled(t *testing.T) {
 
 	// Use schedule to test that the schedule does indeed call cronVulnerabilities.
 	ctx = license.NewContext(ctx, &fleet.LicenseInfo{Tier: fleet.TierPremium})
+	ctx, cancel := context.WithCancel(ctx)
 	s, err := newVulnerabilitiesSchedule(ctx, "test_instance", ds, kitlog.NewNopLogger(), &config)
 	require.NoError(t, err)
 	s.Start()
+	t.Cleanup(func() {
+		cancel()
+		<-s.Done()
+	})
 
 	// Every cron tick is 10 seconds ... here we just wait for a loop interation and assert the vuln
 	// dir. was not created.
@@ -1117,7 +1128,8 @@ func TestVerifyDiskEncryptionKeysJob(t *testing.T) {
 		fleet.MDMAssetCAKey:  {Value: testKeyPEM},
 	}
 	ds.GetAllMDMConfigAssetsByNameFunc = func(ctx context.Context, assetNames []fleet.MDMAssetName,
-		_ sqlx.QueryerContext) (map[fleet.MDMAssetName]fleet.MDMConfigAsset, error) {
+		_ sqlx.QueryerContext,
+	) (map[fleet.MDMAssetName]fleet.MDMConfigAsset, error) {
 		return assets, nil
 	}
 	ds.AppConfigFunc = func(ctx context.Context) (*fleet.AppConfig, error) {

cmd/fleetctl/generate.go

@@ -49,24 +49,24 @@ func generateMDMAppleCommand() *cli.Command {
 			// before printing the CSR output message.
 			client, err := clientFromCLI(c)
 			if err != nil {
-				fmt.Fprintf(c.App.ErrWriter, "client from CLI: %s", err)
+				fmt.Fprintf(c.App.ErrWriter, "client from CLI: %s\n", err)
 				return ErrGeneric
 			}
 
 			csr, err := client.RequestAppleCSR()
 			if err != nil {
-				fmt.Fprintf(c.App.ErrWriter, "requesting APNs CSR: %s", err)
+				fmt.Fprintf(c.App.ErrWriter, "requesting APNs CSR: %s\n", err)
 				return ErrGeneric
 			}
 
 			if err := os.WriteFile(csrPath, csr, defaultFileMode); err != nil {
-				fmt.Fprintf(c.App.ErrWriter, "write CSR: %s", err)
+				fmt.Fprintf(c.App.ErrWriter, "write CSR: %s\n", err)
 				return ErrGeneric
 			}
 
 			appCfg, err := client.GetAppConfig()
 			if err != nil {
-				fmt.Fprintf(c.App.ErrWriter, "fetching app config: %s", err)
+				fmt.Fprintf(c.App.ErrWriter, "fetching app config: %s\n", err)
 				return ErrGeneric
 			}
 

cmd/fleetctl/gitops.go

@@ -86,8 +86,13 @@ func gitopsCommand() *cli.Command {
 				noTeamControls spec.Controls
 				noTeamPresent  bool
 			)
+			isPremium := appConfig.License.IsPremium()
 			for _, flFilename := range flFilenames.Value() {
 				if filepath.Base(flFilename) == "no-team.yml" {
+					if !isPremium {
+						// Message is printed in the next flFilenames loop to avoid printing it multiple times
+						break
+					}
 					baseDir := filepath.Dir(flFilename)
 					config, err := spec.GitOpsFromFile(flFilename, baseDir, appConfig, func(format string, a ...interface{}) {})
 					if err != nil {
@@ -148,13 +153,16 @@ func gitopsCommand() *cli.Command {
 					if !config.Controls.Set() {
 						config.Controls = noTeamControls
 					}
+				} else if !isPremium {
+					logf("[!] skipping team config %s since teams are only supported for premium Fleet users\n", flFilename)
+					continue
 				}
 
 				// Special handling for tokens is required because they link to teams (by
 				// name.) Because teams can be created/deleted during the same gitops run, we
 				// grab some information to help us determine allowed/restricted actions and
 				// when to perform the associations.
-				if isGlobalConfig && totalFilenames > 1 && !(totalFilenames == 2 && noTeamPresent) {
+				if isGlobalConfig && totalFilenames > 1 && !(totalFilenames == 2 && noTeamPresent) && isPremium {
 					abmTeams, hasMissingABMTeam, usesLegacyABMConfig, err = checkABMTeamAssignments(config, fleetClient)
 					if err != nil {
 						return err