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::

.. 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.

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