Kallithea provides full text search of repositories using `Whoosh`__.

.. __: https://pythonhosted.org/Whoosh/

For an incremental index build, run::

    paster make-index my.ini

For a full index rebuild, run::

    paster make-index my.ini -f

The ``--repo-location`` option allows the location of the repositories to be overriden;

usually, the location is retrieved from the Kallithea database.

The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::

    paster make-index my.ini --index-only=vcs,kallithea

To keep your index up-to-date it is necessary to do periodic index builds;

for this, it is recommended to use a crontab entry. Example::

    0  3  *  *  *  /path/to/virtualenv/bin/paster make-index /path/to/kallithea/my.ini

When using incremental mode (the default), Whoosh will check the last

modification date of each file and add it to be reindexed if a newer file is

available. The indexing daemon checks for any removed files and removes them

from index.

If you want to rebuild the index from scratch, you can use the ``-f`` flag as above,

or in the admin panel you can check the "build from scratch" checkbox.

Setting up LDAP support

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

Kallithea supports LDAP authentication. In order

to use LDAP, you have to install the python-ldap_ package. This package is

available via PyPI, so you can install it by running::

    pip install python-ldap

.. note:: ``python-ldap`` requires some libraries to be installed on

          your system, so before installing it check that you have at

          least the ``openldap`` and ``sasl`` libraries.

Here's a typical LDAP setup::

 Connection settings

 Enable LDAP          = checked

 Host                 = host.example.org

 Port                 = 389

 Account              = <account>

 Password             = <password>

 Connection Security  = LDAPS connection

 Certificate Checks   = DEMAND

 Search settings

 Base DN              = CN=users,DC=host,DC=example,DC=org

 LDAP Filter          = (&(objectClass=user)(!(objectClass=computer)))

 LDAP Search Scope    = SUBTREE

 Attribute mappings

 Login Attribute      = uid

 First Name Attribute = firstName

 Last Name Attribute  = lastName

 Email Attribute      = mail

If your user groups are placed in an Organisation Unit (OU) structure, the Search Settings configuration differs::

 Search settings

 Base DN              = DC=host,DC=example,DC=org

 LDAP Filter          = (&(memberOf=CN=your user group,OU=subunit,OU=unit,DC=host,DC=example,DC=org)(objectClass=user))

 LDAP Search Scope    = SUBTREE

.. _enable_ldap:

Enable LDAP : required

    Whether to use LDAP for authenticating users.

.. _ldap_host:

Host : required

    LDAP server hostname or IP address. Can be also a comma separated

    list of servers to support LDAP fail-over.

.. _Port:

Port : required

    389 for un-encrypted LDAP, 636 for SSL-encrypted LDAP.

.. _ldap_account:

Integration with issue trackers

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

Kallithea provides a simple integration with issue trackers. It's possible

to define a regular expression that will match an issue ID in commit messages,

and have that replaced with a URL to the issue. To enable this simply

uncomment the following variables in the ini file::

    issue_pat = (?:^#|\s#)(\w+)

    issue_server_link = https://myissueserver.com/{repo}/issue/{id}

    issue_prefix = #

``issue_pat`` is the regular expression describing which strings in

commit messages will be treated as issue references. A match group in

parentheses should be used to specify the actual issue id.

The default expression matches issues in the format ``#<number>``, e.g., ``#300``.

Matched issue references are replaced with the link specified in

``issue_server_link``. ``{id}`` is replaced with the issue ID, and

``{repo}`` with the repository name.  Since the # is stripped away,

``issue_prefix`` is prepended to the link text.  ``issue_prefix`` doesn't

necessarily need to be ``#``: if you set issue prefix to ``ISSUE-`` this will

generate a URL in the format:

.. code-block:: html

  <a href="https://myissueserver.com/example_repo/issue/300">ISSUE-300</a>

If needed, more than one pattern can be specified by appending a unique suffix to

the variables. For example::

    issue_pat_wiki = (?:wiki-)(.+)

    issue_server_link_wiki = https://mywiki.com/{id}

    issue_prefix_wiki = WIKI-

With these settings, wiki pages can be referenced as wiki-some-id, and every

such reference will be transformed into:

.. code-block:: html

  <a href="https://mywiki.com/some-id">WIKI-some-id</a>

Hook management

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

Hooks can be managed in similar way to that used in ``.hgrc`` files.

The built-in hooks cannot be modified, though they can be enabled or disabled in the *VCS* section.

To add another custom hook simply fill in the first textbox with

``<name>.<hook_type>`` and the second with the hook path. Example hooks

can be found in ``kallithea.lib.hooks``.

Changing default encoding

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

By default, Kallithea uses UTF-8 encoding.

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.

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.*`` and ``broker.*`` configuration variables.

Remember that the ini files use the format with '.' and not with '_' like

Celery. So for example setting `BROKER_HOST` in Celery means setting

`broker.host` in the configuration file.

To start the Celery process, run::

 paster celeryd <configfile.ini>

.. _email:

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

Email settings

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

The Kallithea configuration file has several email related settings. When

these contain correct values, Kallithea will send email in the situations

described below. If the email configuration is not correct so that emails

cannot be sent, all mails will show up in the log output.

Before any email can be sent, an SMTP server has to be configured using the

configuration file setting ``smtp_server``. If required for that server, specify

a username (``smtp_username``) and password (``smtp_password``), a non-standard

port (``smtp_port``), encryption settings (``smtp_use_tls`` or ``smtp_use_ssl``)

and/or specific authentication parameters (``smtp_auth``).

Application emails

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

Kallithea sends an email to `users` on several occasions:

- when comments are given on one of their changesets

- when comments are given on changesets they are reviewer on or on which they

  commented regardless

- when they are invited as reviewer in pull requests

- when they request a password reset

Kallithea sends an email to all `administrators` upon new account registration.

When Kallithea wants to send an email but due to an error cannot correctly

determine the intended recipients, the administrators and the addresses

specified in ``email_to`` in the configuration file are used as fallback.

Recipients will see these emails originating from the sender specified in the

``app_email_from`` setting in the configuration file. This setting can either

contain only an email address, like `kallithea-noreply@example.com`, or both

a name and an address in the following format: `Kallithea

<kallithea-noreply@example.com>`. The subject of these emails can

optionally be prefixed with the value of ``email_prefix`` in the configuration

file.

Error emails

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

When an exception occurs in Kallithea -- and unless interactive debugging is

enabled using ``set debug = true`` in the ``[app:main]`` section of the

configuration file -- an email with exception details is sent by WebError_'s

``ErrorMiddleware`` to the addresses specified in ``email_to`` in the

configuration file.

Recipients will see these emails originating from the sender specified in the

``error_email_from`` setting in the configuration file. This setting can either

contain only an email address, like `kallithea-noreply@example.com`, or both

a name and an address in the following format: `Kallithea Errors

<kallithea-noreply@example.com>`.

*Note:* The WebError_ package does not respect ``smtp_port`` and assumes the

standard SMTP port (25). If you have a remote SMTP server with a different port,

you could set up a local forwarding SMTP server on port 25.

References

----------

- `Error Middleware (Pylons documentation) <http://pylons-webframework.readthedocs.org/en/latest/debugging.html#error-middleware>`_

- `ErrorHandler (Pylons modules documentation) <http://pylons-webframework.readthedocs.org/en/latest/modules/middleware.html#pylons.middleware.ErrorHandler>`_

.. _WebError: https://pypi.python.org/pypi/WebError