System level management utilities

[campb303]

The API is separate from the from the frontend and at this time needs to be managed separately. Starting, stopping and restarting the API could be achieved by one of the following options:

1. Apache Control Script: Using the same control script presented to a user running web services on Templeton for controlling Apache, the API could be managed with the same commands and the Apache server it runs on. This has a benefit of being a unified interface and a drawback of requiring both services to be started, stopped and restarted at the same time.

2. User Level Cronjob: The API could be started by a cronjob run as the same user who controls the Apache web server with an @reboot job. This has a benefit of being automatic and a drawback of no subsequent control as the PID is lost.

3. Init System Hook: Templeton uses the SysV init system. The API could have its own service file for starting, stopping and restarting itself. This has a benefit of a decoupled yet accessible control interface and a drawback of permission restrictions. The web user would need to be given access to that service file.

[campb303]

After the initial webqueue2 demo, @cs and I discussed running the API on pier instead of templeton because the item files are actually stored on pier and the filesystem is exported to templeton just for webqueue. This could allow for significant performance increases. Additionally, pier has a more up to date version of Python and runs on CentOS 7 whereas templeton runs on CentOS 6.

This could work but will require the API to have a dedicated port on pier and a reverse proxy through Apache on templeton.

[campb303]

#45 is related to this.

[campb303]

A SystemD unit file should be written to start, stop, restart and monitor the API and docs site. The UI should be handled via Apache directly, though the unit file could launch the Apache instance for webqueue2

[campb303]

This depends on #121