Running Portal

Running Portal depends on the installation mechanism that you have chosen. However, if you have installed with our recommended configuration, all services apart from Nginx & Memcached can be run from supervisorctl:

sudo supervisorctl start portal:

Supervisorctl can be used remotely, has excellent ability to restart failing services, has good logging and generally makes the administrators live easier.

Monitoring Portal

Portal has its internal healthchecks but more things needs to be monitored. There are lots of external tool to check:

* Load
* Disk Usage
* Memory consumption

It is always good to have such tool installed.

Stopping & Restarting Portal

  • RedHat 6/CentOS 6 systems stop the remaining processes using these commands:

    $ sudo supervisorctl stop portal:
    $ sudo /etc/init.d/elasticsearch stop
    $ sudo /etc/init.d/vidispine stop
    $ sudo /etc/init.d/solr stop
    $ sudo /etc/init.d/transcoder stop
    
  • RedHat 7/CentOS 7 systems stop the remaining processes using these commands:

    $ sudo systemctl stop portal.target
    $ sudo systemctl stop elasticsearch
    $ sudo systemctl stop vidispine
    $ sudo systemctl stop solr
    $ sudo systemctl stop transcoder
    
  • Start everything up again.

  • RedHat 6/CentOS 6 systems starts using these commands:

    $ sudo supervisorctl start portal:
    $ sudo /etc/init.d/elasticsearch start
    $ sudo /etc/init.d/vidispine start
    $ sudo /etc/init.d/solr start
    $ sudo /etc/init.d/transcoder start
    
  • RedHat 7/CentOS 7 systems starts using these commands:

    $ sudo systemctl start vidispine
    $ sudo systemctl start solr
    $ sudo systemctl start transcoder
    $ sudo systemctl start elasticsearch
    $ sudo systemctl start portal.target
    

Status of services

For an overview of what services are running at any particular time.

  • RedHat 6/CentOS 6 systems:

    sudo supervisorctl status
    
  • RedHat 7/CentOS 7 systems:

    sudo systemctl status
    

Supervisor Management Console

Supervisorctl on RedHat 6/CentOS 6 supports a interactive management console which can be invoked:

sudo supervisorctl

Systemctl on RedHat 7/CentOS 7 sysemts:

sudo systemctl

There you can issue commands such as reload, status, help, stop, start, quit. Type help for more information.

Nginx (or other webservers)

Portal creates an interface for other webservers to use. It is recommended to always proxy portal with another webserver that can handle long connections, serving of static media files and handling upload and downloads of files.

Our recommended configuration is for Nginx and comes with a configuration for serving media files such as javascript, css, png, flash and jpeg files.

Nginx (and other webservers) should be started by the process control of the operating system for example to stop and start on Linux RedHat 6/CentOS 6:

sudo /etc/init.d/nginx stop
sudo /etc/init.d/nginx start.

And for RedHat 7/CentOS 7 systems:

systemctl stop nginx
systemctl start nginx

If you need to restart Portal, there is no need to restart Nginx unless a change has been made to Nginx or its configuration.

Memcache

Similar to Nginx, memcache is installed so that it is started by the machine it is running on. Though you should note that Memcache need not be installed on the same machine as the Portal application server. We do not change the amount of memory set aside for Memcache.

Supervisor with Nginx and Memcache

Supervisor can indeed be configured to control Nginx and Memcache as needed. This is out of scope for this document.

Logging

On a Unix production system we log to a Unix syslog server, or a modern variant. This is because we can have multiple instances of Portal running with many workers at one time.

Using HTTPS

In a default installation, Portal is accessible over the HTTP protocol. This configuration is only suitable for a secure environment such as when the system is deployed behind a company firewall or on a private network. If the system is accessible the recommendation is to configure the system to use HTTPS which encrypts the network traffic to protect it from attackers.

Please get a SSL cert for your host from a certified supplier.

If you just want to test SSL or do not have received your proper certificate yet, you may use a “snakeoil cert”, your browser will recommend to not connect to your portal with such a key, but it is still possible.

You can create a “snakeoil cert” like this:

cd /etc/ssl/certs/
./make-dummy-cert snakeoil

In order to configure HTTPS you will have to modify the file /etc/nginx/conf.d/portal.conf as follows.

At the beginning of the server section, change it to say:

listen 443 ssl;
ssl_certificate /etc/ssl/certs/snakeoil;
ssl_certificate_key /etc/ssl/certs/snakeoil;

