Create Config File

[daknob]

Add a way to configure the software, either using environment variables or by using a configuration file.

This will eliminate the need for major edits to personalize the web app to an organization / user.

[j11e]

I'll look into it. My intention being to do this, then improve the backend selection as mentioned in #15 .

[daknob]

Here are some thoughts I had about a Configuration File:

• My experience has shown that changing files inside a docker image, especially from Docker Hub, can be difficult to manage, even if it exposes a volume that can be mapped to the host.
• My experience has also shown that ENV (Environment Variables) are easy to handle in all languages, including Python, and they work perfectly with docker.
• If you decide to run TorPaste in Production, Gunicorn seems to be a good choice for a web server. Gunicorn has a configuration directory already, namely etc/gunicorn.d/. In this directory you add files, and these files are then executed as single applications. These configuration files accept ENV variables and handle them perfectly.

So the way I see it, we can make TorPaste configurable using Environment Variables, so docker users can configure the image without editing it by adding -e's in docker run, while non-docker users can configure it by adding these variables in Gunicorn itself. We should also include a list of all variables currently being used, one by one, in README.md or a similar file, and also include examples of docker run commands as well as a sample Gunicorn Configuration File.

What do you think?

[j11e]

This sounds reasonable and I don't see a problem with this approach. While I would like, generally speaking, to keep configuration within the TorPaste folder, I realize it's not actually possible - this would always require some configuration in Gunicorn or Nginx or whatever. We should keep things simple, and your proposal is, so let's do things this way.

Writing documentation and example files is also clearly a good and important idea. The "standard way" is to have a clear and concise README.md and more complete docs in a doc/ folder, so I propose to do things this way.

What I propose is: let's create a branch (say "feature/configurability") in which I'll push a first draft of example Gunicorn and Nginx files, as well as a more detailed "Installing, configuring and running TorPaste" doc. Then, when we agree on the doc, we'll use it as a spec for the actual implementation. How does that sound?

[daknob]

For a seamless migration for our existing users (I know there are barely any users now, but you get the idea.. 😄 ), I suggest we add the environment variables to the code, and check if they're set. If they're not, we should default to the current behavior. By doing this, everyone will be able to update to a newer version, say v0.5, and still have everything working without needing some change.

For this, I propose the following ENV variables, all starting with TP_ to ensure no conflicts:

• TP_WEBSITE_TITLE: The content of the <title></title> HTML tags, also known as WEBSITE_TITLE in torpaste.py. Default: Tor Paste
• TP_BACKEND: The name of the backend implementation's file to use. Each backend may have additional TP_BACKEND_$1_ variables such as TP_BACKEND_FILESYSTEM_FOLDER_NAME. TorPaste should check if this backend exists and if this version of TorPaste is supported, and then enable it or quit. Default: filesystem
• TP_API_ACTIVE: Enable or disable the TorPaste API. Default: yes
• TP_RATE_LIMITING_ACTIVE: Enable or disable Rate Limiting. Default: no
• TP_PASTE_LIST_ACTIVE: Enable or disable the "Pastes" Menu Item. Default: yes
• TP_PRIVATE_PASTES_ACTIVE: Enable or disable the ability to post private pastes. Default: no

[j11e]

This looks good. Maybe we'll need some additional parameters (similar to TP_BACKEND_$1_*) for the rating limiting or the API (such as the key), but I think we can leave that for when these features will actually be implemented. After all, at that point it will just be a question of updating the documentation.

[daknob]

Yes, this is something we can leave for later and decide what we'll do. These Environment Variables are of course not final, neither binding.