password in recovery.conf
Hello all,
I am setting up a streaming replication stand-by, and the replication role
password has a single quote in it. I am unable to properly reference the
password in the conninfo setting of recovery.conf so it will authenticate
to the master. Doubling the quote gives me a syntax error, and escaping it
or quoting it with double-quotes gives me an authentication error. The
password is correct because I can copy it from the recovery.conf and supply
it when prompted by pg_basebackup, so if I may, what is the proper way to
handle single quotes within the conninfo string?
Obviously I can change the password, but we use an automated password
generator so I'd like to not have to keep generating passwords, and
checking them, until I get one that will work, unless that my only option.
Thanks,
Nelson
On 09/26/14 12:58, Nelson Green wrote:
I am setting up a streaming replication stand-by, and the replication
role password has a single quote in it. I am unable to properly
reference the password in the conninfo setting of recovery.conf so it
will authenticate to the master. Doubling the quote gives me a syntax
error, and escaping it or quoting it with double-quotes gives me an
authentication error.
You may have to double it twice -- once for recovery.conf and once for
the actual usage in the connection.
Thus for password abc'123 you would want to use:
'user=user_name password=abc''''123 host=primary_host'
Or possibly even a combination of doubling and escaping:
'user=user_name password=abc\''123 host=primary_host'
or:
'user=user_name password=abc\\''123 host=primary_host'
This is just conjecture. I don't use this method of recovery myself.
HTH.
Bosco.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi!
Have you tried escape the Single or Double quote? Maybe this information can
help you:
http://stackoverflow.com/questions/12316953/insert-varchar-with-single-quotes-in-postgresql
http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html
Best Regards!
-----
Dame un poco de fe, eso me bastará.
Rozvo Ware Solutions
--
View this message in context: http://postgresql.1045698.n5.nabble.com/password-in-recovery-conf-tp5820725p5820737.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 09/26/2014 12:58 PM, Nelson Green wrote:
Hello all,
I am setting up a streaming replication stand-by, and the replication
role password has a single quote in it. I am unable to properly
reference the password in the conninfo setting of recovery.conf so it
will authenticate to the master. Doubling the quote gives me a syntax
error, and escaping it or quoting it with double-quotes gives me an
authentication error. The password is correct because I can copy it from
the recovery.conf and supply it when prompted by pg_basebackup, so if I
may, what is the proper way to handle single quotes within the conninfo
string?
Doubling the quote seems to work here.
aklaver@panda:~> psql 'dbname=test user=test_user password=test''pwd'
psql (9.0.17)
Type "help" for help.
test=>
What is the syntax error you get?
Another option:
http://www.postgresql.org/docs/9.3/static/standby-settings.html
A password needs to be provided too, if the primary demands password
authentication. It can be provided in the primary_conninfo string, or in
a separate ~/.pgpass file on the standby server (use replication as the
database name)
So you might look at setting up a .pgpass
file(http://www.postgresql.org/docs/9.3/static/libpq-pgpass.html)
Obviously I can change the password, but we use an automated password
generator so I'd like to not have to keep generating passwords, and
checking them, until I get one that will work, unless that my only option.Thanks,
Nelson
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Sep 26, 2014 at 5:51 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 09/26/2014 12:58 PM, Nelson Green wrote:
Hello all,
I am setting up a streaming replication stand-by, and the replication
role password has a single quote in it. I am unable to properly
reference the password in the conninfo setting of recovery.conf so it
will authenticate to the master. Doubling the quote gives me a syntax
error, and escaping it or quoting it with double-quotes gives me an
authentication error. The password is correct because I can copy it from
the recovery.conf and supply it when prompted by pg_basebackup, so if I
may, what is the proper way to handle single quotes within the conninfo
string?Doubling the quote seems to work here.
Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became
obvious
that I was doing something wrong. And yes, in the end you were right.
Doubling
the quote does indeed work.
It turns out it this particular password also had a \ in it, and my console
width wrapped right before it, putting it as the first character on the next
line, where I just didn't notice it until a few minutes ago. I changed that
to
a ^ for the time being, and then doubled the quote whereupon it all worked.
I
will certainly look into how to escape the backslash too, but that's for
next
week at this point.
Apologies for the noise. Just been one of those days.
Thanks,
Nelson
Import Notes
Resolved by subject fallback
On 9/26/2014 4:32 PM, Nelson Green wrote:
Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became
obvious
that I was doing something wrong. And yes, in the end you were right.
Doubling
the quote does indeed work.It turns out it this particular password also had a \ in it, and my
console
width wrapped right before it, putting it as the first character on
the next
line, where I just didn't notice it until a few minutes ago. I changed
that to
a ^ for the time being, and then doubled the quote whereupon it all
worked. I
will certainly look into how to escape the backslash too, but that's
for next
week at this point.
I'd consider using `mkpasswd -l 15 -s 0` just to avoid any such
problems. 15 random alphanumerics is already plenty complex, 62^15th
possible combinations, without needing to mix in special characters.
$ mkpasswd -l 15 -s 0
eec1kj7ZsthlYmh
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 09/26/2014 04:32 PM, Nelson Green wrote:
On Fri, Sep 26, 2014 at 5:51 PM, Adrian Klaver
Doubling the quote seems to work here.
Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became
obvious
that I was doing something wrong. And yes, in the end you were right.
Doubling
the quote does indeed work.It turns out it this particular password also had a \ in it, and my console
width wrapped right before it, putting it as the first character on the next
line, where I just didn't notice it until a few minutes ago. I changed
that to
a ^ for the time being, and then doubled the quote whereupon it all
worked. I
will certainly look into how to escape the backslash too, but that's for
next
week at this point.
aklaver@panda:~> psql 'dbname=test user=test_user password=test\\pwd'
psql (9.0.17)
Type "help" for help.
test=>
Apologies for the noise. Just been one of those days.
Thanks,
Nelson
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 9/26/2014 4:40 PM, John R Pierce wrote:
I'd consider using `mkpasswd -l 15 -s 0` just to avoid any such
problems. 15 random alphanumerics is already plenty complex, 62^15th
possible combinations, without needing to mix in special characters.$ mkpasswd -l 15 -s 0
eec1kj7ZsthlYmh
btw, thats 768,909,700,000,000,000,000,000,000 possible passwords. 768
septillion, using the aamerican 'short scale' naming convention. if you
could brute force try 10000/second, it would merely take
24,365,800,000,000 centuries (24 trillion).
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 27/09/14 11:56, John R Pierce wrote:
On 9/26/2014 4:40 PM, John R Pierce wrote:
I'd consider using `mkpasswd -l 15 -s 0` just to avoid any such
problems. 15 random alphanumerics is already plenty complex,
62^15th possible combinations, without needing to mix in special
characters.$ mkpasswd -l 15 -s 0
eec1kj7ZsthlYmhbtw, thats 768,909,700,000,000,000,000,000,000 possible passwords. 768
septillion, using the aamerican 'short scale' naming convention. if
you could brute force try 10000/second, it would merely take
24,365,800,000,000 centuries (24 trillion).
So do you think a password like *Nxw7TnC2^}%(}tEz* is strong enough? :-)
I developed a Java program that generates 20 passwords (each of 16
characters) at a time, I've attached it for anyone who might be
interested. I have put it under the GPL version 3, but I might consider
releasing under other licences.
Cheers,
Gavin
Attachments:
AppPasswordGenerator.javatext/x-java; name=AppPasswordGenerator.javaDownload
On Fri, Sep 26, 2014 at 6:46 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 09/26/2014 04:32 PM, Nelson Green wrote:
On Fri, Sep 26, 2014 at 5:51 PM, Adrian Klaver
Doubling the quote seems to work here.
Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became
obvious
that I was doing something wrong. And yes, in the end you were right.
Doubling
the quote does indeed work.It turns out it this particular password also had a \ in it, and my
console
width wrapped right before it, putting it as the first character on the
next
line, where I just didn't notice it until a few minutes ago. I changed
that to
a ^ for the time being, and then doubled the quote whereupon it all
worked. I
will certainly look into how to escape the backslash too, but that's for
next
week at this point.aklaver@panda:~> psql 'dbname=test user=test_user password=test\\pwd'
psql (9.0.17)
Type "help" for help.test=>
Thanks again Adrian! Figures it's that easy.
Confession time. When I'm trying to work through something like this where
different iterations are going to be tried, I sit down and spell them out
first.
But since I was remoted in and things were going so slow (and I was pretty
tired), I just tried different combinations on the single quote. When I
noticed
the backslash I tried to double it, but with no luck. However, in all
honesty I
don't know what I was doing with the single quote at that particular moment.
Bottom line is I probably shot myself in the foot in several ways with this
one.
I appreciate the patience with me.
Nelson
On Fri, Sep 26, 2014 at 6:40 PM, John R Pierce <pierce@hogranch.com> wrote:
On 9/26/2014 4:32 PM, Nelson Green wrote:
Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became
obvious
that I was doing something wrong. And yes, in the end you were right.
Doubling
the quote does indeed work.It turns out it this particular password also had a \ in it, and my
console
width wrapped right before it, putting it as the first character on the
next
line, where I just didn't notice it until a few minutes ago. I changed
that to
a ^ for the time being, and then doubled the quote whereupon it all
worked. I
will certainly look into how to escape the backslash too, but that's for
next
week at this point.I'd consider using `mkpasswd -l 15 -s 0` just to avoid any such
problems. 15 random alphanumerics is already plenty complex, 62^15th
possible combinations, without needing to mix in special characters.$ mkpasswd -l 15 -s 0
eec1kj7ZsthlYmh
Thanks John. We use apg which has similar options. But alas, I must comply
with
organizational password policies.
Regards,
Nelson