.. MediaGoblin Documentation
Written in 2011, 2012, 2013, 2014, 2015 by MediaGoblin contributors
To the extent possible under law, the author(s) have dedicated all
copyright and related and neighboring rights to this software to
the public domain worldwide. This software is distributed without
any warranty.
You should have received a copy of the CC0 Public Domain
Dedication along with this software. If not, see
.
=================================================
Further Considerations for Production Deployments
=================================================
This page extends upon our ":doc:`deploying`" 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:
a) 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
b) 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:
Background Media Processing
---------------------------
":doc:`deploying`" 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 :doc:`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 :doc:`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.
.. _`broker`: http://docs.celeryproject.org/en/latest/getting-started/brokers/
.. _`celery`: http://www.celeryproject.org/
.. _sentry:
Error Monitoring with Sentry
----------------------------
We have a plugin for `raven`_ integration, see the ":doc:`/plugindocs/raven`"
documentation.
.. _`raven`: http://raven.readthedocs.org
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.