Thread: pgBackrest Error : authentication method 10 not supported

pgBackrest Error : authentication method 10 not supported

From
Daulat
Date:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

pgbackrest.conf entry:

 cat /etc/pgbackrest/pgbackrest.conf

[global]
repo1-path=/opt/backups
repo1-retention-full=2

[test14]
pg1-path=/opt/PostgreSQL-14/data
pg1-port=5432
pg1-user=postgres
pg1-socket-path=/tmp


Error Message:

pgbackrest stanza-create --stanza=test14 --log-level-console=info --log-path=/etc/pgbackrest/log
2023-01-31 08:46:37.683 P00   INFO: stanza-create command begin 2.43: --exec-id=15887-3e1eecf6 --log-level-console=info --log-path=/etc/pgbackrest/log --pg1-path=/opt/PostgreSQL-14/data --pg1-port=5432 --pg1-socket-path=/tmp --pg1-user=postgres --repo1-path=/opt/backups --stanza=test14
WARN: unable to check pg1: [DbConnectError] unable to connect to 'dbname='postgres' port=5432 user='postgres' host='/tmp'': authentication method 10 not supported
ERROR: [056]: unable to find primary cluster - cannot proceed
       HINT: are all available clusters in recovery?
2023-01-31 08:46:37.686 P00   INFO: stanza-create command end: aborted with exception [056]
[root@ip-172-31-43-98 ~]#

Re: pgBackrest Error : authentication method 10 not supported

From
Magnus Hagander
Date:


On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

This sounds like your libpq is too old, and is not related to backrest itself.

Make sure you have libpq of at least version 10 as well, and not just the server. (Exact package name will of course depend on what distribution you're on, which you didn't specify)

--

Re: pgBackrest Error : authentication method 10 not supported

From
Daulat
Date:
I have pgbackrest   v.43  installed on the same server where we are running postgres v14.6 that is upgraded from postgres v.10.2

 ls  /opt/PostgreSQL-14/lib/

libecpg.a            libecpg_compat.so.3.14  libpgcommon.a        libpgport_shlib.a  libpgtypes.so.3.14  libpq.so.5.14
libecpg_compat.a     libecpg.so              libpgcommon_shlib.a  libpgtypes.a       libpq.a             pkgconfig
libecpg_compat.so    libecpg.so.6            libpgfeutils.a       libpgtypes.so      libpq.so            postgresql
libecpg_compat.so.3  libecpg.so.6.14         libpgport.a          libpgtypes.so.3    libpq.so.5

Thanks,

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net> wrote:


On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

This sounds like your libpq is too old, and is not related to backrest itself.

Make sure you have libpq of at least version 10 as well, and not just the server. (Exact package name will of course depend on what distribution you're on, which you didn't specify)

--

Re: pgBackrest Error : authentication method 10 not supported

From
Magnus Hagander
Date:


On Thu, Feb 2, 2023 at 7:46 AM Daulat <daulat.dba@gmail.com> wrote:
I have pgbackrest   v.43  installed on the same server where we are running postgres v14.6 that is upgraded from postgres v.10.2

 ls  /opt/PostgreSQL-14/lib/

libecpg.a            libecpg_compat.so.3.14  libpgcommon.a        libpgport_shlib.a  libpgtypes.so.3.14  libpq.so.5.14
libecpg_compat.a     libecpg.so              libpgcommon_shlib.a  libpgtypes.a       libpq.a             pkgconfig
libecpg_compat.so    libecpg.so.6            libpgfeutils.a       libpgtypes.so      libpq.so            postgresql
libecpg_compat.so.3  libecpg.so.6.14         libpgport.a          libpgtypes.so.3    libpq.so.5


You've still not said which distribution you've installed on, so it's hard to say. But no distribution installs into /opt/ by default that I'm aware of. My guess if you installed backrest from a different source than wherever you installed your postgres from, and therefor it's using those libraries. Perhaps backrest is using the actual default operating system install, and your postgres is a non-standard one? 

//Magnus
 

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net> wrote:


On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

This sounds like your libpq is too old, and is not related to backrest itself.

Make sure you have libpq of at least version 10 as well, and not just the server. (Exact package name will of course depend on what distribution you're on, which you didn't specify)

Re: pgBackrest Error : authentication method 10 not supported

