The provided `gunicorn` command did not work for me, failing with the following error:
```
ModuleNotFoundError: No module named '/home/paperless/paperless/src/paperless'
```
The solution was to provide only `paperless.wsgi` as the argument to `gunicorn`, and provide a flag for `--pythonpath`. After changing it to this, the server started up fine.
* Vagrant does not seem to have any libvirt boxes for Ubuntu any more.
* Vagrant 2 was released a year ago, but vagrant-libvirt only claims
to support up to Vagrant 1.8.
When using the built-in webserver in debug mode, the static files are
handled automatically. From the Django docs:
During development, if you use django.contrib.staticfiles, this will
be done automatically by runserver when DEBUG is set to True (see
django.contrib.staticfiles.views.serve()).
This method is grossly inefficient and probably insecure, so it is
unsuitable for production.
This means, when using a real webserver, it also has to serve the static
files, i.e. CSS and JavaScript. For that, one needs to run `./manage.py
collectstatic` first.
The problem with the original instruction is that systemd creates a
symlink pointing to the service file in the paperless directory. A user
is unlikely to leave the changes in the service files committed
(especially not on a master branch checkout) and they are easily lost and
the services fail to start without obvious reason.
To avoid this we simply copy the service files to the systemd directory
directly and use the files in the repository only as an example.
Added a line on how to use the ubuntu upstart example in Vagrant. It took me hours to figure out why it wouldn't start on boot but would when you would type "start paperless-server" manually. The start on vagrant-mounted solved the problem, so I thought it would be good to share this with the paperless community.
The default files assume a specific path on the target system. Added a note letting people know they need to edit the files. Also fixed a bug with enabling the service - it caused odd errors on my system. Tested on Centos 7.
This file, like `docker-compose.yml`, should be edited by the user. To
avoid merge conflicts when pulling updates, the edited version should
not be committed to the repository.
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
