Thread: pgBackrest Error : authentication method 10 not supported
[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
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 ~]#
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.
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
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)--
I have pgbackrest v.43 installed on the same server where we are running postgres v14.6 that is upgraded from postgres v.10.2ls /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
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)
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
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.2ls /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.5You'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?//MagnusOn 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)
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
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
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.2ls /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.5You'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?//MagnusOn 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)
> 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.
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