Merge pull request #1784 from EnterpriseDB/release/2021-08-21

Author: josh-heyer

README.md

@@ -138,7 +138,9 @@ If you experience errors or other issues with the site, try the following in the
 
 ## Development
 
-All changes should have a pull request opened against the default branch, `develop`. When a pull request is opened, Heroku should automatically create a review build, which should be linked in the pull request under "deployments". Review builds only include advocacy content. When a pull request is merged, `develop` will automatically deploy the changes to the staging environment.
+All changes should have a pull request opened against the default branch, `develop`. To generate [#draft-deployments](Draft deployments) for the branch, add the `deploy` label to the pull request: a new deployment at a unique URL will be produced every time changes are pushed to the branch. Note: GitHub must be able to merge the branch cleanly in order for this to work; if there are conflicts shown on the pull request, resolve them in order to obtain a new draft deployment.
+
+When a PR is merged into the `develop` branch, the result will be deployed to the [staging](#staging) environment.
 
 To deploy to production, create a pull request merging `develop` into `main`. When that PR is merged, `main` will automatically build and deploy to the production site.
 
@@ -150,13 +152,17 @@ Deployments of the site use the `build-sources.json` file to determine which sou
 
 Staging is hosted on Netlify, and is built from the `develop` branch. The build and deployment process is handled by the `deploy-develop.yml` GitHub workflow.
 
+Staging environment URL: https://edb-docs-staging.netlify.app/docs/
+
 #### Production
 
 Production is hosted on Netlify, and is built from the `main` branch. The build and deployment process is handled by the `deploy-main.yml` GitHub workflow. The production deployment process will update the search index on Algolia.
 
-#### Review Builds
+Production environment URL: https://www.enterprisedb.com/docs
+
+#### Draft deployments
 
-Review builds are automatically created for pull requests. These builds are created by Heroku, and only include advocacy content, no other sources.
+Review builds are automatically created for pull requests when the `deploy` tag is added. The build and deployment process is handled by the `deploy-draft.yml` GitHub workflow. Draft builds are [a Netlify feature](https://docs.netlify.com/cli/get-started/#draft-and-production-deploys) - each new draft has a unique URL (based on the Staging URL) that will persist even when later revisions are deployed.
 
 ## Redirects
 

advocacy_docs/partner_docs/ThalesGuide/02-PartnerInformation.mdx

@@ -1,12 +1,13 @@
 ---
 title: 'Partner Information'
-description: 'Providing a general overview of Thales and the CipherTrust Transparent Encryption product'
+description: 'Overview of Thales and the CipherTrust Transparent Encryption product'
 
 ---
+
 |       |   |
 | ----------- | ----------- |
 | **Partner Name**      | Thales       |
 | **Partner Product**   |  CipherTrust Transparent Encryption       |
 | **Web Site**      |    https://cpl.thalesgroup.com/encryption    |
-| **Version & Platform**   |  7.1.0, Available platforms: Windows , Linux      |
-| **Product Description**      |    CipherTrust Transparent Encryption delivers data-at-rest encryption with centralized key management privileged user access control and detailed data access audit logging. This protects data wherever it resides, on- premises, across multiple clouds and within big data, and container environments.   |
+| **Version & Platform**   |  7.1.0, Available platforms: Windows, Linux      |
+| **Product Description**      |    CipherTrust Transparent Encryption (CTE) delivers data-at-rest encryption with centralized key management, privileged user access control, and detailed data access audit logging. This protects data wherever it resides: on-premises, across multiple clouds and within big data, and container environments.   |

advocacy_docs/partner_docs/ThalesGuide/03-SolutionSummary.mdx

@@ -1,8 +1,15 @@
 ---
 title: 'Solution Summary'
-description: 'A brief explanation of the solution and its purpose'
+description: 'Brief explanation of the solution and its purpose'
 ---
-Thales CipherTrust Transparent Encryption (CTE) is designed to meet data security compliance and best practice requirements with minimal disruption. The CTE agents are installed at the operating file-system or device layer, and encryption and decryption is transparent to all applications that run above it. CTE agents are installed on EDB Postgres Advanced and Postgres Extended database servers and protect the database directories. The solution works in conjunction with the FIPS 140-2 up to Level 3 compliant CipherTrust Manager, which centralizes encryption key and policy management for the CipherTrust Data Security Platform.
+
+
+Thales’ CipherTrust Transparent Encryption secures data at-rest for Postgres databases and backups
+with file system-level encryption backed by centralized key management, privileged user access controls, and
+detailed data access audit logging. CipherTrust Transparent Encryption allows customers to adopt Postgres
+for highly-sensitive and regulated data both on-premises and in the cloud while also meeting their compliance
+obligations. CipherTrust Transparent Encryption has been certified with EDB Postgres Advanced,
+and with EDB Postgres Extended as part of a BDR (bi-directional replication) cluster, and with Barman.
 
 <p align="center">
   <img  src="Images/SolutionSummary.jpg.png">
@@ -11,4 +18,4 @@ Thales CipherTrust Transparent Encryption (CTE) is designed to meet data securit
 
 
 !!! Note
-    EDB Postgres Extended with BDR (Bi-Directional Replication)
+    EDB Postgres Extended represents EDB Postgres Extended* with BDR (Bi-Directional Replication) and Barman.

advocacy_docs/partner_docs/ThalesGuide/04-ImplementingCTE.mdx

@@ -1,26 +1,24 @@
 ---
 title: 'Implementing CipherTrust Transparent Encryption (CTE)'
-description: 'A walk-through of setting up CTE'
+description: 'Walkthrough of setting up CTE'
 ---
 
-Implementing the CipherTrust Transparent Encryption (CTE) solution requires the following components:
+**Implementing the CipherTrust Transparent Encryption (CTE) solution requires the following components:**
 
-1. Postgres Server installed and in operation.
+  - Postgres server installed and operational.
+  - CipherTrust Manager installed and operational.
+  - A CTE agent installed on the Postgres host registered to the CipherTrust Manager.
 
-2. CipherTrust Manager installed and operational.
 
-3. A CTE agent installed on the Postgres host registered to the CipherTrust Manager.
-
-
-The following diagram shows the basic flow of the CTE solution:
+**The following diagram shows the basic flow of the CTE solution:**
 
 <p align="center">
   <img  src="Images/ImplementingCTE.png">
 </p>
 
-### Prerequisites
+### 3.1 Prerequisites
 #### Postgres Host
-1. Ensure that the Postgres Server is installed and running.
+1. Ensure that the Postgres server is installed and running.
 
 2. For CentOS 7, you need to install the following repository:
 
@@ -35,25 +33,30 @@ sudo yum install -y lsof
   <img  src="Images/CipherTrustManager.png">
 </p>
 
-### Configuring CipherTrust Manager
+### 3.2 Configuring CipherTrust Manager
 Logon to the CipherTrust Manager (CM) Web GUI and perform the following steps:
 
-1. **Create  Registration Token**
+1. Create a registration token.
+
+  a. Navigate to **Key and Access Management** and select **Registration Tokens**. This token is used for the CTE agent enrollment to CM. 
 
-    a. Navigate to **Key and Access Management** and select **Registration Tokens**. This token will be used for the CTE agent enrollment to CM. 
+  b. Select **New Registration Token** to create a new registration token. 
+  
 
-    b. Select **New Registration Token** to create a new Registration Token. The following screenshot shows a Registration Token created with the name **edb**.
+The following screenshot shows a registration token created with the name **edb**.
 
 
 <p align="center">
   <img  src="Images/ConfiguringCipherTrustManager.png">
 </p>
 
-2. **Create User Sets**
+2. Create user sets.
 
-    a. Navigate to **CTE** and select **Policies, Policy Elements** and then **User Sets**. 
+  a. Navigate to CTE and select Policies, Policy Elements and then User Sets. 
 
-    b. Select **Create User Set** to create a new User Set. The following screenshots show the User Sets created, **Postgres, EnterpriseDB and Barman**.
+  b. Select Create User Set to create a new user set. 
+    
+Create the Postgres, EnterpriseDB and Barman user sets as shown in the following screenshots.
 
 
 <p align="center">
@@ -70,7 +73,8 @@ Logon to the CipherTrust Manager (CM) Web GUI and perform the following steps:
 
     a. Navigate back to **Policies** and select **Create Policy**.
 
-    b. The following screenshots show Live Data Transformation (LDT) policies **postgres-policy, epas-policy and barman-policy**. 
+    
+**The following screenshots show Live Data Transformation (LDT) policies postgres-policy, epas-policy and barman-policy.**
 
 
 <p align="center">
@@ -90,21 +94,23 @@ Logon to the CipherTrust Manager (CM) Web GUI and perform the following steps:
   <img  src="Images/CreatePolicies4.png">
 </p>
 
-### Installing CTE Agent
+### 3.3 Installing CTE Agent
 
 Refer to the following guides from Thales for installing the CTE agent on the Postgres host:
 
 [CTE Agent Quick Start Guide](https://thalesdocs.com/ctp/cte/Books/Online-Files/7.0.0/CTE_Agent_Linux_Quick_Start_Guide_v7.0.0_Doc_v1.pdf)
 
-[CTE Agent Advanced Installation Guide](https://thalesdocs.com/ctp/cte/Books/Online-Files/7.0.0/CTE_Agent_Linux_Adv_Config_Integration_Guide_v7.0.0_Doc_v6.pdf)
+[*CTE Agent Advanced Installation Guide*](https://thalesdocs.com/ctp/cte/Books/Online-Files/7.0.0/CTE_Agent_Linux_Adv_Config_Integration_Guide_v7.0.0_Doc_v6.pdf)
 
 !!! Note
-    You will need the **Registration Token** and host address of the **CipherTrust Manager** during the installation.
+    You will need the Registration Token and host address of the CipherTrust Manager during the installation.
 
 After the CTE agent is successfully installed, verify the Postgres host is registered with CM.
 1. Log on to the CM Web GUI and navigate to **CTE**.
 2. Select **Clients**. The client status should appear as **Healthy** as shown below (you may have to wait a few seconds for the status to get updated).
 
+The following screenshot shows clients registered with the CipherTrust Manager.
+
 <p align="center">
   <img  src="Images/InstallingCTEAgent.png">
-</p>
+</p>

advocacy_docs/partner_docs/ThalesGuide/05-UsingCTE.mdx

@@ -1,25 +1,28 @@
 ---
 title: 'Using CipherTrust Transparent Encryption (CTE)'
-description: 'Walking through multiple different instances of CTE in use'
+description: 'Walkthroughs of multiple CTE usage scenarios '
 ---
 
 CTE protects data either at the file level or at the storage device level. A CTE Agent running on the (Postgres) host manages the files behind a GuardPoint by enforcing the policy associated with it, and communicates data access events to the CipherTrust Manager for logging. A GuardPoint is usually associated with a Linux mount point or a Windows volume, but may also be associated with a directory subtree.
 
+**The following diagram shows the CTE architecture.**
+
 <p align="center">
   <img  src="Images/UsingCTE.png">
 </p>
 
-### Sample User Scenarios
+### 4.1 Sample User Scenarios
 
-This section describes sample user scenarios of deploying CTE solutions on Postgres hosts such as 
-- EDB Postgres Advanced Server
-- EDB Postgres Extended with BDR
+This section describes sample user scenarios of deploying CTE solutions on EDB Postgres Advanced Server and EDB Postgres Extended with BDR hosts.
+- **EDB Postgres Advanced Server**
+- **EDB Postgres Extended with BDR**
 
-**EDB Postgres Advanced Server 13 (Single Instance)**
+**EDB Postgres Advanced Server (Single Instance)**
 
 1. Install CTE agent on the Postgres host. 
 2. Login to the Postgres host and stop the postgres server.
-3. Create the GuardPoints via the CM Web GUI using the **epas-policy** Policy on the postgres host. Set the following directories as the **Protected Path** on the EPAS host (assuming PGDATA is set /var/lib/edb/as13/data on the host):
+3. Create the GuardPoints via the CM Web GUI using the **epas-policy** Policy on the postgres host. Set the following directories as the **Protected Path** on the EDB Postgres Advanced Server host (assuming PGDATA is set /var/lib/edb/as13/data on the host):
+
 <p align="center">
   <img  src="Images/SampleUserScenarios1.png">
 </p>
@@ -34,10 +37,10 @@ The following diagram shows the BDR-Always-ON architecture. For more details, re
     The documentation requires EDB access credentials.
 
 <p align="center">
-  <img  src="Images/SampleUserScenarios2.png">
+  <img  src="Images/EDBPostgresExtendedwithBDRAlwaysOn.png">
 </p>
 
-1. Install CTE agents on all the Postgres and barman nodes.
+1. Install CTE agents on all the postgres and barman nodes.
 
 2. Create a GuardPoint via the CM Web GUI using the `barman-policy` Policy on the directory  `/var/lib/barman/<server-name>`  on the barman node in data center A (DC A). The following screenshot shows a GuardPoint created for the barman node.
 
@@ -63,10 +66,10 @@ The following diagram shows the BDR-Always-ON architecture. For more details, re
 
 11. Restart the Postgres server on the Lead Master node as the user `postgres`.  Make sure you are logged in using ssh (not sudo).
 
-12. The following screenshot shows a GuardPoint created for Lead Master in data center A.
+The following screenshot shows a GuardPoint created for Lead Master in data center A.
 
 <p align="center">
   <img  src="Images/SampleUserScenarios4.png">
 </p>
 
-13. Repeat steps 2 through 11 for postgres and barman nodes in data center B (DC B).
+12. Repeat steps 2 through 11 for postgres and barman nodes in data center B (DC B).

advocacy_docs/partner_docs/ThalesGuide/06-CertificationEnvironment.mdx

@@ -1,11 +1,12 @@
 ---
 title: 'Certification Environment'
-description: 'Providing a general overview of the certification environment used in the implementation of CTE'
+description: 'Overview of the certification environment used in the implementation of CTE'
 ---
 
 |       |   |
 | ----------- | ----------- |
 | **Certification Test Date**      | May 19 2021       |
+| **EDB Advanced Server**  |  13.2.5     |
 | **OS**      |  CentOS Linux 7 (Core)      |
 | **Memory**      |  2G      |
 | **Processor**   |  Intel® Xeon® Processor SP Family (“Skylake”)       |
@@ -15,15 +16,14 @@ description: 'Providing a general overview of the certification environment used
 | **Socket(s)**  |  1     |
 | **Storage**  |  80 GB     |
 | **CipherTrust Transparent Encryption**  |  7.0.0.99     |
-| **EDB Advanced Server**  |  13.2.5     |
 
 |       |   |
 | ----------- | ----------- |
 | **Certification Test Date**| May 19 2021       |
+| **EDB Postgres Extended with BDR**  |  3.6.1     |
 | **OS**|  CentOS Linux 7       |
 | **Cloud Platform**|  AWS      |
 | **Deployment Tool**|  tpaexec v20.11       |
-| **BDR-Always-ON**|  3.6.1     |
 
 !!! Note
     Refer to the [sample config.yml](07-Appendix.mdx) file in the Appendix for deployment details.

advocacy_docs/partner_docs/ThalesGuide/07-Appendix.mdx

@@ -1,6 +1,6 @@
 ---
 title: 'Appendix'
-description: 'Utilize the config.yml file below'
+description: 'Sample `config.yml` file'
 ---
 
 ### Sample `config.yml` file

advocacy_docs/partner_docs/ThalesGuide/Images/EDBPostgresExtendedwithBDRAlwaysOn.png

@@ -71,34 +71,32 @@ const sourceToPluginConfig = {
 const externalSourcePlugins = () => {
   const sourcePlugins = [];
 
-  if (!process.env.SKIP_SOURCING) {
-    // default to full set of sources
-    let sources = Object.keys(sourceToPluginConfig).reduce((result, source) => {
-      result[source] = true;
-      return result;
-    }, {});
+  // default to full set of sources
+  let sources = Object.keys(sourceToPluginConfig).reduce((result, source) => {
+    result[source] = true;
+    return result;
+  }, {});
 
-    if (gracefulFs.existsSync(sourceFilename)) {
-      console.log(
-        `${ANSI_BLUE}###### Sourcing from ${sourceFilename} #######${ANSI_STOP}`,
-      );
-      console.log(
-        `${ANSI_GREEN}Note: ${sourceFilename} is no longer required; delete it to load the full set of docs.${ANSI_STOP}`,
-      );
-      sources = JSON.parse(gracefulFs.readFileSync(sourceFilename));
-    }
+  if (gracefulFs.existsSync(sourceFilename)) {
+    console.log(
+      `${ANSI_BLUE}###### Sourcing from ${sourceFilename} #######${ANSI_STOP}`,
+    );
+    console.log(
+      `${ANSI_GREEN}Note: ${sourceFilename} is no longer required; delete it to load the full set of docs.${ANSI_STOP}`,
+    );
+    sources = JSON.parse(gracefulFs.readFileSync(sourceFilename));
+  }
 
-    for (const [source, enabled] of Object.entries(sources)) {
-      const config = sourceToPluginConfig[source];
-      if (enabled && config) {
-        sourcePlugins.push({
-          resolve: "gatsby-source-filesystem",
-          options: {
-            name: config.name,
-            path: config.path,
-          },
-        });
-      }
+  for (const [source, enabled] of Object.entries(sources)) {
+    const config = sourceToPluginConfig[source];
+    if (enabled && config) {
+      sourcePlugins.push({
+        resolve: "gatsby-source-filesystem",
+        options: {
+          name: config.name,
+          path: config.path,
+        },
+      });
     }
   }