Notes on installation

Confidence Level TBD  This article has not been reviewed for accuracy, timeliness, or completeness. Check that this information is valid before acting on it.

Confidence Level TBD  This article has not been reviewed for accuracy, timeliness, or completeness. Check that this information is valid before acting on it.


I followed the installation instructions found here.

I did this on a personal AWS account with root privileges so as not to run into any permissions issues. I noticed a few things during the installation that were not clear in the instructions and wanted to note them down somewhere.



Method chosen: 

  1. Create a base image from Centos7 Marketplace AMI as described here: https://github.com/hysds/hysds-framework/wiki/Puppet-Automation#create-a-base-centos-7-image-for-installation-of-all-hysds-component-instances

  2. Start 5 EC2 m5.large instances each with 40GB attached EBS

  3. Use puppet to install the 5 main components on the 5 EC2 instances



Problems:

  1. The minimum requirements do not specify minimum disk space needed. I started first with the default (I think 8GB) of EBS storage but ran out of disk space during installation. Retried with 40GB EBS on each node and was fine. Should specify minimum disk space required.

  2. No ssh key for the ops user.

    1. The puppet scripts create a user and group called 'ops': https://github.com/hysds/puppet-mozart/blob/master/manifests/init.pp#L12 but do not provision any SSH keys for that user

    2. The details for Step 1: Provision VMs for PCM does not mention setting up SSH keys for this 'ops' user but the first step of Step 2: Install HySDS framework on VM instances says to ssh to the mozart machine as 'ops'. This is not possible without first setting up SSH keys. More detail is needed here, even if it's just an extra mention at the end of Provisioning VMs about setting up the 'ops' user for SSH access.

  3. There are 2 Step 3's Step 3: HySDS Cluster Provisioning using TerraformStep 3: Initial Cluster Setup

  4. There needs to be a little bit more information between Step 2: Install HySDS framework on VM instances and Step 3: Initial Cluster Setup. You can't just jump right into sds configure on a new cluster. For the most part the default settings were fine but the main areas I found that need a more information are:

    1. ops User/Password/Home

      1. There is no indication in the installation manual that an ops user has been created on the 5 servers. This is related to the SSH key issue earlier but there should be a mention about when/how/what this ops user is.

      2. It's unclear at this point if this configuration is going to create a user based on this information or if this account should already be created. It's also unclear if this is strictly for logging in to the HySDS web interfaces, ssh access or both. I think this could be cleared up a little.

    2. Jenkins setup

      1. On a new cluster, before running sds configure, you need to go to the jenkins instance and set it up. This includes looking in the jenkins log file for a secret key that was output on startup, creating the root user account, updating plugins, and creating an API user in order to get an API key. This process should be summarized

    3. LDAP planning

      1. The LDAP_GROUPS option is confusing. It is required (I tried leaving it blank but the process erred out) but it is not possible to configure LDAP_HOST or LDAP_BASEDN through this tool. It would be better if configure asked if you are using LDAP, if yes then ask for all 3 settings, if no just skip it (and allow LDAP_GROUPS to be blank)

    4. AWS Access Key

      1. 1 or 2 AWS Access Keys need to be created with authorization to access the created s3 buckets

  5. Additional information on how to modify these configuration values would be nice. Can I rerun sds configure? If I do, how do I distribute the new configs? Where is this configuration being stored? What if I just need to change one value? etc...

  6. After setup was complete I had to stop all of my EC2 instances (to stop incurring charges) and then came back later to continue. I noticed upon restarting my EC2 instances that ElasticSearch was not starting on boot for some reason. The puppet scripts clearly enable the services: https://github.com/hysds/puppet-mozart/blob/master/manifests/init.pp#L210-L212 so I don't know why ES did not come up on it's own. A little more investigation is probably needed there.

  7. During Step 4: Running your First "Hello World" Job, step 18 says "Navigate to your grq instance (e.g. http://<your-grq-instance>/search)* to validate that the AOI dataset was ingested"

    1. The apache server for grq does not automatically redirect http to https and the proxy for '/search' is only setup for https(443) virtual host: https://github.com/hysds/puppet-grq/blob/master/templates/ssl.conf 

    2. Because of (a), http://<your-grq-instance>/search will not work. It needs to be https://<your-grq-instance>/search and/or the apache server should be setup to redirect all http to https

  8. The default search interface that is deployed uses the JPL template including NASA/JPL header and footer. The login page also refers to JPL username and password. Since the intent for this installation is to be for general public, this is probably not appropriate.



Note: JPL employees can also get answers to HySDS questions at Stack Overflow Enterprise: