Researchdata and static-tables playbooks are broken

[acozine]

Expected behavior

These two playbooks (researchdata and static-tables) should install open-source nginx as a local webserver.

Actual behavior

Both playbooks fail with the error:

TASK [nginxplus : Install: Set NGINX App-Protect Signing Key URL] ********************************************************
fatal: [prds-staging2.princeton.edu]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'nginx_app_protect_signing_key' is undefined. 'nginx_app_protect_signing_key' is undefined\n\nThe error appears to be in '/Users/cc62/apps_team/princeton_ansible/roles/nginxplus/tasks/keys/apt-key.yml': line 32, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: \"Install: Set NGINX App-Protect Signing Key URL\"\n  ^ here\nThis one looks easy to fix. It seems that there is a value started\nwith a quote, and the YAML parser is expecting to see the line ended\nwith the same kind of quote. For instance:\n\n    when: \"ok\" in result.stdout\n\nCould be written as:\n\n   when: '\"ok\" in result.stdout'\n\nOr equivalently:\n\n   when: \"'ok' in result.stdout\"\n"}

If you add a line to include /group_vars/nginxplus/main.yml, providing access to the variable from the error above, the playbooks build an nginxplus load balancer on the prds-staging and static-tables VMs.

Steps to replicate

Run the playbooks on staging.

Impact of this bug

We cannot update any of the VMs for these project.

Relevant links and code snippets, if applicable

Implementation notes, if any

We think the playbooks were working correctly as of July 1st. They are broken as of July 8. The nginx_type variable should default to opensource, which should not run the task that errored out above.

[kayiwa]

Should we need to use multiple CORS this will be the way to do that

[maxkadel]

I believe allsearch-frontend works with tunneling because the Access-Control-Allow-Origin header is turned off entirely - see vite.config.ts:8.

It looks like we could give this a more fine-grained CORS policy - see vite config reference and expressjs config reference.

[maxkadel]

When we were trying to see whether static-tables was rendering correctly on the new production server, we followed our common local practice of tunneling into the new server to look at the page before putting it on the load balancer. When we tunneled in, all we saw was a blank page.

To see why, we opened the console in the browser dev tools, and saw that the content was being blocked by CORS policies. Right now, this policy is being set in roles/static_tables/templates/default.conf.j2, and allows the origin https://library.princeton.edu or https://library-staging.princeton.edu, depending which server it's run on. (it's proxy-passed to the library domain, although I assume that's changing soon)

As a developer, I'd like it if the both I and the Ops team can continue to use our tunneling pattern to check a server before putting it on the load balancer.