[Pgpool-general] MD5 authentication in "raw mode"

[Tatsuo Ishii]

I seems the problem has fixed and I have committed the changes.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Sorry, I could not commit this because of a system trouble on
> pgfoundry.org.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> > It appears that it was a nasty bug(probably someone put the checking
> > code without thinking about md5). I have fixed the line in pool_auth.c
> > you pointed out to:
> > 
> > 	else if (authkind == 5)
> > 	{
> > 		if (!RAW_MODE && NUM_BACKENDS > 1)
> > 		{
> > 			pool_send_error_message(frontend, protoMajor, AUTHFAIL_ERRORCODE,
> > 
> > Note that the definition of NUM_BACKENDS has been slightly changed in
> > 2.1. I recommend you to try 2.1 with above changing for grab CVS Head
> > and try again.
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> > 
> > > Hello,
> > > 
> > > I'm trying to set up a "warm standy" system using pgpool in raw mode. 
> > > The (two) backends are set up using md5 authentication in pg_hba.conf. 
> > > Connecting to the initial master backend works like a charm. However, 
> > > once failover takes place, the client cannot connect to the second 
> > > backend. It fails with the error message:
> > > 
> > > "psql: ERROR:  MD5 authentication is unsupported in replication, 
> > > master-slave and parallel modes."
> > > 
> > > Strange, because pgpool is not running in either replication, 
> > > master-slave or parallel modes:
> > > 
> > > duco at debian1:/usr/local/etc$ grep '_mode' pgpool.conf
> > > replication_mode = false
> > > # are load balanced.  This is ignored if replication_mode is false.
> > > load_balance_mode = false
> > > master_slave_mode = false
> > > parallel_mode = false
> > > 
> > > I tried pgpool-II version 1.3.? (as included in Debian), version 2.01 
> > > and version 2.1 (compiled from original source).
> > > 
> > > What puzzled me was that md5 authenticated session do succeed when 
> > > connecting to the master, while it fails connecting to the failover 
> > > server. I would have expected either both or none succeeding.
> > > 
> > > Looking at the source (version 2.01), I noticed something strange. The 
> > > error message itself seems to orginate from the following fragment:
> > > 
> > > 
> > > ***** pool_auth.c:
> > > 		if (NUM_BACKENDS > 1)
> > > 		{
> > > 			pool_send_error_message(frontend, protoMajor, AUTHFAIL_ERRORCODE,
> > > 									"MD5 authentication is unsupported in replication, master-slave 
> > > and parallel modes.",
> > > 									"",
> > > 									"check pg_hba.conf",
> > > 									__FILE__, __LINE__);
> > > 			return -1;
> > > 		}
> > > *****
> > > 
> > > The error conditions is trigged by "NUM_BACKEND > 1". This seems to me a 
> > > weaker condition than "replication, master_slave or parallel mode" as it 
> > > should be possible to use more than one backend in raw mode, too.
> > > 
> > > Still it works before failover takes place. To find out why, I searched 
> > > for the definition of NUM_BACKENDS:
> > > 
> > > ***** pool.h:
> > > 
> > > #define NUM_BACKENDS (in_load_balance? (selected_slot+1) : \
> > > 					  (((!REPLICATION && !PARALLEL_MODE) && !MASTER_SLAVE)? 
> > > Req_info->master_node_id+1: \
> > > 					   pool_config->backend_desc->num_backends))
> > > *****
> > > 
> > > This at least explains the difference in results connection to the 
> > > master and the failover server. From what I understand of #define 
> > > NUM_BACKENDS, until failover takes places, NUM_BACKEND == 1 (we are not 
> > > in_load_balance and not in REPLICATION, PARALLEL_MODE or MASTER_SLAVE, 
> > > so NUM_BACKEND == Req_info->master_node + 1 == 0 + 1 == 1). After 
> > > failover, NUM_BACKEND == Req_info->master_node + 1 == 1 + 1 == 2.
> > > 
> > > These values definitely do not correspond to my intuition with 
> > > "NUM_BACKENDS".
> > > 
> > > Is this a bug in pgpool-II or am I trying to accomplish something that 
> > > is not possible. I definitely would not like to use plain text passwords 
> > > for authentication, especially because SSL does not seems to be 
> > > supported while connection through pgpool.
> > > 
> > > Greetings,
> > > 
> > > Duco
> > _______________________________________________
> > Pgpool-general mailing list
> > Pgpool-general at pgfoundry.org
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general