FIPS-compliant installation specifications

December 23, 2024

If installing EFM on FIPS-complaint servers using TPA:

TPA will be unable to create the efm database user if FIPS is enabled during the deployment. To ensure that EFM installs correctly during the TPA deployment, perform the following steps:

  1. Disable FIPS on all servers during the deployment

  2. Re-enable FIPS after the deployment

  3. Create a scram-sha-256 encrypted password for the efm database user

After deployment with the default md5 encryption, create a scram-sha-256 encrypted password for the efm database user and store that password in the TPA vault:

>> On database server:
enterprisedb@database-server1#  psql -d postgres
>>
postgres>    SHOW password_encryption;

(Expected output: "SCRAM-SHA-256". If not, run "SET password_encryption = 'scram-sha-256';")

postgres>    \password efm

(Type new password 2x)

>> On TPA server:
root@tpa-server#  cd ~/clusters/cluster-name
root@tpa-server#  tpaexec store-password . efm

(Type new password 2x)

 

If installing Barman on a FIPS-complaint server (either using TPA or manually):

The barman-wal-archive command is not FIPS compliant. You will need to use rsync to ensure proper archiving using Barman on a FIPS-compliant server. Perform the following steps based on the type of deployment:

  1. TPA deployments

    On a TPA installation, navigate to the $PGDATA/conf.d directory and open the file 9999-override.conf. Enter the following parameter value (updating the TPA server and primary database server hostnames in the command to match your own environment)  to use rsync in the archive_command:

    >>        archive_command = 'rsync -a %p
              barman@tpa-server:/barman/database-server1/incoming/%f'    

    Reload the configuration for the change to take effect.

    >> On each database server:
    enterprisedb@database-server1/database-server2#  psql -d postgres
    >>
    postgres>    SELECT pg_reload_conf();
    
    (Expected output: "t")

    Perform these steps on all database servers in the cluster.

    NOTE: The path in the archive_command will still reference the database-server1 hostname on each server in the cluster since Barman uses the primary database server name to refer to the entire cluster.

  2. Manual deployments

    On manual deployments, the archive_command can be updated directly in the postgresql.conf file or by using the psql utility.

    Option 1: Update the postgresql.conf file directly on all database servers in the cluster.

    Navigate to the $PGDATA directory, open the postgresql.conf file, and find the archive_command parameter. Enter the below archive_command value to use rsync (updating the server names in the command to match the TPA server and primary database server hostnames in your own environment):

    >> On each database server:
    enterprisedb@database-server1/database-server2#  cd $PGDATA
    enterprisedb@database-server1/database-server2#  vi postgresql.conf
    
    >>        archive_command = 'rsync -a %p
              barman@tpa-server:/barman/database-server1/incoming/%f'
              
    >> Save and exit.
    
    enterprisedb@database-server1/database-server2#  psql -d postgres -c "SELECT pg_reload_conf();"
    
    (Expected output: "t")

    Option 2: Update the archive_command using the psql utility on all database servers in the cluster.

    Log onto the database using psql, and use ALTER SYSTEM to change the archive_command. Update the rsync command below to refer to the TPA server and primary database server hostnames in your own environment.

    >> On each database server:
    enterprisedb@database-server1/database-server2#  psql -d postgres
    >>
    postgres>    ALTER SYSTEM SET archive_command TO "archive_command = 'rsync -a %p
                 barman@tpa-server:/barman/database-server1/incoming/%f'"
                 
    postgres>    SELECT pg_reload_conf();
    
    (Expected output: "t")

    If the archive_command is updated using ALTER SYSTEM, the new archive_command will be stored in the postgresql.auto.conf file within the data directory.

NOTE: The path in the archive_command will still reference the database-server1 hostname on each server in the cluster since Barman uses the primary database server name to refer to the entire cluster. 

Share this