Postgresql 9.2 to 9.

5 update on a cPanel system

Introduction

cPanel by default installs whatever version comes with the distribution which on
Centos 7.2 (11511) is postgresql 9.2 which lacks many features of the newer
versions. On a server without cPanel the upgrade would be relatively simple with an
backup of desired files in the old installation, installation of the new package,
shutdown of the old, and then use pg_upgrade to upgrade from the old to the new
installation.

However, having cPanel installed throws a big monkey wrench into the process.
cPanel uses the script scripts/installpostgres to install postgresql and this
script and it's supporting programs make assumptions about where things are and do
not allow input. For example, version 9.2 stores it's data in /var/lib/pgsql/data
while newer versions use a versioned install with /var/lib/pgsql/9.x/data as their
storage location and since the script doesn't ask the install fails and postgres
does not show up in WHM.

I made notes as I was working through the upgrade and compiled them to help
anyone else who has to do this. It would be nice if cPanel would provide good
support for PostgreSQL in WHM. I'd like to see them get rid of the installpostgres
script and leverage yum to do the install, let us fill out some data in WHM about
where the data files are and whatever else is needed so new updates can be done as
needed without a lot of problems. There is a feature request to provide better
support for PostgreSQL at https://features.cpanel.net/topic/improved-postgresql-
support.

Background

Intially postgresql-9.5 was installed but it did not show up in WHM. Many things
were tried such as linking the 9.5 data and backup directories to /var/lib/pgsql
but the cPanel install script kept failing. To troubleshoot 9.5 was removed and
the version supplied with Centos 7, 9.2, was installed using cPanel's install
script. Now WHM found postgresql and it could be configured and the cPanel
database wizard, maintenance, and phpPGAdmin functions worked. After postgresql
was working the pdo driver was installed for PHP by using EasyApache to rebuild
Apache and PHP. The pdo install worked but pdo_pgsql had to be downloaded (not
installed) from PECL and then compiled and installed since EasyApache does not
include it. The --with-pdo-pgsql=shared switch had to be used or the driver does
not show up. Test web pages were created that connected using each method and
displayed data from a test database's test table.

Upgrade

Now that it was determined postgresql 9.2 worked with cPanel the next step was to
upgrade to the current version 9.5. This was be done by installing 9.5 and using
pg_upgrade to upgrade.

The overall process was

* Backup files
* List current postgresql files
* Install current version
* Shutdown old version
* Initialize cluster for new version
* Adjust authentication
* Use pg_upgrade to upgrade to the new version
* Start new server
 * Test

Backup files
Files and directory are backed up to /root/save directory. It's important to
get the pg_hba.conf file which has the permissions for accesing databases, This
was not really needed since the pg_upgrade moved the files but was done as an added
precaution.

* /var/lib/pgsql directory backed up to /root/save/varlibpgsql directory

* pg_dumpall dumps all databases to the postgres home directory and a copy
saved to the /root/save directory. It was necessary to change pg_hba.conf so that
the postgres user had trust as a method. If left at md5 which cPanel postgresql
config sets it to pg_dumpall kept asking for a password and then failed the dump.
Set it back when done.

List current postgresql files

The output of locate is redirected to files for future reference as to where

files are stored.

* locate postgresql > <file>

* locate pg_ > <file>

Install Current Version

This step gets the current version files installed but not running.

* Download and install postgresql repository for Centos 7

* Add this to CentOS-Base.repo base and update sections so yum will not show
older versions

exclude=postgresql*

* Run yum install postgresql95 postgresql95-devel posgresql95-libs

postgresql95-server

* May want to add postgresql95-contrib later

* At this point WHM showed a configure postgresql entry in SQL Services but
said it was not running even when it was. Ignore this.

Shutdown the current version

systemctl stop postgresql

Initialize New Cluster

Run these commands to initialize the cluster. This creates the directories and
files needed such as the data directory and configuration files.

su - postgress
initdb -D /var/lib/pgsql/9.5/data
exit

Adjust Authentication

The new pg_hba.conf file should have authentication set to peer because
pg_upgrade will connect to both the old and new servers several times.
 Upgrade

The utility pg_upgrade is used to upgrade.

* The --check option was used as do a dry run and sort out any errors. Do not
run the new server but leave the old one running. If the old one is not running
the --check process cannot find it and the command throws an error.

* Run pg_upgrade with --check to see if there are any problems. The old server
should be running and run pg_upgrade with this command.

pg_upgrade.exe
--old-port=5432 # Default for postgresql. Change as needed
--old-datadir=/var/lib/pgsql/data
--new-datadir=/var/lib/pgsql/9.5/data
--old-bindir=/usr/bin
--new-bindir=/usr/pgsql-95/bin
--check

The --check does a dry run and lists any adjustments needed. Once everything
is good remove the --check, stop the old server, and run pg_upgrade again. It
will update files to the new version formats.

Note: The --link option is supposed to create a hard link meaning the inodes
are the same for /var/lib/pgsql/data and /var/lib/pgsql/9.5/data but that did not
happen and cPanel could not see postgresql. Do not use the --link option and
create a symlink from the 9.5 data and backup directories to /var/lib/pgsql/data
and backup after 9.5 is installed. It will be necessary to remove the existing
backups and data directories before creating the symlink.

