On Mon Sep 8 08:32 PM, Tatsuo Ishii wrote: >> On Wed Sep 3 05:16 AM, Tatsuo Ishii wrote: >>> Maybe this should be in the FAQ (I know I have to write but...) >>> >>> Please look into this to know why it's not possible to support md5 >>> in >>> pgpoool: >>> >>> http://lists.pgfoundry.org/pipermail/pgpool-general/2008- >>> August/001171.html -- Tatsuo Ishii SRA OSS, Inc. Japan >>> >> >> Why not just always do auth with the *available master* server? >> Nothing's impossible ;) > > How can we use slave servers witout authenticating them? > -- > Tatsuo Ishii > SRA OSS, Inc. Japan
Right good question, there's 2 issues that are not clear for me 1) pgpool connections to nodes Right now the postgreSQL servers (slave or master) need to trust pgpool connections: host all all 198.168.10.2/32 trust host all all xx.xx.xx.24/32 trust 198.168.0.1 = pgpool 1 IP xx.xx.xx.24 = pgpool 2 IP Couldn't pgpool II be able to connect to nodes in the cluster with md5 auth and keep the connections alive. 2) client connections to pgpool My comment was more about pool_hba.conf, the auth could then always be relayed to the first available master. I currently set enable_pool_hba=false and instead use firewall rules to control who can access pgpool. But having something like: pool_hba=relay (auth sent to first master) pool_hba=native (enable_pool_hba=true) pool_hba=off (enable_pool_hba=false) Would seem very helpful, but that depends on the use cases out there, And the magic 'relay' would probably require a lot of work Hope that was clear enough and makes sense with the pgpool architecture _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
