Public facing URL

[benne238]

Ask Linux group for a top level domain for webqueue2

[campb303]

A request has been made to software queue for this. Waiting to hear from them.

[campb303]

No movement here as of today. Need to check again with Sundeep/schultzy.

[campb303]

The issue has been archives but no webserver installed on on q2vm.

campb303@q2vm [~]
$ which apache
campb303@q2vm [~]
$ which nginx

Need to check with sundeep/shultzy next week.

[campb303]

Last week, Sundeep said that Dave had approved the requests for a webserver to be installed on q2vm.ecn.purdue.edu but I've not heard anything since. Need to ask Sundeep, Schultzy or Dave about this

[campb303]

Not sure if we're proceeding with running webqueue2 on templeton or q2vm. Both the frontend and backend for the system seems to be able to run on templeton with the current supported version of Apache and Python 3. However, work just finished on q2vm that also allows webqueue2 to be run there (though the reverse proxy would need to be modified.)

Need to confirm with Sundeep before deploying anything.

[campb303]

Discussion about this happened in a now archived queue item. Below are the relevant excerpts. For the entire item, see: /home/pier/e/queue/Mail/archives/software/YM2012/59

---

The instructions I have are to implement changes for an Apache application to support webqueue2. I far as I know, webqueue2 is built with Node, not Apache.

webqueue2 exists in two parts: the frontend and the backend. The frontend development requires Node to build static HTML, CSS and JS which can in turn be served by Apache with no special setup aside from the /api endpoint being redirected to the backend. The backend is a standalone WSGI server that only needs Python 3 to run.

...we might support creating a standalone system to run a single Node application. But part of the implementation would need to have some ground-rules:

• The application must be self-starting after a reboot or system failure.

This can be achieved using a cron job but would be better accomplished with an init system level process so that monitoring and active restarting can happen. Discussion about system level controls happens in #11.

• The application must run as an independent account so not to be tied to a staff account.

This should be a non-issue. Any user account can be configured to control the systems needed.

• The application must communicate over a secure channel with SSL, the application must be at a well known URL,

We've set-up the host q2vm.ecn.purdue.edu to handle service requests for the URL https://webqueue2.ecn.purdue.edu.

The account "qweb" is available, on the host, to run the back-end Python3 web server. We've copied Justin's ssh key to the "qweb" account.

• The application must be secured to only be accessible by authorized users, using their career account password or two-factor-authentication, no static passwords allowed.

webqueue2 is configured to only work when using HTTPS. User's authenticate against Active Directory via BoilerAD and are authorized by JWTs stored in secure cookies. See #15

• The application must be able to be redeployed in the case of server disaster recovery, either by back-up should the application collect and store data or just be able to reinstall the application.

Work is underway to package webqueue2 as a Debian package for easy integration with software group's Igor provisioning system. The API's .env file will be configured to be autogenerated during install. Otherwise, data is either derived from the live queue or stored in the client's browser. If/when server data gets stored, import/export facilities will be made available.

[campb303]

Current goal is to make things works on templeton in which case the URL may need to be redirected.

[campb303]

A technical preview of webqueue2 is running on templeton at https://engineering.purdue.edu/webqueue/webqueue2/build/

After the technical preview has been tested well enough, a request should be made to create a new host on templeton and redirect https://webqueue2.ecn.purdue.edu/ to said host.

[campb303]

We should get a dedicated account for webqueue2 to address the current issues with permissions when installing/updating.

Need to talk to Sundeep about this.

[campb303]

Talked with Sundeep about this. Currently discussing options for moving forward in software queue.

[campb303]

The desire for a webqueue2 account on Templeton comes because the current workflow for updating webqueue2 requires two users across two machines with several repeated permissions changes that eventually get overwritten and need to be redone.

Work is in progress on the API side that can ease some of these issues by allowing the API to be deployed and controlled independently from the frontend. This work can be tracked here ECN/webqueue2-api#20. The details have been sent to software queue.

Waiting for a reply from software queue.

[campb303]

Support for infrastructure group has discontinued. We will move forward with a subdirectory of https://engineering.purdue.edu/webqueue/webqueue2/build/ that maps to /groups/web/qweb/webqueue2/build and rely on .htaccess redirects to reconnect other resources. Closing.