Only supported with Patroni as the failover manager. | HAproxy nodes will not be added to the cluster. | -| `--enable-pgbouncer` | PgBouncer will be configured in the Postgres nodes to pool connections for the primary. | PgBouncer will not be configured in the cluster. | -| `--patroni-dcs` | Select the Distributed Configuration Store backend for patroni.
Only option is `etcd` at this time.
Only supported with Patroni as the failover manager. | Defaults to `etcd`. | -| `--efm-bind-by-hostname` | Enable efm to use hostnames instead of IP addresses to configure the cluster `bind.address`. | Defaults to use IP addresses | +| Parameter | Description | Behaviour if omitted | +| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | +| `--platform` | One of `aws`, `docker`, `bare`. | Defaults to `aws`. | +| `--location-names` | A space-separated list of location names. The number of locations is equal to the number of names supplied. | A single location called "main" is used. | +| `--primary-location` | The location where the primary server will be. Must be a member of `location-names`. | The first listed location is used. | +| `--data-nodes-per-location` | A number from 1 upwards. In each location, one node will be configured to stream directly from the cluster's primary node, and the other nodes, if present, will stream from that one. | Defaults to 2. | +| `--witness-only-location` | A location name, must be a member of `location-names`. This location will be populated with a single witness node only. | No witness-only location is added. | +| `--single-node-location` | A location name, must be a member of `location-names`. This location will be populated with a single data node only. | No single-node location is added. | +| `--enable-haproxy` | Two additional nodes will be added as a load balancer layer.
Only supported with Patroni as the failover manager. | HAproxy nodes will not be added to the cluster. | +| `--enable-pgbouncer` | PgBouncer will be configured in the Postgres nodes to pool connections for the primary. | PgBouncer will not be configured in the cluster. | +| `--patroni-dcs` | Select the Distributed Configuration Store backend for patroni.
Only option is `etcd` at this time.
Only supported with Patroni as the failover manager. | Defaults to `etcd`. | +| `--efm-bind-by-hostname` | Enable efm to use hostnames instead of IP addresses to configure the cluster `bind.address`. | Defaults to use IP addresses |
diff --git a/product_docs/docs/tpa/23/architecture-PGD-Always-ON.mdx b/product_docs/docs/tpa/23/architecture-PGD-Always-ON.mdx index 948cf5d1aba..4dd318ac627 100644 --- a/product_docs/docs/tpa/23/architecture-PGD-Always-ON.mdx +++ b/product_docs/docs/tpa/23/architecture-PGD-Always-ON.mdx @@ -5,10 +5,10 @@ originalFilePath: architecture-PGD-Always-ON.md --- -!!! Note +!!!Note + This architecture is for Postgres Distributed 5 only. If you require PGD 4 or 3.7 please use [BDR-Always-ON](architecture-BDR-Always-ON/). -!!! EDB Postgres Distributed 5 in an Always-ON configuration, suitable for use in test and production. @@ -85,9 +85,9 @@ data centre that provides a level of redundancy, in whatever way this definition makes sense to your use case. For example, AWS regions, your own data centres, or any other designation to identify where your servers are hosted. +!!! - -!!! Note Note for AWS users +!!! Note for AWS users If you are using TPA to provision an AWS cluster, the locations will be mapped to separate availability zones within the `--region` you diff --git a/product_docs/docs/tpa/23/reference/architecture-PGD-Lightweight.mdx b/product_docs/docs/tpa/23/reference/architecture-PGD-Lightweight.mdx new file mode 100644 index 00000000000..a9b2f88d5d4 --- /dev/null +++ b/product_docs/docs/tpa/23/reference/architecture-PGD-Lightweight.mdx @@ -0,0 +1,103 @@ +--- +description: Configuring a PGD Lightweight cluster with TPA. +title: PGD Lightweight +originalFilePath: architecture-PGD-Lightweight.md + +--- + +!!! Note + + This architecture is for Postgres Distributed 5 only. + If you require PGD 4 or 3.7 please use [BDR-Always-ON](../architecture-BDR-Always-ON/). + + EDB Postgres Distributed 5 in a Lightweight configuration, + suitable for use in test and production. + + This architecture requires an EDB subscription. + All software will be sourced from [EDB Repos 2.0](edb_repositories/). + +## Cluster configuration + +### Overview of configuration options + +An example invocation of `tpaexec configure` for this architecture +is shown below. + +```bash + tpaexec configure ~/clusters/pgd-lw \ + --architecture Lightweight \ + --edb-postgres-extended 15 \ + --platform aws --instance-type t3.micro \ + --distribution Debian \ + --location-names main dr \ +``` + +You can list all available options using the help command. + +```bash +tpaexec configure --architecture Lightweight --help +``` + +The table below describes the mandatory options for PGD-Always-ON +and additional important options. +More detail on the options is provided in the following section. + +#### Mandatory Options + +| Options | Description | +| ----------------------------------------------------- | -------------------------------------------------------------------------------------------- | +| `--architecture` (`-a`) | Must be set to `Lightweight` | +| Postgres flavour and version (e.g. `--postgresql 15`) | A valid [flavour and version specifier](../tpaexec-configure/#postgres-flavour-and-version). | + +
+ +#### Additional Options + +| Options | Description | Behaviour if omitted | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | +| `--platform` | One of `aws`, `docker`, `bare`. | Defaults to `aws`. | +| `--location-names` | A space-separated list of location names. The number of locations is equal to the number of names supplied. | TPA will configure a single location with three data nodes. | +| `--add-proxy-nodes-per-location` | The number of proxy nodes in each location. | PGD-proxy will be installed on each data node. | +| `--bdr-database` | The name of the database to be used for replication. | Defaults to `bdrdb`. | +| `--enable-pgd-probes` | Enable http(s) api endpoints for pgd-proxy such as `health/is-ready` to allow probing proxy's health. | Disabled by default. | +| `--proxy-listen-port` | The port on which proxy nodes will route traffic to the write leader. | Defaults to 6432 | +| `--proxy-read-only-port` | The port on which proxy nodes will route read-only traffic to shadow nodes. | Defaults to 6433 | + +
+ +### More detail about Lightweight configuration + +A PGD Lightweight cluster comprises 2 locations, with a primary active location containing 2 nodes and a disaster recovery (dr) location with a single node. + +Location names for the cluster are specified as +`--location-names primary dr`. A location represents an independent +data centre that provides a level of redundancy, in whatever way +this definition makes sense to your use case. For example, AWS +regions, your own data centres, or any other designation to identify +where your servers are hosted. + +!!! Note for AWS users + + If you are using TPA to provision an AWS cluster, the locations will + be mapped to separate availability zones within the `--region` you + specify. + You may specify multiple `--regions`, but TPA does not currently set + up VPC peering to allow instances in different regions to + communicate with each other. For a multi-region cluster, you will + need to set up VPC peering yourself. + +By default, every data node (in every location) will also run PGD-Proxy +for connection routing. To create separate PGD-Proxy instances instead, +use `--add-proxy-nodes-per-location 3` (or however many proxies you want +to add). + +Global routing will make every proxy route to a single write leader, elected amongst all available data nodes across all locations. + +You may optionally specify `--bdr-database dbname` to set the name of +the database with BDR enabled (default: bdrdb). + +You may optionally specify `--enable-pgd-probes [{http, https}]` to +enable http(s) api endpoints that will allow to easily probe proxy's health. + +You may also specify any of the options described by +[`tpaexec help configure-options`](../tpaexec-configure/). diff --git a/product_docs/docs/tpa/23/reference/barman.mdx b/product_docs/docs/tpa/23/reference/barman.mdx index 80f7546e683..d9c8c10d1e4 100644 --- a/product_docs/docs/tpa/23/reference/barman.mdx +++ b/product_docs/docs/tpa/23/reference/barman.mdx @@ -90,3 +90,121 @@ them to each other's authorized_keys file. The postgres user must be able to ssh to the barman server in order to archive WAL segments (if configured), and the barman user must be able to ssh to the Postgres instance to take or restore backups. + +## `barman` and `barman_role` Postgres users + +TPA will create two Postgres users, `barman` and `barman_role`. + +TPA versions `<23.35` created the `barman` Postgres user as a `superuser`. + +Beginning with `23.35` the `barman` user is created with `NOSUPERUSER`, +so any re-deploys on existing clusters will remove the `superuser` attribute +from the `barman` Postgres user. Instead, the `barman_role` is granted the +required set of privileges and the `barman` user is granted `barman_role` membership. + +This avoids granting the `superuser` attribute to the `barman` user, using the set +of privileges provided in the [Barman Manual](https://docs.pgbarman.org/release/latest/#postgresql-connection). + +## Shared Barman server + +!!! Note + + To use the shared Barman functionality with clusters created using a + TPA version earlier than 23.35, you must: + a) upgrade to a version of TPA that supports creating + shared Barman instances. + b) after upgrading TPA, run deploy on $first-cluster so TPA can make + necessary config changes for subsequent clusters to run smoothly + against the shared Barman node. + +Some deployments may want to share a single Barman server for multiple +clusters. Shared Barman server deployment within +tpaexec is supported via the `barman_shared` setting that can be set via +`vars:` under the Barman server instance for the given cluster config +that plans to use an existing Barman server. `barman_shared` is a +boolean variable so possible values are true and false(default). When +making any changes to the Barman config in a shared scenario, you must +ensure that configurations across multiple clusters remain in sync so as +to avoid a scenario where one cluster adds a specific configuration and +a second cluster overrides it. + +A typical workflow for using a shared Barman server across multiple +clusters is described below. + +1. Create a TPA cluster with an instance that has `barman` role + (call it 'first-cluster' for this example). + +2. In the second cluster (second-cluster for example), reference this + particular Barman instance from $clusters/first-cluster as a shared + Barman server instance and use `bare` as platform so we are not + trying to create a new Barman instance when running provision. Also + specify the IP address of the Barman instance that this cluster can + use to access it. + + ```yml + - Name: myBarman + node: 5 + role: + - barman + platform: bare + ip_address: x.x.x.x + vars: + barman_shared: true + ``` + +3. Once the second-cluster is provisioned but before running deploy, + make sure that it can access the Barman server instance via ssh. You + can allow this access by copying second-cluster's public key to + Barman server instance via `ssh-copy-id` and then do an ssh to + make sure you can login without having to specify the password. + + ```bash + # add first-cluster's key to the ssh-agent + $ cd $clusters/first-cluster + $ ssh-add id_first-clutser + $ cd $clusters/second-cluster + $ ssh-keyscan -t rsa,ecdsa -4 $barman-server-ip >> tpa_known_hosts + $ ssh-copy-id -i id_second-cluster.pub -o 'UserKnownHostsFile=tpa_known_hosts' $user@$barman-server-ip + $ ssh -F ssh_config $barman-server + ``` + +4. Copy the Barman user's keys from first-cluster to second-cluster + ```bash + $ mkdir $clusters/second-cluster/keys + $ cp $clusters/first-cluster/keys/id_barman* clusters/second-cluster/keys + ``` + +5. Run `tpaexec deploy $clusters/second-cluster` + +!!! Note + + You must use caution when setting up clusters that share a Barman + server instance. There are a number of important aspects you must + consider before attempting such a setup. For example: + + 1. Making sure that no two instances in any of the clusters sharing a + Barman server use the same name. + 2. Barman configuration and settings otherwise should remain in sync in + all the clusters using a common Barman server to avoid a scenario + where one cluster sets up a specific configuration and the others do + not either because the configuration is missing or uses a different + value. + 3. Version of Postgres on instances being backed up across different + clusters needs to be the same. + 4. Different clusters using a common Barman server cannot specify + different versions of Barman packages when attempting to override + default. + +Some of these may be addressed in a future release as we continue to +improve the shared Barman server support. + +!!!Warning + +Be extremely careful when deprovisioning clusters sharing a common +Barman node. Especially where the first cluster that deployed Barman +uses non-bare platform. Deprovisioning the first cluster that +originally provisioned and deployed Barman will effectively leave +other clusters sharing the Barman node in an inconsistent state +because the Barman node will already have been deprovisioned by the +first cluster and it won't exist anymore. +!!! diff --git a/product_docs/docs/tpa/23/reference/compliance.mdx b/product_docs/docs/tpa/23/reference/compliance.mdx new file mode 100644 index 00000000000..54b6d864555 --- /dev/null +++ b/product_docs/docs/tpa/23/reference/compliance.mdx @@ -0,0 +1,166 @@ +--- +description: Generating standards-compliant clusters with TPA +title: Compliance +originalFilePath: compliance.md + +--- + +TPA can generate configurations designed to make it easy for a +cluster to comply with the STIG or CIS standards. If you pass +`--compliance stig` or `--compliance cis` to `tpaexec configure`, +TPA will: + +- Check that other options are compatible with the appropriate + standard. +- Add various entries to the generated `config.yml`, including + marking that this is a cluster meant to comply with a particular + standard and setting Postgres configuration as required by + the standard. +- Adjust some deployment tasks to enforce compliance. +- Run checks at the end of deployment. + +The deploy-time checks can +be skipped by giving the option `--excluded_tasks=compliance` to `tpaexec +deploy`. This feature is intended for testing only, when using a test +system on which full compliance is impossible (for example, +because SSL certificates are not available). + +There are some situations in which TPA will intentionally fail to +comply with the selected standard; these are documented under Exceptions +below. + +## STIG + +STIG compliance is indicated by the `--compliance stig` option to +`tpaexec configure`. + +### Option compatibility + +STIG compliance requires the `bare` platform and the `epas` flavour. +It requires the RedHat OS with version 8 or 9. + +### Settings in config.yml + +The following entry is added to `cluster_vars` to use the SQL/Protect +feature of EDB Postgres Advanced Server: + +``` + extra_postgres_extensions: [ 'sql_protect' ] +``` + +The following entries are added to `cluster_vars` to force clients +to use SSL authentication: + +``` + hba_force_hostssl: True + hba_force_certificate_auth: True + hba_cert_authentication_map: sslmap +``` + +The following entries are added to `cluster_vars` to set GUCs in +postgresql.conf: + +``` + tcp_keepalives_idle: 10 + tcp_keepalives_interval: 10 + tcp_keepalives_count: 10 + log_destination: "stderr" + postgres_log_file_mode: "0600" +``` + +The following entries are added to `postgres_conf_settings` in +`cluster_vars` to set GUCs in postgresql.conf: + +``` + edb_audit: "xml" + edb_audit_statement: "all" + edb_audit_connect: "all" + edb_audit_disconnect: "all" + statement_timeout: 1000 + client_min_messages: "ERROR" +``` + +### Deployment differences + +During deployment, TPA will set connection limits for the database users +it creates, corresponding to the number of connections that are needed +for normal operation. As each user is set up, it will also check that +an SSL client certificate has been provided for it. + +### Providing client ssl certificates + +STIG requires DOD-approved ssl certificates for client connections. +These certificates can't be generated by TPA and therefore must be +supplied. When setting up authentication for a user from a +node in the cluster, TPA will look for a certificate/key pair on the +node. The certificate and key should be in files called .crt +and .key in the directory given by the `ssl_client_cert_dir` +setting. The default for this setting is `/`, so the files would be, +for example, `/barman.crt` and `/barman.key` when the `barman` user is +being set up. + +### Final checks + +At the end of deployment, TPA will check that the server has FIPS +enabled. + +### Exceptions + +If you select EFM as the failover manager, TPA will configure password +authentication for the EFM user. This goes against the STIG requirement +that all TCP connections use certificate authentication. The reason for +this exception is that EFM does not support certificate authentication. + +## CIS + +CIS compliance is indicated by the `--compliance cis` option to `tpaexec +configure`. + +### Settings in config.yml + +The following entries are added to `cluster_vars` to set GUCs in +postgresql.conf: + +``` + log_connections: "on" + log_disconnections: "on" +``` + +The following entry is added to `cluster_vars` to enable required +extensions: + +``` + extra_postgres_extensions: ["passwordcheck", "pgaudit"] +``` + +The following entry is added to `cluster_vars` to set the umask for +the postgres OS user: + +``` + extra_bash_rc_lines: "umask 0077" +``` + +The following entries are added to `postgres_conf_settings` in +`cluster_vars` to set GUCs in postgresql.conf: + +``` + + log_error_verbosity: "verbose" + log_line_prefix: "'%m [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h '" + log_replication_commands: "on" + temp_file_limit: "1GB" +``` + +### Final checks + +At the end of deployment, TPA will check that the server has FIPS +enabled. + +### Exceptions + +TPA does not support pgBackRest as mentioned in the CIS specification. +Instead TPA installs Barman. + +TPA does not install and configure `set_user` as required by the CIS +specification. This is because preventing logon by the Postgres user +would leave TPA unable to connect to, and configure, the database. diff --git a/product_docs/docs/tpa/23/reference/efm.mdx b/product_docs/docs/tpa/23/reference/efm.mdx index 6f262752296..ef4eaf194f7 100644 --- a/product_docs/docs/tpa/23/reference/efm.mdx +++ b/product_docs/docs/tpa/23/reference/efm.mdx @@ -24,6 +24,18 @@ to the cluster. See the [EFM documentation](https://www.enterprisedb.com/docs/efm/latest/) for more details on EFM configuration. +## efm_user_password_encryption + +Must be either `scram-sha-256` or `md5` + +Set `efm_user_password_encryption` to control the `auth-method` for the +`efm` Postgres user's `auth-method` in `pg_hba.conf` as well as the algorithm +used when generating it's encrypted password. + +```yaml +efm_user_password_encryption: 'scram-sha-256' # or can be set to `md5` +``` + ## efm_conf_settings You can use `efm_conf_settings` to set any parameters, whether recognised diff --git a/product_docs/docs/tpa/23/reference/harp.mdx b/product_docs/docs/tpa/23/reference/harp.mdx index 281f9e5515a..27dfdc5a9ed 100644 --- a/product_docs/docs/tpa/23/reference/harp.mdx +++ b/product_docs/docs/tpa/23/reference/harp.mdx @@ -13,7 +13,7 @@ to `harp`, which is the default for BDR-Always-ON clusters. You must provide the `harp-manager` and `harp-proxy` packages. Please contact EDB to obtain access to these packages. -## Configuring HARP +## Variables for HARP configuration See the [HARP documentation](https://www.enterprisedb.com/docs/pgd/4/harp/04_configuration/) for more details on HARP configuration. @@ -41,6 +41,7 @@ for more details on HARP configuration. | `harp_proxy_max_client_conn` | `75` | Maximum number of client connections accepted by harp-proxy (`max_client_conn`) | | `harp_ssl_password_command` | None | a custom command that should receive the obfuscated sslpassword in the stdin and provide the handled sslpassword via stdout. | | `harp_db_request_timeout` | `10s` | similar to dcs -> request_timeout, but for connection to the database itself. | +| `harp_local_etcd_only` | None | limit harp manager endpoints list to only contain the local etcd node instead of all etcd nodes | You can use the [harp-config hook](../tpaexec-hooks/#harp-config) @@ -114,7 +115,7 @@ provide api endpoints to monitor service's health. The variable can contain these keys: -``` +```yaml enable: false secure: false cert_file: "/etc/tpa/harp_proxy/harp_proxy.crt" diff --git a/product_docs/docs/tpa/23/reference/pgbouncer.mdx b/product_docs/docs/tpa/23/reference/pgbouncer.mdx index 567d840caac..8e36b4528d6 100644 --- a/product_docs/docs/tpa/23/reference/pgbouncer.mdx +++ b/product_docs/docs/tpa/23/reference/pgbouncer.mdx @@ -1,16 +1,28 @@ --- -description: Adding pgbouncer to your Postgres cluster. -title: Configuring pgbouncer +description: Adding PgBouncer to your Postgres cluster. +title: Configuring PgBouncer originalFilePath: pgbouncer.md --- -TPA will install and configure pgbouncer on instances whose `role` +TPA will install and configure PgBouncer on instances whose `role` contains `pgbouncer`. -By default, pgbouncer listens for connections on port 6432 and forwards -connections to `127.0.0.1:5432` (which may be either Postgres or -[haproxy](haproxy/), depending on the architecture). +By default, PgBouncer listens for connections on port 6432 and, if no +`pgbouncer_backend` is specified, forwards connections to +`127.0.0.1:5432` (which may be either Postgres or [haproxy](haproxy/), +depending on the architecture). + +!!!Note Using PgBouncer to route traffic to the primary + +If you are using the M1 architecture with repmgr you can set +`repmgr_redirect_pgbouncer: true` hash under `cluster_vars` to have +PgBouncer connections directed to the primary. The PgBouncer will be +automatically updated on failover to route to the new primary. You +should use this option in combination with setting `pgbouncer_backend` +to the primary instance name to ensure that the cluster is initially +deployed with PgBouncer configured to route to the primary. +!!! You can set the following variables on any `pgbouncer` instance. diff --git a/product_docs/docs/tpa/23/reference/tpaexec-download-packages.mdx b/product_docs/docs/tpa/23/reference/tpaexec-download-packages.mdx index 801d59d2ece..08c3fb4b241 100644 --- a/product_docs/docs/tpa/23/reference/tpaexec-download-packages.mdx +++ b/product_docs/docs/tpa/23/reference/tpaexec-download-packages.mdx @@ -24,7 +24,7 @@ are supported. container of the target operating system and uses that system's package manager to resolve dependencies and download all necessary packages. The required Docker setup for download-packages is the same as that for - [using Docker as a deployment platform](../platform-docker). + [using Docker as a deployment platform](../platform-docker/). ## Usage diff --git a/product_docs/docs/tpa/23/rel_notes/index.mdx b/product_docs/docs/tpa/23/rel_notes/index.mdx index 9a3fd7f6f59..651be5a8139 100644 --- a/product_docs/docs/tpa/23/rel_notes/index.mdx +++ b/product_docs/docs/tpa/23/rel_notes/index.mdx @@ -3,6 +3,7 @@ title: Trusted Postgres Architect release notes navTitle: Release notes description: Release notes for Trusted Postgres Architect and later navigation: + - tpa_23.35_rel_notes - tpa_23.34.1_rel_notes - tpa_23.34_rel_notes - tpa_23.33_rel_notes @@ -36,6 +37,7 @@ The Trusted Postgres Architect documentation describes the latest version of Tru | Trusted Postgres Architect version | Release Date | |---|---| +| [23.35](./tpa_23.35_rel_notes) | 25 Nov 2024 | | [23.34.1](./tpa_23.34.1_rel_notes) | 09 Sep 2024 | | [23.34](./tpa_23.34_rel_notes) | 22 Aug 2024 | | [23.33](./tpa_23.33_rel_notes) | 24 Jun 2024 | diff --git a/product_docs/docs/tpa/23/rel_notes/src/draft/tpa_23.35_rel_notes.yml b/product_docs/docs/tpa/23/rel_notes/src/draft/tpa_23.35_rel_notes.yml deleted file mode 100644 index a3c080918cd..00000000000 --- a/product_docs/docs/tpa/23/rel_notes/src/draft/tpa_23.35_rel_notes.yml +++ /dev/null @@ -1,142 +0,0 @@ -product: Trusted Postgres Architect -version: 23.35 -date: 29 October 2024 -intro: | - New features, enhancements, bug fixes, and other changes in Trusted Postgres Architect 23.35 include the following: -highlights: | - - More Trust - - More Postgres - - More Architect -relnotes: -- details: | - `PermissionsStartOnly` has been deprecated and is now achieved via `ExecStartPost=+/bin/bash...` syntax. - relnote: Remove deprecated `PermissionStartOnly` in postgres.service.j2 template - impact: low - jira: - - TPA-762 - type: Change -- details: | - Fixed a bug whereby the test that ensures the current pgd-proxy configuration - matches the expected configuration would fail for version < 5.5.0. This fix ensures - that TPA won't try to query configuration keys added in version 5.5.0. - impact: low - jira: - - TPA-819 - relnote: Fix tpaexec test for pgd-proxy config verification - type: Bug Fix -- details: | - The PostGIS package will automatically be added when a user specifies `postgis` - as an entry in either `postgres_extensions` or the list of extensions named under - `postgres_databases`. Also enables the CRB (Code Ready Builder) repository for - RHEL-compatible distributions so PostGIS dependencies can be installed. - impact: low - jira: - - TPA-771 - relnote: Add `postgis` to list of recognized extensions - type: Change -- details: | - Certain required privileges are granted to Postgres role, `barman_role`, - which is then granted to the `barman` Postgres user. This avoids creating the - `barman` user as a superuser. This role can also be granted to other Postgres - users by adding it to their `granted_roles` list using `postgres/createuser`. The - `barman_role` is created as part of the Barman tasks; if Barman is not used, this - role will not be created. Therefore, the task that grants privileges to this role - is only executed if the `barman_role` username is in the list of Postgres users - that are created. The ''barman'' user now has `NOSUPERUSER` explicitly specified - as a role attribute. If a cluster was deployed with a previous TPA version (which - created the ''barman'' user as a superuser), deploying with this version will - remove the `superuser` role attribute from the `barman` user. - impact: low - jira: - - TPA-148 - - TPA-818 - relnote: The `barman` Postgres user should not be a superuser - type: Change -- details: | - A `primary_slot_name` is configured on the primary node to ensure the - old primary uses a physical slot for replication during an EFM switchover. However, - ''bdr_init_physical'' attempts to use it for node initialisation and hangs indefinitely - since the slot does not exist in a PGD installation. This `primary_slot_name` - is now conditionally set explicitly when the `failover_manager` is EFM to avoid - setting it unnecessarily. - impact: low - jira: - - TPA-712 - relnote: '`primary_slot_name` added for EFM compatibility interferes with `bdr_init_physical` ' - type: Bug Fix -- details: | - If the `pgdcli_package_version` is specified in `config.yml`, the `bash-completion` - package is incorrectly named because the `packages_for` filter erroneously appends - the `pgdcli_package_version` to the package name. This results in an attempt - to download a nonexistant package. The `bash-completion` package is now appended - to the list after the `packages_for` filter, since it''s version is independent - from the `pgdcli_package_version`. - impact: low - jira: - - TPA-794 - relnote: Download correct `bash-completion` package version - type: Bug Fix -- details: | - Fixed an issue whereby in some cases error messages would be repeated - even after successful tasks. - impact: low - jira: - - TPA-812 - relnote: Clear error message stack after each task - type: Bug Fix -- details: | - Improve postgres-monitor script to better manage recoverable errors and - add retries on network errors to ensure that it won''t return failure when it - just didn't allow enough time for postgres service to be fully started. - impact: low - jira: - - TPA-796 - relnote: Improve postgres-monitor script - type: Change -- details: | - Fixed an issue whereby new replicas in patroni clusters would fail with - errors related to replication slots. - impact: low - jira: - - TPA-792 - - TPA-781 - relnote: Enable new replicas in patroni clusters - type: Bug Fix -- details: | - A support ticket questioned why the `pemserver` and `barman` nodes are - added to the `Allowed node host list` in EFM when they are not relevant to EFM - functions. Refactored the task that writes the `efm.node` configuration to only - include those nodes that have `efm` in their list of roles. - impact: low - jira: - - TPA-817 - relnote: Only add nodes with `efm` role to cluster `efm.nodes` file - type: Change -- details: | - 'If `--enable-pem` and `--enable-pg-backup-api` are passed to `tpaexec - configure`, `pem-agent` is added twice to the `barman` node if it is also a `witness`. Fixed - by by consolidating both `if` statements together to only evaluate the conditions - once. ' - impact: low - jira: - - TPA-793 - relnote: Add `pem-agent` role on barman nodes at most once for M1 architecture - type: Bug Fix -- details: | - Fixed a bug whereby if the user excluded the `pkg` selector, later pem-related - tasks would fail because the pem_python_executable fact had not been set. - impact: low - jira: - - TPA-814 - relnote: set pem_python_executable outside pkg role - type: Bug Fix -- details: | - The `--efm-install-path` and `--efm-cluster-name` flags are set when a PEM - server is registered on an EFM node. The `Streaming Replication`, `Failover - Manager Node Status` and `Failover Manager Cluster Info` probes are enabled when - a PEM agent is registered on an EFM node. ' - impact: low - jira: - - TPA-586 - relnote: Enable EFM probes when a PEM agent is registered on an EFM node - type: Change \ No newline at end of file diff --git a/product_docs/docs/tpa/23/rel_notes/src/meta.yml b/product_docs/docs/tpa/23/rel_notes/src/meta.yml index 124ea56dc04..6a6b069cdad 100644 --- a/product_docs/docs/tpa/23/rel_notes/src/meta.yml +++ b/product_docs/docs/tpa/23/rel_notes/src/meta.yml @@ -62,3 +62,4 @@ precursor: date: 21 Feb 2023 - version: "23.1-11" date: 21 Jun 2023 to 31 Jan 2023 + diff --git a/product_docs/docs/tpa/23/rel_notes/src/tpa_23.35_rel_notes.yml b/product_docs/docs/tpa/23/rel_notes/src/tpa_23.35_rel_notes.yml new file mode 100644 index 00000000000..2a3d85e7a6d --- /dev/null +++ b/product_docs/docs/tpa/23/rel_notes/src/tpa_23.35_rel_notes.yml @@ -0,0 +1,283 @@ +product: Trusted Postgres Architect +version: 23.35 +date: 25 November 2024 +intro: | + New features, enhancements, bug fixes, and other changes in Trusted Postgres Architect 23.35 include the following: +highlights: | + - Options for STIG/CIS compliance. + - Support for PGD Lightweight architecture + - Postgis is now a recognized extension. + - Docker `configure` creates named networks with static IP addresses. + - Support for RedHat Enterprise Linux 9 for ARM architectures. + - Support for PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server 17. +relnotes: + - details: >- + `PermissionsStartOnly` has been deprecated and is now achieved via + `ExecStartPost=+/bin/bash...` syntax + impact: low + jira: + - TPA-762 + relnote: Remove deprecated `PermissionStartOnly` in postgres.service.j2 template + type: Change + - details: >- + Fixed a bug whereby the test that ensures the current pgd-proxy + configuration matches the expected configuration would fail for version < + 5.5.0. This fix ensures that TPA won't try to query configuration keys + added in version 5.5.0. + impact: low + jira: + - TPA-819 + relnote: Fix tpaexec test for pgd-proxy config verification + type: Bug Fix + - details: >- + The PostGIS package will automatically be added when a user specifies + `postgis` as an entry in either `postgres_extensions` or the list of + extensions named under `postgres_databases`. Also enables the CRB (Code + Ready Builder) repository for RHEL-compatible distributions so PostGIS + dependencies can be installed. + impact: low + jira: + - TPA-771 + relnote: Add `postgis` to list of recognized extensions + type: Enhancement + - details: >- + Certain required privileges are granted to Postgres role, `barman_role`, + which is then granted to the `barman` Postgres user. This avoids creating + the `barman` user as a superuser. This role can also be granted to other + Postgres users by adding it to their `granted_roles` list using + `postgres/createuser`. The `barman_role` is created as part of the Barman + tasks; if Barman is not used, this role will not be created. Therefore, + the task that grants privileges to this role is only executed if the + `barman_role` username is in the list of Postgres users that are created. + The 'barman' user now has `NOSUPERUSER` explicitly specified as a role + attribute. If a cluster was deployed with a previous TPA version (which + created the 'barman' user as a superuser), deploying with this version + will remove the `superuser` role attribute from the `barman` user. + impact: low + jira: + - TPA-148 + - TPA-818 + relnote: The `barman` Postgres user is no longer a superuser + type: Change + - details: >- + Add new optional var `harp_local_etcd_only` available when using etcd with + HARP. This option tells HARP manager to connect to local etcd node. This + recommendation follows the best practices learnt by doing the same when + `bdr` as consensus procotol is being used. The default mode of adding + multiple endpoints can lead to performance issues in some cases. This + option is added to give more control to the user. + impact: low + jira: + - TPA-821 + relnote: Add new option `harp_local_etcd_only` when using etcd with HARP + type: Change + - details: >- + A `primary_slot_name` is configured on the primary node to ensure the old + primary uses a physical slot for replication during an EFM switchover. + However, 'bdr_init_physical' attempts to use it for node initialisation + and hangs indefinitely since the slot does not exist in a PGD + installation. This `primary_slot_name` is now conditionally set explicitly + when the `failover_manager` is EFM to avoid setting it unnecessarily. + impact: low + jira: + - TPA-712 + relnote: >- + Fix case where `primary_slot_name` added for EFM compatibility interferes + with `bdr_init_physical` + type: Bug Fix + - details: >- + If the `pgdcli_package_version` is specified in `config.yml`, the + `bash-completion` package is incorrectly named because the `packages_for` + filter erroneously appends the `pgdcli_package_version` to the package + name. This results in an attempt to download a nonexistant package. The + `bash-completion` package is now appended to the list after the + `packages_for` filter, since it's version is independent from the + `pgdcli_package_version`. + impact: low + jira: + - TPA-794 + relnote: Download correct `bash-completion` package version + type: Bug Fix + - details: >- + TPA is now able to generate a PGD Lightweight architecture comprised of + three nodes in two locations (2 nodes in Primary and one in Disaster + Recovery) designed to ease migrations from physical replication. Users can + now run `tpaexec configure lw -a Lightweight --postgresql 15`. + impact: medium + jira: + - TPA-838 + relnote: Add support for PGD Lightweight architecture + type: Enhancement + - details: >- + TPA now clears the error message stack after each task to ensure messages + are not spuriously repeated + impact: low + jira: + - TPA-812 + relnote: >- + Fix an issue whereby in some cases error messages would be repeated even + after successful tasks. + type: Bug Fix + - details: >- + Improve postgres-monitor script to better manage recoverable errors and + add retries on network errors to ensure that it won't return failure when + it just didn't allow enough time for postgres service to be fully started. + impact: low + jira: + - TPA-796 + relnote: Improve postgres-monitor script + type: Change + - details: >- + Fixed an issue whereby new replicas in Patroni clusters would fail with + errors related to replication slots. + impact: low + jira: + - TPA-792 + - TPA-781 + relnote: Fix issue that prevented the addition of replicas to Patroni clusters + type: Bug Fix + - details: >- + Previously the `pemserver` and `barman` nodes were added to the `Allowed + node host list` in EFM when they were not relevant to EFM functions. + Refactored the task that writes the `efm.node` configuration to only + include those nodes that have `efm` in their list of roles. + impact: low + jira: + - TPA-817 + relnote: Only add nodes with `efm` role to cluster `efm.nodes` file + type: Change + - details: >- + If `--enable-pem` and `--enable-pg-backup-api` are passed to `tpaexec + configure`, `pem-agent` is added twice to the `barman` node if it is also + a `witness`. Fixed by consolidating both `if` statements together to only + evaluate the conditions once. + impact: low + jira: + - TPA-793 + relnote: Add `pem-agent` role on barman nodes at most once for M1 architecture + type: Bug Fix + - details: >- + Fixed a bug whereby if the user excluded the `pkg` selector, later + PEM-related tasks would fail because the `pem_python_executable` fact had + not been set. + impact: low + jira: + - TPA-814 + relnote: Set `pem_python_executable` outside of the `pkg` role + type: Bug Fix + - details: >- + The `--efm-install-path` and `--efm-cluster-name` flags are set when a PEM + server is registered on an EFM node. The `Streaming Replication`, + `Failover Manager Node Status` and `Failover Manager Cluster Info` probes + are enabled when a PEM agent is registered on an EFM node. + impact: low + jira: + - TPA-586 + relnote: Enable EFM probes when a PEM agent is registered on an EFM node + type: Enhancement + - details: >- + TPA now supports command-line options to create a cluster configured to + conform to many of the requirements of the STIG and CIS security + standards. These options cause TPA to set postgresql.conf settings as + defined in the relevant standards, to install required extensions, to + configure other aspects of system behaviour such as filesystem permissions + and user connection limits, and to check for other requirements such as + FIPS crypto standards which TPA can't directly impose. The clusters thus + generated are not certified by TPA to conform to the standards, but much + of the groundwork of creating a conforming cluster is now automated. + impact: high + jira: + - TPA-366 + - TPA-836 + - TPA-837 + relnote: Support STIG/CIS compliance + type: Enhancement + - details: >- + The configure command will now automatically add a named network and + static IP addresses to config.yml when Docker is the selected platform. + The network name is the same as the cluster name and the address range + follows the existing semantics of the --network option with the exception + that only one subnet is used for the whole cluster rather than one per + location. If a subnet prefix is not specified by the user, TPA will + attempt to select a prefix which results in a subnet large enough to fit + the whole cluster. The key `ip_address` may now be used to specify a + static IP for a Docker instance as long as a named network is specified in + the config.yml. + impact: medium + jira: + - TPA-261 + - TPA-407 + - TPA-434 + relnote: Have `configure` create a user-defined network on Docker + type: Enhancement + - details: >- + Packages are now published targeting RHEL 9 ARM64, and TPA supports + deployments using this architecture and OS. Also updated the list of + supported AWS images to include the RedHat 9 ARM64 AMI provided by Amazon. + The default `instance_type` for ARM64 EC2 instances has been updated from + `a1` to `t4g`, which is the current generation processor available for + burstable general purpose workloads. + impact: low + jira: + - TPA-780 + relnote: Support RedHat Enterprise Linux 9 for ARM architectures + type: Enhancement + - details: >- + Clusters can be configured to use PostgreSQL, EDB Postgres Extended and + EDB Postgres Advanced Server version 17. Barman no longer needs to install + the postgres server package to get the `pg_receivewal` binary when using + EDB Postgres Advanced Server 17 or EDB Postgres Extended 17 since the + binary has been added to the client package for these versions. TPA raises + an architecture error when a cluster is configured with `repmgr` as the + failover_manager as it is not available for Postgres 17. Updated + documentation to reflect supported versions. + impact: low + jira: + - TPA-803 + relnote: >- + Support PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced + Server 17 + type: Enhancement + - details: >- + When using an existing Barman node as a backup node in a new cluster, + users can set `barman_shared: true` in the Barman instance's vars with the + platform set to `bare` and other information supplied as usual for bare + instances. This change allows TPA to skip some configuration steps that + would otherwise fail due to usermod issues, as the Barman user already has + running processes from previous deployments. The shared Barman instance is + treated as a bare instance, so the required access, including the Barman + user's access to the target PostgreSQL instances, must be already in + place. Copying the Barman user's keys from the original cluster to the new + cluster can be used to achieve this, see the Barman section of the TPA + documentation for detailed information. + impact: medium + jira: + - TPA-777 + relnote: >- + Added experimental support for using an existing Barman node as backup + node in new cluster + type: Enhancement + - details: >- + Expose a configurable `efm_user_password_encryption` variable which should + be set to either `'md5'` or `'scram-sha-256'` depending on user + requirements. This controls the `auth-method` for the `efm` Postgres user + in `pg_hba.conf` and the algorithm used for generating it's encrypted + password. In clusters deployed with `compliance` configured to `stig`, the + 'efm' Postgres user's `auth-method` in `pg_hba.conf` will be set to + `scram-sha-256` since FIPS-enabled operating systems do not allow `md5` to + be used. + impact: low + jira: + - TPA-832 + - TPA-836 + relnote: Make `password_encryption` algorithm for `efm` Postgres user configurable. + type: Enhancement + - details: >- + When using the `--hostnames-from` option to `tpaexec configure`, you can + now include two ip addresses on each line, which will be included in the + generated config.yml as public_ip and private_ip. + impact: low + jira: + - TPA-841 + relnote: Allow multiple addresses to be supplied with hostnames + type: Enhancement \ No newline at end of file diff --git a/product_docs/docs/tpa/23/rel_notes/tpa_23.35_rel_notes.mdx b/product_docs/docs/tpa/23/rel_notes/tpa_23.35_rel_notes.mdx new file mode 100644 index 00000000000..6f8bbb20dd3 --- /dev/null +++ b/product_docs/docs/tpa/23/rel_notes/tpa_23.35_rel_notes.mdx @@ -0,0 +1,58 @@ +--- +title: Trusted Postgres Architect 23.35 release notes +navTitle: Version 23.35 +--- + +Released: 25 November 2024 + +New features, enhancements, bug fixes, and other changes in Trusted Postgres Architect 23.35 include the following: + +## Highlights + +- Options for STIG/CIS compliance. +- Support for PGD Lightweight architecture +- Postgis is now a recognized extension. +- Docker `configure` creates named networks with static IP addresses. +- Support for RedHat Enterprise Linux 9 for ARM architectures. +- Support for PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server 17. + +## Enhancements + +
| Description | Addresses |
|---|---|
Support STIG/CIS complianceTPA now supports command-line options to create a cluster configured to conform to many of the requirements of the STIG and CIS security standards. These options cause TPA to set postgresql.conf settings as defined in the relevant standards, to install required extensions, to configure other aspects of system behaviour such as filesystem permissions and user connection limits, and to check for other requirements such as FIPS crypto standards which TPA can't directly impose. The clusters thus generated are not certified by TPA to conform to the standards, but much of the groundwork of creating a conforming cluster is now automated. | |
Add support for PGD Lightweight architectureTPA is now able to generate a PGD Lightweight architecture comprised of three nodes in two locations (2 nodes in Primary and one in Disaster Recovery) designed to ease migrations from physical replication. Users can now run | |
Have | |
Added experimental support for using an existing Barman node as backup node in new clusterWhen using an existing Barman node as a backup node in a new cluster, users can set | |
Add | |
Enable EFM probes when a PEM agent is registered on an EFM nodeThe | |
Support RedHat Enterprise Linux 9 for ARM architecturesPackages are now published targeting RHEL 9 ARM64, and TPA supports deployments using this architecture and OS. Also updated the list of supported AWS images to include the RedHat 9 ARM64 AMI provided by Amazon. The default | |
Support PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server 17Clusters can be configured to use PostgreSQL, EDB Postgres Extended and EDB Postgres Advanced Server version 17. Barman no longer needs to install the postgres server package to get the | |
Make | |
Allow multiple addresses to be supplied with hostnamesWhen using the |
| Description | Addresses |
|---|---|
Remove deprecated | |
The | |
Add new option | |
Improve postgres-monitor scriptImprove postgres-monitor script to better manage recoverable errors and add retries on network errors to ensure that it won't return failure when it just didn't allow enough time for postgres service to be fully started. | |
Only add nodes with |
| Description | Addresses |
|---|---|
Fix tpaexec test for pgd-proxy config verificationFixed a bug whereby the test that ensures the current pgd-proxy configuration matches the expected configuration would fail for version < 5.5.0. This fix ensures that TPA won't try to query configuration keys added in version 5.5.0. | |
Fix case where | |
Download correct | |
Fix an issue whereby in some cases error messages would be repeated even after successful tasks.TPA now clears the error message stack after each task to ensure messages are not spuriously repeated | |
Fix issue that prevented the addition of replicas to Patroni clustersFixed an issue whereby new replicas in Patroni clusters would fail with errors related to replication slots. | |
Add | |
Set |
{headingText}
-
+
);
const Page = () => {
@@ -173,7 +173,7 @@ const Page = () => {
{updates.slice(0, 2).map((update) => (
-
+