Changeset - 850f096505ac
[Not reviewed]
stable
0 2 0
Mads Kiilerich (mads) - 6 years ago 2020-06-11 20:16:32
mads@kiilerich.com
docs: mention the npm dependency more clearly (Issue #345)
2 files changed with 8 insertions and 4 deletions:
0 comments (0 inline, 0 general)
docs/overview.rst
Show inline comments
 
@@ -96,99 +96,101 @@ locale that has the ``UTF-8`` encoding (
 
For technical reasons, the locale configuration **must** be provided in the
 
environment in which Kallithea runs - it cannot be specified in the ``.ini`` file.
 
How to practically do this depends on the web server that is used and the way it
 
is started. For example, gearbox is often started by a normal user, either
 
manually or via a script. In this case, the required locale environment
 
variables can be provided directly in that user's environment or in the script.
 
However, web servers like Apache are often started at boot via an init script or
 
service file. Modifying the environment for this case would thus require
 
root/administrator privileges. Moreover, that environment would dictate the
 
settings for all web services running under that web server, Kallithea being
 
just one of them. Specifically in the case of Apache with ``mod_wsgi``, the
 
locale can be set for a specific service in its ``WSGIDaemonProcess`` directive,
 
using the ``lang`` parameter.
 

	
 

	
 
Installation methods
 
--------------------
 

	
 
Kallithea must be installed on a server. Kallithea is installed in a Python
 
environment so it can use packages that are installed there and make itself
 
available for other packages.
 

	
 
Two different cases will pretty much cover the options for how it can be
 
installed.
 

	
 
- The Kallithea source repository can be cloned and used -- it is kept stable and
 
  can be used in production. The Kallithea maintainers use the development
 
  branch in production. The advantage of installation from source and regularly
 
  updating it is that you take advantage of the most recent improvements. Using
 
  it directly from a DVCS also means that it is easy to track local customizations.
 

	
 
  Running ``pip install -e .`` in the source will use pip to install the
 
  necessary dependencies in the Python environment and create a
 
  ``.../site-packages/Kallithea.egg-link`` file there that points at the Kallithea
 
  source.
 

	
 
- Kallithea can also be installed from ready-made packages using a package manager.
 
  The official released versions are available on PyPI_ and can be downloaded and
 
  installed with all dependencies using ``pip install kallithea``.
 

	
 
  With this method, Kallithea is installed in the Python environment as any
 
  other package, usually as a ``.../site-packages/Kallithea-X-py3.8.egg/``
 
  directory with Python files and everything else that is needed.
 

	
 
  (``pip install kallithea`` from a source tree will do pretty much the same
 
  but build the Kallithea package itself locally instead of downloading it.)
 

	
 
.. note::
 
   Kallithea includes front-end code that needs to be processed first.
 
   The tool npm_ is used to download external dependencies and orchestrate the
 
   processing. The ``npm`` binary must thus be available.
 
   Kallithea includes front-end code that needs to be processed to prepare
 
   static files that can be served at run time and used on the client side. The
 
   tool npm_ is used to download external dependencies and orchestrate the
 
   processing. The ``npm`` binary must thus be available at install time but is
 
   not used at run time.
 

	
 

	
 
Web server
 
----------
 

	
 
Kallithea is (primarily) a WSGI_ application that must be run from a web
 
server that serves WSGI applications over HTTP.
 

	
 
Kallithea itself is not serving HTTP (or HTTPS); that is the web server's
 
responsibility. Kallithea does however need to know its own user facing URL
 
(protocol, address, port and path) for each HTTP request. Kallithea will
 
usually use its own HTML/cookie based authentication but can also be configured
 
to use web server authentication.
 

	
 
There are several web server options:
 

	
 
- Kallithea uses the Gearbox_ tool as command line interface. Gearbox provides
 
  ``gearbox serve`` as a convenient way to launch a Python WSGI / web server
 
  from the command line. That is perfect for development and evaluation.
 
  Actual use in production might have different requirements and need extra
 
  work to make it manageable as a scalable system service.
 

	
 
  Gearbox comes with its own built-in web server for development but Kallithea
 
  defaults to using Waitress_. Gunicorn_ and Gevent_ are also options. These
 
  web servers have different limited feature sets.
 

	
 
  The web server used by ``gearbox serve`` is configured in the ``.ini`` file.
 
  Create it with ``config-create`` using for example ``http_server=waitress``
 
  to get a configuration starting point for your choice of web server.
 

	
 
  (Gearbox will do like ``paste`` and use the WSGI application entry point
 
  ``kallithea.config.middleware:make_app`` as specified in ``setup.py``.)
 

	
 
- `Apache httpd`_ can serve WSGI applications directly using mod_wsgi_ and a
 
  simple Python file with the necessary configuration. This is a good option if
 
  Apache is an option.
 

	
 
- uWSGI_ is also a full web server with built-in WSGI module. Use
 
  ``config-create`` with ``http_server=uwsgi`` to get a ``.ini`` file with
 
  uWSGI configuration.
 

	
 
- IIS_ can also server WSGI applications directly using isapi-wsgi_.
 

	
 
- A `reverse HTTP proxy <https://en.wikipedia.org/wiki/Reverse_proxy>`_
 
  can be put in front of another web server which has WSGI support.
 
  Such a layered setup can be complex but might in some cases be the right
 
  option, for example to standardize on one internet-facing web server, to add
 
  encryption or special authentication or for other security reasons, to
docs/setup.rst
Show inline comments
 
@@ -9,97 +9,99 @@ Setting up Kallithea
 
--------------------
 

	
 
First, you will need to create a Kallithea configuration file. Run the
 
following command to do so::
 

	
 
    kallithea-cli config-create my.ini
 

	
 
This will create the file ``my.ini`` in the current directory. This
 
configuration file contains the various settings for Kallithea, e.g.
 
proxy port, email settings, usage of static files, cache, Celery
 
settings, and logging. Extra settings can be specified like::
 

	
 
    kallithea-cli config-create my.ini host=8.8.8.8 "[handler_console]" formatter=color_formatter
 

	
 
Next, you need to create the databases used by Kallithea. It is recommended to
 
use PostgreSQL or SQLite (default). If you choose a database other than the
 
default, ensure you properly adjust the database URL in your ``my.ini``
 
configuration file to use this other database. Kallithea currently supports
 
PostgreSQL, SQLite and MariaDB/MySQL databases. Create the database by running
 
the following command::
 

	
 
    kallithea-cli db-create -c my.ini
 

	
 
This will prompt you for a "root" path. This "root" path is the location where
 
Kallithea will store all of its repositories on the current machine. After
 
entering this "root" path ``db-create`` will also prompt you for a username
 
and password for the initial admin account which ``db-create`` sets
 
up for you.
 

	
 
The ``db-create`` values can also be given on the command line.
 
Example::
 

	
 
    kallithea-cli db-create -c my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos
 

	
 
The ``db-create`` command will create all needed tables and an
 
admin account. When choosing a root path you can either use a new
 
empty location, or a location which already contains existing
 
repositories. If you choose a location which contains existing
 
repositories Kallithea will add all of the repositories at the chosen
 
location to its database.  (Note: make sure you specify the correct
 
path to the root).
 

	
 
.. note:: the given path for Mercurial_ repositories **must** be write
 
          accessible for the application. It's very important since
 
          the Kallithea web interface will work without write access,
 
          but when trying to do a push it will fail with permission
 
          denied errors unless it has write access.
 

	
 
Finally, prepare the front-end by running::
 
Finally, the front-end files must be prepared. This requires ``npm`` version 6
 
or later, which needs ``node.js`` (version 12 or later). Prepare the front-end
 
by running::
 

	
 
    kallithea-cli front-end-build
 

	
 
You are now ready to use Kallithea. To run it simply execute::
 

	
 
    gearbox serve -c my.ini
 

	
 
- This command runs the Kallithea server. The web app should be available at
 
  http://127.0.0.1:5000. The IP address and port is configurable via the
 
  configuration file created in the previous step.
 
- Log in to Kallithea using the admin account created when running ``db-create``.
 
- The default permissions on each repository is read, and the owner is admin.
 
  Remember to update these if needed.
 
- In the admin panel you can toggle LDAP, anonymous, and permissions
 
  settings, as well as edit more advanced options on users and
 
  repositories.
 

	
 

	
 
Internationalization (i18n support)
 
-----------------------------------
 

	
 
The Kallithea web interface is automatically displayed in the user's preferred
 
language, as indicated by the browser. Thus, different users may see the
 
application in different languages. If the requested language is not available
 
(because the translation file for that language does not yet exist or is
 
incomplete), English is used.
 

	
 
If you want to disable automatic language detection and instead configure a
 
fixed language regardless of user preference, set ``i18n.enabled = false`` and
 
specify another language by setting ``i18n.lang`` in the Kallithea
 
configuration file.
 

	
 

	
 
Using Kallithea with SSH
 
------------------------
 

	
 
Kallithea supports repository access via SSH key based authentication.
 
This means:
 

	
 
- repository URLs like ``ssh://kallithea@example.com/name/of/repository``
 

	
 
- all network traffic for both read and write happens over the SSH protocol on
 
  port 22, without using HTTP/HTTPS nor the Kallithea WSGI application
 

	
 
- encryption and authentication protocols are managed by the system's ``sshd``
 
  process, with all users using the same Kallithea system user (e.g.
 
  ``kallithea``) when connecting to the SSH server, but with users' public keys
 
  in the Kallithea system user's `.ssh/authorized_keys` file granting each user
0 comments (0 inline, 0 general)