From
Daulat
Date:
Thanks for your quick reply.

uname -a
.amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Postgres and pgBackrest installed from source

curl -LO https://github.com/pgbackrest/pgbackrest/archive/release/2.43.tar.gz
wget https://ftp.postgresql.org/pub/source/v14.6/postgresql-14.6.tar.gz

Thanks

On Thu, Feb 2, 2023 at 2:57 PM Magnus Hagander <magnus@hagander.net> wrote:


On Thu, Feb 2, 2023 at 7:46 AM Daulat <daulat.dba@gmail.com> wrote:
I have pgbackrest   v.43  installed on the same server where we are running postgres v14.6 that is upgraded from postgres v.10.2

 ls  /opt/PostgreSQL-14/lib/

libecpg.a            libecpg_compat.so.3.14  libpgcommon.a        libpgport_shlib.a  libpgtypes.so.3.14  libpq.so.5.14
libecpg_compat.a     libecpg.so              libpgcommon_shlib.a  libpgtypes.a       libpq.a             pkgconfig
libecpg_compat.so    libecpg.so.6            libpgfeutils.a       libpgtypes.so      libpq.so            postgresql
libecpg_compat.so.3  libecpg.so.6.14         libpgport.a          libpgtypes.so.3    libpq.so.5


You've still not said which distribution you've installed on, so it's hard to say. But no distribution installs into /opt/ by default that I'm aware of. My guess if you installed backrest from a different source than wherever you installed your postgres from, and therefor it's using those libraries. Perhaps backrest is using the actual default operating system install, and your postgres is a non-standard one? 

//Magnus
 

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net> wrote:


On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

This sounds like your libpq is too old, and is not related to backrest itself.

Make sure you have libpq of at least version 10 as well, and not just the server. (Exact package name will of course depend on what distribution you're on, which you didn't specify)

From Clause Conditional

From
Zahir Lalani
Date:

Confidential

Hello All

 

We are testing a upgrade from pg11 to pg14 and have some issues to overcome. One of these is that we have upgraded pgsodium to the latest and there is a functional change – this question is not about sodium BTW.

 

So here is a sample bit of code that I will use to explain the issue – this would usually be params passed in, but I have hard coded one particular case that does not need the decryption. The code below would return decrypted data if the key is supplied (non 0) otherwise return null. This code used to work because the secret box call would allow null params. It no longer does. When the key is 0, the data passed in would be null.

 

LEFT JOIN lateral (

SELECT

                                CASE

WHEN (0 > 0) THEN

convert_from(crypto_secretbox_open, 'utf8')::JSON

ELSE

NULL

END AS edata

FROM

                                crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)

where (0>0)

) enc ON true

 

The issue is that, even when the key is 0, the select is still run (its part of a lateral join) and what we need to achieve is to effectively have a conditional where we only run the select if the key > 0 otherwise we return null – I have a brain freeze on this! I am sure there is an easy solution, but right now I can’t see it.

 

Thx in advance

 

Z

Re: pgBackrest Error : authentication method 10 not supported

From
Magnus Hagander
Date:
On Thu, Feb 2, 2023 at 12:38 PM Daulat <daulat.dba@gmail.com> wrote:
Thanks for your quick reply.

uname -a
.amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Postgres and pgBackrest installed from source

curl -LO https://github.com/pgbackrest/pgbackrest/archive/release/2.43.tar.gz
wget https://ftp.postgresql.org/pub/source/v14.6/postgresql-14.6.tar.gz



If you install from source, you have to manually configure our backrest install to use the libraries from your manual installed postgres. By default it will use the libraries that are part of your distribution, which clearly are not updated. You'll be able to see that by running ldd on the pgbackrest binary, you'll see how it uses the system libpq.9

IIRC, but not verified, in meson you can do that by setting LIBRARY_PATH before you configure it.

//Magnus
 
On Thu, Feb 2, 2023 at 2:57 PM Magnus Hagander <magnus@hagander.net> wrote:


On Thu, Feb 2, 2023 at 7:46 AM Daulat <daulat.dba@gmail.com> wrote:
I have pgbackrest   v.43  installed on the same server where we are running postgres v14.6 that is upgraded from postgres v.10.2

 ls  /opt/PostgreSQL-14/lib/

