Fix content issues for CommonMark migration, part 2 (enterprise) (#42…

…226)

content/admin/backing-up-and-restoring-your-instance/configuring-backups-on-your-instance.md

@@ -93,13 +93,13 @@ Backup snapshots are written to the disk path set by the `GHE_DATA_DIR` data dir
 1. To customize your configuration, edit `backup.config` in a text editor.
    1. Set the `GHE_HOSTNAME` value to your primary {% data variables.product.prodname_ghe_server %} instance's hostname or IP address.
 
-     {% note %}
+      {% note %}
 
-     **Note:** If {% data variables.location.product_location %} is deployed as a cluster or in a high availability configuration using a load balancer, the `GHE_HOSTNAME` can be the load balancer hostname, as long as it allows SSH access (on port 122) to {% data variables.location.product_location %}.
+      **Note:** If {% data variables.location.product_location %} is deployed as a cluster or in a high availability configuration using a load balancer, the `GHE_HOSTNAME` can be the load balancer hostname, as long as it allows SSH access (on port 122) to {% data variables.location.product_location %}.
 
-     To ensure a recovered instance is immediately available, perform backups targeting the primary instance even in a geo-replication configuration.
+      To ensure a recovered instance is immediately available, perform backups targeting the primary instance even in a geo-replication configuration.
 
-     {% endnote %}
+      {% endnote %}
    1. Set the `GHE_DATA_DIR` value to the filesystem location where you want to store backup snapshots. We recommend choosing a location on the same filesystem as your backup host, but outside of where you cloned the Git repository in step 1.
 1. To grant your backup host access to your instance, open your primary instance's settings page at `http(s)://HOSTNAME/setup/settings` and add the backup host's SSH key to the list of authorized SSH keys. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh#enabling-access-to-the-administrative-shell-via-ssh)."
 1. On your backup host, verify SSH connectivity with {% data variables.location.product_location %} with the `ghe-host-check` command.
@@ -143,11 +143,11 @@ If your installation is in a Git repository, you can install the latest version
 ### Upgrading an installation in a Git repository
 
 {% data reusables.enterprise_backup_utilities.enterprise-backup-utils-directory %}
-  {% note %}
+   {% note %}
 
-  **Note:** We recommend creating a copy of your existing `backup.config` file in a temporary location, like `$HOME/backup.config`, before upgrading {% data variables.product.prodname_enterprise_backup_utilities %}.
+   **Note:** We recommend creating a copy of your existing `backup.config` file in a temporary location, like `$HOME/backup.config`, before upgrading {% data variables.product.prodname_enterprise_backup_utilities %}.
 
-  {% endnote %}
+   {% endnote %}
 
 1. Download the latest project updates by running the `git fetch` command.
 

content/admin/configuration/configuring-user-applications-for-your-enterprise/configuring-email-for-notifications.md

