I have discovered that the default init script distributed with pgsql v8.1 sets the listening port to 5432 but does not enable tcp/ip connections. One must add the -i switch to the invocation line in the script. I am not sure if this is an oversight or whether there is another way to tell postmaster to start with tcp/ip listening enabled that I am unaware of. However, I thought that this information might be of interest to anyone else running a non-distro version of pgsql.
Regards, Jim
-- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3
James B. Byrne wrote:
I have discovered that the default init script distributed with pgsql v8.1 sets the listening port to 5432 but does not enable tcp/ip connections. One must add the -i switch to the invocation line in the script. I am not sure if this is an oversight or whether there is another way to tell postmaster to start with tcp/ip listening enabled that I am unaware of. However, I thought that this information might be of interest to anyone else running a non-distro version of pgsql.
Regards, Jim
-- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
edit your
/var/lib/pgsql/data/postgresql.conf
and set the variable
listen_addresses
leonel
James B. Byrne wrote:
I have discovered that the default init script distributed with pgsql v8.1 sets the listening port to 5432 but does not enable tcp/ip connections. One must add the -i switch to the invocation line in the script. I am not sure if this is an oversight or whether there is another way to tell postmaster to start with tcp/ip listening enabled that I am unaware of. However, I thought that this information might be of interest to anyone else running a non-distro version of pgsql.
Regards, Jim
-- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Jim, also be aware that there is a non-password login from root on that distro, as well as the CentOS version. I found out the hard way after being compromised by some idiot portscanning me. No damage, but thought it odd to have a password-less service open to the world.
Sam
On Fri, 2005-11-18 at 16:41 -0500, Sam Drinkard wrote:
James B. Byrne wrote:
Jim, also be aware that there is a non-password login from root on that distro, as well as the CentOS version. I found out the hard way after being compromised by some idiot portscanning me. No damage, but thought it odd to have a password-less service open to the world.
---- I got the impression that it was an upstream decision...just like mysql- server
Craig
Craig White wrote:
On Fri, 2005-11-18 at 16:41 -0500, Sam Drinkard wrote:
James B. Byrne wrote:
I got the impression that it was an upstream decision...just like mysql- server
Craig
Could be, like the deal with sendmail. I assume (wrong thing to do it seems) that things you think would be protected aren't and things that aren't are.
On Fri, 2005-11-18 at 17:10 -0500, Sam Drinkard wrote:
Craig White wrote:
On Fri, 2005-11-18 at 16:41 -0500, Sam Drinkard wrote:
James B. Byrne wrote:
I got the impression that it was an upstream decision...just like mysql- server
Craig
Could be, like the deal with sendmail. I assume (wrong thing to do it seems) that things you think would be protected aren't and things that aren't are.
---- even if installed, it doesn't get started without a kick by the user. If the user is going to populate it with data, then it seems logical that the user has to log in. If the user has to log in, how is he going to know the password?
Craig
On Friday 18 November 2005 16:41, Sam Drinkard wrote:
James B. Byrne wrote:
I have discovered that the default init script distributed with pgsql v8.1 sets the listening port to 5432 but does not enable tcp/ip connections. One must add the -i switch to the invocation line in the script.
As one of the authors of that initscript, I can state with certainty that is is intentional and by design. (See Craig's followups for why; you nailed the reasons, Craig).
I am not sure if this is an oversight or whether there is another way to tell postmaster to start with tcp/ip listening enabled that I am unaware of.
This has already been answered in this thread. Previously, the tcpip_socket parameter was used, but was changed (CVSweb for src/backend/utils/misc/postgresql.conf.sample): ++++++++++++++++++++++ Revision 1.109: download - view: text, markup, annotated - select for diffs Tue Mar 23 01:23:48 2004 UTC (19 months, 4 weeks ago) by tgl Branches: MAIN Diff to previous 1.108: preferred, colored Changes since revision 1.108: +3 -3 lines
Replace the virtual_host and tcpip_socket parameters with a unified listen_addresses parameter, as per recent discussion. The default behavior is now to listen on localhost, which eliminates the need for the -i postmaster switch in many scenarios.
Andrew Dunstan ++++++++++++++++++++++
However, I thought that this information might be of interest to anyone else running a non-distro version of pgsql.
This is true for the distro versions after the above mentioned change.
Note that the CentOS default 7.4 PostgreSQL uses tcpip_socket instead of listen_addresses, but that the default initscript still doesn't start postmaster with a -i.
Jim, also be aware that there is a non-password login from root on that distro, as well as the CentOS version. I found out the hard way after being compromised by some idiot portscanning me. No damage, but thought it odd to have a password-less service open to the world.
This is why -i was made non-default back in PostgreSQL 6.5 days. If the postgres database superuser were to be created by default with a password, then that password would also be well-known (search the pgsql-hackers list archives for some of the many discussions on this topic from the past). Thus, the PostgreSQL developers (myself included once I became RPM maintainer) decided to make TCP/IP listening not the default (it was already the default in the tarball distribution, and I decided to continue this in the RPM). This behavior is now different as of version 8 due to listen_addresses (see Andrew's comment in the CVS log entry above), as now it defaults to listening on localhost only (fixing the most common instance of a local php process accessing localhost:5432).
You will find me (at one of my other e-mail addresses) listed in many of those files, and at http://www.postgresql.org/developer/bios so this is one area I actually know a little about. Not a lot; but a little nonetheless.
On Friday 18 November 2005 15:42, James B. Byrne wrote:
I have discovered that the default init script distributed with pgsql v8.1 sets the listening port to 5432 but does not enable tcp/ip connections. One must add the -i switch to the invocation line in the script.
Oh, I forgot to mention one detail you will want to know about. The initscript will get overwritten the next time you upgrade the RPM (it is not a configuration file, after all, but a program and part of the package and subject to change from time to time). Thus if your postmaster quits responding when you upgrade next, you'll know why.
For those using the regular CentOS PostgreSQL (either CentOS 3 or 4) if you add the -i in the initscript be prepared for a yum update to change it back (the initscript is NOT a configuration file, but part of the program itself. /var/lib/pgsql/data/postgresql.conf is the correct place, and will never be overwritten as the RPM is currently written unless you run an initdb (which creates that file from the postgresql.conf.sample template).
Oh, I forgot to mention one detail you will want to know about. The initscript will get overwritten the next time you upgrade the RPM (it is not a configuration file, after all, but a program and part of the package and subject to change from time to time). Thus if your postmaster quits responding when you upgrade next, you'll know why.
Perfectly reasonable, but along these lines (at least for the rhel/centos/fedora rpms) why not seperate things out like what's done with bind, apache, nfs etc, and put any options like -i into an /etc/sysconfig/pgsql file?
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Friday 18 November 2005 22:42, Jim Perrin wrote:
Oh, I forgot to mention one detail you will want to know about. The initscript will get overwritten the next time you upgrade the RPM (it is not a configuration file, after all, but a program and part of the package and subject to change from time to time). Thus if your postmaster quits responding when you upgrade next, you'll know why.
Perfectly reasonable, but along these lines (at least for the rhel/centos/fedora rpms) why not seperate things out like what's done with bind, apache, nfs etc, and put any options like -i into an /etc/sysconfig/pgsql file?
That's an excellent question, Jim, and with current packages might be an option.
However, in the future the PostgreSQL RPM's will gain the feature of allowing multiple databases of multiple versions to coexist; in this case one database in the cluster might need to listen on one address and one port, and another on another address:port pair, and another might need Unix sockets only. Apache is probably the only other package among those that has this sort of capability (similar to, yet different from, virtual hosting), but I envision the ability to run a 7.4.8 PostgreSQL backend in parallel with an 8.1 backend with Slony-I replicating from the old to the new for migration and migration testing. That would be like running multiple websites on the box with multiple versions of apache.
Consistent with the PostgreSQL philosophy, the configuration data for the database itself belongs with the database's data (it is possible to store it elsewhere, but it is still database and not backend specific).
I could have, for instance, a database in /var/lib/pgsql/data (the default) listening on localhost:5432, a database in /var/lib/pgsql/finance listening on 192.168.1.12:6793, a database in /var/lib/pgsql/website listening on 209.119.165.234:1520 (and running as a different user, in fact, with a different userbase, different set of postgres user passwords, etc).
This makes the obvious solution not so obvious; but, yes, it has been suggested before. As postgresql.conf solves the problem in the general case in a manner consistent with all the non-Linux PostgreSQL installations (I guess you heard Sun's news today, right?), I decided to not do it the /etc/sysconfig/pgsql way. Devrim, Tom, and I might decide to do it differently some day; past are the days I decided these things more or less unilaterally (thank goodness; I didn't always make the right choices!).
I hope that helped understand the mindset; sorry for the verbosity, I don't have time to make it shorter tonight.
-
Craig White -
James B. Byrne -
Jim Perrin -
Lamar Owen -
Leonel Nunez -
Sam Drinkard