Skip to content

Latest commit

 

History

History
57 lines (32 loc) · 2.55 KB

README.md

File metadata and controls

57 lines (32 loc) · 2.55 KB

Octave Online Server: Back Server

This directory contains the source code for the Octave Online Server back server. This is the "master" process that communicates with the downstream user via Redis and with the GNU Octave subprocess. Commands dealing with the filesystem are in the back-filesystem directory parallel to this directory.

Setup

There are three modes for the back server.

  1. SELinux: Fast, and able to handle many concurrent sessions.
  2. Unsafe: Fast and easy, but not recommended with untrusted users. Every Octave process is run without any sandboxing or resource limitations.

Previously, a third mode, "docker", worked by creating a new Docker container for each session. This is no longer supported. Instead, if running with trusted users, you can use a single Docker container and Unsafe mode.

Option 1: SELinux

Ensure that you are running on CentOS or another distribution of Linux that supports SELinux. SELinux should come pre-installed on CentOS.

Make and build Octave from source. Follow a procedure similar to the one put forth in dockerfiles/build-octave.dockerfile.

Run sudo yum install -y selinux-policy-devel policycoreutils-sandbox selinux-policy-sandbox libcgroup-tools

Ensure that Node.js is installed and the dependencies are downloaded for the shared project:

$ (cd shared && npm install)

Run all of the following make commands from the projects directory.

  • sudo make install-cgroup
  • sudo make install-selinux-policy
  • sudo make install-selinux-bin
  • sudo make install-site-m

Option 2: Unsafe

Follow the Option 2 instructions to build and install Octave from source. Stop before installing selinux-policy-devel and other selinux packages.

Running the Back Server

Debugging

Go to the back-master directory and run DEBUG=* node app.js to start the back server. The DEBUG=* enables debug logging.

Production

node app.js can be run directly, but consider using oo.service in the entrypoint directory parallel to this directory.

Stopping the Back Server

By default, after the back server receives a successful maintenance request, it will wait for all sessions to close, and then cleanup and exit with code 0.

If you wish to cause the back server process to gracefully release all sessions without exiting, you can send the signal SIGUSR1 to the process.

To-do list