Notes ID Profiles for Vagrant Instances

[JoelProminic]

I recently had to upgrade to Notes 12.0.2FP1, and the local Domino Java applications are almost completely broken at this point. These application tended to crash even in the best conditions before, but I was able to work around it.

We would like to make changes so that we can run the required applications in a Domino Vagrant instance instead. Domino Vagrant can already support actions like DXL Importer, but it currently only works with the default, generated ID file. This ID file won't have access to production servers, so we will need a way to support using real user IDs.

Setting up an ID is pretty straightforward:

1. Create a new directory on the VM. For example, /local/notesjava/myid
2. Copy the full ID file (not the safe ID) to the new directory
3. Copy /local/notesjava/notes.ini to the new directory
4. Update the notes.ini copy to change the ID file name (TODO)
5. Update the owner of the directory and files to java_user. This may not be strictly required, but the REST interface will have access as this user, and it avoids more environment setup

However, this ID file will require a different password. We could save the password in a file, but by necessity these are very sensitive users. @JustinProminic proposed we work around this by saving the password in-memory with a separate application. Moonshine would need to detect (through the REST interface) whether the password is saved, and provide an interface for the user to enter the password.

I rarely use other ID files besides my own for development, but @JustinProminic reported that this is more common for other developers, so we would like to support this case. This would require some changes to the Vagrant Instance interface:

• Update the settings page to let the user configure new ID files
  • Option A - Have a separate list of ID files, and deploy them automatically when the user tries to to run an action agaist that server as that user
  • Option B - Deploy ID files to each server individually, and determine the available servers for an instance in a similar way to the capabilities
• Add a new drop-down to each affected Vagrant action to let the user choose which user to run as. The default should be configurable for each server. Note that some features like deploying databases (through Genesis) or Royale applications don't depend on a specific ID.

[JoelProminic]

If I want to make updates to the server /info page, I should update the REST API configuration file at: /opt/rest-interface/config/application.yml

The template is here: https://github.com/STARTcloud/hcl_roles/blob/main/hcl_domino_vagrant_rest_api/templates/rest_config.yml.j2

The script that deploys a new ID file would also need to update the file to add the new user.

UPDATE: rest-config.yml.j2 has been moved.

[JoelProminic]

I created a basic script to deploy the ID file. The other steps should be similar to other actions we have done, like deploy_database.sh.

Suggested location: /opt/domino/scripts/setup_id_file.sh

java_user@demo2:/opt/domino/scripts$ cat setup_id_file.sh 
#!/bin/bash
# USAGE: ./setup_id_file.sh <id-file-path> <identifier>
# This script will setup the ID file to run Domino Java applications on the server.
# 1. Create a directory called /local/notesjava/<identifier>
# 2. Copy the provided ID file to this directory
# 3. Setup a copy of notes.ini.
# EXAMPLE: ./setup_id_file.sh /tmp/TestUser.id TestUser

set -e

# Parameters
ID_UPLOAD_PATH=$1
ID_LABEL=$2
echo "Setting up ID $ID_LABEL ($ID_UPLOAD_PATH)"

TARGET_ID_NAME=external_user.id
BASE_DIR=/local/notesjava
ID_DIR="${BASE_DIR}/${ID_LABEL}"

#TODO;  check if it already exists

mkdir -p "$ID_DIR"
cp "$ID_UPLOAD_PATH" "$ID_DIR"
# TODO: replace ID file name
cat $BASE_DIR/notes.ini  | sed "s/KeyFilename=.*$/KeyFilename=${TARGET_ID_NAME}/" > "$ID_DIR/notes.ini"

# check and return the ID
cd "$ID_DIR"
java -jar ../CheckNotesUser.jar
# TODO: parse and return the ID

[JoelProminic]

Here is a quick mockup for the ID Files interface. This would be added under Moonshine > Settings > Vagrant. Note that "Default" is a placeholder that will be used to represent the default user for the Vagrant instance:

Fields:

• Label - a Moonshine name for the ID file, and it could also be used to identify the configured ID file on ths server. We may want to limit this to alphanumeric characters only to simplify the server logic
• ID File - the path to the local ID file
• TODO: The actual user name for the file. I don't think we can compute this locally. I'm hoping to return this as part of the ID upload action, but that may not be convenient for populating this datagrid.
• TODO: Checksum? We could consider using this to identify if the ID is on the Vagrant instance already, but this could change

While @JustinProminic and I discussed this, we also found we needed to track the target servers, so that we can setup the connection documents if needed. Fields:

• Server - the server name. I think this needs to include the organization/certifier (/STARTcloud)
• Address - the IP address for the server

The Test Server Action button is an example of how these entries would be used.

The process would like this:

1. Deploy the ID to the Vagrant instance and configure it throught the REST interface, if this is not already done. Some ways to track the status:
   • Update the /info page to show the IDs configured on the Vagrant instance
   • Check against the Label (this could have duplicates)
   • Check against the user name for the ID. However, we would need to determine this programatically when it is first uploaded
   • Check against a checksum for the ID file. However, this may change as the ID is renewed.
2. Provide the password for the ID file (if not done already). This will probably be done through some sort of password manager on the Vagrant instance.
3. Call the REST interface to make sure that the specified server is reachable. This will probably require creating a connection document if it doesn't exist already
4. Trigger the action through the REST interface.