view doc/configuration.rst @ 4231:e11b13418ba6

plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441
author Goffi <goffi@goffi.org>
date Sat, 06 Apr 2024 12:57:23 +0200
parents d6837db456fd
children 5f83bba6cd27
line wrap: on
line source

.. _configuration:

=============
Configuration
=============

Libervia main configuration is set in a file named ``libervia.conf`` (which may be prefixed
by a ``.`` if you want to hide it on suitable platforms). It is a common file used both by
backend and all frontends (and even related project like Libervia Pubsub).

This file can be located in the following paths (in order of parsing):
  - ``/etc``
  - ``~`` (``$HOME`` or your home directory)
  - XDG directory for configuration (most of time it is
    ``~/.config/libervia/``)
  - the parent directory of Libervia installation path

If several configurations files are found, they are merged. In case of conflict, the
option parsed last is the one used (in other words: if you have an option set in
``/etc/libervia.conf`` and the same one set in ``~/.libervia.conf``, the one from ``~/.libervia.conf``
will be used because it is parsed after ``/etc``).

Format
======

``libervia.conf`` is using the `INI`_ file format as understood by Python's `SafeConfigParser`_
(meaning that you can use interpolation).

The ``DEFAULT`` section is used for global options, this is where you specify where are
your media.

Each frontend can have specific section with its name in lowercase (sections are case
sensitive), and some backend plugin can use specific sections too (usually named ``plugin
<plugin name>``). The ``pubsub`` section is used by ``Libervia PubSub``. A section can also
have the name of a web site used with Libervia web framework.


To recapitulate, you can have the following sections in your ``libervia.conf``:

``[DEFAULT]``
  the main, global section
frontend name (in lower case)
  frontend specific settings. Some examples:

  - ``[desktop]``
  - ``[cli]``
  - ``[tui]``
  - ``[web]``
``[plugin <plugin name>]``
  backend plugin specific settings. Some examples:

  - ``[plugin account]``
  - ``[plugin muc]``
  - ``[plugin search]``
``[pubsub]``
  Libervia PubSub settings
``[<website name>]``
  the settings of a website for Libervia web framework

.. _INI: https://en.wikipedia.org/wiki/INI_file
.. _SafeConfigParser: https://docs.python.org/2/library/configparser.html

In the section, the option names suffixes are used to identify the type of settings:

- ``_dir`` is used to indicate a path to a directory
- ``_path`` is used to indicate a path (generally to a file, ``_dir`` being used for
  directories)
- ``_int`` indicate a integer
- ``_list`` indicate a list comma-separated values
- ``_dict`` indicate a dictionary
- ``_json`` is used for complex data, represented with JSON format

Remember that if you want to span your data on several lines (which is often used with
``*_dict`` or ``*_json`` options), you need to indent the extra lines and keep the same
indentation.

Sample
======

Here is a configuration that you can use as a model to specify your own settings. Check
the comments to get the meaning of each option.

.. sourcecode:: cfg

    [DEFAULT]
    ; where Libervia media are located
    media_dir = ~/workspace/sat_media
    log_level = debug
    ; domain used for new accounts
    xmpp_domain = example.net
    ; list of profiles with admin rights
    admins_list = toto,titi
    ; settings to let the backend send emails
    email_from = NOREPLY@example.net
    email_server = localhost
    # email_port =
    # email_username =
    # email_password =
    # email_starttls = true
    # email_auth = true
    # email_admins_list = toto@example.net, titi@example.org
    ; override DNS records
    hosts_dict = {
        "example.org": {"host": "127.0.0.1"}
        }
    ; background luminance, used by terminal frontends
    ; can be "auto" (default) to autodetect, "dark" or "light"
    background = auto
    # end-user facing URL, used by Web frontend
    public_url = example.com
    # uncomment next line if you don't want to use local cache for pubsub items
    ; pubsub_cache_strategy = "no_cache"

    [plugin account]
    ; where a new account must be created
    new_account_server = localhost
    new_account_domain = example.net

    [plugin muc]
    ; default room to use in the "Join room" menu
    default_muc = libervia@chat.jabberfr.org

    [tui]
    log_level = debug
    ; how the logs are formatted
    ; note that "%" must be doubled here
    log_fmt = %%(levelname)s: %%(message)s
    ; use bracketed paste mode
    bracketed_paste = true

    [cli]
    ; how to use xdotool to refresh Firefox when doing "li blog edit"
    blog_preview_open_cmd = firefox -new-tab {url}
    blog_preview_update_cmd = /bin/sh -c "WID=$(xdotool search --name 'Mozilla Firefox' | head -1); xdotool windowactivate $WID; xdotool key F5"
    ; and below the equivalent with Konqueror
    # blog_preview_open_cmd = konqueror {url}
    # blog_preview_update_cmd = /bin/sh -c "qdbus $(qdbus org.kde.konqueror\*) /konqueror/MainWindow_1 reload"

    [web]
    ; do we want "http", "https" or "both"?
    connection_type = both
    port = 8080
    port_https = 8443
    ; external port used for HTTPS (0 to use "port_https" value)
    port_https_ext = 443
    ; TLS public certificate or private key
    ; and public certificate combined (PEM format)
    tls_certificate = libervia.pem
    ; TLS certificate private key (PEM format)
    tls_private_key = libervia-key.pem
    ; if true (or 1), HTTP will redirect to HTTPS
    redirect_to_https = 1
    ; passphrase for libervia profile
    passphrase = something_secure
    ; here we redirect main libervia page
    ; to the blog of a profile named "some_profile"
    url_redirections_dict = {
      "/": "/u/some_profile"
      }