# Installation

## Build the server binary

    CGO_ENABLED=0 go build -ldflags='-s -w'

## Create a server certificate

    mkdir data
    openssl req -newkey rsa:2048 -nodes -keyout data/key.pem -x509 -days 365 -out data/cert.pem

## Set the server administrator credentials

This step is optional.

    echo 'god:topsecret' > data/passwd

## Set up a TURN server

This step depends on your network setup and your user population.  If your
server is accessible from the Internet (no firewall or NAT) and none of
your users are behind restrictive firewalls, then no ICE servers are
necessary.  If your server is behind a NAT, a STUN server is required.  If
any of your users are behind restrictive firewalls (which is usually the
case of Academic and Enterprise networks), then you will need a TURN
server running on an innocent-looking TCP port.  This is the recommended
setup.

You should probably be running your own TURN server — I use *coturn*.  The
address of the TURN server is configured in the file `data/ice-servers.json`.
It should look like this:

    [
        {
            "urls":["turn:turn.example.com:443"],
            "username":"username",
            "credential":"password"
        },
        {
            "urls":["turn:turn.example.com:443?transport=tcp"],
            "username":"username",
            "credential":"password"
        }
    ]

The port number, username and password should be the same as the ones in
your TURN server's configuration.

## Set up a group

A group is set up by creating a file `groups/name.json`.  The available
options are described below.

    mkdir groups
    vi groups/public.json

    {
      "public":true,
      "op":[{"username":"jch","password":"1234"}],
      "presenter":[{}],
      "max-users":100
    }

## Copy the necessary files to your server:

Assuming you have set up a user *sfu*:

    rsync -a sfu static data groups sfu@server.example.org:

## Run the server binary:

    ssh sfu@server.example.org
    nohup ./sfu &

If you are using *runit*, use a script like the following:

    #!/bin/sh
    exec 2>&1
    cd ~sfu
    exec setuidgid sfu ./sfu

If you are using *systemd*, use `Type=simple` in your service file.

# Locations

There is a landing page at the root of the server.  It contains a form
for typing the name of a group, and a clickable list of public groups.

Groups are available under `/group/groupname`.  You may share this URL
with others, there is no need to go through the landing page.

Recordings can be accessed under `/recordings/groupname`.  This is only
available to the administrator of the group.

Some statistics are available under `/stats`.  This is only available to
the server administrator.


# Group definitions

Groups are defined by files in the directory defined by the `-groups`
command-line option, one per group.  The group definition file does not
contain the name of the group -- that makes it possible to set up a new
group just by copying a template file.

The group definition file contains a JSON directory with the following
fields, all of which are optional.

 - `op`, `presenter`, `other`: each of these is an array of user
   definitions (see below) and specifies the users allowed to connect
   respectively with operator privileges, with presenter privileges, and
   as passive listeners;
 - `public`: if true, then the group is visible on the landing page;
 - `description`: a human-readable description of the group; this is
   displayed on the landing page for public groups;
 - `max-clients`: the maximum number of clients that may join the group at
   a time;
 - `max-history-age`: the time, in seconds, during which chat history is
   kept (default 14400, i.e. 4 hours);
 - `allow-recording`: if true, then recording is allowed in this group;
 - `allow-anonymous`: if true, then users may connect with an empty username.
 - `allow-subgroups`: if true, then subgroups of the form `group/subgroup`
   are automatically created when accessed.
 - `redirect`: if set, then attempts to join the group will be redirected
   to the given URL; most other fields are ignored in this case.
   
A user definition is a dictionary with the following fields:

 - `username`: the username of the user; if omitted, any username is
   allowed;
 - `password`: the password of the user; if omitted, then any password
   (including the empty paassword) is allowed.
   
For example

    {"username":"jch", "password":"topsecret"}
    
specifies user *jch* with password *topsecret*, while

    {"password":"topsecret"}
    
specifies that any username will do.  The empty dictionary

    {}
    
specifies that any username will do and that passwords are not verified.


# Commands

Typing a line starting with a slash `/` in the chat dialogue causes
a command to be sent to the server.  Type `/help` to get the list of
available commands; the output depends on whether you are an operator or
not.

--- Juliusz Chroboczek <https://www.irif.fr/~jch/>