Infrastructure

Right now pgpool in cn-buildout is configured with the three cn-dev-* servers. Additionally, the pg_hba.conf file is manually edited on each server to include entries so that allow authentication/communication between each of the three servers for the "csd" database for the "ciloogn" user.
I need to figure out how to dynamically configure these properties based on the deployment "environment" of the buildout -- I believe this is done in dataone-cn-os-core to a great extent, but I haven't taken the time to figure out all the details (though Chris was kind enough to give me an overview).

That being said, there are overarching issues with replicated portal deployment that will prevent fail-proof operation of the portal in a round-robin context and I'm awaiting decisions and changes from the CILogon team as to how to move forward.

I can configure the sandbox with a version of the portal that will work *sometimes based on the randomness of the round robin, but that hardly seems ideal!

The dataone-cn-portal debian scripts can take advantage of the debconf properties that have been set by the dataone-cn-os-core package. These include:

dataone-cn-os-core/cn.context.label
dataone-cn-os-core/cn.iplist

In the postinst file, the portal installation can source the debconf module:

. /usr/share/debconf/confmodule

and then get these properties with:

db_get dataone-cn-os-core/cn.context.label
CONTEXT=${RET}

db_get dataone-cn-os-core/cn.iplist
IPLIST=${RET}

Now the context is known (like DEV, SANDBOX, etc), and the iplist can be iterated over to set values in pg_hba.conf, etc.

To see all D1 debconf properties, use:

sudo debconf-get-selections | grep dataone

I've redeployed portal.war in a single-server mode on:
https://cn-sandbox-ucsb-1.dataone.org/portal

(I do not have sudo access on the others, but deployment from the cn-buildout will give you a fully functional portal for the given node)

Current state of portal configuration:
-assume three servers in round robin
-one of those servers hosts the Postgres DB
-all three servers are configured to communicate with the postgres server
-the postgres server needs to accept connections from all three servers (pg_hba.conf)
-the cfg.rdf file needs to point to the single postgres server ("hasStore" section)
-the cfg.rdf file must point to the round robin entry for callbacks, not a specific server ("callback url" sections)
-the web.xml file must use the correct CN URL which will be the round entry, not a specific server.