After the upgrade to Odin Automation 7.1, when trying to deploy new functionalities using PostgreSQL DB replication mechanisms there are issues in Task Manager related to the certificate validity.
Starting from 7.1, the nodes hosting master PostgreSQL database (Operations/Billing) and its replica, use public and private keys for data encryption. Therefore, if the keys are invalid or expired the communications between slave and master DB will be broken. This causes issues with all the functionalities using DB replication mechanisms (master-slave PostgreSQL DB communications) like Business Intelligence, APS Booster, PostgreSQL high availability (PGHA) cluster. For the new 7.1 installations the certificate is 100 years by default, however, the upgrade scenarios to Odin Automation 7.1 imply that the certificate validity stays as it was configured during its first installation. Before 7.1 release, the certificate's default validity was 30 days.
Important: Before installing the APS Booster, PGHA cluster, and Business Intelligence, make sure that the certificate's remaining period of validity is minimum 5 years (here we imply the period from the current date till the expiration date is not less than 5 years). Otherwise, you should update your certificate. BUT before generating a new valid certificate check if the existing certificate is already used in your system. Generating a new certificate will overwrite the existing one which will cause issues with the services already using it.
To check the certificate's period of validity, do the following:
Log in to the node, hosting the master PostgreSQL DB (MN or Billing DB node).
To view the certificate's period of validity, run the following command:
# openssl x509 -in /var/lib/pgsql/9.X/data/server.crt -noout -dates
9.X- hereinafter should be replaced with your DB version, for example 9.6
For example, the output can be the following:
notBefore=Oct 9 20:17:21 2010 GMT notAfter=Aug 13 20:17:21 2017 GMT
Let's consider the following scenarios how to solve the issue with the certificate in each case depending on the valitidy.
Case 1. The existing certificate is expired
You can regenerate a new valid certificate using the following command on master DB node:
# su - postgres -c 'openssl req -nodes -new -x509 -days 36500 -keyout /var/lib/pgsql/9.X/data/server.key -out /var/lib/pgsql/9.X/data/server.crt -subj "/C=RU/O=Odin/CN=OA System Database Master Endpoint"'
The certificate and key should belong to user
This command will re-issue a new server certificate for approximately 100 years. After generation of a new certificate, restart PostgreSQL. This will cause a downtime for a while.
Case 2. The existing certificate validity is less than 5 years and it is not used by slave nodes
In this case regenerate the certificate as it is described in the Case 1.
Case 3. The existing certificate validity is less than 5 years and it is already used by slave nodes
If the existing certificate is already used by slave nodes, the generation of a new certificate will overwrite the existing one and break the existing communications between master and slave nodes, hosting the DBs.
Important: If you make a decision to generate a new certificate, make sure that the newly issued certificate is propagated to all slave nodes, hosting the database.
Follow the steps below:
On master node:
Regenerate a new valid certificate as it is described in the Case 1.
Copy the newly generated certificates to a slave node (if you have several slave nodes, then copy to all of them).
# scp /var/lib/pgsql/9.X/data/server.* root@<slave_node_IP_address>:/var/lib/pgsql/9.X/data
On slave node(s):
Create a directory for slave certificate (if it does not exist yet):
# su - postgres -c 'mkdir -p "/var/lib/pgsql/.postgresql"'
Copy the certificate from
/var/lib/pgsql/.postgresql/and rename it as
# su - postgres -c 'cp -f "/var/lib/pgsql/9.X/data/server.crt" "/var/lib/pgsql/.postgresql/root.crt"'
- Restart PostgreSQL.