@@ -64,11 +64,11 @@ settings to allow incoming emails](#configuring-dns-and-firewall-settings-to-all
 1. Under "Send test email to," type an address to send the test email to.
 1. Click **Send test email**.
 
-  {% tip %}
+   {% tip %}
 
-  **Tip:** If SMTP errors occur while sending a test email—such as an immediate delivery failure or an outgoing mail configuration error—you will see them in the Test email settings dialog box.
+   **Tip:** If SMTP errors occur while sending a test email—such as an immediate delivery failure or an outgoing mail configuration error—you will see them in the Test email settings dialog box.
 
-  {% endtip %}
+   {% endtip %}
 
 1. If the test email fails, [troubleshoot your email settings](#troubleshooting-email-delivery).
 1. When the test email succeeds, under the "Settings" sidebar, click **Save settings**.

content/admin/identity-and-access-management/using-saml-for-enterprise-iam/disabling-saml-single-sign-on-for-your-enterprise.md

@@ -25,7 +25,7 @@ After you disable SAML SSO for your enterprise, the following effects apply:
 
    **Note:** If you're unable to access the enterprise because your IdP is unavailable, you can use a recovery code to bypass SSO. For more information, see "[AUTOTITLE](/admin/identity-and-access-management/managing-recovery-codes-for-your-enterprise/accessing-your-enterprise-account-if-your-identity-provider-is-unavailable)."
 
-  {% endnote %}
+   {% endnote %}
 
 {% data reusables.enterprise-accounts.settings-tab %}
 {% data reusables.enterprise-accounts.security-tab %}

content/admin/installation/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-openstack-kvm.md

@@ -39,7 +39,7 @@ shortTitle: Install on OpenStack
 {% data reusables.enterprise_installation.create-attached-storage-volume %} For instructions, see the OpenStack guide "[Create and manage volumes](https://docs.openstack.org/horizon/latest/user/manage-volumes.html)."
 1. Create a security group, and add a new security group rule for each port in the table below. For instructions, see the OpenStack guide [Configure access and security for instances](https://docs.openstack.org/horizon/latest/user/configure-access-and-security-for-instances.html).
 
-  {% data reusables.enterprise_installation.necessary_ports %}
+   {% data reusables.enterprise_installation.necessary_ports %}
 1. Optionally, associate a floating IP to the instance. Depending on your OpenStack setup, you may need to allocate a floating IP to the project and associate it to the instance. Contact your system administrator to determine if this is the case for you. For more information, see [Allocate a floating IP address to an instance](https://docs.openstack.org/horizon/latest/user/configure-access-and-security-for-instances.html#allocate-a-floating-ip-address-to-an-instance) in the OpenStack documentation.
 1. Launch {% data variables.location.product_location %} using the image, data volume, and security group created in the previous steps. For instructions, see the OpenStack guide [Launch and manage instances](https://docs.openstack.org/horizon/latest/user/launch-instances.html).
 

content/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/managing-projects-using-jira.md

@@ -26,11 +26,11 @@ shortTitle: Project management with Jira
 {% data reusables.user-settings.oauth_apps %}
 1. Click **New {% data variables.product.prodname_oauth_app %}**.
 
-  {% note %}
+   {% note %}
 
-  **Note:** If you haven't created an app before, this button will say, **Register an application**.
+   **Note:** If you haven't created an app before, this button will say, **Register an application**.
 
-  {% endnote %}
+   {% endnote %}
 1. Fill in the application settings:
     - In the **Application name** field, type "Jira" or any name you would like to use to identify the Jira instance.
     - In the **Homepage URL** field, type the full URL of your Jira instance.

content/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks.md

@@ -44,11 +44,12 @@ For example, you can configure {% data variables.location.product_location %} to
 1. Optionally, in the **Secret** field, type a string to use as a `secret` key.
 1. Optionally, if your payload URL is HTTPS and you would not like {% data variables.product.prodname_ghe_server %} to verify SSL certificates when delivering payloads, under "SSL verification", select **Disable**. Read the information about SSL verification, then click **Disable, I understand my webhooks may not be secure**.
 
-  {% warning %}
+   {% warning %}
 
-  **Warning:** SSL verification helps ensure that hook payloads are delivered securely. We do not recommend disabling SSL verification.
+   **Warning:** SSL verification helps ensure that hook payloads are delivered securely. We do not recommend disabling SSL verification.
+
+   {% endwarning %}
 
-  {% endwarning %}
 1. Under "Which events would you like to trigger this webhook?", select if you'd like this webhook to trigger for every event or for selected events.
     - For every event, select **Send me everything**.
     - To choose specific events, select **Let me select individual events**.

content/admin/monitoring-managing-and-updating-your-instance/updating-the-virtual-machine-and-physical-resources/known-issues-with-upgrades-to-your-instance.md

@@ -130,55 +130,55 @@ If you cannot upgrade {% data variables.location.product_location %}, then you c
 
 1. Put your instance into maintenance mode:
 
-  ```shell copy
-  ghe-maintenance -s
-  ```
+   ```shell copy
+   ghe-maintenance -s
+   ```
 1. Update consul template for nomad:
 
-  ```shell copy
-  sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl
-  ```
+   ```shell copy
+   sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl
+   ```
 1. Render consul template for nomad:
 
-  ```shell copy
-  sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl
-  ```
+   ```shell copy
+   sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl
+   ```
 1. Verify current `kill_timeout` setting:
 
-  ```shell copy
-  nomad job inspect mysql | grep KillTimeout
-  ```
+   ```shell copy
+   nomad job inspect mysql | grep KillTimeout
+   ```
 
-  Expected response:
+   Expected response:
 
-  ```shell copy
-  "KillTimeout": 5000000000
-  ```
+   ```shell copy
+   "KillTimeout": 5000000000
+   ```
 1. Stop MySQL:
 
-  ```shell copy
-  nomad job stop mysql
-  ```
+   ```shell copy
+   nomad job stop mysql
+   ```
 1. Run new MySQL job:
 
-  ```shell copy
-  nomad job run /etc/nomad-jobs/mysql/mysql.hcl
-  ```
+   ```shell copy
+   nomad job run /etc/nomad-jobs/mysql/mysql.hcl
+   ```
 1. Verify kill_timeout has been updated:
 
-  ```shell copy
-  nomad job inspect mysql | grep KillTimeout
-  ```
-  Expected response:
+   ```shell copy
+   nomad job inspect mysql | grep KillTimeout
+   ```
+   Expected response:
 
-  ```shell copy
-  "KillTimeout": 600000000000,
-  ```
+   ```shell copy
+   "KillTimeout": 600000000000,
+   ```
 1. Take instance out of maintenance mode:
 
-  ```shell copy
-  ghe-maintenance -u
-  ```
+   ```shell copy
+   ghe-maintenance -u
+   ```
 
 Now that the nomad timeout for MySQL has been updated you can upgrade your {% data variables.product.prodname_ghe_server %} instance to 3.9.
 

content/admin/monitoring-managing-and-updating-your-instance/updating-the-virtual-machine-and-physical-resources/upgrading-github-enterprise-server.md

@@ -42,20 +42,20 @@ To prepare for an upgrade, plan the upgrade path, optionally upgrade {% data var
 1. Determine an upgrade strategy and choose a version to upgrade to. For more information, see "[AUTOTITLE](/admin/enterprise-management/updating-the-virtual-machine-and-physical-resources/upgrade-requirements)" and refer to the [{% data variables.enterprise.upgrade_assistant %}](https://support.github.com/enterprise/server-upgrade) to find the upgrade path from your current release version.
 1. Create a fresh backup of your instance's primary node with the {% data variables.product.prodname_enterprise_backup_utilities %}. For more information, see the [README](https://github.com/github/backup-utils#readme) in the {% data variables.product.prodname_enterprise_backup_utilities %} project documentation.
 
-  {% note %}
+   {% note %}
 
-  **Note:** Your {% data variables.product.prodname_enterprise_backup_utilities %} version needs to be the same version as, or at most two versions ahead of, {% data variables.location.product_location %}. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance#upgrading-github-enterprise-server-backup-utilities)."
+   **Note:** Your {% data variables.product.prodname_enterprise_backup_utilities %} version needs to be the same version as, or at most two versions ahead of, {% data variables.location.product_location %}. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance#upgrading-github-enterprise-server-backup-utilities)."
 
-  {% endnote %}
+   {% endnote %}
 
 1. If {% data variables.location.product_location %} uses ephemeral self-hosted runners for {% data variables.product.prodname_actions %} and you've disabled automatic updates, upgrade your runners to the version of the runner application that your upgraded instance will run.
 1. If you are upgrading using an upgrade package, schedule a maintenance window for {% data variables.product.prodname_ghe_server %} end users. If you are using a hotpatch, maintenance mode is not required.
 
-  {% note %}
+   {% note %}
 
-  **Note:** The maintenance window depends on the type of upgrade you perform. Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time. Following the versioning scheme of MAJOR.FEATURE.PATCH, patch releases using an upgrade package typically require less than five minutes of downtime. Feature releases that include data migrations take longer depending on storage performance and the amount of data that's migrated. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
+   **Note:** The maintenance window depends on the type of upgrade you perform. Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time. Following the versioning scheme of MAJOR.FEATURE.PATCH, patch releases using an upgrade package typically require less than five minutes of downtime. Feature releases that include data migrations take longer depending on storage performance and the amount of data that's migrated. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
 
-  {% endnote %}
+   {% endnote %}
 
 ## Taking a snapshot
 
@@ -68,13 +68,13 @@ There are two types of snapshots:
 - **VM snapshots** save your entire VM state, including user data and configuration data. This snapshot method requires a large amount of disk space and is time consuming.
 - **Data disk snapshots** only save your user data.
 
-  {% note %}
+   {% note %}
 
-  **Notes:**
-  - Some platforms don't allow you to take a snapshot of just your data disk. For these platforms, you'll need to take a snapshot of the entire VM.
-  - If your hypervisor does not support full VM snapshots, you should take a snapshot of the root disk and data disk in quick succession.
+   **Notes:**
+    - Some platforms don't allow you to take a snapshot of just your data disk. For these platforms, you'll need to take a snapshot of the entire VM.
+    - If your hypervisor does not support full VM snapshots, you should take a snapshot of the root disk and data disk in quick succession.
 
-  {% endnote %}
+   {% endnote %}
 
 | Platform | Snapshot method | Documentation |
 |---|---|---|
@@ -190,11 +190,11 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
 {% data reusables.enterprise_installation.download-package %}
 1. Enable maintenance mode and wait for all active processes to complete on the {% data variables.product.prodname_ghe_server %} instance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
 
-  {% note %}
+   {% note %}
 
-  **Note**: When upgrading the primary node in a high availability configuration, the instance should already be in maintenance mode if you are following the instructions in "[Upgrading the primary node](#upgrading-the-primary-node)."
+   **Note**: When upgrading the primary node in a high availability configuration, the instance should already be in maintenance mode if you are following the instructions in "[Upgrading the primary node](#upgrading-the-primary-node)."
 
-  {% endnote %}
+   {% endnote %}
 
 1. Run the `ghe-upgrade` command using the package file name:
 
@@ -205,13 +205,13 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
 
 1. Confirm that you'd like to continue with the upgrade and restart after the package signature verifies. The new root filesystem writes to the secondary partition and the instance automatically restarts in maintenance mode:
 
-  ```shell
-  *** applying update...
-  This package will upgrade your installation to version VERSION-NUMBER
-  Current root partition: /dev/xvda1 [VERSION-NUMBER]
-  Target root partition:  /dev/xvda2
-  Proceed with installation? [y/N]
-  ```
+   ```shell
+   *** applying update...
+   This package will upgrade your installation to version VERSION-NUMBER
+   Current root partition: /dev/xvda1 [VERSION-NUMBER]
+   Target root partition:  /dev/xvda2
+   Proceed with installation? [y/N]
+   ```
 
 {%- ifversion ghe-migrations-cli-utility %}
 1. Optionally, during an upgrade to a feature release, you can monitor the status of database migrations using the `ghe-migrations` utility. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-migrations)."
@@ -227,11 +227,11 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
 {% endif %}
 1. For single node upgrades, disable maintenance mode so users can use {% data variables.location.product_location %}.
 
-  {% note %}
+   {% note %}
 
-  **Note**: After you upgrade an instance in a high availability configuration, you should remain in maintenance mode until you have upgraded all of the replica nodes and replication is current. For more information, see "[Upgrading additional nodes with an upgrade package](#upgrading-additional-nodes-with-an-upgrade-package)."
+   **Note**: After you upgrade an instance in a high availability configuration, you should remain in maintenance mode until you have upgraded all of the replica nodes and replication is current. For more information, see "[Upgrading additional nodes with an upgrade package](#upgrading-additional-nodes-with-an-upgrade-package)."
 
-  {% endnote %}
+   {% endnote %}
 
 ### Upgrading an instance with multiple nodes using an upgrade package
 

content/billing/managing-your-license-for-github-enterprise/troubleshooting-license-usage-for-github-enterprise.md

@@ -88,9 +88,10 @@ To ensure that the each user is only consuming a single seat for different deplo
 
    {% note %}
 
-  **Note:** To make troubleshooting easier, we recommend using verified domains with your enterprise account on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise)."
+   **Note:** To make troubleshooting easier, we recommend using verified domains with your enterprise account on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise)."
+
+   {% endnote %}
 
-  {% endnote %}
 1. After you identify users who are consuming multiple seats, make sure that the same email address is associated with all of the user's accounts. For more information about which email addresses must match, see "[About the calculation of consumed licenses](#about-the-calculation-of-consumed-licenses)."
 1. If an email address was recently updated or verified to correct a mismatch, view the timestamp of the last license sync job. If a job hasn't run since the correction was made, manually trigger a new job. For more information, see "[AUTOTITLE](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud)."