geni-nsf / aws-transition Goto Github PK

If a portal user has speaks-for authorization enabled they are unable to interact with aggregates via the portal. To test, have an admin enable speaks-for authorization ("User Name"->Profile, "Authorize the Portal") and try to allocate or renew resources at an aggregate.

In the portal log I saw an error involving the --verify flag. It looked like a permission problem on the temp file.

This is not a blocker because only admins can enable speaks-for authorization.

This looks like a timezone issue. The times are 5 hours ahead, which is the offset between EST and UTC. It looks like they are being converted to UTC a second time, erroneously.

The database record has a correct time in UTC as we would expect.

CloudLab uses the Utah Emulab SA certificate to talk to the clearinghouse. This used to work, but stopped working after transition.

The Utah Emulab SA certificate (or its parent) is no longer configured in the trust roots. The httpd configuration has the GENI CA+MA.

On the portal go to Tools->GENI Desktop and try to "Authorize the GENI Desktop". See that the authorize button does nothing.

Checking the web browser console, the xml-signer code did not load. Following that URL manually results in an error.

The "VM", "Xen VM", and "Raw PC IG" icons in the Jacks editor are reverting to the default icon instead of the custom icons.

The geni-sync-wireless cron job fails with the following error:

Date: Thu, 17 Nov 2016 02:00:02 +0000 (UTC)
From: "(Cron Daemon)" <root@>
To: root@
Subject: Cron <root@> /usr/bin/geni-sync-wireless --cleanup

Traceback (most recent call last):
  File "/usr/bin/geni-sync-wireless", line 782, in <module>
    sys.exit(main())
  File "/usr/bin/geni-sync-wireless", line 778, in main
    wpm.synchronize()
  File "/usr/bin/geni-sync-wireless", line 304, in synchronize
    self.get_geni_projects()
  File "/usr/bin/geni-sync-wireless", line 670, in get_geni_projects
    self._user)
  File "/usr/bin/geni-sync-wireless", line 650, in get_wimax_projects
    response = xmlrpc_client.lookup('PROJECT', credentials, options)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1306, in single_request
    return self.parse_response(response)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1482, in parse_response
    return u.close()
  File "/usr/lib64/python2.7/xmlrpclib.py", line 794, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1: 'CHAPIv1AuthorizationError: [AUTHORIZATION] AUTHORIZATION_ERROR (Client certificate required but not provided)'>

Since the original portal and CH are in Eastern zone, its just easier to use teh same on the AWS hosts so that cronjobs dont have be changed .

To set the correct time zone i ran.
timedatectl set-timezone America/New_York

Users receive an invalid passphrase error even if they're using the correct passphrase

When I try to sign in to GEE from the portal (Partners->GEE) I get an apache error that the OpenID server cannot be reached.

It seems likely that httpd is not configured to serve the OpenID server files.

The database is exhausting the connection limit. This makes the portal and any other clearinghouse clients inoperable.

A stanza is missing from the httpd config file. It needs this added to the port 443 virtual host:

    # Use rewrite engine to show a relatively friendly page to
    # clients who don't display SSL certs, regardless of what URL
    # they requested on this vhost
    RewriteEngine On
    RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
    RewriteRule .* /index.html [L]

After the WSGI fix we are still seeing a handful of initialization log messages per restart of httpd:

After a restart at 10:45 a.m.:

01/24/2017 10:45:33:INFO    :chapi:CH_SERVER: INITIALIZED CH_SERVER
01/24/2017 10:45:34:INFO    :chapi:CH_SERVER: INITIALIZED CH_SERVER
01/24/2017 10:46:47:INFO    :chapi:CH_SERVER: INITIALIZED CH_SERVER

Googling for "wsgi one time global initialization" found a response by Graham Dumpleton, the WSGI developer:

http://stackoverflow.com/questions/6221851/loading-a-file-just-once-on-initialization-of-python-script-using-mod-wsgi-and-b

Determine if this needs to be addressed. If it does need to be addressed, use mock-ch to experiment with solutions.

The httpd (portal & ch) and shibd (portal) services do not start when the AWS VM is rebooted.

The portal and clearinghouse send email under a variety of circumstances.

• Check the configuration files to verify that the correct addresses are in place
• Test portal email
  ** Request project lead privilege
  ** Request to be added to a project
• Test clearinghouse email
  ** Find some use cases...