.. _installation:

==========================

Installation on Unix/Linux

==========================

The following describes three different ways of installing Kallithea:

- :ref:`installation-source`: The simplest way to keep the installation

  up-to-date and track any local customizations is to run directly from

  source in a Kallithea repository clone, preferably inside a virtualenv

  virtual Python environment.

- :ref:`installation-virtualenv`: If you prefer to only use released versions

  of Kallithea, the recommended method is to install Kallithea in a virtual

  Python environment using `virtualenv`. The advantages of this method over

  direct installation is that Kallithea and its dependencies are completely

  contained inside the virtualenv (which also means you can have multiple

  installations side by side or remove it entirely by just removing the

  virtualenv directory) and does not require root privileges.

- :ref:`installation-without-virtualenv`: The alternative method of installing

  a Kallithea release is using standard pip. The package will be installed in

  the same location as all other Python packages you have ever installed. As a

  result, removing it is not as straightforward as with a virtualenv, as you'd

  have to remove its dependencies manually and make sure that they are not

  needed by other packages.

Regardless of the installation method you may need to make sure you have

appropriate development packages installed, as installation of some of the

Kallithea dependencies requires a working C compiler and libffi library

headers. Depending on your configuration, you may also need to install

Git and development packages for the database of your choice.

For Debian and Ubuntu, the following command will ensure that a reasonable

set of dependencies is installed::

    sudo apt-get install build-essential git libffi-dev python3-dev

For Fedora and RHEL-derivatives, the following command will ensure that a

reasonable set of dependencies is installed::

    sudo yum install gcc git libffi-devel python3-devel

.. _installation-source:

Installation from repository source

-----------------------------------

To install Kallithea in a virtualenv using the stable branch of the development

repository, use the following commands in your bash shell::

        hg clone https://kallithea-scm.org/repos/kallithea -u stable

        cd kallithea

        python3 -m venv ../kallithea-venv

        . ../kallithea-venv/bin/activate

        pip install --upgrade pip setuptools

        pip install --upgrade -e .

        python3 setup.py compile_catalog   # for translation of the UI

.. _installation-virtualenv:

Installing a released version in a virtualenv

---------------------------------------------

It is highly recommended to use a separate virtualenv for installing Kallithea.

This way, all libraries required by Kallithea will be installed separately from your

main Python installation and other applications and things will be less

problematic when upgrading the system or Kallithea.

An additional benefit of virtualenv is that it doesn't require root privileges.

- Assuming you have installed virtualenv, create a new virtual environment

  for example, in `/srv/kallithea/venv`, using the venv command::

    python3 -m venv /srv/kallithea/venv

- Activate the virtualenv in your current shell session and make sure the

  basic requirements are up-to-date by running the following commands in your

  bash shell::

    . /srv/kallithea/venv/bin/activate

    pip install --upgrade pip setuptools

.. note:: You can't use UNIX ``sudo`` to source the ``virtualenv`` script; it

   will "activate" a shell that terminates immediately. It is also perfectly

   acceptable (and desirable) to create a virtualenv as a normal user.

- Make a folder for Kallithea data files, and configuration somewhere on the

  filesystem. For example::

    mkdir /srv/kallithea

- Go into the created directory and run this command to install Kallithea::

    pip install --upgrade kallithea

.. note:: Some dependencies are optional. If you need them, install them in

   the virtualenv too::

     pip install --upgrade kallithea python-ldap python-pam psycopg2

   This might require installation of development packages using your

   distribution's package manager.

  Alternatively, download a .tar.gz from http://pypi.python.org/pypi/Kallithea,

  extract it and install from source by running::

    pip install --upgrade .

- This will install Kallithea together with all other required

  Python libraries into the activated virtualenv.

.. _installation-without-virtualenv:

Installing a released version without virtualenv

------------------------------------------------

For installation without virtualenv, 'just' use::

    pip install kallithea

Note that this method requires root privileges and will install packages

globally without using the system's package manager.

To install as a regular user in ``~/.local``, you can use::

    pip install --user kallithea

You can now proceed to :ref:`setup`.

.. _overview:

=====================

Installation overview

=====================

