Member Nodes

Eric Fritzinger (ericf@cse.unr.edu) has developed some documentation for what he needed to do on his end related to having a Windows server acting as a reverse proxy to the Linux server where they have their GMN:

Just as an addendum, and for your documentation in the future should you have any users with a similar setup (or who want a similar setup), we managed to get the reverse proxy working with https.

As you may recall, our server setup is a Windows Server 2012 IIS 8 server acting as a reverse proxy to the back-end GMN linux server. In order to get IIS 8 to work with using https on the back-end, there are a couple things that had to be done.

First, I had to update the IIS Application Request Routing module to 3.0 (I was previously using 2.0).

Secondly, I had to make sure the reverse proxy server trusted the certificate used by the target server. There are two ways to do this (the “target server” in these cases is the back-end GMN server that the reverse proxy is pointing to):

1.) Create a Certificate Root Authority server that the cluster recognizes and trusts (Windows Server OS has a Role that can be added for this purpose). Make sure the reverse proxy server recognizes the CRA as a Trusted source (explained below). Then, have the CRA issue the certificate requested by the target server and configure the target server to use that issued certificate.

2.) Create a self-signed certificate on the target server and export it. Have the IIS 8 server import the certificate as a Trusted Certificate Root Authority certificate (explained below), and it will be trusted.

To check the status of a Trusted CRA on a Windows Server OS, or to import a certificate into the TCRA:
1. Go to Start -> Run, type “mmc.exe” and click OK
2. When the console window comes up click File->Add/Remove Snap-In…
3. Add the “Certificates” module and click Next
4. Select the “Computer Account” option, click Next
5. Select the “Local Computer” option, click OK

If you expand the tree, you’ll see the “Trusted Certificate Root Authorities” folder to see all the trusted root authorities. This is where either the local Certificate Root Authority server certificate should be, or where you import the target server’s self-signed certificate (by right-clicking the folder and selecting Import from the context menu).

Option 1 is typically good for larger server clusters that will have a lot of servers behind a reverse proxy using https (which we eventually will be using). Option 2 is quick and easy. I went with Option 2 for now since I wanted to be sure it worked quickly without much hassle.

This write-up is mainly to let you all know how we got it to work (I’m not a fan of “magic”, myself =) ). Also, I wanted to make sure it was written down somewhere in case of emergency.

Take care!
~Eric

Current (temporary) technical POC is Hannah Munoz, hannah.munoz92@gmail.com.

NRDC's LE cert had expired, and while sorting that out we discovered some more concerning issues. Email from Laura to Eric 8/16/17:

When looking to see how the NRDC MN is behaving, we uncovered some issues. Prepare yourself…

We see 6663 objects on the CNs. https://cn.dataone.org/cn/v2/object?nodeId=urn:node:NRDC These objects comprise the 2221 datasets that we see in DataONE search.

We see 0 objects on the MN. https://dataone.sensor.nevada.edu/mn/v2/object (This is where I freaked out a bit.)
Because DataONE doesn’t see any objects on the MN, when we try to download any object from NRDC from the search results, we get 404s. The science metadata, however, IS retrievable from the CNs from where it was sync’d previously. (Yay)

The last time we really talked about NRDC was 12/12/16, which is also the Last Harvested Date (see in the node registration document https://cn.dataone.org/cn/v2/node/urn:node:NRDC). At that time, you were still running GMN v1.x. We’re thinking that something in the transition to GMN v2.0.5 has confused things a bit – perhaps a configuration change, maybe something related to settings_site.py and settings.py being combined in GMN v2. We’ll do some more investigating, but Mark has identified some things we need your help with to figure out what is going on.

1. Ensure that PostgreSQL database is accessible to the GMN application
2. Ensure that the OBJECT_STORE_PATH attribute is correctly set to the NRDC location for GMN data (OBJECT_STORE_PATH = '/var/local/dataone/gmn_object_store')
3. Ensure the server you deployed GMN v2.0.5 to is indeed the correct server

Maybe look at your GMN and see if both the settings_site.py and settings.py files are present? If they are, maybe GMN is confused?

Eric responded the same day:

Thank you for the heads up!

I have CC’d Hannah on this since she is in charge of the DataONE server’s GMN.

We will get to the bottom of this and get everything back up and running. =)