Thread: phppgadmin not working under v. 8.1
Hello! I am running a debian sarge system, which originally had postgresql 7.4.7-6; I removed that installation of postgresql and compiled version 8.1, without problems. Now, the issue is, I cannot connect from phppgadmin (which I didn't touch, so it's sarge's original 3.5.2-5), it returns each time "login failed" ; php and phppgadmin are working properly, or at least they were when I was still running the older postgres version, user / password are also the same as before. I looked through this list, and the only hints I found pointed towards the line "tcpip_socket" in postgresql.conf; but it seems that that line has been replaced by a more general one "listen_addresses" ( http://www.postgresql.org/docs/8.1/interactive/release-8-0.html ) I modified the postgresql.conf file uncommenting the port number and giving the (private) network address number as argument to "listen_addresses", so: #--------------------------------------------------------------------------- # CONNECTIONS AND AUTHENTICATION #--------------------------------------------------------------------------- # - Connection Settings - listen_addresses = '192.168.1.0' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all port = 5432 max_connections = 100 ......................... and the pg_hba.conf file to listen to all local connections and all connections coming from the local network, so # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust host all all 192.168.1.0/24 trust # IPv6 local connections: host all all ::1/128 trust -------------- restarting thereafter the postmaster, but nonetheless it is still impossible to authenticate to it via phppg admin (it may be obvious, but the psql client connects perfectly) I am sorry if I am skipping something obvious, and apologize in advance for it if this were the case; anyway, I would be very grateful if somebody could give me some hint where to look for, since I need the visual interface for daily work. Thank you all very much for the continuous feedback, Bárbara Figueirido S.C. de Bariloche
If you completely wiped the previous install, including the data directory then you would have lost your pg_hba.conf Have a look and check it. More details: http://www.postgresql.org/docs/8.1/static/client-authentication.html#AUTH-PG -HBA-CONF Cheers, -p -----Original Message----- From: pgsql-novice-owner@postgresql.org [mailto:pgsql-novice-owner@postgresql.org] On Behalf Of barbara figueirido Sent: Friday, 25 August 2006 11:59 To: pgsql-novice@postgresql.org Subject: [NOVICE] phppgadmin not working under v. 8.1 Hello! I am running a debian sarge system, which originally had postgresql 7.4.7-6; I removed that installation of postgresql and compiled version 8.1, without problems. Now, the issue is, I cannot connect from phppgadmin (which I didn't touch, so it's sarge's original 3.5.2-5), it returns each time "login failed" ; php and phppgadmin are working properly, or at least they were when I was still running the older postgres version, user / password are also the same as before. I looked through this list, and the only hints I found pointed towards the line "tcpip_socket" in postgresql.conf; but it seems that that line has been replaced by a more general one "listen_addresses" ( http://www.postgresql.org/docs/8.1/interactive/release-8-0.html ) I modified the postgresql.conf file uncommenting the port number and giving the (private) network address number as argument to "listen_addresses", so: #--------------------------------------------------------------------------- # CONNECTIONS AND AUTHENTICATION #--------------------------------------------------------------------------- # - Connection Settings - listen_addresses = '192.168.1.0' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all port = 5432 max_connections = 100 ......................... and the pg_hba.conf file to listen to all local connections and all connections coming from the local network, so # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust host all all 192.168.1.0/24 trust # IPv6 local connections: host all all ::1/128 trust -------------- restarting thereafter the postmaster, but nonetheless it is still impossible to authenticate to it via phppg admin (it may be obvious, but the psql client connects perfectly) I am sorry if I am skipping something obvious, and apologize in advance for it if this were the case; anyway, I would be very grateful if somebody could give me some hint where to look for, since I need the visual interface for daily work. Thank you all very much for the continuous feedback, Bárbara Figueirido S.C. de Bariloche ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match *******************Confidentiality and Privilege Notice******************* The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments
On 8/25/06, barbara figueirido <barbara@bariloche.com.ar> wrote: > #--------------------------------------------------------------------------- > > # CONNECTIONS AND AUTHENTICATION > #--------------------------------------------------------------------------- > > > # - Connection Settings - > > listen_addresses = '192.168.1.0' # what IP address(es) to > listen on; Is that actually the machines IP address? Cheers, Andrej
"Andrej Ricnik-Bay" <andrej.groups@gmail.com> writes:
> On 8/25/06, barbara figueirido <barbara@bariloche.com.ar> wrote:
>> listen_addresses = '192.168.1.0' # what IP address(es) to
>> listen on;
> Is that actually the machines IP address?
The answer to that is no, as I'm sure Andrej knows ;-) ... no valid IP
address ends in .0.
If you don't want to say listen_addresses = '*' then you need to specify
the exact IP address of your machine's network interface in
listen_addresses. Unless you have multiple IP addresses and know what
they are and why you want to distinguish between them, just write '*'.
The other thing that enters into this is the contents of pg_hba.conf.
An entry like 192.168.1.0/24 would be pretty reasonable in pg_hba.conf,
if you want to let in just connections from your local LAN.
regards, tom lane
On 8/25/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Is that actually the machines IP address? > The answer to that is no, as I'm sure Andrej knows ;-) ... no valid IP > address ends in .0. Heh - yes, I do indeed. I'd be interested to hear the answer, though ;]
Hello everybody! In fact, it is *not* the machine's address, I thought the net address would do. I'm trying it with the actual address and let you know. Thank you very much for taking the trouble to answer. Bárbara Andrej Ricnik-Bay escribió: > On 8/25/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> > Is that actually the machines IP address? >> The answer to that is no, as I'm sure Andrej knows ;-) ... no valid IP >> address ends in .0. > Heh - yes, I do indeed. > > I'd be interested to hear the answer, though ;] > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Tom Lane escribió: > If you don't want to say listen_addresses = '*' then you need to specify > the exact IP address of your machine's network interface in > listen_addresses. Unless you have multiple IP addresses and know what > they are and why you want to distinguish between them, just write '*'. > > The problem lied, in fact, in the postgresql.conf file; I wanted to limit the range of ip addresses to my own private network; so, after trying the net address (without mask, initially, as already posted), I tried to correct it with some of the suggestions received here (tank you all for that, I deeply appreciate your involvement). But even setting listen_addresses to the exact ip address of the machine hosting the server did not correct the problem (for the record: problem was, phppgadmin rejected all login attempts, even though I was logging with the only normal user created by the system). > The other thing that enters into this is the contents of pg_hba.conf. > An entry like 192.168.1.0/24 would be pretty reasonable in pg_hba.conf, > if you want to let in just connections from your local LAN. > > regards, tom lane > > I overlooked this remark, that's why I was trying to limit access from postgresql.conf In the end, thanks to the invaluable help of Guido Barosio, who went to the trouble of guiding me in the process of parsing all possible configurations, both for postgres as well as for phppgadmin and even apache, we discovered that the faulty configuration was precisely the line containing the listen_addresses directive; setting it to '*', as suggested here, immediately corrected de problem, and I am now able to view and manipulate the data from my web browser through phppgadmin as usual..... with great relief for my eyes and fingers... :-) Once again, thank you all for the ideas, I hope to be able sometime to help others as you did. Barbara >
Guido Barosio escribió:
(from the postgresql 8.1 documentation: http://www.postgresql.org/docs/8.1/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES )
Pretty often we face users confusing the listen_addresses param toyou are right and I apologize, I should have delved deeper into the documentation, which in fact I read somewhat hastily; but anyway, you should recognize that this *is* confusing:
what pg_hba.conf functionality provides.
...
Obviously, a user getting involved with documentation (good rtfm
person) would make a difference. But seems that in general, the
wildcard '*' translates into the user mind as "this will represent a
security hazzard, so I will hardcode my ipaddress", and seriously, *I
don't know why* this allways fails.
(from the postgresql 8.1 documentation: http://www.postgresql.org/docs/8.1/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES )
- listen_addresses (string)
Specifies the TCP/IP address(es) on which the server is to listen for connections from client applications. The value takes the form of a comma-separated list of host names and/or numeric IP addresses. The special entry * corresponds to all available IP interfaces. If the list is empty, the server does not listen on any IP interface at all, in which case only Unix-domain sockets can be used to connect to it. The default value is localhost, which allows only local "loopback" connections to be made. This parameter can only be set at server start. ---
if there were nothing of "hostnames and/or numeric IP addresses", the line reading "all available IP interfaces" would acquire its full sense and one might (so I think) notice at a glance the reference to interfaces; as it implies that you *should* enter hostnames or IP addresses, one might think it correct to give the interface's IP address -- which proved wrong, at least in my case.
Obviously this is no excuse for not having taken care of the differences of postgresql.conf and pg_hba.conf, which I'll try to bear in mind in future....
Tank you again to all of you,
Bárbara
On 9/7/06, barbara figueirido <barbara@bariloche.com.ar> wrote: >> Obviously, a user getting involved with documentation (good rtfm >> person) would make a difference. But seems that in general, the >> wildcard '*' translates into the user mind as "this will represent a >> security hazzard, so I will hardcode my ipaddress", and seriously, *I >> don't know why* this allways fails. It doesn't always fail, and it does make sense to pin it down to one interface in a scenario where a machine has a public interface to the internet as well as local network. I wouldn't want my server/ router/firewall to listen to postgres connections from the wild as well as on the internal interface. > Obviously this is no excuse for not having taken care of the differences of > postgresql.conf and pg_hba.conf, which I'll try to bear in mind in > future.... Quick question - I haven't seen a single mail of Guido's on the list; did he respond to you in private, or do we have ourselves a mail-transport problem? > Tank you again to all of you, > > Bárbara Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
Andrej Ricnik-Bay escribió: > Quick question - I haven't seen a single mail of Guido's on the > list; did he respond to you in private, or do we have ourselves > a mail-transport problem? > It's a good question; Guido helped me in private, but I thought the message I was answering was directed to the list, since it was in english; after seeing your question I checked the headers and it wasn't --which I should have noticed from the fact that I had to insert manually the list's address. I thought it was me making some mistake, but from the time I began posting it stuck me that it was very difficult to respond to some messages, in fact I remember that when reporting what the problem had been, I "replied all" to a message sent by Tom Lane and it went only to his address -- and bounced; I had to repeat the message and insert the addresses manually -- whereby I also made some mistakes too shameful to tell.... As already said, I thought I was doing something wrong (I can't happen to find the first, welcome message to the list), but since you are asking.... Till some other time, Bárbara
> Andrej Ricnik-Bay escribió: > > Quick question - I haven't seen a single mail of Guido's on the > > list; did he respond to you in private, or do we have ourselves > > a mail-transport problem? A day or two ago, there was a DNS problems that affected one or more of the postgresql servers. There is a thread on the pg-general list about this. Maybe this could have been the cause. > It's a good question; Guido helped me in private, but I thought the > message I was answering was directed to the list, since it was in > english; after seeing your question I checked the headers and it wasn't > --which I should have noticed from the fact that I had to insert > manually the list's address. hmm... I never had that happen to me. If you can reproduce the results I would send an email to the webmaster@postgresql.org. He will know the correct person/list to forward the email to. > > I thought it was me making some mistake, but from the time I began > posting it stuck me that it was very difficult to respond to some > messages, in fact I remember that when reporting what the problem had > been, I "replied all" to a message sent by Tom Lane and it went only to > his address -- and bounced; I had to repeat the message and insert the > addresses manually -- whereby I also made some mistakes too shameful to > tell.... > > As already said, I thought I was doing something wrong (I can't happen > to find the first, welcome message to the list), but since you are > asking.... > > Till some other time, > Bárbara
Richard Broersma Jr escribió: > A day or two ago, there was a DNS problems that affected one or more of the postgresql servers. > There is a thread on the pg-general list about this. Maybe this could have been the cause. > ... > hmm... I never had that happen to me. If you can reproduce the results I would send an email to > the webmaster@postgresql.org. He will know the correct person/list to forward the email to. > > It seems that whatever the problem might have been, it's now corrected; I have tested answering with "reply all" a couple of mails (without actually sending the messages), and in all cases the list address was included; only thing is, I have to manually remove then the personal addresses of any participantes in the thread to prevent them from receiveing duplicate messages... is there any other way? -- well, this is actually OT, isn't it? Bárbara
only thing is, I have to manually remove then the personal > addresses of any participantes in the thread to prevent them from > receiveing duplicate messages... is there any other way? -- well, this > is actually OT, isn't it? Actually, there was a thread on the General List where someone brought up the same issue. The respondants discussed why it is configured this way. IIRC, the personal address is included to allow quick reply to individuals as the mail from the list can have significant delays. But it was up to the "REPLIER" to decide whether on not to delete the personal address and keep the list address. Regards, Richard Broersma Jr.
--As of September 9, 2006 8:18:32 AM -0700, Richard Broersma Jr is alleged to have said: > only thing is, I have to manually remove then the personal >> addresses of any participantes in the thread to prevent them from >> receiveing duplicate messages... is there any other way? -- well, this >> is actually OT, isn't it? > > Actually, there was a thread on the General List where someone brought up > the same issue. The respondants discussed why it is configured this way. > IIRC, the personal address is included to allow quick reply to > individuals as the mail from the list can have significant delays. But it > was up to the "REPLIER" to decide whether on not to delete the personal > address and keep the list address. --As for the rest, it is mine. It's kinda a religious issue, really... I actually set my 'reply-to' header to the list (when I can, I don't always use the same email client for this address) so that replies automatically go to the list but not to me. There are arguments to be made both ways. Some lists rewrite the headers, some don't. We deal. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------
On Sat, Sep 09, 2006 at 17:39:50 -0400, Daniel Staal <DStaal@usa.net> wrote: > > It's kinda a religious issue, really... I actually set my 'reply-to' > header to the list (when I can, I don't always use the same email client > for this address) so that replies automatically go to the list but not to > me. You can also set mail-followup-to to tell mail clients which addresses should be used for reply all and still have reply to sender work properly. However, mail-followup-to isn't as well supported in mail clients as the reply-to header.
On Sat, Sep 09, 2006 at 10:18:01 -0300, barbara figueirido <barbara@bariloche.com.ar> wrote: > I have tested answering with "reply all" a couple of mails (without > actually sending the messages), and in all cases the list address was > included; only thing is, I have to manually remove then the personal > addresses of any participantes in the thread to prevent them from > receiveing duplicate messages... is there any other way? -- well, this > is actually OT, isn't it? You shouldn't bother removing the addresses. The senders have ways of telling your mail client not add them to the list and they can also tell the mailing list server not to send them a copy if they are cc'd on a message.