Version 5 (modified by, 8 years ago) (diff)



There are two servers involved in the public-facing GENI software suite hosted by the GENI Project Office (GPO). Both of these servers are virtual machines hosted in VMWare vSphere.

There are three virtual hosts split across two virtual machines, both living on the same physical host. The physical host runs VMWare vSphere software. The two virtual machines, including their DNS aliases, are listed here with their configuration:

Virtual Machine DNS Aliases CPUs Memory (GB) Disk (GB) OS, 4 2 10 Ubuntu 10.04 1 1 10 Ubuntu 10.04

The three virtual hosts each play a specific role in GENI:

Virtual Host Purpose GENI Experimenter Portal GENI Federation Services (member authority, slice authority, etc.) GENI Identity Provider

Note that while theoretically possible to split the GENI Experimenter Portal and GENI Federation services across hosts, we have never run the software this way. It is likely that the two must be co-located or at least have access to the same database. We consider conditions that force this co-location to be bugs, however, and given time and resources it would be good to fully separate the two pieces.


Given the distinct purposes for each virtual host (see table above), here is the software running on each. Note that and share a common database, are served by a single apache installation, and share one copy of gcf/omni.

  • Shibboleth identity provider 2.3.8
  • Tomcat 6.0
  • Java 6 (OpenJDK) 6b27
  • Apache 2.2
  • PostgreSQL 8.4
  • Open LDAP 2.4
  • GPO Account Request system (geni-ar) (PHP)
  • Dependencies of the above (numerous software packages typically installed by apt)

git repositories

There is no anonymous access to the git repositories, access requires an account See the getting an account page for instructions.

There are several git repositories involved:

Name URL Description
Portal All portal software plus database schemas and most management scripts
Clearinghouse Clearinghouse services: Member Authority (MA), Slice Authority (SA), etc.
Shibboleth configuration/installation Setup and configuration of Shibboleth identity provider and service provider


The GPO Lab uses ganglia to monitor hosts. These graphs provide an indication of load and usage on the systems.


Some thinks we all need to keep in mind:

  • is an InCommon service provider and is included in the InCommon federation. We may have to transfer the InCommon membership.
  • It's very useful to have development, staging, and production hosts. We use that model internally.
  • There is an "operator" privilege level that allows some individuals to:
    • Run certain maintenance scripts
    • Access the portal during a maintenance outage
    • Access any project or slice
  • We should provide a list of ports in use by the different servers
  • Certificates are tied to the hostname
  • Some ports are open in the host firewall (need a table of open port and reason/service)
  • Some config files are managed by puppet (need a list, see gsw:SwClearinghouse/Install (internal link))
  • The portal sends Google Analytics statistics. We'll need to provide access to this.

Issues encountered

SR.get_services called, but PGCH responds that it doesn't have get_services


Always directed to welcome page

no tool activated

Redirected to error page with "Invalid result received from Clearinghouse API:"

PHP CURL does not send the intermediate CA certificate along with the experimenter's certificate, so the experimenter's certificate gets rejected.

Fixed by adding the MA certificate to the the file pointed to by !SSLCACertificateFile in apache config. The file contains both CA and MA. This happens on CentOS 6.5 and RHEL 7.