Gottas in Upgrading to Red Hat 8.0 - Mailing list pgsql-novice

After upgrading my linux server from Redhat 7.1 to Rehat 8.0, I
have come across some gotchas.  I am making a list of them in
case they are useful to others who also want to install Redhat 8.0
Forward this to people who might find it helpful (like maybe the
webteam?).  Anyone not using linux or having any plans to do
so can safely delete this message.

Paul "Webdaddy" Sundling

In Redhat 7.1 Postgres 7.2.1 was included and it's default
permissions in /var/lib/pgsql/data/pg_hba.conf were:

  # By default, allow anything over UNIX domain sockets and localhost.
  local        all                                           trust
  host         all         127.0.0.1     255.255.255.255     trust

In Redhat 8.0 Postgres 7.2.2 was included and it's default permissions
in /var/lib/pgsql/data/pg_hba.conf are:

  local  all     ident   sameuser

There are good comments in the file that explain what this
pg_hba.conf does.  In essence they've tightened security from
any connection from the local machine to where you can only
connect to a database with the same username, expect for the
postgres user.  So if you do the command "psql -U postgres -d template1",
this will work for the postgres unix account, but not even root!
So you might want some level of security in between.

With Postgres 7.2.1 with the default configuration the connection
host could be specified as localhost with no problem.  With
Postgres 7.2.2 if you specify ANY host, even localhost you
will get your connection refused.  Either don't use any host
in your connection string to the database or start postmaster
with the -i flag with makes postgres listen for TCP socket
connections as well as local sockets. To change the -i flag, i
you can change the startup script /etc/rc.d/init.d/postgresql
and change the line

  su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -p /usr/bin/postmaster start  > /dev/null 2>&1" < /dev/null

to

su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -p /usr/bin/postmaster -o -i start  > /dev/null 2>&1" <
/dev/null

You may have further gotchas in Apache configs since the change from
the 1.3 tree to the 2.0 version tree is pretty big.


Apache and PHP didn't seem to work out of the box in 8.0.  Actually
PHP does work, but I've been lazy and have used the short version of
the tags (<? and ?>).  Redhat 8.0 uses Apache 2.0 which by
default does not process the short version.  So not even a phpinfo()
would work until I used the long version of the tags (<?php and ?>).
If you have this situation you can avoid changing your scripts by
editing /etc/php.ini and changing the file:
  Short_open_tag = Off
to
  Short_open_tag = On

Some scripts that use that register global variables may not work.
As of PHP 4.2.0, the default in the configs for register_globals was
changed to off.  This was done because it can be a security hazard
if you don't validate the input data.  Fortunately, I did consider
this in my scripts.  If you don't want to change such scripts you
can change the value in /etc/php.ini from
  register_globals = Off
to
  register_globals = On



After upgrading my linux server from Redhat 7.1 to Rehat 8.0, I
have come across some gotchas.  I am making a list of them in
case they are useful to others who also want to install Redhat 8.0
Forward this to people who might find it helpful (like maybe the
webteam?).  Anyone not using linux or having any plans to do
so can safely delete this message.

Apache and PHP didn't seem to work out of the box in 8.0.  Actually
PHP does work, but I've been lazy and have used the short version of
the tags (<? and ?>).  Redhat 8.0 uses Apache 2.0 which by
default does not process the short version.  So not even a phpinfo()
would work until I used the long version of the tags (<?php and ?>).
If you have this situation you can avoid changing your scripts by
editing /etc/php.ini and changing the file:
  Short_open_tag = Off
to
  Short_open_tag = On

Some scripts that use that register global variables may not work.
As of PHP 4.2.0, the default in the configs for register_globals was
changed to off.  This was done because it can be a security hazard
if you don't validate the input data.  Fortunately, I did consider
this in my scripts.  If you don't want to change such scripts you
can change the value in /etc/php.ini from
  register_globals = Off
to
  register_globals = On

In Redhat 7.1 Postgres 7.2.1 was included and it's default
permissions in /var/lib/pgsql/data/pg_hba.conf were:

  # By default, allow anything over UNIX domain sockets and localhost.
  local        all                                           trust
  host         all         127.0.0.1     255.255.255.255     trust

In Redhat 8.0 Postgres 7.2.2 was included and it's default permissions
in /var/lib/pgsql/data/pg_hba.conf are:

  local  all     ident   sameuser

There are good comments in the file that explain what this
pg_hba.conf does.  In essence they've tightened security from
any connection from the local machine to where you can only
connect to a database with the same username, expect for the
postgres user.  So if you do the command "psql -U postgres -d template1",
this will work for the postgres unix account, but not even root!
So you might want some level of security in between.

With Postgres 7.2.1 with the default configuration the connection
host could be specified as localhost with no problem.  With
Postgres 7.2.2 if you specify ANY host, even localhost you
will get your connection refused.  Either don't use any host
in your connection string to the database or start postmaster
with the -i flag with makes postgres listen for TCP socket
connections as well as local sockets. To change the -i flag, i
you can change the startup script /etc/rc.d/init.d/postgresql
and change the line

  su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -p /usr/bin/postmaster start  > /dev/null 2>&1" < /dev/null

to

su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -p /usr/bin/postmaster -o -i start  > /dev/null 2>&1" <
/dev/null

You may have further gotchas in Apache configs since the change from
the 1.3 tree to the 2.0 version tree is pretty big.