Further Considerations for Production Deployments

This page extends upon our “Deploying MediaGoblin” guide to describe some common issues affecting production deployments.

Should I Keep Open Registration Enabled?

Unfortunately, in this current release of MediaGoblin we are suffering from spammers registering to public instances en masse. As such, you may want to either:

  1. Disable registration on your instance and just make accounts for people you know and trust (eg via the gmg adduser command). You can disable registration in your mediagoblin.ini like so:

    [mediagoblin]
allow_registration = false

  2. Enable a CAPTCHA plugin. But unfortunately, though some CAPTCHA plugins exist, for various reasons we do not have any general recommendations we can make at this point.

We hope to have a better solution to this situation shortly. We apologize for the inconvenience in the meanwhile.

Confidential Files

Warning

The directory user_dev/crypto/ contains confidential information. In particular, the itsdangeroussecret.bin is important for the security of login sessions. Make sure not to publish its contents anywhere. If the contents gets leaked nevertheless, delete your file and restart the server, so that it creates a new secret key. All previous login sessions will be invalidated.

Background Media Processing

“Deploying MediaGoblin” covers use of a separate Celery process, but this sections describes this in more detail.

MediaGoblin uses Celery to handle heavy and long-running tasks. Celery can be launched in two ways:

  1. Embedded in the main MediaGoblin web application. This is the way ./lazyserver.sh does it for you. It’s simple as you only have to run one process. The only bad thing with this is that the heavy and long-running tasks will run in the webserver, keeping the user waiting each time some heavy lifting is needed as in for example processing a video. This could lead to problems as an aborted connection will halt any processing and since most front-end web servers will terminate your connection if it doesn’t get any response from the MediaGoblin web application in a while. This approach is suitable for development, small sites or when primarily using command line uploads.

  2. As a separate web application and media processing application (recommended). In this approach, the MediaGoblin web application delegates all media processing to a task queue via a broker (task queue). This is the approach used in our deployment guide, with RabbitMQ as the broker. This offloads the heavy lifting from the MediaGoblin web application and users will be able to continue to browse the site while the media is being processed in the background. This approach provided the best user experience and is recommended for production sites.

The choice between these two behaviours is controlled by the CELERY_ALWAYS_EAGER environment variable. Specifying true instructs MediaGoblin to processing media within the web application while you wait. Specifying false instructs MediaGoblin to use background processing.

Error Monitoring with Sentry

We have a plugin for raven integration, see the “raven plugin” documentation.

Running multiple MediaGoblin instances on the same server

It is possible to run multiple separate MediaGoblin instances concurrently on the same server. We don’t provide detailed instructions to do this, but broadly, each instance will need:

  1. A separate mediagoblin.ini and paste.ini.

  2. A separate database that is configured in mediagoblin.ini.

  3. A unique CELERY_DEFAULT_QUEUE configured in mediagoblin.ini. Queues are automatically created, but must be unique between MediaGoblin instances.

  4. A separate data directory created and configured in mediagoblin.ini and paste.ini.

  5. A unique server port configured in paste.ini under [server:broadcast].

You would typically configure the web server to route requests to the appropriate MediaGoblin instance port based on the requested domain name or something similar.

It is also possible to share the same MediaGoblin codebase and Python virtualenv between multiple instances, so long as they have a unique data directory.