Changeset - 883a0c6c425f
[Not reviewed]
default
0 1 0
Mads Kiilerich (mads) - 5 years ago 2021-05-09 22:17:21
mads@kiilerich.com
Grafted from: a4c973f1e3b4
docs: document how proxy servers must be configured
1 file changed with 29 insertions and 0 deletions:
0 comments (0 inline, 0 general)
docs/setup.rst
Show inline comments
 
@@ -361,96 +361,125 @@ By default, Kallithea uses UTF-8 encodin
 
This is configurable as ``default_encoding`` in the .ini file.
 
This affects many parts in Kallithea including user names, filenames, and
 
encoding of commit messages. In addition Kallithea can detect if the ``chardet``
 
library is installed. If ``chardet`` is detected Kallithea will fallback to it
 
when there are encode/decode errors.
 

	
 
The Mercurial encoding is configurable as ``hgencoding``. It is similar to
 
setting the ``HGENCODING`` environment variable, but will override it.
 

	
 

	
 
Celery configuration
 
--------------------
 

	
 
Kallithea can use the distributed task queue system Celery_ to run tasks like
 
cloning repositories or sending emails.
 

	
 
Kallithea will in most setups work perfectly fine out of the box (without
 
Celery), executing all tasks in the web server process. Some tasks can however
 
take some time to run and it can be better to run such tasks asynchronously in
 
a separate process so the web server can focus on serving web requests.
 

	
 
For installation and configuration of Celery, see the `Celery documentation`_.
 
Note that Celery requires a message broker service like RabbitMQ_ (recommended)
 
or Redis_.
 

	
 
The use of Celery is configured in the Kallithea ini configuration file.
 
To enable it, simply set::
 

	
 
  use_celery = true
 

	
 
and add or change the ``celery.*`` configuration variables.
 

	
 
Configuration settings are prefixed with 'celery.', so for example setting
 
`broker_url` in Celery means setting `celery.broker_url` in the configuration
 
file.
 

	
 
To start the Celery process, run::
 

	
 
  kallithea-cli celery-run -c my.ini
 

	
 
Extra options to the Celery worker can be passed after ``--`` - see ``-- -h``
 
for more info.
 

	
 
.. note::
 
   Make sure you run this command from the same virtualenv, and with the same
 
   user that Kallithea runs.
 

	
 

	
 
Proxy setups
 
------------
 

	
 
When Kallithea is processing HTTP requests from a user, it will see and use
 
some of the basic properties of the connection, both at the TCP/IP level and at
 
the HTTP level. The WSGI server will provide this information to Kallithea in
 
the "environment".
 

	
 
In some setups, a proxy server will take requests from users and forward
 
them to the actual Kallithea server. The proxy server will thus be the
 
immediate client of the Kallithea WSGI server, and Kallithea will basically see
 
it as such. To make sure Kallithea sees the request as it arrived from the
 
client to the proxy server, the proxy server must be configured to
 
somehow pass the original information on to Kallithea, and Kallithea must be
 
configured to pick that information up and trust it.
 

	
 
Kallithea will by default rely on its WSGI server to provide the IP of the
 
client in the WSGI environment as ``REMOTE_ADDR``, but it can also
 
get it from the ``X-Real-IP`` or ``X-Forwarded-For`` HTTP headers.
 

	
 
Kallithea will by default rely on finding the protocol (``http`` or ``https``)
 
in the WSGI environment as ``wsgi.url_scheme``. If the proxy server puts
 
the protocol of the client request in the ``X-Url-Scheme``,
 
``X-Forwarded-Scheme``, or ``X-Forwarded-Proto`` HTTP header,
 
Kallithea can be configured to trust these headers by setting::
 

	
 
    https_fixup = true
 

	
 

	
 
HTTPS support
 
-------------
 

	
 
Kallithea will by default generate URLs based on the WSGI environment.
 

	
 
Alternatively, you can use some special configuration settings to control
 
directly which scheme/protocol Kallithea will use when generating URLs:
 

	
 
- With ``https_fixup = true``, the scheme will be taken from the
 
  ``X-Url-Scheme``, ``X-Forwarded-Scheme`` or ``X-Forwarded-Proto`` HTTP header
 
  (default ``http``).
 
- With ``force_https = true``, the scheme will be seen as ``https``.
 
- With ``use_htsts = true``, Kallithea will set ``Strict-Transport-Security`` when using https.
 

	
 
.. _nginx_virtual_host:
 

	
 

	
 
Nginx virtual host example
 
--------------------------
 

	
 
Sample config for Nginx using proxy:
 

	
 
.. code-block:: nginx
 

	
 
    upstream kallithea {
 
        server 127.0.0.1:5000;
 
        # add more instances for load balancing
 
        #server 127.0.0.1:5001;
 
        #server 127.0.0.1:5002;
 
    }
 

	
 
    ## gist alias
 
    server {
 
       listen          443;
 
       server_name     gist.example.com;
 
       access_log      /var/log/nginx/gist.access.log;
 
       error_log       /var/log/nginx/gist.error.log;
 

	
 
       ssl on;
 
       ssl_certificate     gist.your.kallithea.server.crt;
 
       ssl_certificate_key gist.your.kallithea.server.key;
 

	
 
       ssl_session_timeout 5m;
 

	
 
       ssl_protocols SSLv3 TLSv1;
 
       ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5;
 
       ssl_prefer_server_ciphers on;
 

	
0 comments (0 inline, 0 general)