Use sphinx instead of pandoc, and add a deploy job
This commit is contained in:
louiz’
@@ -2,6 +2,7 @@ stages:
|
||||
- build # Build in various conf, keeps the artifacts
|
||||
- test # Use the build artifacts to run the tests
|
||||
- packaging # Publish some packages (rpm, deb…)
|
||||
- deploy # Deploy things like the web doc
|
||||
- external # Interact with some external service (coverity…)
|
||||
|
||||
before_script:
|
||||
@@ -233,3 +234,21 @@ packaging:archlinux:
|
||||
- makepkg -si --noconfirm
|
||||
- test -e /usr/bin/biboumi
|
||||
dependencies: []
|
||||
|
||||
#
|
||||
# Deploy jobs
|
||||
#
|
||||
|
||||
doc:
|
||||
stage: deploy
|
||||
only:
|
||||
- branches@louiz/biboumi
|
||||
tags:
|
||||
- www
|
||||
image: docker.louiz.org/louiz/biboumi/doc-builder
|
||||
script:
|
||||
- cd doc/
|
||||
- make html
|
||||
- rm -rf /www/latest
|
||||
- mv _build/html /www/latest
|
||||
dependencies: []
|
||||
|
||||
+2
-20
@@ -74,26 +74,8 @@ set(SOFTWARE_VERSION
|
||||
#
|
||||
## The rule that generates the documentation
|
||||
#
|
||||
execute_process(COMMAND "date" "+%Y-%m-%d" OUTPUT_VARIABLE DOC_DATE
|
||||
OUTPUT_STRIP_TRAILING_WHITESPACE)
|
||||
set(MAN_PAGE ${CMAKE_CURRENT_BINARY_DIR}/doc/${PROJECT_NAME}.1)
|
||||
set(DOC_PAGE ${CMAKE_CURRENT_SOURCE_DIR}/doc/${PROJECT_NAME}.1.rst)
|
||||
if (NOT PANDOC_EXECUTABLE)
|
||||
find_program(PANDOC_EXECUTABLE NAMES pandoc
|
||||
DOC "The pandoc software, to build the man page from the rst documentation")
|
||||
if(PANDOC_EXECUTABLE)
|
||||
message(STATUS "Found Pandoc: ${PANDOC_EXECUTABLE}")
|
||||
set(WITH_DOC true)
|
||||
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doc/)
|
||||
add_custom_command(OUTPUT ${MAN_PAGE}
|
||||
COMMAND ${PANDOC_EXECUTABLE} -M date="${DOC_DATE}" -s -t man ${DOC_PAGE} -o ${MAN_PAGE}
|
||||
DEPENDS ${DOC_PAGE})
|
||||
add_custom_target(doc ALL DEPENDS ${MAN_PAGE})
|
||||
else()
|
||||
message(STATUS "Pandoc not found, documentation cannot be built")
|
||||
endif()
|
||||
endif()
|
||||
mark_as_advanced(PANDOC_EXECUTABLE)
|
||||
add_custom_target(doc COMMAND make html BUILDDIR=${CMAKE_CURRENT_BINARY_DIR}
|
||||
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/doc)
|
||||
|
||||
#
|
||||
## Set this search path for cmake, to find our custom search modules
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# Minimal makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = sphinx-build
|
||||
SPHINXPROJ = biboumi
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
|
||||
# Put it first so that "make" without argument is like "make help".
|
||||
help:
|
||||
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
.PHONY: help Makefile
|
||||
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
@@ -0,0 +1,7 @@
|
||||
Administrator documentation
|
||||
===========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
configuration
|
||||
+160
@@ -0,0 +1,160 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file does only contain a selection of the most common options. For a
|
||||
# full list see the documentation:
|
||||
# http://www.sphinx-doc.org/en/master/config
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
# import os
|
||||
# import sys
|
||||
# sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = 'biboumi'
|
||||
copyright = '2018, Florent Le Coz'
|
||||
author = 'Florent Le Coz'
|
||||
|
||||
# The short X.Y version
|
||||
version = '8.3'
|
||||
# The full version, including alpha/beta/rc tags
|
||||
release = '8.3'
|
||||
|
||||
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#
|
||||
# needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'sphinx.ext.coverage',
|
||||
'sphinx.ext.autosectionlabel',
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
#
|
||||
# source_suffix = ['.rst', '.md']
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = None
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path .
|
||||
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#
|
||||
# html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# Custom sidebar templates, must be a dictionary that maps document names
|
||||
# to template names.
|
||||
#
|
||||
# The default sidebars (for documents that don't match any pattern) are
|
||||
# defined by theme itself. Builtin themes are using these templates by
|
||||
# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
|
||||
# 'searchbox.html']``.
|
||||
#
|
||||
# html_sidebars = {}
|
||||
|
||||
|
||||
# -- Options for HTMLHelp output ---------------------------------------------
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'biboumidoc'
|
||||
|
||||
|
||||
# -- Options for LaTeX output ------------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
#
|
||||
# 'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#
|
||||
# 'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#
|
||||
# 'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#
|
||||
# 'figure_align': 'htbp',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'biboumi.tex', 'biboumi Documentation',
|
||||
'Florent Le Coz', 'manual'),
|
||||
]
|
||||
|
||||
|
||||
# -- Options for manual page output ------------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'biboumi', 'biboumi Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
|
||||
# -- Options for Texinfo output ----------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'biboumi', 'biboumi Documentation',
|
||||
author, 'biboumi', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
# -- Extension configuration -------------------------------------------------
|
||||
@@ -0,0 +1,279 @@
|
||||
Usage
|
||||
=====
|
||||
|
||||
Biboumi acts as a server, it should be run as a daemon that lives in the
|
||||
background for as long as it is needed. Note that biboumi does not
|
||||
daemonize itself, this task should be done by your init system (SysVinit,
|
||||
systemd, upstart).
|
||||
|
||||
When started, biboumi connects, without encryption (see :ref:`Security`), to the
|
||||
local XMPP server on the port ``5347`` and authenticates with the provided
|
||||
password. Biboumi then serves the configured ``hostname``: this means that
|
||||
all XMPP stanza with a `to` JID on that domain will be forwarded to biboumi
|
||||
by the XMPP server, and biboumi will only send messages coming from that
|
||||
hostname.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The configuration file is read by biboumi as it starts. The path is
|
||||
specified as the only argument to the biboumi binary.
|
||||
|
||||
The configuration file uses a simple format of the form ``option=value``
|
||||
(note that there are no spaces before or after the equal sign).
|
||||
|
||||
The values from the configuration file can be overridden by environment
|
||||
variables, with the name all in upper case and prefixed with `BIBOUMI_`.
|
||||
For example, if the environment contains “BIBOUMI_PASSWORD=blah", this will
|
||||
override the value of the “password” option in the configuration file.
|
||||
|
||||
Sending SIGUSR1, SIGUSR2 or SIGHUP (see kill(1)) to the process will force
|
||||
it to re-read the configuration and make it close and re-open the log
|
||||
files. You can use this to change any configuration option at runtime, or
|
||||
do a log rotation.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
A configuration file can look something like this:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
hostname=biboumi.example.com
|
||||
password=mypassword
|
||||
xmpp_server_ip=127.0.0.1
|
||||
port=5347
|
||||
admin=myself@example.com
|
||||
db_name=postgresql://biboumi:password@localhost/biboumi
|
||||
realname_customization=true
|
||||
realname_from_jid=false
|
||||
log_file=
|
||||
ca_file=
|
||||
outgoing_bind=192.168.0.12
|
||||
|
||||
|
||||
Here is a description of all available options
|
||||
|
||||
hostname
|
||||
~~~~~~~~
|
||||
|
||||
Mandatory. The hostname served by the XMPP gateway. This domain must be
|
||||
configured in the XMPP server as an external component. See the manual
|
||||
for your XMPP server for more information. For prosody, see
|
||||
http://prosody.im/doc/components#adding_an_external_component
|
||||
|
||||
password
|
||||
~~~~~~~~
|
||||
|
||||
Mandatory. The password used to authenticate the XMPP component to your
|
||||
XMPP server. This password must be configured in the XMPP server,
|
||||
associated with the external component on *hostname*.
|
||||
|
||||
xmpp_server_ip
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The IP address to connect to the XMPP server on. The connection to the
|
||||
XMPP server is unencrypted, so the biboumi instance and the server should
|
||||
normally be on the same host. The default value is 127.0.0.1.
|
||||
|
||||
port
|
||||
~~~~
|
||||
|
||||
The TCP port to use to connect to the local XMPP component. The default
|
||||
value is 5347.
|
||||
|
||||
db_name
|
||||
~~~~~~~
|
||||
|
||||
The name of the database to use. This option can only be used if biboumi
|
||||
has been compiled with a database support (Sqlite3 and/or PostgreSQL). If
|
||||
the value begins with the postgresql scheme, “postgresql://” or
|
||||
“postgres://”, then biboumi will try to connect to the PostgreSQL database
|
||||
specified by the URI. See
|
||||
https://www.postgresql.org/docs/current/static/libpq-connect.html#idm46428693970032
|
||||
for all possible values. For example the value could be
|
||||
“postgresql://user:secret@localhost”. If the value does not start with the
|
||||
postgresql scheme, then it specifies a filename that will be opened with
|
||||
Sqlite3. For example the value could be “/var/lib/biboumi/biboumi.sqlite”.
|
||||
|
||||
admin
|
||||
~~~~~
|
||||
|
||||
The bare JID of the gateway administrator. This JID will have more
|
||||
privileges than other standard users, for example some administration
|
||||
ad-hoc commands will only be available to that JID.
|
||||
|
||||
If you need more than one administrator, separate them with a colon (:).
|
||||
|
||||
fixed_irc_server
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
If this option contains the hostname of an IRC server (for example
|
||||
irc.example.org), then biboumi will enforce the connexion to that IRC
|
||||
server only. This means that a JID like ``#chan@biboumi.example.com``
|
||||
must be used instead of ``#chan%irc.example.org@biboumi.example.com``. The
|
||||
`%` character loses any meaning in the JIDs. It can appear in the JID but
|
||||
will not be interpreted as a separator (thus the JID
|
||||
``#channel%hello@biboumi.example.com`` points to the channel named
|
||||
``#channel%hello`` on the configured IRC server) This option can for
|
||||
example be used by an administrator that just wants to let their users
|
||||
join their own IRC server using an XMPP client, while forbidding access to
|
||||
any other IRC server.
|
||||
|
||||
persistent_by_default
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If this option is set to `true`, all rooms will be persistent by default:
|
||||
the value of the “persistent” option in the global configuration of each
|
||||
user will be “true”, but the value of each individual room will still
|
||||
default to false. This means that a user just needs to change the global
|
||||
“persistent” configuration option to false in order to override this.
|
||||
|
||||
If it is set to false (the default value), all rooms are not persistent by
|
||||
default.
|
||||
|
||||
Each room can be configured individually by each user, to override this
|
||||
default value. See :ref:`Ad-hoc commands`.
|
||||
|
||||
realname_customization
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If this option is set to “false” (default is “true”), the users will not be
|
||||
able to use the ad-hoc commands that lets them configure their realname and
|
||||
username.
|
||||
|
||||
realname_from_jid
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
If this option is set to “true”, the realname and username of each biboumi
|
||||
user will be extracted from their JID. The realname is their bare JID, and
|
||||
the username is the node-part of their JID. Note that if
|
||||
``realname_customization`` is “true”, each user will still be able to
|
||||
customize their realname and username, this option just decides the default
|
||||
realname and username.
|
||||
|
||||
If this option is set to “false” (the default value), the realname and
|
||||
username of each user will be set to the nick they used to connect to the
|
||||
IRC server.
|
||||
|
||||
webirc_password
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Configure a password to be communicated to the IRC server, as part of the
|
||||
WEBIRC message (see https://kiwiirc.com/docs/webirc). If this option is
|
||||
set, an additional DNS resolution of the hostname of each XMPP server will
|
||||
be made when connecting to an IRC server.
|
||||
|
||||
log_file
|
||||
~~~~~~~~
|
||||
|
||||
A filename into which logs are written. If none is provided, the logs are
|
||||
written on standard output.
|
||||
|
||||
log_level
|
||||
~~~~~~~~~
|
||||
|
||||
Indicate what type of log messages to write in the logs. Value can be
|
||||
from 0 to 3. 0 is debug, 1 is info, 2 is warning, 3 is error. The
|
||||
default is 0, but a more practical value for production use is 1.
|
||||
|
||||
ca_file
|
||||
~~~~~~~
|
||||
|
||||
Specifies which file should be used as the list of trusted CA when
|
||||
negociating a TLS session. By default this value is unset and biboumi
|
||||
tries a list of well-known paths.
|
||||
|
||||
outgoing_bind
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
An address (IPv4 or IPv6) to bind the outgoing sockets to. If no value is
|
||||
specified, it will use the one assigned by the operating system. You can
|
||||
for example use outgoing_bind=192.168.1.11 to force biboumi to use the
|
||||
interface with this address. Note that this is only used for connections
|
||||
to IRC servers.
|
||||
|
||||
identd_port
|
||||
~~~~~~~~~~~
|
||||
|
||||
The TCP port on which to listen for identd queries. The default is the
|
||||
standard value: 113. To be able to listen on this privileged port, biboumi
|
||||
needs to have certain capabilities: on linux, using systemd, this can be
|
||||
achieved by adding `AmbientCapabilities=CAP_NET_BIND_SERVICE` to the unit
|
||||
file. On other systems, other solutions exist, like the portacl module on
|
||||
FreeBSD.
|
||||
|
||||
If biboumi’s identd server is properly started, it will receive queries from
|
||||
the IRC servers asking for the “identity” of each IRC connection made to it.
|
||||
Biboumi will answer with a hash of the JID that made the connection. This is
|
||||
useful for the IRC server to be able to distinguish the different users, and
|
||||
be able to deal with the absuses without having to simply ban the IP. Without
|
||||
this identd server, moderation is a lot harder, because all the different
|
||||
users of a single biboumi instance all share the same IP, and they can’t be
|
||||
distinguished by the IRC servers.
|
||||
|
||||
To disable the built-in identd, you may set identd_port to 0.
|
||||
|
||||
policy_directory
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
A directory that should contain the policy files, used to customize
|
||||
Botan’s behaviour when negociating the TLS connections with the IRC
|
||||
servers. If not specified, the directory is the one where biboumi’s
|
||||
configuration file is located: for example if biboumi reads its
|
||||
configuration from /etc/biboumi/biboumi.cfg, the policy_directory value
|
||||
will be /etc/biboumi.
|
||||
|
||||
|
||||
TLS configuration
|
||||
-----------------
|
||||
|
||||
Various settings of the TLS connections can be customized using policy
|
||||
files. The files should be located in the directory specified by the
|
||||
configuration option `policy_directory`_. When attempting to connect to
|
||||
an IRC server using TLS, biboumi will use Botan’s default TLS policy, and
|
||||
then will try to load some policy files to override the values found in
|
||||
these files. For example, if policy_directory is /etc/biboumi, when
|
||||
trying to connect to irc.example.com, biboumi will try to read
|
||||
/etc/biboumi/policy.txt, use the values found to override the default
|
||||
values, then it will try to read /etc/biboumi/irc.example.com.policy.txt
|
||||
and re-override the policy with the values found in this file.
|
||||
|
||||
The policy.txt file applies to all the connections, and
|
||||
irc.example.policy.txt will only apply (in addition to policy.txt) when
|
||||
connecting to that specific server.
|
||||
|
||||
To see the list of possible options to configure, refer to `Botan’s TLS
|
||||
documentation <https://botan.randombit.net/manual/tls.html#tls-policies>`_.
|
||||
In addition to these Botan options, biboumi implements a few custom options
|
||||
listed hereafter:
|
||||
- verify_certificate: if this value is set to false, biboumi will not check
|
||||
the certificate validity at all. The default value is true.
|
||||
|
||||
By default, biboumi provides a few policy files, to work around some
|
||||
issues found with a few well-known IRC servers.
|
||||
|
||||
|
||||
Security
|
||||
========
|
||||
|
||||
The connection to the XMPP server can only be made on localhost. The
|
||||
XMPP server is not supposed to accept non-local connections from
|
||||
components. Thus, encryption is not used to connect to the local
|
||||
XMPP server because it is useless.
|
||||
|
||||
If compiled with the Botan library, biboumi can use TLS when communicating
|
||||
with the IRC servers. It will first try ports 6697 and 6670 and use TLS
|
||||
if it succeeds, if connection fails on both these ports, the connection is
|
||||
established on port 6667 without any encryption.
|
||||
|
||||
Biboumi does not check if the received JIDs are properly formatted using
|
||||
nodeprep. This must be done by the XMPP server to which biboumi is
|
||||
directly connected.
|
||||
|
||||
Biboumi does not provide a way to ban users from connecting to it, has no
|
||||
protection against flood or any sort of abuse that your users may cause on
|
||||
the IRC servers. Some XMPP server however offer the possibility to restrict
|
||||
what JID can access a gateway. Use that feature if you wish to grant access
|
||||
to your biboumi instance only to a list of trusted users.
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
Biboumi is an XMPP gateway that connects to IRC servers and translates
|
||||
between the two protocols. It can be used to access IRC channels using any
|
||||
XMPP client as if these channels were XMPP MUCs.
|
||||
@@ -0,0 +1,16 @@
|
||||
.. biboumi documentation master file, created by
|
||||
sphinx-quickstart on Mon Aug 27 19:50:26 2018.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Biboumi – XMPP gateway to IRC
|
||||
=============================
|
||||
|
||||
.. include:: description.rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
install
|
||||
admin
|
||||
user
|
||||
@@ -1,24 +1,28 @@
|
||||
INSTALL
|
||||
=======
|
||||
Installation
|
||||
============
|
||||
|
||||
tl;dr
|
||||
-----
|
||||
The very short version:
|
||||
|
||||
cmake . && make && ./biboumi
|
||||
.. code-block:: sh
|
||||
|
||||
cmake . && make && ./biboumi
|
||||
|
||||
If that didn’t work, read on.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
Build and runtime dependencies:
|
||||
Here’s the list of all the build and runtime dependencies. Because we
|
||||
strive to use the smallest number of dependencies possible, many of them
|
||||
are optional. That being said, you will have the best experience using
|
||||
biboumi by having all dependencies.
|
||||
|
||||
Tools:
|
||||
~~~~~~
|
||||
|
||||
- A C++14 compiler (clang >= 3.4 or gcc >= 5.0 for example)
|
||||
- CMake
|
||||
- pandoc (optional) to build the man page
|
||||
- sphinx (optional) to build the documentation
|
||||
|
||||
Libraries:
|
||||
~~~~~~~~~~
|
||||
@@ -59,28 +63,61 @@ systemd_ (optional)
|
||||
Provides the support for a systemd service of Type=notify. This is useful only
|
||||
if you are packaging biboumi in a distribution with Systemd.
|
||||
|
||||
|
||||
Configure
|
||||
Customize
|
||||
---------
|
||||
|
||||
Configure the build system using cmake, there are many solutions to do that,
|
||||
the simplest is to just run
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
|
||||
cmake .
|
||||
Once you have all the dependencies you need, configure the build system
|
||||
using cmake. The cleanest way is to create a build directory, and run
|
||||
everything inside it:
|
||||
|
||||
in the current directory.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
mkdir build/ && cd build/ && cmake ..
|
||||
|
||||
Choosing the dependencies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Without any option, cmake will look for all dependencies available on the
|
||||
system and use everything it finds. If a mandatory dependency is missing
|
||||
it will obviously stop and yield an error, however if an optional
|
||||
dependency is missing, it will just ignore it.
|
||||
|
||||
To specify that you want or don’t want to use, you need to
|
||||
pass an option like this:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
cmake .. -DWITH_XXXX=1 -DWITHOUT_XXXX=1
|
||||
|
||||
The `WITH_` prefix indicates that cmake should stop if that dependency can
|
||||
not be found, and the `WITHOUT_` prefix indicates that this dependency
|
||||
should not be used even if it is present on the system.
|
||||
|
||||
The `XXXX` part needs to be replaced by one of the following: BOTAN,
|
||||
LIBIDN, SYSTEMD, DOC, UDNS, SQLITE3, POSTGRESQL.
|
||||
|
||||
Other options
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The default build type is "Debug", if you want to build a release version,
|
||||
set the CMAKE_BUILD_TYPE variable to "release", by running this command
|
||||
instead:
|
||||
|
||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr
|
||||
.. code-block:: sh
|
||||
|
||||
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
|
||||
|
||||
You can also configure many parameters of the build (like customize CFLAGS,
|
||||
the install path, choose the compiler, or enabling some options like the
|
||||
POLLER to use), using the ncurses interface of ccmake:
|
||||
|
||||
ccmake .
|
||||
.. code-block:: sh
|
||||
|
||||
ccmake ..
|
||||
|
||||
In ccmake, first use 'c' to configure the build system, edit the values you
|
||||
need and finaly use 'g' to generate the Makefiles to build the system and
|
||||
@@ -88,7 +125,8 @@ quit ccmake.
|
||||
|
||||
You can also configure these options using a -D command line flag.
|
||||
|
||||
The list of available options:
|
||||
Biboumi also has a few advanced options that are useful only in very
|
||||
specific cases.
|
||||
|
||||
- POLLER: lets you select the poller used by biboumi, at
|
||||
compile-time. Possible values are:
|
||||
@@ -97,25 +135,16 @@ The list of available options:
|
||||
- POLL: use the standard poll(2). This is the default value on all non-Linux
|
||||
platforms.
|
||||
|
||||
- DEBUG_SQL_QUERIES: If set to ON, additional debug logging and timing will be
|
||||
done for every SQL query that is executed. The default is OFF.
|
||||
|
||||
- WITH_BOTAN and WITHOUT_BOTAN: The first force the usage of the Botan library,
|
||||
if it is not found, the configuration process will fail. The second will
|
||||
make the build process ignore the Botan library, it will not be used even
|
||||
if it's available on the system. If none of these option is specified, the
|
||||
library will be used if available and will be ignored otherwise.
|
||||
|
||||
- WITH_LIBIDN and WITHOUT_LIBIDN: Just like the WITH(OUT)_BOTAN options, but
|
||||
for the IDN library
|
||||
|
||||
- WITH_SYSTEMD and WITHOUT_SYSTEMD: Just like the other WITH(OUT)_* options,
|
||||
but for the Systemd library
|
||||
- DEBUG_SQL_QUERIES: If set to ON, additional debug logging and timing
|
||||
will be done for every SQL query that is executed. The default is OFF.
|
||||
Please set it to ON if you intend to share your debug logs on the bug
|
||||
trackers, if your issue affects the database.
|
||||
|
||||
Example:
|
||||
|
||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr
|
||||
-DWITH_BOTAN=1 -DWITHOUT_SYSTEMD=1
|
||||
.. code-block:: sh
|
||||
|
||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr -DWITH_BOTAN=1 -DWITHOUT_SYSTEMD=1
|
||||
|
||||
This command will configure the project to build a release, with TLS enabled
|
||||
(using Botan) but without using Systemd (even if available on the system).
|
||||
@@ -123,41 +152,34 @@ This command will configure the project to build a release, with TLS enabled
|
||||
|
||||
Build
|
||||
-----
|
||||
|
||||
Once you’ve configured everything using cmake, build the software:
|
||||
|
||||
To build the biboumi binary:
|
||||
To build the biboumi binary, run:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
make
|
||||
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
And then, optionaly, Install the software system-wide
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
make install
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
You can run the test suite with
|
||||
|
||||
make check
|
||||
|
||||
This project uses the Catch unit test framework, it will be automatically
|
||||
fetched with cmake, by cloning the github repository.
|
||||
|
||||
You can also check the overall code coverage of this test suite by running
|
||||
|
||||
make coverage
|
||||
|
||||
This requires gcov and lcov to be installed.
|
||||
This will install the biboumi binary, but also the man-page (if configured
|
||||
with it), the policy files, the systemd unit file, etc.
|
||||
|
||||
|
||||
Run
|
||||
---
|
||||
Run the software using the `biboumi` binary. Read the documentation (the
|
||||
man page biboumi(1) or the `biboumi.1.rst`_ file) for more information on how
|
||||
to use biboumi.
|
||||
|
||||
Finally, run the software using the `biboumi` binary. Read the documentation (the
|
||||
man page biboumi(1)) or the usage page.
|
||||
|
||||
.. _expat: http://expat.sourceforge.net/
|
||||
.. _libiconv: http://www.gnu.org/software/libiconv/
|
||||
+120
-386
@@ -1,275 +1,13 @@
|
||||
======================
|
||||
Biboumi(1) User Manual
|
||||
======================
|
||||
|
||||
.. contents:: :depth: 2
|
||||
|
||||
NAME
|
||||
====
|
||||
|
||||
biboumi - XMPP gateway to IRC
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Biboumi is an XMPP gateway that connects to IRC servers and translates
|
||||
between the two protocols. It can be used to access IRC channels using any
|
||||
XMPP client as if these channels were XMPP MUCs.
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
biboumi [*config_filename*]
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
Available command line options:
|
||||
|
||||
config_filename
|
||||
---------------
|
||||
|
||||
Specify the file to read for configuration. See the `Configuration`_ section for more
|
||||
details on its content.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The configuration file uses a simple format of the form ``option=value``.
|
||||
|
||||
The values from the configuration file can be overridden by environment
|
||||
variables, with the name all in upper case and prefixed with "BIBOUMI_".
|
||||
For example, if the environment contains “BIBOUMI_PASSWORD=blah", this will
|
||||
override the value of the “password” option in the configuration file.
|
||||
|
||||
Sending SIGUSR1, SIGUSR2 or SIGHUP (see kill(1)) to the process will force
|
||||
it to re-read the configuration and make it close and re-open the log
|
||||
files. You can use this to change any configuration option at runtime, or
|
||||
do a log rotation.
|
||||
|
||||
Here is a description of every possible option:
|
||||
|
||||
hostname
|
||||
--------
|
||||
|
||||
Mandatory. The hostname served by the XMPP gateway. This domain must be
|
||||
configured in the XMPP server as an external component. See the manual
|
||||
for your XMPP server for more information. For prosody, see
|
||||
http://prosody.im/doc/components#adding_an_external_component
|
||||
|
||||
password
|
||||
--------
|
||||
|
||||
Mandatory. The password used to authenticate the XMPP component to your
|
||||
XMPP server. This password must be configured in the XMPP server,
|
||||
associated with the external component on *hostname*.
|
||||
|
||||
xmpp_server_ip
|
||||
--------------
|
||||
|
||||
The IP address to connect to the XMPP server on. The connection to the
|
||||
XMPP server is unencrypted, so the biboumi instance and the server should
|
||||
normally be on the same host. The default value is 127.0.0.1.
|
||||
|
||||
port
|
||||
----
|
||||
|
||||
The TCP port to use to connect to the local XMPP component. The default
|
||||
value is 5347.
|
||||
|
||||
db_name
|
||||
-------
|
||||
|
||||
The name of the database to use. This option can only be used if biboumi
|
||||
has been compiled with a database support (Sqlite3 and/or PostgreSQL). If
|
||||
the value begins with the postgresql scheme, “postgresql://” or
|
||||
“postgres://”, then biboumi will try to connect to the PostgreSQL database
|
||||
specified by the URI. See
|
||||
https://www.postgresql.org/docs/current/static/libpq-connect.html#idm46428693970032
|
||||
for all possible values. For example the value could be
|
||||
“postgresql://user:secret@localhost”. If the value does not start with the
|
||||
postgresql scheme, then it specifies a filename that will be opened with
|
||||
Sqlite3. For example the value could be “/var/lib/biboumi/biboumi.sqlite”.
|
||||
|
||||
admin
|
||||
-----
|
||||
|
||||
The bare JID of the gateway administrator. This JID will have more
|
||||
privileges than other standard users, for example some administration
|
||||
ad-hoc commands will only be available to that JID.
|
||||
|
||||
If you need more than one administrator, separate them with a colon (:).
|
||||
|
||||
fixed_irc_server
|
||||
----------------
|
||||
|
||||
If this option contains the hostname of an IRC server (for example
|
||||
irc.example.org), then biboumi will enforce the connexion to that IRC
|
||||
server only. This means that a JID like ``#chan@biboumi.example.com``
|
||||
must be used instead of ``#chan%irc.example.org@biboumi.example.com``. The
|
||||
`%` character loses any meaning in the JIDs. It can appear in the JID but
|
||||
will not be interpreted as a separator (thus the JID
|
||||
``#channel%hello@biboumi.example.com`` points to the channel named
|
||||
``#channel%hello`` on the configured IRC server) This option can for
|
||||
example be used by an administrator that just wants to let their users
|
||||
join their own IRC server using an XMPP client, while forbidding access to
|
||||
any other IRC server.
|
||||
|
||||
persistent_by_default
|
||||
---------------------
|
||||
|
||||
If this option is set to `true`, all rooms will be persistent by default:
|
||||
the value of the “persistent” option in the global configuration of each
|
||||
user will be “true”, but the value of each individual room will still
|
||||
default to false. This means that a user just needs to change the global
|
||||
“persistent” configuration option to false in order to override this.
|
||||
|
||||
If it is set to false (the default value), all rooms are not persistent by
|
||||
default.
|
||||
|
||||
Each room can be configured individually by each user, to override this
|
||||
default value. See `Ad-hoc commands`_.
|
||||
|
||||
realname_customization
|
||||
----------------------
|
||||
|
||||
If this option is set to “false” (default is “true”), the users will not be
|
||||
able to use the ad-hoc commands that lets them configure their realname and
|
||||
username.
|
||||
|
||||
realname_from_jid
|
||||
-----------------
|
||||
|
||||
If this option is set to “true”, the realname and username of each biboumi
|
||||
user will be extracted from their JID. The realname is their bare JID, and
|
||||
the username is the node-part of their JID. Note that if
|
||||
``realname_customization`` is “true”, each user will still be able to
|
||||
customize their realname and username, this option just decides the default
|
||||
realname and username.
|
||||
|
||||
If this option is set to “false” (the default value), the realname and
|
||||
username of each user will be set to the nick they used to connect to the
|
||||
IRC server.
|
||||
|
||||
webirc_password
|
||||
---------------
|
||||
|
||||
Configure a password to be communicated to the IRC server, as part of the
|
||||
WEBIRC message (see https://kiwiirc.com/docs/webirc). If this option is
|
||||
set, an additional DNS resolution of the hostname of each XMPP server will
|
||||
be made when connecting to an IRC server.
|
||||
|
||||
log_file
|
||||
--------
|
||||
|
||||
A filename into which logs are written. If none is provided, the logs are
|
||||
written on standard output.
|
||||
|
||||
log_level
|
||||
---------
|
||||
|
||||
Indicate what type of log messages to write in the logs. Value can be
|
||||
from 0 to 3. 0 is debug, 1 is info, 2 is warning, 3 is error. The
|
||||
default is 0, but a more practical value for production use is 1.
|
||||
|
||||
ca_file
|
||||
-------
|
||||
|
||||
Specifies which file should be used as the list of trusted CA when
|
||||
negociating a TLS session. By default this value is unset and biboumi
|
||||
tries a list of well-known paths.
|
||||
|
||||
outgoing_bind
|
||||
-------------
|
||||
|
||||
An address (IPv4 or IPv6) to bind the outgoing sockets to. If no value is
|
||||
specified, it will use the one assigned by the operating system. You can
|
||||
for example use outgoing_bind=192.168.1.11 to force biboumi to use the
|
||||
interface with this address. Note that this is only used for connections
|
||||
to IRC servers.
|
||||
|
||||
identd_port
|
||||
Quick-start
|
||||
-----------
|
||||
|
||||
The TCP port on which to listen for identd queries. The default is the
|
||||
standard value: 113. To be able to listen on this privileged port, biboumi
|
||||
needs to have certain capabilities: on linux, using systemd, this can be
|
||||
achieved by adding `AmbientCapabilities=CAP_NET_BIND_SERVICE` to the unit
|
||||
file. On other systems, other solutions exist, like the portacl module on
|
||||
FreeBSD.
|
||||
|
||||
If biboumi’s identd server is properly started, it will receive queries from
|
||||
the IRC servers asking for the “identity” of each IRC connection made to it.
|
||||
Biboumi will answer with a hash of the JID that made the connection. This is
|
||||
useful for the IRC server to be able to distinguish the different users, and
|
||||
be able to deal with the absuses without having to simply ban the IP. Without
|
||||
this identd server, moderation is a lot harder, because all the different
|
||||
users of a single biboumi instance all share the same IP, and they can’t be
|
||||
distinguished by the IRC servers.
|
||||
|
||||
To disable the built-in identd, you may set identd_port to 0.
|
||||
|
||||
policy_directory
|
||||
----------------
|
||||
|
||||
A directory that should contain the policy files, used to customize
|
||||
Botan’s behaviour when negociating the TLS connections with the IRC
|
||||
servers. If not specified, the directory is the one where biboumi’s
|
||||
configuration file is located: for example if biboumi reads its
|
||||
configuration from /etc/biboumi/biboumi.cfg, the policy_directory value
|
||||
will be /etc/biboumi.
|
||||
|
||||
|
||||
TLS configuration
|
||||
=================
|
||||
|
||||
Various settings of the TLS connections can be customized using policy
|
||||
files. The files should be located in the directory specified by the
|
||||
configuration option `policy_directory`_. When attempting to connect to
|
||||
an IRC server using TLS, biboumi will use Botan’s default TLS policy, and
|
||||
then will try to load some policy files to override the values found in
|
||||
these files. For example, if policy_directory is /etc/biboumi, when
|
||||
trying to connect to irc.example.com, biboumi will try to read
|
||||
/etc/biboumi/policy.txt, use the values found to override the default
|
||||
values, then it will try to read /etc/biboumi/irc.example.com.policy.txt
|
||||
and re-override the policy with the values found in this file.
|
||||
|
||||
The policy.txt file applies to all the connections, and
|
||||
irc.example.policy.txt will only apply (in addition to policy.txt) when
|
||||
connecting to that specific server.
|
||||
|
||||
To see the list of possible options to configure, refer to `Botan’s TLS
|
||||
documentation <https://botan.randombit.net/manual/tls.html#tls-policies>`_.
|
||||
In addition to these Botan options, biboumi implements a few custom options
|
||||
listed hereafter:
|
||||
- verify_certificate: if this value is set to false, biboumi will not check
|
||||
the certificate validity at all. The default value is true.
|
||||
|
||||
By default, biboumi provides a few policy files, to work around some
|
||||
issues found with a few well-known IRC servers.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Biboumi acts as a server, it should be run as a daemon that lives in the
|
||||
background for as long as it is needed. Note that biboumi does not
|
||||
daemonize itself, this task should be done by your init system (SysVinit,
|
||||
systemd, upstart).
|
||||
|
||||
When started, biboumi connects, without encryption (see `Security`_), to the
|
||||
local XMPP server on the port ``5347`` and authenticates with the provided
|
||||
password. Biboumi then serves the configured ``hostname``: this means that
|
||||
all XMPP stanza with a `to` JID on that domain will be forwarded to biboumi
|
||||
by the XMPP server, and biboumi will only send messages coming from that
|
||||
hostname.
|
||||
|
||||
When a user joins an IRC channel on an IRC server (see `Join an IRC
|
||||
channel`_), biboumi connects to the remote IRC server, sets the user’s nick
|
||||
as requested, and then tries to join the specified channel. If the same
|
||||
user subsequently tries to connect to an other channel on the same server,
|
||||
the same IRC connection is used. If, however, an other user wants to join
|
||||
an IRC channel on that same IRC server, biboumi opens a new connection to
|
||||
that server. Biboumi connects once to each IRC server, for each user on it.
|
||||
that server. Biboumi connects once to each IRC servner, for each user on it.
|
||||
|
||||
Additionally, if one user is using more than one clients (with the same bare
|
||||
JID), they can join the same IRC channel (on the same server) behind one
|
||||
@@ -286,6 +24,13 @@ communication is acknowledged by all IRC servers. If one or more IRC
|
||||
servers do not respond, biboumi will only exit if it receives the same
|
||||
signal again or if a 2 seconds delay has passed.
|
||||
|
||||
.. note:: If you use a biboumi that you have no control on: remember that the
|
||||
administrator of the gateway you use is able to view all your IRC
|
||||
conversations, whether you’re using encryption or not. This is exactly as
|
||||
if you were running your IRC client on someone else’s server. Only use
|
||||
biboumi if you trust its administrator (or, better, if you are the
|
||||
administrator) or if you don’t intend to have any private conversation.
|
||||
|
||||
Addressing
|
||||
----------
|
||||
|
||||
@@ -371,7 +116,7 @@ You can add some JIDs provided by biboumi into your own roster, to receive
|
||||
presence from them. Biboumi will always automatically accept your requests.
|
||||
|
||||
Biboumi’s JID
|
||||
-------------
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
By adding the component JID into your roster, the user will receive an available
|
||||
presence whenever it is started, and an unavailable presence whenever it is being
|
||||
@@ -379,7 +124,7 @@ shutdown. This is useful to quickly view if that biboumi instance is started or
|
||||
not.
|
||||
|
||||
IRC server JID
|
||||
--------------
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
These presence will appear online in the user’s roster whenever they are
|
||||
connected to that IRC server (see `Connect to an IRC server`_ for more
|
||||
@@ -400,14 +145,14 @@ IRC users’.
|
||||
History
|
||||
-------
|
||||
|
||||
Public channel messages are saved into archives, inside the database, unless
|
||||
the `record_history` option is set to false by that user (see `Ad-hoc commands`_).
|
||||
Private messages (messages that are sent directly to a nickname, not a
|
||||
channel) are never stored in the database.
|
||||
Public channel messages are saved into archives, inside the database,
|
||||
unless the `record_history` option is set to false by that user (see
|
||||
`Ad-hoc commands`_). Private messages (messages that are sent directly to
|
||||
a nickname, not a channel) are never stored in the database.
|
||||
|
||||
A channel history can be retrieved by using `Message archive management (MAM)
|
||||
<https://xmpp.org/extensions/xep-0313.htm>`_ on the channel JID. The results
|
||||
can be filtered by start and end dates.
|
||||
A channel history can be retrieved by using `Message archive management
|
||||
(MAM) <https://xmpp.org/extensions/xep-0313.htm>`_ on the channel JID.
|
||||
The results can be filtered by start and end dates.
|
||||
|
||||
When a channel is joined, if the client doesn’t specify any limit, biboumi
|
||||
sends the `max_history_length` last messages found in the database as the
|
||||
@@ -422,20 +167,20 @@ complexity for almost no benefit.
|
||||
|
||||
For a given channel, each user has her or his own archive. The content of
|
||||
the archives are never shared, and thus a user can not use someone else’s
|
||||
archive to get the messages that they didn’t receive when they were offline.
|
||||
Although this feature would be very convenient, this would introduce a very
|
||||
important privacy issue: for example if a biboumi gateway is used by two
|
||||
users, by querying the archive one user would be able to know whether or not
|
||||
the other user was in a room at a given time.
|
||||
archive to get the messages that they didn’t receive when they were
|
||||
offline. Although this feature would be very convenient, this would
|
||||
introduce a very important privacy issue: for example if a biboumi gateway
|
||||
is used by two users, by querying the archive one user would be able to
|
||||
know whether or not the other user was in a room at a given time.
|
||||
|
||||
|
||||
List channels
|
||||
-------------
|
||||
|
||||
You can list the IRC channels on a given IRC server by sending an XMPP disco
|
||||
items request on the IRC server JID. The number of channels on some servers
|
||||
is huge so the result stanza may be very big, unless your client supports
|
||||
result set management (XEP 0059)
|
||||
You can list the IRC channels on a given IRC server by sending an XMPP
|
||||
disco items request on the IRC server JID. The number of channels on some
|
||||
servers is huge so the result stanza may be very big, unless your client
|
||||
supports result set management (XEP 0059)
|
||||
|
||||
Nicknames
|
||||
---------
|
||||
@@ -445,16 +190,17 @@ single nickname at one given time on all the channels of a server. This is
|
||||
different from XMPP where a user can have a different nick on each MUC,
|
||||
even if these MUCs are on the same server.
|
||||
|
||||
This means that the nick you choose when joining your first IRC channel on a
|
||||
given IRC server will be your nickname in all other channels that you join
|
||||
on that same IRC server.
|
||||
This means that the nick you choose when joining your first IRC channel on
|
||||
a given IRC server will be your nickname in all other channels that you
|
||||
join on that same IRC server.
|
||||
|
||||
If you explicitely change your nickname on one channel, your nickname will
|
||||
be changed on all channels on the same server as well.
|
||||
Joining a new channel with a different nick, however, will not change your
|
||||
nick. The provided nick will be ignored, in order to avoid changing your
|
||||
nick on the whole server by mistake. If you want to have a different
|
||||
nickname in the channel you’re going to join, you need to do it explicitly
|
||||
with the NICK command before joining the channel.
|
||||
be changed on all channels on the same server as well. Joining a new
|
||||
channel with a different nick, however, will not change your nick. The
|
||||
provided nick will be ignored, in order to avoid changing your nick on the
|
||||
whole server by mistake. If you want to have a different nickname in the
|
||||
channel you’re going to join, you need to do it explicitly with the NICK
|
||||
command before joining the channel.
|
||||
|
||||
Private messages
|
||||
----------------
|
||||
@@ -587,50 +333,67 @@ Ad-hoc commands
|
||||
Biboumi supports a few ad-hoc commands, as described in the XEP 0050.
|
||||
Different ad-hoc commands are available for each JID type.
|
||||
|
||||
On the gateway itself (e.g on the JID biboumi.example.com):
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
On the gateway itself
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- ping: Just respond “pong”
|
||||
.. note:: For example on the JID biboumi.example.com
|
||||
|
||||
- hello: Provide a form, where the user enters their name, and biboumi
|
||||
responds with a nice greeting.
|
||||
ping
|
||||
^^^^
|
||||
Just respond “pong”
|
||||
|
||||
- disconnect-user: Only available to the administrator. The user provides
|
||||
a list of JIDs, and a quit message. All the selected users are
|
||||
disconnected from all the IRC servers to which they were connected,
|
||||
using the provided quit message. Sending SIGINT to biboumi is equivalent
|
||||
to using this command by selecting all the connected JIDs and using the
|
||||
“Gateway shutdown” quit message, except that biboumi does not exit when
|
||||
using this ad-hoc command.
|
||||
hello
|
||||
^^^^^
|
||||
|
||||
- disconnect-from-irc-servers: Disconnect a single user from one or more
|
||||
IRC server. The user is immediately disconnected by closing the socket,
|
||||
no message is sent to the IRC server, but the user is of course notified
|
||||
with an XMPP message. The administrator can disconnect any user, while
|
||||
the other users can only disconnect themselves.
|
||||
Provide a form, where the user enters their name, and biboumi responds
|
||||
with a nice greeting.
|
||||
|
||||
- configure: Lets each user configure some options that applies globally.
|
||||
The provided configuration form contains these fields:
|
||||
* Record History: whether or not history messages should be saved in
|
||||
the database.
|
||||
* Max history length: The maximum number of lines in the history
|
||||
that the server is allowed to send when joining a channel.
|
||||
disconnect-user
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
* Persistent: Overrides the value specified in each individual channel.
|
||||
If this option is set to true, all channels are persistent, whether
|
||||
or not their specific value is true or false. This option is true by
|
||||
default for everyone if the `persistent_by_default` configuration
|
||||
option is true, otherwise it’s false. See below for more details on
|
||||
what a persistent channel is. This value is
|
||||
Only available to the administrator. The user provides a list of JIDs, and
|
||||
a quit message. All the selected users are disconnected from all the IRC
|
||||
servers to which they were connected, using the provided quit message.
|
||||
Sending SIGINT to biboumi is equivalent to using this command by selecting
|
||||
all the connected JIDs and using the “Gateway shutdown” quit message,
|
||||
except that biboumi does not exit when using this ad-hoc command.
|
||||
|
||||
On a server JID (e.g on the JID chat.freenode.org@biboumi.example.com)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
disconnect-from-irc-servers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- configure: Lets each user configure some options that applies to the
|
||||
Disconnect a single user from one or more IRC server. The user is
|
||||
immediately disconnected by closing the socket, no message is sent to the
|
||||
IRC server, but the user is of course notified with an XMPP message. The
|
||||
administrator can disconnect any user, while the other users can only
|
||||
disconnect themselves.
|
||||
|
||||
configure
|
||||
^^^^^^^^^
|
||||
|
||||
Lets each user configure some options that applies globally.
|
||||
The provided configuration form contains these fields:
|
||||
|
||||
- **Record History**: whether or not history messages should be saved in
|
||||
the database.
|
||||
- **Max history length**: The maximum number of lines in the history that
|
||||
the server is allowed to send when joining a channel.
|
||||
- **Persistent**: Overrides the value specified in each individual
|
||||
channel. If this option is set to true, all channels are persistent,
|
||||
whether or not their specific value is true or false. This option is true
|
||||
by default for everyone if the `persistent_by_default` configuration
|
||||
option is true, otherwise it’s false. See below for more details on what a
|
||||
persistent channel is. This value is
|
||||
|
||||
On a server JID
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
E.g on the JID chat.freenode.org@biboumi.example.com
|
||||
|
||||
- **configure**: Lets each user configure some options that applies to the
|
||||
concerned IRC server. The provided configuration form contains these
|
||||
fields:
|
||||
|
||||
* Address: This address (IPv4, IPv6 or hostname) will be used, when
|
||||
- **Address**: This address (IPv4, IPv6 or hostname) will be used, when
|
||||
biboumi connects to this server. This is a very handy way to have a
|
||||
custom name for a network, and be able to edit the address to use
|
||||
if one endpoint for that server is dead, but continue using the same
|
||||
@@ -640,90 +403,92 @@ On a server JID (e.g on the JID chat.freenode.org@biboumi.example.com)
|
||||
the network name forever: if “chat.freenode.net” breaks for some
|
||||
reason, it can be changed to “irc.freenode.org” instead, and the user
|
||||
would not need to change all their bookmarks and settings.
|
||||
* Realname: The customized “real name” as it will appear on the
|
||||
- **Realname**: The customized “real name” as it will appear on the
|
||||
user’s whois. This option is not available if biboumi is configured
|
||||
with realname_customization to false.
|
||||
* Username: The “user” part in your `user@host`. This option is not
|
||||
- **Username**: The “user” part in your `user@host`. This option is not
|
||||
available if biboumi is configured with realname_customization to
|
||||
false.
|
||||
* In encoding: The incoming encoding. Any received message that is not
|
||||
- **In encoding**: The incoming encoding. Any received message that is not
|
||||
proper UTF-8 will be converted will be converted from the configured
|
||||
In encoding into UTF-8. If the conversion fails at some point, some
|
||||
characters will be replaced by the placeholders.
|
||||
* Out encoding: Currently ignored.
|
||||
* After-connection IRC commands: Raw IRC commands that will be sent
|
||||
- **Out encoding**: Currently ignored.
|
||||
- **After-connection IRC commands**: Raw IRC commands that will be sent
|
||||
one by one to the server immediately after the connection has been
|
||||
successful. It can for example be used to identify yourself using
|
||||
NickServ, with a command like this: `PRIVMSG NickServ :identify
|
||||
PASSWORD`.
|
||||
* Ports: The list of TCP ports to use when connecting to this IRC server.
|
||||
- **Ports**: The list of TCP ports to use when connecting to this IRC server.
|
||||
This list will be tried in sequence, until the connection succeeds for
|
||||
one of them. The connection made on these ports will not use TLS, the
|
||||
communication will be insecure. The default list contains 6697 and 6670.
|
||||
* TLS ports: A second list of ports to try when connecting to the IRC
|
||||
- **TLS ports**: A second list of ports to try when connecting to the IRC
|
||||
server. The only difference is that TLS will be used if the connection
|
||||
is established on one of these ports. All the ports in this list will
|
||||
be tried before using the other plain-text ports list. To entirely
|
||||
disable any non-TLS connection, just remove all the values from the
|
||||
“normal” ports list. The default list contains 6697.
|
||||
* Verify certificate: If set to true (the default value), when connecting
|
||||
- **Verify certificate**: If set to true (the default value), when connecting
|
||||
on a TLS port, the connection will be aborted if the certificate is
|
||||
not valid (for example if it’s not signed by a known authority, or if
|
||||
the domain name doesn’t match, etc). Set it to false if you want to
|
||||
connect on a server with a self-signed certificate.
|
||||
* SHA-1 fingerprint of the TLS certificate to trust: if you know the hash
|
||||
- **SHA-1 fingerprint of the TLS certificate to trust**: if you know the hash
|
||||
of the certificate that the server is supposed to use, and you only want
|
||||
to accept this one, set its SHA-1 hash in this field.
|
||||
* Nickname: A nickname that will be used instead of the nickname provided
|
||||
- **Nickname**: A nickname that will be used instead of the nickname provided
|
||||
in the initial presence sent to join a channel. This can be used if the
|
||||
user always wants to have the same nickname on a given server, and not
|
||||
have to bother with setting that nick in all the bookmarks on that
|
||||
server. The nickname can still manually be changed with a standard nick
|
||||
change presence.
|
||||
* Server password: A password that will be sent just after the connection,
|
||||
- **Server password**: A password that will be sent just after the connection,
|
||||
in a PASS command. This is usually used in private servers, where you’re
|
||||
only allowed to connect if you have the password. Note that, although
|
||||
this is NOT a password that will be sent to NickServ (or some author
|
||||
authentication service), some server (notably Freenode) use it as if it
|
||||
was sent to NickServ to identify your nickname.
|
||||
* Throttle limit: specifies a number of messages that can be sent
|
||||
- **Throttle limit**: specifies a number of messages that can be sent
|
||||
without a limit, before the throttling takes place. When messages
|
||||
are throttled, only one command per second is sent to the server.
|
||||
The default is 10. You can lower this value if you are ever kicked
|
||||
for excess flood. If the value is 0, all messages are throttled. To
|
||||
disable this feature, set it to a negative number, or an empty string.
|
||||
|
||||
- get-irc-connection-info: Returns some information about the IRC server,
|
||||
- **get-irc-connection-info**: Returns some information about the IRC server,
|
||||
for the executing user. It lets the user know if they are connected to
|
||||
this server, from what port, with or without TLS, and it gives the list
|
||||
of joined IRC channel, with a detailed list of which resource is in which
|
||||
channel.
|
||||
|
||||
On a channel JID (e.g on the JID #test%chat.freenode.org@biboumi.example.com)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
On a channel JID
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
- configure: Lets each user configure some options that applies to the
|
||||
E.g on the JID #test%chat.freenode.org@biboumi.example.com
|
||||
|
||||
- **configure**: Lets each user configure some options that applies to the
|
||||
concerned IRC channel. Some of these options, if not configured for a
|
||||
specific channel, defaults to the value configured at the IRC server
|
||||
level. For example the encoding can be specified for both the channel
|
||||
and the server. If an encoding is not specified for a channel, the
|
||||
encoding configured in the server applies. The provided configuration
|
||||
form contains these fields:
|
||||
* In encoding: see the option with the same name in the server configuration
|
||||
form.
|
||||
* Out encoding: Currently ignored.
|
||||
* Persistent: If set to true, biboumi will stay in this channel even when
|
||||
all the XMPP resources have left the room. I.e. it will not send a PART
|
||||
command, and will stay idle in the channel until the connection is
|
||||
forcibly closed. If a resource comes back in the room again, and if
|
||||
the archiving of messages is enabled for this room, the client will
|
||||
receive the messages that where sent in this channel. This option can be
|
||||
used to make biboumi act as an IRC bouncer.
|
||||
* Record History: whether or not history messages should be saved in
|
||||
the database, for this specific channel. If the value is “unset” (the
|
||||
default), then the value configured globally is used. This option is there,
|
||||
for example, to be able to enable history recording globally while disabling
|
||||
it for a few specific “private” channels.
|
||||
- **In encoding**: see the option with the same name in the server configuration
|
||||
form.
|
||||
- **Out encoding**: Currently ignored.
|
||||
- **Persistent**: If set to true, biboumi will stay in this channel even when
|
||||
all the XMPP resources have left the room. I.e. it will not send a PART
|
||||
command, and will stay idle in the channel until the connection is
|
||||
forcibly closed. If a resource comes back in the room again, and if
|
||||
the archiving of messages is enabled for this room, the client will
|
||||
receive the messages that where sent in this channel. This option can be
|
||||
used to make biboumi act as an IRC bouncer.
|
||||
- **Record History**: whether or not history messages should be saved in
|
||||
the database, for this specific channel. If the value is “unset” (the
|
||||
default), then the value configured globally is used. This option is there,
|
||||
for example, to be able to enable history recording globally while disabling
|
||||
it for a few specific “private” channels.
|
||||
|
||||
Raw IRC messages
|
||||
----------------
|
||||
@@ -739,34 +504,3 @@ send the message “WHOIS Foo” to ``irc.example.com@biboumi.example.com``.
|
||||
The message will be forwarded as is, without any modification appart from
|
||||
adding ``\r\n`` at the end (to make it a valid IRC message). You need to
|
||||
have a little bit of understanding of the IRC protocol to use this feature.
|
||||
|
||||
Security
|
||||
========
|
||||
|
||||
The connection to the XMPP server can only be made on localhost. The
|
||||
XMPP server is not supposed to accept non-local connections from components.
|
||||
Thus, encryption is not used to connect to the local XMPP server because it
|
||||
is useless.
|
||||
|
||||
If compiled with the Botan library, biboumi can use TLS when communicating
|
||||
with the IRC servers. It will first try ports 6697 and 6670 and use TLS if
|
||||
it succeeds, if connection fails on both these ports, the connection is
|
||||
established on port 6667 without any encryption.
|
||||
|
||||
Biboumi does not check if the received JIDs are properly formatted using
|
||||
nodeprep. This must be done by the XMPP server to which biboumi is directly
|
||||
connected.
|
||||
|
||||
Note if you use a biboumi that you have no control on: remember that the
|
||||
administrator of the gateway you use is able to view all your IRC
|
||||
conversations, whether you’re using encryption or not. This is exactly as
|
||||
if you were running your IRC client on someone else’s server. Only use
|
||||
biboumi if you trust its administrator (or, better, if you are the
|
||||
administrator) or if you don’t intend to have any private conversation.
|
||||
|
||||
Biboumi does not provide a way to ban users from connecting to it, has no
|
||||
protection against flood or any sort of abuse that your users may cause on
|
||||
the IRC servers. Some XMPP server however offer the possibility to restrict
|
||||
what JID can access a gateway. Use that feature if you wish to grant access
|
||||
to your biboumi instance only to a list of trusted users.
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
End-user documentation
|
||||
======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
usage
|
||||
Reference in New Issue
Block a user