Some overview and some details that can help understanding the options when

installing Kallithea.

1. **Prepare environment and external dependencies.**

    Kallithea needs:

    * A filesystem where the Mercurial and Git repositories can be stored.

    * A database where meta data can be stored.

    * A Python environment where the Kallithea application and its dependencies

      can be installed.

    * A web server that can host the Kallithea web application using the WSGI

      API.

2. **Install Kallithea software.**

    This makes the ``kallithea-cli`` command line tool available.

    Use ``kallithea-cli config-create`` to create a ``.ini`` file with database

    connection info, mail server information, configuration for the specified

    web server, etc.

    Use ``kallithea-cli db-create`` with the ``.ini`` file to create the

    database schema and insert the most basic information: the location of the

    repository store and an initial local admin user.

6. **Configure the web server.**

    The web server must invoke the WSGI entrypoint for the Kallithea software

    using the ``.ini`` file (and thus the database). This makes the web

    application available so the local admin user can log in and tweak the

    configuration further.

7. **Configure users.**

    The initial admin user can create additional local users, or configure how

    users can be created and authenticated from other user directories.

See the subsequent sections, the separate OS-specific instructions, and

:ref:`setup` for details on these steps.

Python environment

------------------

**Kallithea** is written entirely in Python_ and requires Python version

3.6 or higher.

Given a Python installation, there are different ways of providing the

environment for running Python applications. Each of them pretty much

corresponds to a ``site-packages`` directory somewhere where packages can be

installed.

Kallithea itself can be run from source or be installed, but even when running

from source, there are some dependencies that must be installed in the Python

environment used for running Kallithea.

- Packages *could* be installed in Python's ``site-packages`` directory ... but

  that would require running pip_ as root and it would be hard to uninstall or

  upgrade and is probably not a good idea unless using a package manager.

- Packages could also be installed in ``~/.local`` ... but that is probably

  only a good idea if using a dedicated user per application or instance.

- Finally, it can be installed in a virtualenv. That is a very lightweight

  "container" where each Kallithea instance can get its own dedicated and

  self-contained virtual environment.

We recommend using virtualenv for installing Kallithea.

Locale environment

------------------

In order to ensure a correct functioning of Kallithea with respect to non-ASCII

characters in user names, file paths, commit messages, etc., it is very

important that Kallithea is run with a correct `locale` configuration.

On Unix, environment variables like ``LANG`` or ``LC_ALL`` can specify a language (like

``en_US``) and encoding (like ``UTF-8``) to use for code points outside the ASCII

range. The flexibility of supporting multiple encodings of Unicode has the flip

side of having to specify which encoding to use - especially for Mercurial.

It depends on the OS distribution and system configuration which locales are

available. For example, some Docker containers based on Debian default to only

supporting the ``C`` language, while other Linux environments have ``en_US`` but not

``C``. The ``locale -a`` command will show which values are available on the

current system. Regardless of the actual language, you should normally choose a

locale that has the ``UTF-8`` encoding (note that spellings ``utf8``, ``utf-8``,

``UTF8``, ``UTF-8`` are all referring to the same thing)

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

.. _setup:

=====

Setup

=====

Setting up Kallithea

--------------------

Some further details to the steps mentioned in the overview.

Create low level configuration file

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

First, you will need to create a Kallithea configuration file. The

configuration file is a ``.ini`` file that contains various low level settings

for Kallithea, e.g. configuration of how to use database, web server, email,

and logging.

Run the following command to create the file ``my.ini`` in the current

directory::

    kallithea-cli config-create my.ini http_server=waitress

To get a good starting point for your configuration, specify the http server

you intend to use. It can be ``waitress``, ``gearbox``, ``gevent``,

``gunicorn``, or ``uwsgi``. (Apache ``mod_wsgi`` will not use this

configuration file, and it is fine to keep the default http_server configuration

unused. ``mod_wsgi`` is configured using ``httpd.conf`` directives and a WSGI

wrapper script.)

Extra custom settings can be specified like::

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

Populate the database

^^^^^^^^^^^^^^^^^^^^^

Next, you need to create the databases used by Kallithea. Kallithea currently

