Merge branch 'rst'
This commit is contained in:
+37
-32
@@ -1,65 +1,63 @@
|
|||||||
|
INSTALL
|
||||||
|
=======
|
||||||
|
|
||||||
tl;dr
|
tl;dr
|
||||||
=====
|
-----
|
||||||
|
|
||||||
cmake . && make && ./biboumi
|
cmake . && make && ./biboumi
|
||||||
|
|
||||||
If that didn’t work, read on.
|
If that didn’t work, read on.
|
||||||
|
|
||||||
Dependencies
|
Dependencies
|
||||||
============
|
------------
|
||||||
|
|
||||||
Build and runtime dependencies:
|
Build and runtime dependencies:
|
||||||
|
|
||||||
Tools:
|
Tools:
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
- A C++14 compiler (clang >= 3.4 or gcc >= 4.9 for example)
|
- A C++14 compiler (clang >= 3.4 or gcc >= 4.9 for example)
|
||||||
- CMake
|
- CMake
|
||||||
- ronn (optional) to build the man page
|
- ronn (optional) to build the man page
|
||||||
|
|
||||||
Libraries:
|
Libraries:
|
||||||
|
~~~~~~~~~~
|
||||||
|
|
||||||
- expat
|
expat_
|
||||||
Used to parse XML from the XMPP server.
|
Used to parse XML from the XMPP server.
|
||||||
http://expat.sourceforge.net/
|
|
||||||
|
|
||||||
- libiconv
|
libiconv_
|
||||||
Encoding from anything into UTF-8
|
Encoding from anything into UTF-8
|
||||||
http://www.gnu.org/software/libiconv/
|
|
||||||
|
|
||||||
- libuuid
|
libuuid_
|
||||||
Generate unique IDs
|
Generate unique IDs
|
||||||
http://sourceforge.net/projects/libuuid/
|
|
||||||
|
|
||||||
- libidn (optional, but recommended)
|
libidn_ (optional, but recommended)
|
||||||
Provides the stringprep functionality. Without it, JIDs for IRC users are
|
Provides the stringprep functionality. Without it, JIDs for IRC users are
|
||||||
not provided.
|
not provided.
|
||||||
http://www.gnu.org/software/libidn/
|
|
||||||
|
|
||||||
- c-ares (optional, but recommended)
|
c-ares_ (optional, but recommended)
|
||||||
Asynchronously resolve domain names. This offers better reactivity and
|
Asynchronously resolve domain names. This offers better reactivity and
|
||||||
performances when connecting to a big number of IRC servers at the same
|
performances when connecting to a big number of IRC servers at the same
|
||||||
time.
|
time.
|
||||||
http://c-ares.haxx.se/
|
|
||||||
|
|
||||||
- libbotan 1.11 (optional)
|
libbotan_ 1.11 (optional)
|
||||||
Provides TLS support. Without it, IRC connections are all made in
|
Provides TLS support. Without it, IRC connections are all made in
|
||||||
plain-text mode.
|
plain-text mode.
|
||||||
Other branches than the 1.11 are not supported.
|
Other branches than the 1.11 are not supported.
|
||||||
http://botan.randombit.net/
|
|
||||||
|
|
||||||
- litesql (optional)
|
litesql_ (optional)
|
||||||
Provides a way to store various options in a (sqlite3) database. Each user
|
Provides a way to store various options in a (sqlite3) database. Each user
|
||||||
of the gateway can store their own values (for example their prefered port,
|
of the gateway can store their own values (for example their prefered port,
|
||||||
or their IRC password).
|
or their IRC password).
|
||||||
http://git.louiz.org/litesql
|
|
||||||
|
|
||||||
- systemd (optional)
|
systemd_ (optional)
|
||||||
Provides the support for a systemd service of Type=notify. This is useful only
|
Provides the support for a systemd service of Type=notify. This is useful only
|
||||||
if you are packaging biboumi in a distribution with Systemd.
|
if you are packaging biboumi in a distribution with Systemd.
|
||||||
|
|
||||||
|
|
||||||
Configure
|
Configure
|
||||||
=========
|
---------
|
||||||
|
|
||||||
Configure the build system using cmake, there are many solutions to do that,
|
Configure the build system using cmake, there are many solutions to do that,
|
||||||
the simplest is to just run
|
the simplest is to just run
|
||||||
@@ -90,8 +88,9 @@ The list of available options:
|
|||||||
|
|
||||||
- POLLER: lets you select the poller used by biboumi, at
|
- POLLER: lets you select the poller used by biboumi, at
|
||||||
compile-time. Possible values are:
|
compile-time. Possible values are:
|
||||||
EPOLL: use the Linux-specific epoll(7). This is the default on Linux.
|
|
||||||
POLL: use the standard poll(2). This is the default value on all non-Linux
|
- EPOLL: use the Linux-specific epoll(7). This is the default on Linux.
|
||||||
|
- POLL: use the standard poll(2). This is the default value on all non-Linux
|
||||||
platforms.
|
platforms.
|
||||||
|
|
||||||
- WITH_BOTAN and WITHOUT_BOTAN: The first force the usage of the Botan library,
|
- WITH_BOTAN and WITHOUT_BOTAN: The first force the usage of the Botan library,
|
||||||
@@ -108,7 +107,7 @@ The list of available options:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX \
|
cmake . -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr
|
||||||
-DWITH_BOTAN=1 -DWITHOUT_SYSTEMD=1
|
-DWITH_BOTAN=1 -DWITHOUT_SYSTEMD=1
|
||||||
|
|
||||||
This command will configure the project to build a release, with TLS enabled
|
This command will configure the project to build a release, with TLS enabled
|
||||||
@@ -116,24 +115,21 @@ This command will configure the project to build a release, with TLS enabled
|
|||||||
|
|
||||||
|
|
||||||
Build
|
Build
|
||||||
=====
|
-----
|
||||||
|
Once you’ve configured everything using cmake, build the project
|
||||||
- Once you’ve configured everything using cmake, build the project
|
|
||||||
|
|
||||||
make
|
make
|
||||||
|
|
||||||
|
|
||||||
Install
|
Install
|
||||||
=======
|
-------
|
||||||
|
And then, optionaly, Install the software system-wide
|
||||||
- And then, optionaly, Install the software system-wide
|
|
||||||
|
|
||||||
make install
|
make install
|
||||||
|
|
||||||
|
|
||||||
Testing
|
Testing
|
||||||
=======
|
-------
|
||||||
|
|
||||||
You can run the test suite with
|
You can run the test suite with
|
||||||
|
|
||||||
make check
|
make check
|
||||||
@@ -149,8 +145,17 @@ This requires gcov and lcov to be installed.
|
|||||||
|
|
||||||
|
|
||||||
Run
|
Run
|
||||||
===
|
---
|
||||||
|
|
||||||
Run the software using the `biboumi` binary. Read the documentation (the
|
Run the software using the `biboumi` binary. Read the documentation (the
|
||||||
man page biboumi(1) or the `biboumi.1.md` file) for more information on how
|
man page biboumi(1) or the `biboumi.1.rst`_ file) for more information on how
|
||||||
to use biboumi.
|
to use biboumi.
|
||||||
|
|
||||||
|
.. _expat: http://expat.sourceforge.net/
|
||||||
|
.. _libiconv: http://www.gnu.org/software/libiconv/
|
||||||
|
.. _libuuid: http://sourceforge.net/projects/libuuid/
|
||||||
|
.. _libidn: http://www.gnu.org/software/libidn/
|
||||||
|
.. _libbotan: http://botan.randombit.net/
|
||||||
|
.. _c-ares: http://c-ares.haxx.se/
|
||||||
|
.. _litesql: http://git.louiz.org/litesql
|
||||||
|
.. _systemd: https://www.freedesktop.org/wiki/Software/systemd/
|
||||||
|
.. _biboumi.1.rst: doc/biboumi.1.rst
|
||||||
+10
-9
@@ -21,21 +21,21 @@ important goal is to keep the software (and its code) light and simple.
|
|||||||
|
|
||||||
|
|
||||||
Install
|
Install
|
||||||
=======
|
-------
|
||||||
Refer to the [INSTALL][] file.
|
Refer to the INSTALL_ file.
|
||||||
|
|
||||||
|
|
||||||
Usage
|
Usage
|
||||||
=====
|
-----
|
||||||
|
Read `the documentation`_.
|
||||||
Read [the documentation](doc/biboumi.1.md).
|
|
||||||
|
|
||||||
Authors
|
Authors
|
||||||
=======
|
-------
|
||||||
Florent Le Coz (louiz’) <louiz@louiz.org>
|
Florent Le Coz (louiz’) <louiz@louiz.org>
|
||||||
|
|
||||||
|
|
||||||
Contact/Support
|
Contact/Support
|
||||||
===============
|
---------------
|
||||||
* XMPP ChatRoom: biboumi@muc.poez.io
|
* XMPP ChatRoom: biboumi@muc.poez.io
|
||||||
* Report a bug: https://dev.louiz.org/projects/biboumi/issues/new
|
* Report a bug: https://dev.louiz.org/projects/biboumi/issues/new
|
||||||
|
|
||||||
@@ -51,11 +51,12 @@ beforehand.
|
|||||||
|
|
||||||
|
|
||||||
Licence
|
Licence
|
||||||
=======
|
-------
|
||||||
Biboumi is Free Software.
|
Biboumi is Free Software.
|
||||||
(learn more: http://www.gnu.org/philosophy/free-sw.html)
|
(learn more: http://www.gnu.org/philosophy/free-sw.html)
|
||||||
|
|
||||||
Biboumi is released under the zlib license.
|
Biboumi is released under the zlib license.
|
||||||
Please read the COPYING file for details.
|
Please read the COPYING file for details.
|
||||||
|
|
||||||
[INSTALL]: INSTALL
|
.. _INSTALL: INSTALL.rst
|
||||||
|
.. _the documentation: doc/biboumi.1.rst
|
||||||
@@ -1,160 +1,178 @@
|
|||||||
BIBOUMI 1 "2014-06-02"
|
=======================
|
||||||
======================
|
Biboumi(1) User Manual
|
||||||
|
=======================
|
||||||
|
|
||||||
|
.. contents:: :depth: 2
|
||||||
|
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
====
|
||||||
|
|
||||||
biboumi - XMPP gateway to IRC
|
biboumi - XMPP gateway to IRC
|
||||||
|
|
||||||
DESCRIPTION
|
Description
|
||||||
-----------
|
===========
|
||||||
|
|
||||||
Biboumi is an XMPP gateway that connects to IRC servers and translates
|
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
|
between the two protocols. It can be used to access IRC channels using any
|
||||||
XMPP client as if these channels were XMPP MUCs.
|
XMPP client as if these channels were XMPP MUCs.
|
||||||
|
|
||||||
SYNOPSIS
|
Synopsis
|
||||||
--------
|
========
|
||||||
|
|
||||||
`biboumi` [`config_filename`]
|
biboumi [*config_filename*\ ]
|
||||||
|
|
||||||
OPTIONS
|
Options
|
||||||
-------
|
=======
|
||||||
|
|
||||||
Available command line options:
|
Available command line options:
|
||||||
|
|
||||||
`config_filename`
|
config_filename
|
||||||
|
---------------
|
||||||
|
|
||||||
Specify the file to read for configuration. See *CONFIG* section for more
|
Specify the file to read for configuration. See *CONFIG* section for more
|
||||||
details on its content.
|
details on its content.
|
||||||
|
|
||||||
CONFIG
|
Configuration
|
||||||
------
|
=============
|
||||||
|
|
||||||
The configuration file uses a simple format of the form
|
The configuration file uses a simple format of the form
|
||||||
`"option=value"`. Here is a description of each possible option:
|
``option=value``. Here is a description of each 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.
|
|
||||||
|
|
||||||
`admin`
|
|
||||||
|
|
||||||
The bare JID of the gateway administrator. This JID will have more
|
|
||||||
privileges than other standard users (the admin thus needs to check their
|
|
||||||
privileges), for example some administration ad-hoc commands will only be
|
|
||||||
available to that JID.
|
|
||||||
|
|
||||||
`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". In that
|
|
||||||
mode, the virtual channel (see *Connect to an IRC server*) is not
|
|
||||||
available and you still need to use the ! separator to send message to an
|
|
||||||
IRC user (for example "foo!@biboumi.example.com" to send a message to
|
|
||||||
foo), although the in-room JID still work as expected
|
|
||||||
("#channel@biboumi.example.com/Nick"). On the other hand, the '%' lose
|
|
||||||
any meaning. 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.
|
|
||||||
|
|
||||||
`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 use 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.
|
|
||||||
|
|
||||||
The configuration can be re-read at runtime (you can for example change the
|
The configuration can be re-read at runtime (you can for example change the
|
||||||
log level without having to restart biboumi) by sending SIGUSR1 or SIGUSR2
|
log level without having to restart biboumi) by sending SIGUSR1 or SIGUSR2
|
||||||
(see kill(1)) to the process.
|
(see kill(1)) to the process.
|
||||||
|
|
||||||
USAGE
|
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.
|
||||||
|
|
||||||
|
admin
|
||||||
-----
|
-----
|
||||||
|
|
||||||
|
The bare JID of the gateway administrator. This JID will have more
|
||||||
|
privileges than other standard users (the admin thus needs to check their
|
||||||
|
privileges), for example some administration ad-hoc commands will only be
|
||||||
|
available to that JID.
|
||||||
|
|
||||||
|
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". In that
|
||||||
|
mode, the virtual channel (see `Connect to an IRC server`_) is not
|
||||||
|
available and you still need to use the ! separator to send message to an
|
||||||
|
IRC user (for example "foo!@biboumi.example.com" to send a message to
|
||||||
|
foo), although the in-room JID still work as expected
|
||||||
|
("#channel@biboumi.example.com/Nick"). On the other hand, the '%' lose
|
||||||
|
any meaning. 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.
|
||||||
|
|
||||||
|
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 use 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.
|
||||||
|
|
||||||
|
Usage
|
||||||
|
=====
|
||||||
|
|
||||||
Biboumi acts as a server, it should be run as a daemon that lives in the
|
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
|
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,
|
daemonize itself, this task should be done by your init system (SysVinit,
|
||||||
systemd, upstart).
|
systemd, upstart).
|
||||||
|
|
||||||
When started, biboumi connects, without encryption (see *SECURITY*), to the
|
When started, biboumi connects, without encryption (see `Security`_), to the
|
||||||
local XMPP server on the port `5347` and authenticates with the provided
|
local XMPP server on the port ``5347`` and authenticates with the provided
|
||||||
password. Biboumi then serves the configured `hostname`: this means that
|
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
|
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
|
by the XMPP server, and biboumi will only send messages coming from that
|
||||||
hostname.
|
hostname.
|
||||||
|
|
||||||
When a user joins an IRC channel on an IRC server (see *Join an IRC
|
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
|
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
|
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,
|
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
|
the same IRC connection is used. If, however, an other user wants to join
|
||||||
@@ -168,38 +186,39 @@ 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
|
servers do not respond, biboumi will only exit if it receives the same
|
||||||
signal again or if a 2 seconds delay has passed.
|
signal again or if a 2 seconds delay has passed.
|
||||||
|
|
||||||
### Addressing
|
Addressing
|
||||||
|
----------
|
||||||
|
|
||||||
IRC entities are represented by XMPP JIDs. The domain part of the JID is
|
IRC entities are represented by XMPP JIDs. The domain part of the JID is
|
||||||
the domain served by biboumi (the part after the `@`, biboumi.example.com in
|
the domain served by biboumi (the part after the ``@``, biboumi.example.com in
|
||||||
the examples), and the local part (the part before the `@`) depends on the
|
the examples), and the local part (the part before the ``@``) depends on the
|
||||||
concerned entity.
|
concerned entity.
|
||||||
|
|
||||||
IRC channels have a local part formed like this:
|
IRC channels have a local part formed like this:
|
||||||
`channel_name`%`irc_server`.
|
``channel_name`` % ``irc_server``.
|
||||||
|
|
||||||
If the IRC channel you want to adress starts with the `'#'` character (or an
|
If the IRC channel you want to adress starts with the ``'#'`` character (or an
|
||||||
other character, announced by the IRC server, like `'&'`, `'+'` or `'!'`),
|
other character, announced by the IRC server, like ``'&'``, ``'+'`` or ``'!'``),
|
||||||
then you must include it in the JID. Some other gateway implementations, as
|
then you must include it in the JID. Some other gateway implementations, as
|
||||||
well as some IRC clients, do not require them to be started by one of these
|
well as some IRC clients, do not require them to be started by one of these
|
||||||
characters, adding an implicit `'#'` in that case. Biboumi does not do that
|
characters, adding an implicit ``'#'`` in that case. Biboumi does not do that
|
||||||
because this gets confusing when trying to understand the difference between
|
because this gets confusing when trying to understand the difference between
|
||||||
the channels *#foo*, and *##foo*. Note that biboumi does not use the
|
the channels *#foo*, and *##foo*. Note that biboumi does not use the
|
||||||
presence of these special characters to identify an IRC channel, only the
|
presence of these special characters to identify an IRC channel, only the
|
||||||
presence of the separator `%` is used for that.
|
presence of the separator `%` is used for that.
|
||||||
|
|
||||||
The channel name can also be empty (for example `%irc.example.com`), in that
|
The channel name can also be empty (for example ``%irc.example.com``), in that
|
||||||
case this represents the virtual channel provided by biboumi. See *Connect
|
case this represents the virtual channel provided by biboumi. See *Connect
|
||||||
to an IRC server* for more details.
|
to an IRC server* for more details.
|
||||||
|
|
||||||
There is two ways to address an IRC user, using a local part like this:
|
There is two ways to address an IRC user, using a local part like this:
|
||||||
`nickname`!`irc_server`
|
``nickname`` ! ``irc_server``
|
||||||
or by using the in-room address of the participant, like this:
|
or by using the in-room address of the participant, like this:
|
||||||
`channel_name`%`irc_server`@`biboumi.example.com`/`Nickname`
|
``channel_name`` % ``irc_server`` @ ``biboumi.example.com`` / ``Nickname``
|
||||||
|
|
||||||
The second JID is available only to be compatible with XMPP clients when the
|
The second JID is available only to be compatible with XMPP clients when the
|
||||||
user wants to send a private message to the participant `Nickname` in the
|
user wants to send a private message to the participant ``Nickname`` in the
|
||||||
room `channel_name%irc_server@biboumi.example.com`.
|
room ``channel_name%irc_server@biboumi.example.com``.
|
||||||
|
|
||||||
On XMPP, the node part of the JID can only be lowercase. On the other hand,
|
On XMPP, the node part of the JID can only be lowercase. On the other hand,
|
||||||
IRC nicknames are case-insensitive, this means that the nicknames toto,
|
IRC nicknames are case-insensitive, this means that the nicknames toto,
|
||||||
@@ -209,30 +228,30 @@ talk to the user toto, and this will work.
|
|||||||
Also note that some IRC nicknames may contain characters that are not
|
Also note that some IRC nicknames may contain characters that are not
|
||||||
allowed in the local part of a JID (for example '@'). If you need to send a
|
allowed in the local part of a JID (for example '@'). If you need to send a
|
||||||
message to a nick containing such a character, you have to use a jid like
|
message to a nick containing such a character, you have to use a jid like
|
||||||
`%irc.example.com@biboumi.example.com/AnnoyingNickn@me`, because the JID
|
``%irc.example.com@biboumi.example.com/AnnoyingNickn@me``, because the JID
|
||||||
`AnnoyingNickn@me!irc.example.com@biboumi.example.com` would not work.
|
``AnnoyingNickn@me!irc.example.com@biboumi.example.com`` would not work.
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
`#foo%irc.example.com@biboumi.example.com` is the #foo IRC channel, on the
|
* ``#foo%irc.example.com@biboumi.example.com`` is the #foo IRC channel, on the
|
||||||
irc.example.com IRC server, and this is served by the biboumi instance on
|
irc.example.com IRC server, and this is served by the biboumi instance on
|
||||||
biboumi.example.com
|
biboumi.example.com
|
||||||
|
|
||||||
`toto!irc.example.com@biboumi.example.com` is the IRC user named toto, or
|
* ``toto!irc.example.com@biboumi.example.com`` is the IRC user named toto, or
|
||||||
TotO, etc.
|
TotO, etc.
|
||||||
|
|
||||||
`irc.example.com@biboumi.example.com` is the IRC server irc.example.com.
|
* ``irc.example.com@biboumi.example.com`` is the IRC server irc.example.com.
|
||||||
|
|
||||||
`%irc.example.com@biboumi.example.com` is the virtual channel provided by
|
* ``%irc.example.com@biboumi.example.com`` is the virtual channel provided by
|
||||||
biboumi, for the IRC server irc.example.com.
|
biboumi, for the IRC server irc.example.com.
|
||||||
|
|
||||||
Note: Some JIDs are valid but make no sense in the context of
|
Note: Some JIDs are valid but make no sense in the context of
|
||||||
biboumi:
|
biboumi:
|
||||||
|
|
||||||
`!irc.example.com@biboumi.example.com` is the empty-string nick on the
|
* ``!irc.example.com@biboumi.example.com`` is the empty-string nick on the
|
||||||
irc.example.com server. It makes no sense to try to send messages to it.
|
irc.example.com server. It makes no sense to try to send messages to it.
|
||||||
|
|
||||||
`#test%@biboumi.example.com`, or any other JID that does not contain an
|
* ``#test%@biboumi.example.com``, or any other JID that does not contain an
|
||||||
IRC server is invalid. Any message to that kind of JID will trigger an
|
IRC server is invalid. Any message to that kind of JID will trigger an
|
||||||
error, or will be ignored.
|
error, or will be ignored.
|
||||||
|
|
||||||
@@ -241,27 +260,30 @@ representing the “hostname” provided by the IRC server. This JID can only
|
|||||||
be used to set IRC modes (for example to ban a user based on its IP), or to
|
be used to set IRC modes (for example to ban a user based on its IP), or to
|
||||||
identify user. It cannot be used to contact that user using biboumi.
|
identify user. It cannot be used to contact that user using biboumi.
|
||||||
|
|
||||||
### Join an IRC channel
|
Join an IRC channel
|
||||||
|
-------------------
|
||||||
|
|
||||||
To join an IRC channel `#foo` on the IRC server `irc.example.com`,
|
To join an IRC channel ``#foo`` on the IRC server ``irc.example.com``,
|
||||||
join the XMPP MUC `#foo%irc.example.com@hostname`.
|
join the XMPP MUC ``#foo%irc.example.com@biboumi.example.com``.
|
||||||
|
|
||||||
### Connect to an IRC server
|
Connect to an IRC server
|
||||||
|
------------------------
|
||||||
|
|
||||||
The connection to the IRC server is automatically made when the user tries
|
The connection to the IRC server is automatically made when the user tries
|
||||||
to join any channel on that IRC server. The connection is closed whenever
|
to join any channel on that IRC server. The connection is closed whenever
|
||||||
the last channel on that server is left by the user. To be able to stay
|
the last channel on that server is left by the user. To be able to stay
|
||||||
connected to an IRC server without having to be in a real IRC channel,
|
connected to an IRC server without having to be in a real IRC channel,
|
||||||
biboumi provides a virtual channel on the jid
|
biboumi provides a virtual channel on the jid
|
||||||
`%irc.example.com@biboumi.example.com`. For example if you want to join the
|
``%irc.example.com@biboumi.example.com``. For example if you want to join the
|
||||||
channel `#foo` on the server `irc.example.com`, but you need to authenticate
|
channel ``#foo`` on the server ``irc.example.com``, but you need to authenticate
|
||||||
to a bot of the server before you’re allowed to join it, you can first join
|
to a bot of the server before you’re allowed to join it, you can first join
|
||||||
the room `%irc.example.com@biboumi.example.com` (this will effectively
|
the room ``%irc.example.com@biboumi.example.com`` (this will effectively
|
||||||
connect you to the IRC server without joining any room), then send your
|
connect you to the IRC server without joining any room), then send your
|
||||||
authentication message to the user `bot!irc.example.com@biboumi.example.com`
|
authentication message to the user ``bot!irc.example.com@biboumi.example.com``
|
||||||
and finally join the room `#foo%irc.example.com@biboumi.example.com`.
|
and finally join the room ``#foo%irc.example.com@biboumi.example.com``.
|
||||||
|
|
||||||
### Channel messages
|
Channel messages
|
||||||
|
----------------
|
||||||
|
|
||||||
On XMPP, unlike on IRC, the displayed order of the messages is the same for
|
On XMPP, unlike on IRC, the displayed order of the messages is the same for
|
||||||
all participants of a MUC. Biboumi can not however provide this feature, as
|
all participants of a MUC. Biboumi can not however provide this feature, as
|
||||||
@@ -270,14 +292,16 @@ messages to other users. This means that the order of the messages
|
|||||||
displayed in your XMPP client may not be the same than the order on other
|
displayed in your XMPP client may not be the same than the order on other
|
||||||
IRC users’.
|
IRC users’.
|
||||||
|
|
||||||
### List channels
|
List channels
|
||||||
|
-------------
|
||||||
|
|
||||||
You can list the IRC channels on a given IRC server by sending an XMPP disco
|
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
|
items request on the IRC server JID. The number of channels on some servers
|
||||||
is huge, and biboumi does not (yet) support result set management (XEP 0059)
|
is huge, and biboumi does not (yet) support result set management (XEP 0059)
|
||||||
so the result stanza may be very big.
|
so the result stanza may be very big.
|
||||||
|
|
||||||
### Nicknames
|
Nicknames
|
||||||
|
---------
|
||||||
|
|
||||||
On IRC, nicknames are server-wide. This means that one user only has one
|
On IRC, nicknames are server-wide. This means that one user only has one
|
||||||
single nickname at one given time on all the channels of a server. This is
|
single nickname at one given time on all the channels of a server. This is
|
||||||
@@ -295,7 +319,8 @@ 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
|
nickname in the channel you’re going to join, you need to do it explicitly
|
||||||
with the NICK command before joining the channel.
|
with the NICK command before joining the channel.
|
||||||
|
|
||||||
### Private messages
|
Private messages
|
||||||
|
----------------
|
||||||
|
|
||||||
Private messages are handled differently on IRC and on XMPP. On IRC, you
|
Private messages are handled differently on IRC and on XMPP. On IRC, you
|
||||||
talk directly to one server-user: toto on the channel #foo is the same user
|
talk directly to one server-user: toto on the channel #foo is the same user
|
||||||
@@ -306,43 +331,47 @@ previously sent a message to an in-room participant (something like
|
|||||||
\#test%irc.example.com@biboumi.example.com/nickname), in which case future
|
\#test%irc.example.com@biboumi.example.com/nickname), in which case future
|
||||||
messages from that same user will be received from that same “in-room” JID.
|
messages from that same user will be received from that same “in-room” JID.
|
||||||
|
|
||||||
### Notices
|
Notices
|
||||||
|
-------
|
||||||
|
|
||||||
Notices are received exactly like private messages. It is not possible to
|
Notices are received exactly like private messages. It is not possible to
|
||||||
send a notice.
|
send a notice.
|
||||||
|
|
||||||
### Kicks and bans
|
Kicks and bans
|
||||||
|
--------------
|
||||||
|
|
||||||
Kicks are transparently translated from one protocol to another. However
|
Kicks are transparently translated from one protocol to another. However
|
||||||
banning an XMPP participant has no effect. To ban an user you need to set a
|
banning an XMPP participant has no effect. To ban an user you need to set a
|
||||||
mode +b on that user nick or host (see *MODES*) and then kick it.
|
mode +b on that user nick or host (see `IRC modes`_) and then kick it.
|
||||||
|
|
||||||
### Encoding
|
Encoding
|
||||||
|
--------
|
||||||
|
|
||||||
On XMPP, the encoding is always `UTF-8`, whereas on IRC the encoding of
|
On XMPP, the encoding is always ``UTF-8``, whereas on IRC the encoding of
|
||||||
each message can be anything.
|
each message can be anything.
|
||||||
|
|
||||||
This means that biboumi has to convert everything coming from IRC into UTF-8
|
This means that biboumi has to convert everything coming from IRC into UTF-8
|
||||||
without knowing the encoding of the received messages. To do so, it checks
|
without knowing the encoding of the received messages. To do so, it checks
|
||||||
if each message is UTF-8 valid, if not it tries to convert from
|
if each message is UTF-8 valid, if not it tries to convert from
|
||||||
`iso_8859-1` (because this appears to be the most common case, at least
|
``iso_8859-1`` (because this appears to be the most common case, at least
|
||||||
on the channels I visit) to `UTF-8`. If that conversion fails at some
|
on the channels I visit) to ``UTF-``. If that conversion fails at some
|
||||||
point, a placeholder character `'�'` is inserted to indicate this
|
point, a placeholder character ``'�'`` is inserted to indicate this
|
||||||
decoding error.
|
decoding error.
|
||||||
|
|
||||||
Messages are always sent in UTF-8 over IRC, no conversion is done in that
|
Messages are always sent in UTF-8 over IRC, no conversion is done in that
|
||||||
direction.
|
direction.
|
||||||
|
|
||||||
### IRC modes
|
IRC modes
|
||||||
|
---------
|
||||||
|
|
||||||
One feature that doesn’t exist on XMPP but does on IRC is the `modes`.
|
One feature that doesn’t exist on XMPP but does on IRC is the ``modes``.
|
||||||
Although some of these modes have a correspondance in the XMPP world (for
|
Although some of these modes have a correspondance in the XMPP world (for
|
||||||
example the `+o` mode on a user corresponds to the `moderator` role in
|
example the ``+o`` mode on a user corresponds to the ``moderator`` role in
|
||||||
XMPP), it is impossible to map all these modes to an XMPP feature. To
|
XMPP), it is impossible to map all these modes to an XMPP feature. To
|
||||||
circumvent this problem, biboumi provides a raw notification when modes are
|
circumvent this problem, biboumi provides a raw notification when modes are
|
||||||
changed, and lets the user change the modes directly.
|
changed, and lets the user change the modes directly.
|
||||||
|
|
||||||
To change modes, simply send a message starting with “`/mode`” followed by
|
To change modes, simply send a message starting with “``/mode``” followed by
|
||||||
the modes and the arguments you want to send to the IRC server. For example
|
the modes and the arguments you want to send to the IRC server. For example
|
||||||
“/mode +aho louiz”. Note that your XMPP client may interprete messages
|
“/mode +aho louiz”. Note that your XMPP client may interprete messages
|
||||||
begining with “/” like a command. To actually send a message starting with
|
begining with “/” like a command. To actually send a message starting with
|
||||||
@@ -356,61 +385,53 @@ notified of this XMPP event as well. For example if a mode “+o toto” is
|
|||||||
received, then toto’s role will be changed to moderator. The mapping
|
received, then toto’s role will be changed to moderator. The mapping
|
||||||
between IRC modes and XMPP features is as follow:
|
between IRC modes and XMPP features is as follow:
|
||||||
|
|
||||||
`+q`
|
``+q``
|
||||||
|
Sets the participant’s role to ``moderator`` and its affiliation to ``owner``.
|
||||||
|
|
||||||
Sets the participant’s role to `moderator` and its affiliation to `owner`.
|
``+a``
|
||||||
|
Sets the participant’s role to ``moderator`` and its affiliation to ``owner``.
|
||||||
|
|
||||||
`+a`
|
``+o``
|
||||||
|
Sets the participant’s role to ``moderator`` and its affiliation to ``admin``.
|
||||||
|
|
||||||
Sets the participant’s role to `moderator` and its affiliation to `owner`.
|
``+h``
|
||||||
|
Sets the participant’s role to ``moderator`` and its affiliation to ``member``.
|
||||||
|
|
||||||
`+o`
|
``+v``
|
||||||
|
Sets the participant’s role to `participant` and its affiliation to ``member``.
|
||||||
Sets the participant’s role to `moderator` and its affiliation to `admin`.
|
|
||||||
|
|
||||||
`+h`
|
|
||||||
|
|
||||||
Sets the participant’s role to `moderator` and its affiliation to `member`.
|
|
||||||
|
|
||||||
`+v`
|
|
||||||
|
|
||||||
Sets the participant’s role to `participant` and its affiliation to `member`.
|
|
||||||
|
|
||||||
Similarly, when a biboumi user changes some participant's affiliation or role, biboumi translates that in an IRC mode change.
|
Similarly, when a biboumi user changes some participant's affiliation or role, biboumi translates that in an IRC mode change.
|
||||||
|
|
||||||
Affiliation set to `none`
|
Affiliation set to ``none``
|
||||||
|
|
||||||
Sets mode to -vhoaq
|
Sets mode to -vhoaq
|
||||||
|
|
||||||
Affiliation set to `member`
|
Affiliation set to ``member``
|
||||||
|
|
||||||
Sets mode to +v-hoaq
|
Sets mode to +v-hoaq
|
||||||
|
|
||||||
Role set to `moderator`
|
Role set to ``moderator``
|
||||||
|
|
||||||
Sets mode to +h-oaq
|
Sets mode to +h-oaq
|
||||||
|
|
||||||
Affiliation set to `admin`
|
Affiliation set to ``admin``
|
||||||
|
|
||||||
Sets mode to +o-aq
|
Sets mode to +o-aq
|
||||||
|
|
||||||
Affiliation set to `owner`
|
Affiliation set to ``owner``
|
||||||
|
|
||||||
Sets mode to +a-q
|
Sets mode to +a-q
|
||||||
|
|
||||||
### Ad-hoc commands
|
Ad-hoc commands
|
||||||
|
---------------
|
||||||
|
|
||||||
Biboumi supports a few ad-hoc commands, as described in the XEP 0050.
|
Biboumi supports a few ad-hoc commands, as described in the XEP 0050.
|
||||||
Different ad-hoc commands are available for each JID type.
|
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 (e.g on the JID biboumi.example.com):
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- ping: Just respond “pong”
|
- ping: Just respond “pong”
|
||||||
|
|
||||||
- hello: Provide a form, where the user enters their name, and biboumi
|
- hello: Provide a form, where the user enters their name, and biboumi
|
||||||
responds with a nice greeting.
|
responds with a nice greeting.
|
||||||
|
|
||||||
- disconnect-user: Only available to the administrator. The user provides
|
- disconnect-user: Only available to the administrator. The user provides
|
||||||
a list of JIDs, and a quit message. All the selected users are
|
a list of JIDs, and a quit message. All the selected users are
|
||||||
disconnected from all the IRC servers to which they were connected,
|
disconnected from all the IRC servers to which they were connected,
|
||||||
using the provided quit message. Sending SIGINT to biboumi is equivalent
|
using the provided quit message. Sending SIGINT to biboumi is equivalent
|
||||||
@@ -418,27 +439,30 @@ Different ad-hoc commands are available for each JID type.
|
|||||||
“Gateway shutdown” quit message, except that biboumi does not exit when
|
“Gateway shutdown” quit message, except that biboumi does not exit when
|
||||||
using this ad-hoc command.
|
using this ad-hoc command.
|
||||||
|
|
||||||
- disconnect-from-irc-servers: Disconnect a single user from one or more
|
- disconnect-from-irc-servers: Disconnect a single user from one or more
|
||||||
IRC server. The user is immediately disconnected by closing the socket,
|
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
|
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
|
with an XMPP message. The administrator can disconnect any user, while
|
||||||
the other users can only disconnect themselves.
|
the other users can only disconnect themselves.
|
||||||
|
|
||||||
#### On a server JID (e.g on the JID chat.freenode.org@biboumi.example.com)
|
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
|
- Configure: Lets each user configure some options that applies to the
|
||||||
concerned IRC server.
|
concerned IRC server.
|
||||||
|
|
||||||
#### On a channel JID (e.g on the JID #test%chat.freenode.org@biboumi.example.com)
|
On a channel JID (e.g on the JID #test%chat.freenode.org@biboumi.example.com)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Configure: Lets each user configure some options that applies to the
|
- Configure: Lets each user configure some options that applies to the
|
||||||
concerned IRC channel. Some of these options, if not configured for a
|
concerned IRC channel. Some of these options, if not configured for a
|
||||||
specific channel, defaults to the value configured at the IRC server
|
specific channel, defaults to the value configured at the IRC server
|
||||||
level. For example the encoding can be specified for both the channel
|
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
|
and the server. If an encoding is not specified for a channel, the
|
||||||
encoding configured in the server applies.
|
encoding configured in the server applies.
|
||||||
|
|
||||||
### Raw IRC messages
|
Raw IRC messages
|
||||||
|
----------------
|
||||||
|
|
||||||
Biboumi tries to support as many IRC features as possible, but doesn’t
|
Biboumi tries to support as many IRC features as possible, but doesn’t
|
||||||
handle everything yet (or ever). In order to let the user send any
|
handle everything yet (or ever). In order to let the user send any
|
||||||
@@ -452,8 +476,8 @@ 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
|
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.
|
a little bit of understanding of the IRC protocol to use this feature.
|
||||||
|
|
||||||
SECURITY
|
Security
|
||||||
--------
|
========
|
||||||
|
|
||||||
The connection to the XMPP server can only be made on localhost. The
|
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.
|
XMPP server is not supposed to accept non-local connections from components.
|
||||||
@@ -481,13 +505,3 @@ 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
|
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
|
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.
|
to your biboumi instance only to a list of trusted users.
|
||||||
|
|
||||||
AUTHORS
|
|
||||||
-------
|
|
||||||
|
|
||||||
This software and man page are both written by Florent Le Coz.
|
|
||||||
|
|
||||||
LICENSE
|
|
||||||
-------
|
|
||||||
|
|
||||||
Biboumi is released under the zlib license.
|
|
||||||
Reference in New Issue
Block a user