change .ssh directory perms to match the postgres perms on .ssh dirs to support both nfs and fsgroup file system types with the pgbackrest feature

jmccormick2001 · jmccormick2001 · commit 93e5ad6e16a6 · 2019-01-17T17:44:32.000-06:00
diff --git a/apiservermsgs/common.go b/apiservermsgs/common.go
@@ -17,7 +17,7 @@ limitations under the License.
 
 import ()
 
-const PGO_VERSION = "3.5.0-rc7"
+const PGO_VERSION = "3.5.0-rc6"
 
 // Ok status
 const Ok = "ok"
diff --git a/centos7/Dockerfile.pgo-backrest-restore.centos7 b/centos7/Dockerfile.pgo-backrest-restore.centos7
@@ -23,7 +23,7 @@ ADD bin/uid_postgres.sh /opt/cpm/bin
 RUN chmod g=u /etc/passwd && \
         chmod g=u /etc/group
 
-RUN mkdir /.ssh && chown 26:26 /.ssh && chmod g+rwx /.ssh
+RUN mkdir /.ssh && chown 26:0 /.ssh && chmod g+rwx /.ssh
 
 ENTRYPOINT ["/opt/cpm/bin/uid_postgres.sh"]
 
diff --git a/conf/postgres-operator/pgo.yaml b/conf/postgres-operator/pgo.yaml
@@ -4,7 +4,7 @@ Cluster:
   CCPImagePrefix:  crunchydata
   Metrics:  false
   Badger:  false
-  CCPImageTag:  centos7-11.1-2.3.0-rc5
+  CCPImageTag:  rhel7-9.6.11-2.3.0-rc5
   Port:  5432
   User:  testuser
   Database:  userdb
@@ -83,4 +83,4 @@ Pgo:
   LSPVCTemplate:  /pgo-config/pgo.lspvc-template.json
   LoadTemplate:  /pgo-config/pgo.load-template.json
   COImagePrefix:  crunchydata
-  COImageTag:  centos7-3.5.0-rc7
+  COImageTag:  rhel7-3.5.0-rc6
diff --git a/hugo/content/Design/_index.md b/hugo/content/Design/_index.md
@@ -170,7 +170,8 @@ At this point the PG database is back in a working state.  DBAs are still respon
 Other things to take into account before you do a restore:
 
  * if a schedule has been created for this PG cluster, delete that schedule prior to performing a restore
- * after a restore, exec into the PG primary and make sure the database has fully recovered by looking at the database logs, if not recovered, you might have to run psql command *select pg_wal_replay_resume()* to complete the recovery
+ * after a restore, exec into the PG primary and make sure the database has fully recovered by looking at the database logs, if not recovered, you might have to run psql command *select pg_wal_replay_resume()* to complete the recovery, on PG 9.6
+systems, the command you will use is *select pg_xlog_replay_resume()*.
  * a restore is destructive in the sense that it deletes the existing Deployment, not the existing primary PVC, that is left but will become unused when the primary Deployment is removed, be sure to create a pgbasebackup prior to restoring, make sure you can restore from that pgbasebackup to avoid any data loss
  * there is currently no Operator validation of user entered pgBackRest command options, you will need to make sure to enter these correctly, if not the pgBackRest restore command can fail.
  * the restore workflow does not perform a backup after the restore nor does it verify that any replicas are in a working status after the restore, it is possible you might have to take actions on the replica to get them back to replicating with the new restored primary.
diff --git a/rhel7/Dockerfile.pgo-backrest-restore.rhel7 b/rhel7/Dockerfile.pgo-backrest-restore.rhel7
@@ -25,7 +25,7 @@ ADD bin/uid_postgres.sh /opt/cpm/bin
 RUN chmod g=u /etc/passwd && \
         chmod g=u /etc/group
 
-RUN mkdir /.ssh && chown 26:26 /.ssh && chmod g+rwx /.ssh
+RUN mkdir /.ssh && chown 26:0 /.ssh && chmod g+rwx /.ssh
 
 ENTRYPOINT ["/opt/cpm/bin/uid_postgres.sh"]
 
