From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | armand pirvu <armand(dot)pirvu(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: authentication failure |
Date: | 2018-04-12 14:08:24 |
Message-ID: | a7fa504e-8295-bd5d-c9e9-c4be0baafa40@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 04/12/2018 06:59 AM, armand pirvu wrote:
Please reply to list also.
Ccing list.
> Yes and worked fine until two days ago
> I use .pgpass
So can you connect from wherever the process is run to the server
manually? Something like:
psql -d birstab -U csidba -h some_server
> I will also check and see if there are not too many hands in the cookie jar so to speak and things happen without being communicated
>
>
>> On Apr 12, 2018, at 8:56 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>>
>> On 04/12/2018 06:51 AM, armand pirvu wrote:
>>> Hi there
>>> I have a process in place which runs several queries from one host to another one
>>> All of a sudden I started noticing authentication failures
>>> Like below
>>> .009 ms statement: COPY NACDS.tf_show_code_response_person FROM STDIN with csv;",,,,,,,,,"psql"
>>> 2018-04-12 00:10:48.765 CDT,"csidba","birstdb",7553,"172.16.20.4:40330",5aceea2e.1d81,1,"UPDATE",2018-04-12 00:10:06 CDT,24/0,0,LOG,00000,"duration: 425
>>> 90.993 ms statement: UPDATE
>>> csischema.tf_transaction_person
>>> SET
>>> is_deleted = 'TRUE',
>>> birst_is_deleted = 'TRUE',
>>> update_datetime = now()::timestamp(0)
>>> WHERE
>>> show_id = '984BIOWC18' AND
>>> birst_is_deleted = 'FALSE' AND
>>> person_transaction_id IN (
>>> SELECT a.person_transaction_id
>>> FROM csischema.tf_transaction_person a
>>> LEFT JOIN BIOWC.tf_transaction_person b
>>> ON a.person_transaction_id=b.person_transaction_id
>>> WHERE a.show_id = '984BIOWC18' AND b.person_transaction_id IS NULL
>>> )
>>> ;",,,,,,,,,"psql"
>>> 2018-04-12 00:10:48.823 CDT,"csidba","birstdb",7755,"172.16.20.4:40455",5aceea58.1e4b,1,"authentication",2018-04-12 00:10:48 CDT,3/20320168,0,FATAL,28P0
>>> 1,"password authentication failed for user ""csidba""","Connection matched pg_hba.conf line 84: ""host all all 0.0.0.0/0 md5""",,,,,,,,""
>>> 2018-04-12 00:10:48.841 CDT,"csidba","birstdb",7756,"172.16.20.4:40456",5aceea58.1e4c,1,"authentication",2018-04-12 00:10:48 CDT,3/20320169,0,FATAL,28P0
>>> 1,"password authentication failed for user ""csidba""","Connection matched pg_hba.conf line 84: ""host all all 0.0.0.0/0 md5""",,,,,,,,""
>>> 2018-04-12 00:10:48.957 CDT,"csidba","birstdb",7759,"172.16.20.4:40459",5aceea58.1e4f,1,"authentication",2018-04-12 00:10:48 CDT,3/20320172,0,FATAL,28P0
>>> pg_hba.conf
>>> # "local" is for Unix domain socket connections only
>>> #local all all peer
>>> local all all md5
>>> # IPv4 local connections:
>>> #host all all 127.0.0.1/32 ident
>>> host all all 0.0.0.0/0 md5
>>> # IPv6 local connections:
>>> host all all ::1/128 ident
>>> # Allow replication connections from localhost, by a user with the
>>> # replication privilege.
>>> #local replication postgres peer
>>> #host replication postgres 127.0.0.1/32 ident
>>> #host replication postgres ::1/128 ident
>>> local replication csidba md5
>>> host replication csidba 127.0.0.1/32 md5
>>> host replication csidba 0.0.0.0/0 md5
>>> local replication repuser md5
>>> host replication repuser 127.0.0.1/32 md5
>>> host replication repuser 0.0.0.0/0 md5
>>> local all repuser md5
>>> host all repuser 127.0.0.1/32 md5
>>> host all repuser 0.0.0.0/0 md5
>>> Did I run in somthing similar to a racong condition ?
>>> Any ideas ?
>>
>> Is the process using the correct password?
>>
>>> Many thanks
>>> — Armand
>>
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | armand pirvu | 2018-04-12 14:12:32 | Re: authentication failure |
Previous Message | Adrian Klaver | 2018-04-12 13:56:53 | Re: authentication failure |