supports PostgreSQL, SQLite and MariaDB/MySQL databases. It is recommended to

start out using SQLite (the default) and move to PostgreSQL if it becomes a

bottleneck or to get a "proper" database. MariaDB/MySQL is also supported.

For PostgreSQL, run ``pip install psycopg2`` to get the database driver. Make

sure the PostgreSQL server is initialized and running. Make sure you have a

database user with password authentication with permissions to create databases

- for example by running::

    sudo -u postgres createuser 'kallithea' --pwprompt --createdb

For MariaDB/MySQL, run ``pip install mysqlclient`` to get the ``MySQLdb``

database driver. Make sure the database server is initialized and running. Make

sure you have a database user with password authentication with permissions to

create the database - for example by running::

    echo 'CREATE USER "kallithea"@"localhost" IDENTIFIED BY "password"' | sudo -u mysql mysql

    echo 'GRANT ALL PRIVILEGES ON `kallithea`.* TO "kallithea"@"localhost"' | sudo -u mysql mysql

Check and adjust ``sqlalchemy.url`` in your ``my.ini`` configuration file to use

this database.

Create the database, tables, and initial content by running the following

command::

    kallithea-cli db-create -c my.ini

This will first prompt you for a "root" path. This "root" path is the location

where Kallithea will store all of its repositories on the current machine. This

location must be writable for the running Kallithea application. Next,

``db-create`` will prompt you for a username and password for the initial admin

account it 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:: It is also possible to use an existing database. For example,

          when using PostgreSQL without granting general createdb privileges to

          the PostgreSQL kallithea user, set ``sqlalchemy.url =

          postgresql://kallithea:password@localhost/kallithea`` and create the

          database like::

              sudo -u postgres createdb 'kallithea' --owner 'kallithea'

              kallithea-cli db-create -c my.ini --reuse

Running

^^^^^^^

You are now ready to use Kallithea. To run it using a gearbox web server,

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

  sandboxed access to the repositories.

- users and admins can manage SSH public keys in the web UI

- in their SSH client configuration, users can configure how the client should

  control access to their SSH key - without passphrase, with passphrase, and

  optionally with passphrase caching in the local shell session (``ssh-agent``).

  This is standard SSH functionality, not something Kallithea provides or

  interferes with.

- network communication between client and server happens in a bidirectional

  stateful stream, and will in some cases be faster than HTTP/HTTPS with several

  stateless round-trips.

.. note:: At this moment, repository access via SSH has been tested on Unix

    only. Windows users that care about SSH are invited to test it and report

    problems, ideally contributing patches that solve these problems.

Users and admins can upload SSH public keys (e.g. ``.ssh/id_rsa.pub``) through

the web interface. The server's ``.ssh/authorized_keys`` file is automatically

maintained with an entry for each SSH key. Each entry will tell ``sshd`` to run

``kallithea-cli`` with the ``ssh-serve`` sub-command and the right Kallithea user ID

when encountering the corresponding SSH key.

To enable SSH repository access, Kallithea must be configured with the path to

the ``.ssh/authorized_keys`` file for the Kallithea user, and the path to the

``kallithea-cli`` command. Put something like this in the ``.ini`` file::

    ssh_enabled = true

    ssh_authorized_keys = /home/kallithea/.ssh/authorized_keys

    kallithea_cli_path = /srv/kallithea/venv/bin/kallithea-cli

The SSH service must be running, and the Kallithea user account must be active

(not necessarily with password access, but public key access must be enabled),

all file permissions must be set as sshd wants it, and ``authorized_keys`` must

be writeable by the Kallithea user.

.. note:: The ``authorized_keys`` file will be rewritten from scratch on

    each update. If it already exists with other data, Kallithea will not

    overwrite the existing ``authorized_keys``, and the server process will

    instead throw an exception. The system administrator thus cannot ssh

    directly to the Kallithea user but must use su/sudo from another account.

    If ``/home/kallithea/.ssh/`` (the directory of the path specified in the

    ``ssh_authorized_keys`` setting of the ``.ini`` file) does not exist as a

    directory, Kallithea will attempt to create it. If that path exists but is

    *not* a directory, or is not readable-writable-executable by the server