Servers
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 |
| nye.gpolab.bbn.com | ch.geni.net, portal.geni.net | 4 | 2 | 10 | Ubuntu 10.04 |
| escobar.gpolab.bbn.com | shib-idp.geni.net | 1 | 1 | 10 | Ubuntu 10.04 |
The three virtual hosts each play a specific role in GENI:
| Virtual Host | Purpose |
| portal.geni.net | GENI Experimenter Portal |
| ch.geni.net | GENI Federation Services (member authority, slice authority, etc.) |
| shib-idp.geni.net | 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.
Software
Given the distinct purposes for each virtual host (see table above), here is the software running on each. Note that portal.geni.net and ch.geni.net share a common database, are served by a single apache installation, and share one copy of gcf/omni.
portal.geni.net
- Apache 2.2
- PostgreSQL 8.4
- Shibboleth service provider 2.4.3
- GPO Portal (proto-ch) (PHP)
- GPO GCF/Omni (Python)
- Detailed list of software dependencies
ch.geni.net
- Apache 2.2
- PostgreSQL 8.4
- xml-signer software for signing speaks-for credentials (JavaScript)
- libabac 0.1.6 ABAC library and prover (C, Python, Java)
- AMSoil
- GPO Federation services (chapi) (Python)
- GPO GCF/Omni (Python)
- Detailed list of software dependencies
shib-idp.geni.net
- 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 | http://trac.gpolab.bbn.com/git/proto-ch.git | All portal software plus database schemas and most management scripts |
| Clearinghouse | http://trac.gpolab.bbn.com/git/chapi.git | Clearinghouse services: Member Authority (MA), Slice Authority (SA), etc. |
| Shibboleth configuration/installation | http://trac.gpolab.bbn.com/git/shib.git | Setup and configuration of Shibboleth identity provider and service provider |
Monitoring
The GPO Lab uses ganglia to monitor hosts. These graphs provide an indication of load and usage on the systems.
Miscellaneous
Some thinks we all need to keep in mind:
- portal.geni.net 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 ch.geni.net 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.
cron
The current portal uses a few cron jobs. These are sprinkled across "root" (for privileges, presumably), "www-data" (to send email), and "tmitchel" (because we thought it was a short-term job).
Here they are, with an indication of which crontab they are in:
# m h dom mon dow command # # (root) Delete omni log files in /tmp 55 23 * * * /usr/bin/find /tmp -name '*-omni-log-??????' -mtime +7 | /usr/bin/xargs /bin/rm -f # # (root) Create the member authority CRL 10 2 * * * /usr/local/sbin/geni-create-ma-crl && service apache2 restart # # (www-data) Notify users of expiring certificates 5 1 * * * /usr/local/sbin/geni-expiring-certs --days 30,14,7,2 # # (tmitchel) Check for stale omni processes every 5 minutes */5 * * * * /home/tmitchel/bin/stale-omni
There are other cron jobs used by the infra team in both root and www-data cron tabs. We'll need to figure out which ones to transition, or how to replace them in the RENCI environment, if at all.
Issues encountered
SR.get_services called, but PGCH responds that it doesn't have get_services
PATH_INFO
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.
