This is a list of enterprise-integration points and other common application-server concerns that AMIT should check during deployments, upgrades, and cut-overs.

  • Host Name:Is this a web application? What is the intended public CNAME(s)?
    • Apache redirects to the public name.
    • Shibboleth is configured to use that name. 
    • touchstone-dev was contacted to add the hostname to Touchstone.
    • Apache's certificates are for the public hostname, and the request for the cert was sent with the hostname all lower case.
    • vhosts are set correctly for both HTTP and HTTPS.
  • Memory Settings: Production and Staging servers likely have more resources than Development and Test. Validate the memory settings for runtime environments like Java and PHP.
  • RAdminD: Server Operations manages the operating systems with RAdminD, make sure all paths to AMIT installed components are excluded from the RAdminD system profile or that the component is managed by RAdmind.
  • Runtimes
    • Redundancy: For machines with a legacy of more than one runtime installed (multiple Java, multiple PHP), work with the development team to figure out which one to keep and eliminate the rest. 
    • Get an accurate list of which runtimes are being used (Java, PHP, Python) and in what context (web, feed script) and configure the runtime to work only in the ways that system uses it.
  • Feeds: Is the system dependent on feeds from other systems? Validate they are working correctly.
  • Backup: Is a backup mechinism in place and functioning properly? This is different depending on the hosting option.
  • Touchstone/Shibboleth: Does this system require authentication for a local or external user account? Or by certs?
    • For these tests, you will need:
      1. An internal MIT id that is already been configured for use with Touchstone (this should be the default for all @mit.edu accounts).
      2. An external account registered through touchstone.net for use with CAMS.
      3. A x.509 cert issued by mitcert@mit.edu.
      4. Either 3 browsers, each one configured to use a different auth method from the above, or the ability to clear cookies and authenticated sessions for one browser. These browsers will also need to be configured to accept cookies from the MIT IdP's, WAYF's, and the server/service you are testing.
      5. An expectation of how the application will handle users, either first time users, or logins of established users. Does it require out of band pre-registration, does is automatically create user accounts, do you need to use a separate login page, etc.
    • First, check that the application is up on the server, and that its PID has completed any init process that it need to run, and its CPU% utilization has dropped.
    • Go to the shibverify URL for the server/service that you are testing. This will be in the format of 
       https://[service name].mit.edu/shibverify
      1. For the two shibboleth services, there should be non-null data filled into the top response block and the lines in the lower response block that begin with 'Shib-' or 'key = Shib-'.
      2. You will need to do this either twice, clearing cookies and authenticated session in the browswer, and selecting first Touchstone, and then CAMS, whenever you are redirected to the IdP or WAYF.
    • For the Cert test, shibverify will not return expected values. You will need to use either 
       https://[service name].mit.edu/cgi-bin/shibenv.pl
      or 
       https://[service name].mit.edu/secure/shibenv.pl
      depending upon the configuration of the server in question.

      This is not currently configured on most systems.

    • Then you can progress to repeated these methods for the individual application or service, not just the server configuration.

      This is application specific. Some applications will automatically create a login for you the first time you use it, some will prompt you, give you an invalid user error, or some other behavior. Find out what the expected behavior is before testing.


  • No labels