libecpg.a            libecpg_compat.so.3.14  libpgcommon.a        libpgport_shlib.a  libpgtypes.so.3.14  libpq.so.5.14
libecpg_compat.a     libecpg.so              libpgcommon_shlib.a  libpgtypes.a       libpq.a             pkgconfig
libecpg_compat.so    libecpg.so.6            libpgfeutils.a       libpgtypes.so      libpq.so            postgresql
libecpg_compat.so.3  libecpg.so.6.14         libpgport.a          libpgtypes.so.3    libpq.so.5


You've still not said which distribution you've installed on, so it's hard to say. But no distribution installs into /opt/ by default that I'm aware of. My guess if you installed backrest from a different source than wherever you installed your postgres from, and therefor it's using those libraries. Perhaps backrest is using the actual default operating system install, and your postgres is a non-standard one? 

//Magnus
 

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net> wrote:


On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:
Hello,

I am getting an error message " authentication method 10 not supported" while trying to create stanza on postgres14 after upgrading postgres from v.10 to Postgres v.14. 

I am using pgbackrest version:  v.43 and the scram-sha-256 for hba authentication.

This sounds like your libpq is too old, and is not related to backrest itself.

Make sure you have libpq of at least version 10 as well, and not just the server. (Exact package name will of course depend on what distribution you're on, which you didn't specify)



--

Re: From Clause Conditional

From
Erik Wienhold
Date:
> On 02/02/2023 13:54 CET Zahir Lalani <zahirlalani@oliver.agency> wrote:
>
> Confidential
>
> Hello All
>
> We are testing a upgrade from pg11 to pg14 and have some issues to overcome.
> One of these is that we have upgraded pgsodium to the latest and there is a
> functional change – this question is not about sodium BTW.
>
> So here is a sample bit of code that I will use to explain the issue – this
> would usually be params passed in, but I have hard coded one particular case
> that does not need the decryption. The code below would return decrypted data
> if the key is supplied (non 0) otherwise return null. This code used to work
> because the secret box call would allow null params. It no longer does. When
> the key is 0, the data passed in would be null.
>
> LEFT JOIN lateral (
> SELECT
> CASE
> WHEN (0 > 0) THEN
> convert_from(crypto_secretbox_open, 'utf8')::JSON
> ELSE
> NULL
> END AS edata
> FROM
> crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)
> where (0>0)
> ) enc ON true
>
> The issue is that, even when the key is 0, the select is still run (its part
> of a lateral join) and what we need to achieve is to effectively have a
> conditional where we only run the select if the key > 0 otherwise we return
> null – I have a brain freeze on this! I am sure there is an easy solution,
> but right now I can’t see it.

Looks similar to a post from a few days ago:
https://www.postgresql.org/message-id/flat/CAALojA-nHoxDr7B2k0e1-EtGMPsGPZiCVeS_ds0aHG0SEOrPxg%40mail.gmail.com

I don't know pgsodium but the query optimizer will evalute crypto_secretbox_open
if the function is immutable and is called with constant arguments.

How is the key and the data passed to this query?  Is it a prepared statement or
is the query generated on the fly for specific key and data that is already
known?  In the latter case you can handle the case expression with two different
queries (one with crypto_secret_box and one without) depending on whether a key
exists or not.

--
Erik

PS: Please don't hijack threads on this mailing list.



Re: From Clause Conditional

From
Tom Lane
Date:
Zahir Lalani <ZahirLalani@oliver.agency> writes:
> LEFT JOIN lateral (
> SELECT
>                                 CASE
> WHEN (0 > 0) THEN
> convert_from(crypto_secretbox_open, 'utf8')::JSON
> ELSE
> NULL
> END AS edata
> FROM
>                                 crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)
> where (0>0)
> ) enc ON true

> The issue is that, even when the key is 0, the select is still run (its part of a lateral join) and what we need to
achieveis to effectively have a conditional where we only run the select if the key > 0 otherwise we return null - I
havea brain freeze on this! I am sure there is an easy solution, but right now I can't see it. 

Is crypto_secretbox_open marked IMMUTABLE?  I think recent PG versions
are capable of folding this all to a constant if so, whereas older
ones might not have.  If you care about when/whether crypto_secretbox_open
runs, then it must have side-effects, so it shouldn't be IMMUTABLE.

            regards, tom lane