cd /var/lib/pgsql/9.5
rm -rf /var/lib/pgsql/data /var/lib/pgsql/backups
ln -s /var/lib/pgsql/9.5/data /var/lib/pgsql
ln -s /var/lib/pgsql/9.5/backup /var/lib/pgsql

* cPanel expects the postgresql files to be in /usr/bin but most are in

/usr/pgsql-9.5/bin so use this script to link them to /usr/bin. This is from a
post on the cPanel forums about upgrading from 8.4 to 9.2.

https://forums.cpanel.net/threads/upgrade-postresql-from-8-4-to-9-2.340042/

This can be entered as one line. It traverses all the files i1n /usr/pgsql-
9.5/bin, renames the corresponding file in /usr/bin, and then links the /usr/pgsql-
9.5/bin file to /usr/bin. If this is not done there will be old version files run
when postgresql commands are executed. Once everything is working the .2 files can
be deleted.

cd /usr/pgsql-9.5/bin/; for f in *; do echo $f; [ -e /usr/bin/$f ] && mv

/usr/bin/$f /usr/bin/$f.2; ln -s $(pwd)/$f /usr/bin/$f; done

Possible Issues in the Upgrade Process

* pg_upgrade fails and the /var/lib/pgsql/pg_upgrade_server.log shows this

entry. This is because in newer versions unix_socket_directory does not exist but
has been changed to unix_socket_directories - note the change from directory to
directories. This is the error produced.

command: "/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D

"/var/lib/pgsql/data" -o "-p 5432 -b -c listen_addresses='' -c
unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >>
"pg_upgrade_server.log" 2>&1
waiting for server to start....FATAL: unrecognized configuration
parameter "unix_socket_directory"
stopped waiting

The solution is this, taken from this source by Ziggy who has strong bash
kung-fu skills. http://dba.stackexchange.com/questions/50135/pg-upgrade-
unrecognized-configuration-parameter-unix-socket-directory - Fix for it from Ziggy.

I (meaning Ziggy) hacked the problem by running (as root):

mv /usr/bin/pg_ctl{,-orig}
echo '#!/bin/bash' > /usr/bin/pg_ctl
echo '"$0"-org "${@/unix_socket_directory/unix_socket_directories}"'
>> /usr/bin/pg_ctl
chmod +x /usr/bin/pg_ctl

Run pg_upgrade as intended, then undo the hack:

mv -f /usr/bin/pg_ctl{-org,}

Start New Server

Restore the pg_hba.conf file if desired or just edit it to add the values
cPanel had placed. Basically cPanel removed what was there and created these
entries. The samerole entries simply say that if a user or a group has the same
name as the database allow access. The md5 will ask for an encrypted password.
The ::1/128 is the ipv6 localhost version and is needed only if the server tries to
connect using ipv6 and can be omitted if not needed. This server does try and use
ipv6.

local all postgres md5

local samerole all md5
host samerole all 127.0.0.200/32 pam pamservice=postgresql_cpses
host samerole all 127.0.0.1/32 md5
host all postgres 127.0.0.1/32 md5

host samerole all ::1/128 md5

Enable the server so it starts on reboots and then start the server.

systemctl enable postgresql-9.5

systemctl start postgresql-9.5
systemctl disable postgresql # Disable old server

Test

Tests are run with cPanel, WHM, and the web test pages. If logged into cPanel
log out and log back in.

* WHM

After the upgrade there was a configure postgresql entry under SQL Services
but if it was clicked on WHM said the server was not running even though it was.
Ignore this but it would be nice to know what WHM is looking for.

* cPanel
 Despite the error thrown by WHM cPanel can see the databases. If cPanel was
logged into while the upgrade was done logout and then back in.

* Login as a cPanel user and see if the Postgresql databases application can
see the databases and users by using the PostgreSQL Databases entry.

* Run pgpadmin and make sure the database(s) can be accessed as well as the
users.

* Web page

Run the web test pages to test pdo and pdo_pgsql drivers. The test pages
used pdo and pdo_sql methods in php to connect to a test database. The database
had one table with one column containing a text string. If these are working the
text in the test tables should be displayed on the web page.

Additonal Notes

* This is printed by pg_upgrade after it completes and is here for reference.

If there are adjustments that need to be made manually pg_upgrade will list them
and if it has created a script file to fix any issues the script file name will be
given.

After upgrade

f you want to start the old cluster, you will need to remove
the ".old" suffix from /var/lib/pgsql/data/global/pg_control.old.
Because "link" mode was used, the old cluster cannot be safely
started once the new cluster has been started.

Linking user relation files

ok
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
./delete_old_cluster.sh

The delete_old_cluster.sh script deletes the data directory.

* cPanel Notes

(https://documentation.cpanel.net/display/1148Docs/PostgreSQL+Databases)
stresses that databases and users should be created by using the Postgresql
Database Wizard in cPanel. Don't use phpPGAdmin to do this but phpPGAdmin can be
used to modify tables, etc. It appears that cPanel can't see databases created on
the server but more testing needs to be done.