Replace the certificate files above with your proper certificate as soon you have a proper cert available.

At the very end of the file, comment out the following block:

server {
    listen 80;
    server_name_in_redirect off;
    large_client_header_buffers 4 16k;

    # Proxy APInoauth requests for the java uploader
    location /APInoauth/ {
        client_max_body_size 1000M;
        proxy_buffering off;
        proxy_set_header     Referer "";
        proxy_pass           http://127.0.0.1:8080/APInoauth/;
    }

    # Redirect all other request to use https
    location / {
    rewrite ^(.*) https://$host$1 permanent;
    }
}

After this, restart nginx.

After this you need to update configuration so vidispine knows to contact Portal over https instead of http. This can either be done via the system settings page or by running the following:

/opt/cantemo/portal/manage.py get_vidispine_property portal_uri

which will print the existing value of the setting. Change this to say https instead of http and then run:

/opt/cantemo/portal/manage.py set_vidispine_property portal_uri <uri from above>

If you are running a self-signed certificate, or rulesengine fail to connect over ssl your certificate needs to be imported the certificate in “pem format” to certify:

cp /etc/ssl/certs/snakeoil.pem /opt/cantemo/python/lib/python3.6/site-packages/pip/_vendor/certifi/
cp /opt/cantemo/python/lib/python3.6/site-packages/certifi/cacert.pem /opt/cantemo/python/lib/python3.6/site-packages/certifi/cacert.pem.old
cat /etc/ssl/certs/snakeoil.pem >> /opt/cantemo/python/lib/python3.6/site-packages/certifi/cacert.pem

After moving your less trustworthy certificate in with the others, you will need to restart services dependant on the certificate:

  • nginx
  • portal.target
  • tomcat

When/if you have a properly signed certificate, you should remove your self-signed cert from the end of /opt/cantemo/python/lib/python3.6/site-packages/certifi/cacert.pem

NOTE: When using a self-signed / snakeoil or otherwise untrusted certificate, certain browsers and or browser versions may not download media files properly which can cause the video player not to work. In this case, make sure you have added the certificate to your computer’s local key store. How to do this varies between browsers and/or operating systems. You will also have to add the certificate to the truststore so vidispine can contact portal.

Using HTTP and HTTPS Proxies

If you need to specify proxy servers for any of the services/components that Portal is using, you will need to set them up by using environment variables. The http_proxy and https_proxy environment variables are used to specify proxy settings for client programs executing http requests. The format looks like:

http_proxy="http://SERVER:PORT/"
http_proxy="http://USERNAME:PASSWORD@SERVER:PORT/"

When setting them up, all the http or https requests will pass through the proxy. So, depending on your configuration, you might sometimes need to specify a way to skip some requests to go through the proxy. For instance, in the regular installation Portal and Vidispine are running on the same server, so it’s needed to avoid proxying the localhost address for them to be able to communicate. This can be done by using the no_proxy variable:

no_proxy="127.0.0.1, localhost"

In order to permanently set the variables, they can be added to “/etc/environment”, so that they will be loaded every time a new process is started. As most of the services in Portal are running under “systemd”, it is also needed to set them up in a special way for every service. If we take “portal-web.service” as an example of a service we want to specify these variables on, you will need to do the following:

First, create a folder with the service name and “.d” suffix under /etc/systemd/system/, for example:

/etc/systemd/system/portal-web.service.d

Then, add a text file (with any name), but with the “.conf” suffix, for example, “proxies.conf”, and add the environment variables like this:

[Service]
Environment=http_proxy=...
Environment=no_proxy=...

Then restart the systemd daemon so that the changes take effect:

systemctl daemon-reload

And then restart portal.target:

systemctl restart portal.target

Note

Always remember to properly specify the no_proxy variable, as the Portal installer is also making use of this and can fail if cannot establish a communication with Vidispine or other services.

Changing the log level

Simply change the log level on Portal’s system settings page available under Admin

_images/LogLevelChange.png

To one of these levels: DEBUG, ERROR, INFO, WARN, CRITICAL.

Click save and the change will take effect immediately.

More information please see Portal logging.

Additional logging parameters

Portal uses the Python logging module, and its documentation is a good source of further usage and configuration of logging such as handlers for automatically emailing certain levels, having a HTTP server for seeing log files and logging to multiple locations.