From d060b250735fd7f4ea3985885eac48d79cd08ff8 Mon Sep 17 00:00:00 2001 From: hasufell Date: Wed, 19 Aug 2015 13:06:08 +0200 Subject: [PATCH] saving uncommitted changes in /etc prior to emerge run --- conf.d/bitlbee | 8 - default/._cfg0000_grub | 74 --- init.d/._cfg0000_bitlbee | 31 - init.d/._cfg0000_nvidia-persistenced | 25 - init.d/._cfg0000_nvidia-smi | 25 - init.d/._cfg0000_tor | 84 --- init.d/bitlbee | 28 - init.d/nvidia-persistenced | 2 +- init.d/nvidia-smi | 2 +- init.d/tor | 2 +- jabber/._cfg0000_c2s.xml | 705 ----------------------- jabber/._cfg0000_c2s.xml.dist | 705 ----------------------- jabber/._cfg0000_router.xml | 215 ------- jabber/._cfg0000_router.xml.dist | 215 ------- jabber/._cfg0000_s2s.xml | 323 ----------- jabber/._cfg0000_s2s.xml.dist | 323 ----------- jabber/._cfg0000_sm.xml | 811 --------------------------- jabber/._cfg0000_sm.xml.dist | 811 --------------------------- jabber/.keep_net-im_jabber-base-0 | 0 jabber/c2s.xml | 701 ----------------------- jabber/c2s.xml.dist | 701 ----------------------- jabber/jabberd.cfg | 18 - jabber/jabberd.cfg.dist | 18 - jabber/mu-conference.xml | 61 -- jabber/router-filter.xml | 47 -- jabber/router-filter.xml.dist | 47 -- jabber/router-users.xml | 11 - jabber/router-users.xml.dist | 11 - jabber/router.xml | 215 ------- jabber/router.xml.dist | 215 ------- jabber/s2s.xml | 323 ----------- jabber/s2s.xml.dist | 323 ----------- jabber/sm.xml | 811 --------------------------- jabber/sm.xml.dist | 811 --------------------------- jabber/style.css | 25 - jabber/templates/roster.xml | 7 - jabber/templates/roster.xml.dist | 7 - modprobe.d/._cfg0000_nvidia.conf | 14 - modprobe.d/nvidia.conf | 2 +- 39 files changed, 4 insertions(+), 8753 deletions(-) delete mode 100644 conf.d/bitlbee delete mode 100644 default/._cfg0000_grub delete mode 100755 init.d/._cfg0000_bitlbee delete mode 100755 init.d/._cfg0000_nvidia-persistenced delete mode 100755 init.d/._cfg0000_nvidia-smi delete mode 100755 init.d/._cfg0000_tor delete mode 100755 init.d/bitlbee delete mode 100644 jabber/._cfg0000_c2s.xml delete mode 100644 jabber/._cfg0000_c2s.xml.dist delete mode 100644 jabber/._cfg0000_router.xml delete mode 100644 jabber/._cfg0000_router.xml.dist delete mode 100644 jabber/._cfg0000_s2s.xml delete mode 100644 jabber/._cfg0000_s2s.xml.dist delete mode 100644 jabber/._cfg0000_sm.xml delete mode 100644 jabber/._cfg0000_sm.xml.dist delete mode 100644 jabber/.keep_net-im_jabber-base-0 delete mode 100644 jabber/c2s.xml delete mode 100644 jabber/c2s.xml.dist delete mode 100644 jabber/jabberd.cfg delete mode 100644 jabber/jabberd.cfg.dist delete mode 100644 jabber/mu-conference.xml delete mode 100644 jabber/router-filter.xml delete mode 100644 jabber/router-filter.xml.dist delete mode 100644 jabber/router-users.xml delete mode 100644 jabber/router-users.xml.dist delete mode 100644 jabber/router.xml delete mode 100644 jabber/router.xml.dist delete mode 100644 jabber/s2s.xml delete mode 100644 jabber/s2s.xml.dist delete mode 100644 jabber/sm.xml delete mode 100644 jabber/sm.xml.dist delete mode 100644 jabber/style.css delete mode 100644 jabber/templates/roster.xml delete mode 100644 jabber/templates/roster.xml.dist delete mode 100644 modprobe.d/._cfg0000_nvidia.conf diff --git a/conf.d/bitlbee b/conf.d/bitlbee deleted file mode 100644 index d581222..0000000 --- a/conf.d/bitlbee +++ /dev/null @@ -1,8 +0,0 @@ -# Bitlbee options (see /usr/sbin/bitlbee -h) -BITLBEE_OPTS="-F" - -# By default, the bitlbee init script will attempt to stop -# all bitlbee-owned processes, including per-client forks. -# Setting this to "no" tells the init script to only -# stop the main bitlbee process. -BITLBEE_STOP_ALL="yes" diff --git a/default/._cfg0000_grub b/default/._cfg0000_grub deleted file mode 100644 index 35ab767..0000000 --- a/default/._cfg0000_grub +++ /dev/null @@ -1,74 +0,0 @@ -# Copyright 1999-2015 Gentoo Foundation -# Distributed under the terms of the GNU General Public License v2 -# $Id$ -# -# To populate all changes in this file you need to regenerate your -# grub configuration file afterwards: -# 'grub2-mkconfig -o /boot/grub/grub.cfg' -# -# See the grub info page for documentation on possible variables and -# their associated values. - -GRUB_DISTRIBUTOR="Gentoo" - -# Default menu entry -#GRUB_DEFAULT=0 - -# Boot the default entry this many seconds after the menu is displayed -#GRUB_TIMEOUT=5 -#GRUB_TIMEOUT_STYLE=menu - -# Append parameters to the linux kernel command line -#GRUB_CMDLINE_LINUX="" -# -# Examples: -# -# Boot with network interface renaming disabled -# GRUB_CMDLINE_LINUX="net.ifnames=0" -# -# Boot with systemd instead of sysvinit (openrc) -# GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" - -# Append parameters to the linux kernel command line for non-recovery entries -#GRUB_CMDLINE_LINUX_DEFAULT="" - -# Uncomment to disable graphical terminal (grub-pc only) -#GRUB_TERMINAL=console - -# The resolution used on graphical terminal. -# Note that you can use only modes which your graphic card supports via VBE. -# You can see them in real GRUB with the command `vbeinfo'. -#GRUB_GFXMODE=640x480 - -# Set to 'text' to force the Linux kernel to boot in normal text -# mode, 'keep' to preserve the graphics mode set using -# 'GRUB_GFXMODE', 'WIDTHxHEIGHT'['xDEPTH'] to set a particular -# graphics mode, or a sequence of these separated by commas or -# semicolons to try several modes in sequence. -#GRUB_GFXPAYLOAD_LINUX= - -# Path to theme spec txt file. -# The starfield is by default provided with use truetype. -# NOTE: when enabling custom theme, ensure you have required font/etc. -#GRUB_THEME="/boot/grub/themes/starfield/theme.txt" - -# Background image used on graphical terminal. -# Can be in various bitmap formats. -#GRUB_BACKGROUND="/boot/grub/mybackground.png" - -# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to kernel -#GRUB_DISABLE_LINUX_UUID=true - -# Uncomment to disable generation of recovery mode menu entries -#GRUB_DISABLE_RECOVERY=true - -# Uncomment to disable generation of the submenu and put all choices on -# the top-level menu. -# Besides the visual affect of no sub menu, this makes navigation of the -# menu easier for a user who can't see the screen. -#GRUB_DISABLE_SUBMENU=y - -# Uncomment to play a tone when the main menu is displayed. -# This is useful, for example, to allow users who can't see the screen -# to know when they can make a choice on the menu. -#GRUB_INIT_TUNE="60 800 1" diff --git a/init.d/._cfg0000_bitlbee b/init.d/._cfg0000_bitlbee deleted file mode 100755 index f2c7984..0000000 --- a/init.d/._cfg0000_bitlbee +++ /dev/null @@ -1,31 +0,0 @@ -#!/sbin/runscript -# Copyright 1999-2014 Gentoo Foundation -# Distributed under the terms of the GNU General Public License, v2 or -# later -# $Id$ - -DAEMON=/usr/sbin/bitlbee -PIDFILE=/var/run/bitlbee/bitlbee.pid - -depend() { - need logger net -} - -start () { - ebegin "Starting bitlbee" - checkpath -d -m 0755 -o bitlbee:bitlbee $(dirname ${PIDFILE}) - start-stop-daemon --start --quiet \ - -u bitlbee:bitlbee --exec ${DAEMON} --pidfile ${PIDFILE} \ - -- -P ${PIDFILE} ${BITLBEE_OPTS} - eend $? -} - -stop() { - ebegin "Stopping bitlbee" - local pidfile= - yesno ${BITLBEE_STOP_ALL:-YES} || - pidfile="--pidfile ${PIDFILE}" - start-stop-daemon --stop --quiet ${pidfile} -u bitlbee:bitlbee - eend $? -} - diff --git a/init.d/._cfg0000_nvidia-persistenced b/init.d/._cfg0000_nvidia-persistenced deleted file mode 100755 index 07f6905..0000000 --- a/init.d/._cfg0000_nvidia-persistenced +++ /dev/null @@ -1,25 +0,0 @@ -#!/sbin/runscript -# Copyright 1999-2014 Gentoo Foundation -# Distributed under the terms of the GNU General Public License v2 -# $Id$ - -pidfile="/var/run/nvidia-persistenced/nvidia-persistenced.pid" - -start() { - if ! [ "${NVPD_USER}x" = x ]; then - ebegin "Starting nvidia-persistenced for ${NVPD_USER}" - NVPD_USER_ARG="--user ${NVPD_USER}" - else - ebegin "Starting nvidia-persistenced" - fi - start-stop-daemon --start --quiet --pidfile ${pidfile} \ - --background --exec /opt/bin/nvidia-persistenced \ - -- ${NVPD_USER_ARG} ${ARGS} - eend $? -} - -stop() { - ebegin "Stopping nvidia-persistenced" - start-stop-daemon --stop --quiet --pidfile ${pidfile} - eend $? -} diff --git a/init.d/._cfg0000_nvidia-smi b/init.d/._cfg0000_nvidia-smi deleted file mode 100755 index 6dce4e8..0000000 --- a/init.d/._cfg0000_nvidia-smi +++ /dev/null @@ -1,25 +0,0 @@ -#!/sbin/runscript -# Copyright 1999-2013 Gentoo Foundation -# Distributed under the terms of the GNU General Public License v2 -# $Id$ - -pidfile="/run/nvidia-smi.pid" - -depend() { - after modules -} - -start() { - ebegin "Starting NVIDIA System Management Interface" - rm -f ${pidfile} - start-stop-daemon --start --quiet --pidfile ${pidfile} \ - --make-pidfile --background --exec /opt/bin/nvidia-smi -- \ - -q -l 300 - eend $? -} - -stop() { - ebegin "Stopping NVIDIA System Management Interface" - start-stop-daemon --stop --quiet --pidfile ${pidfile} - eend $? -} diff --git a/init.d/._cfg0000_tor b/init.d/._cfg0000_tor deleted file mode 100755 index 799cca1..0000000 --- a/init.d/._cfg0000_tor +++ /dev/null @@ -1,84 +0,0 @@ -#!/sbin/runscript -# Copyright 1999-2014 Gentoo Foundation -# Distributed under the terms of the GNU General Public License v2 -# $Id$ - -PIDFILE=/var/run/tor/tor.pid -CONFFILE=/etc/tor/torrc -GRACEFUL_TIMEOUT=${GRACEFUL_TIMEOUT:-60} - -# See bug #523552, and https://trac.torproject.org/projects/tor/ticket/5525 -# Graceful = wait 30 secs or so until all connections are properly closed. -extra_commands="checkconfig" -extra_started_commands="graceful gracefulstop reload" -description="Anonymizing overlay network for TCP" -description_checkconfig="Check for valid config file." -description_reload="Reload the configuration." -description_graceful="Gracefully restart." -description_gracefulstop="Gracefully stop." - -depend() { - need net -} - -checkconfig() { - # first check that it exists - if [ ! -f ${CONFFILE} ] ; then - eerror "You need to setup ${CONFFILE} first" - eerror "Example is in ${CONFFILE}.sample" - return 1 - fi - - # now verify whether the configuration is valid - /usr/bin/tor --verify-config -f ${CONFFILE} > /dev/null 2>&1 - if [ $? -eq 0 ] ; then - einfo "Tor configuration (${CONFFILE}) is valid." - return 0 - else - eerror "Tor configuration (${CONFFILE}) not valid." - /usr/bin/tor --verify-config -f ${CONFFILE} - return 1 - fi -} - -start() { - checkconfig || return 1 - checkpath -d -m 0755 -o tor:tor /var/run/tor - ebegin "Starting Tor" - HOME=/var/lib/tor - start-stop-daemon --start --pidfile "${PIDFILE}" --quiet --exec /usr/bin/tor -- -f "${CONFFILE}" --runasdaemon 1 --PidFile "${PIDFILE}" > /dev/null 2>&1 - eend $? -} - -stop() { - ebegin "Stopping Tor" - start-stop-daemon --stop --pidfile "${PIDFILE}" --exec /usr/bin/tor -- --PidFile "${PIDFILE}" - eend $? -} - -graceful() { - gracefulstop - start - eend $? -} - -gracefulstop() { - local rc=0 - ebegin "Gracefully stopping Tor" - ebegin "This can take up to ${GRACEFUL_TIMEOUT} seconds" - start-stop-daemon -P --stop --signal INT -R ${GRACEFUL_TIMEOUT} --pidfile "${PIDFILE}" --exec /usr/bin/tor -- --PidFile "${PIDFILE}" - rc=$? - eend "done" - eend $rc -} - -reload() { - if [ ! -f ${PIDFILE} ]; then - eerror "${SVCNAME} isn't running" - return 1 - fi - checkconfig || return 1 - ebegin "Reloading Tor configuration" - start-stop-daemon --signal HUP --pidfile ${PIDFILE} - eend $? -} diff --git a/init.d/bitlbee b/init.d/bitlbee deleted file mode 100755 index 235b374..0000000 --- a/init.d/bitlbee +++ /dev/null @@ -1,28 +0,0 @@ -#!/sbin/runscript -# Copyright 1999-2013 Gentoo Foundation -# Distributed under the terms of the GNU General Public License, v2 or -# later -# $Header: /var/cvsroot/gentoo-x86/net-im/bitlbee/files/bitlbee.initd,v 1.4 2013/01/08 14:25:21 cedk Exp $ - -DAEMON=/usr/sbin/bitlbee -PIDFILE=/var/run/bitlbee/bitlbee.pid - -depend() { - need logger net -} - -start () { - ebegin "Starting bitlbee" - checkpath -d -m 0755 -o bitlbee:bitlbee `dirname ${PIDFILE}` - start-stop-daemon --start --quiet \ - -u bitlbee:bitlbee --exec ${DAEMON} -- -P ${PIDFILE} \ - ${BITLBEE_OPTS} - eend $? -} - -stop() { - ebegin "Stopping bitlbee" - start-stop-daemon --stop --quiet --pidfile ${PIDFILE} - eend $? -} - diff --git a/init.d/nvidia-persistenced b/init.d/nvidia-persistenced index e712514..07f6905 100755 --- a/init.d/nvidia-persistenced +++ b/init.d/nvidia-persistenced @@ -1,7 +1,7 @@ #!/sbin/runscript # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/files/nvidia-persistenced.init,v 1.2 2014/09/19 22:09:28 jer Exp $ +# $Id$ pidfile="/var/run/nvidia-persistenced/nvidia-persistenced.pid" diff --git a/init.d/nvidia-smi b/init.d/nvidia-smi index 71bbc6d..6dce4e8 100755 --- a/init.d/nvidia-smi +++ b/init.d/nvidia-smi @@ -1,7 +1,7 @@ #!/sbin/runscript # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/files/nvidia-smi.init,v 1.2 2013/05/09 16:32:00 jer Exp $ +# $Id$ pidfile="/run/nvidia-smi.pid" diff --git a/init.d/tor b/init.d/tor index 466f952..799cca1 100755 --- a/init.d/tor +++ b/init.d/tor @@ -1,7 +1,7 @@ #!/sbin/runscript # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/net-misc/tor/files/tor.initd-r7,v 1.2 2014/12/23 17:26:49 blueness Exp $ +# $Id$ PIDFILE=/var/run/tor/tor.pid CONFFILE=/etc/tor/torrc diff --git a/jabber/._cfg0000_c2s.xml b/jabber/._cfg0000_c2s.xml deleted file mode 100644 index e846d74..0000000 --- a/jabber/._cfg0000_c2s.xml +++ /dev/null @@ -1,705 +0,0 @@ - - - - c2s - - - /var/run/jabber/${id}.pid - - - - - 127.0.0.1 - 5347 - - - jabberd - secret - - - - - - - - 3 - - - 3 - - - 2 - - - - - - - jabberd/c2s - - - local3 - - - - - - - - - - - - localhost.localdomain - - - - - 0.0.0.0 - - - 5222 - - - - - - - - - - - - - - - - - - - - - 1024 - - - - - 0 - - - 1000 - - - 0 - - - 65535 - - - - - - - - - allow,deny - - - - - - - - - - - - - - - 0 - - - 0 - - - 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - /usr/lib64/jabberd - - - db - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /var/spool/jabber/db/sqlite.db - - - - - - 2000 - - - - - - - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </sqlite> - - <!-- MySQL module configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - <!-- use bcrypt passwords - NOTE: cost has to be higher than 3 and lower than 32 - <bcrypt cost='10'/> - --> - </password_type> - </mysql> - - <!-- PostgreSQL module configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </pgsql> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Berkeley DB module configuration --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- LDAPFULL module configuration --> - <ldapfull> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- Type of LDAP server. Currently "ad" for active directory and "ldap" - for other ldap servers. If not specified, then it is ldap. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <!-- LDAP attribute that holds the cleartext or hashed password - (not needed when pwscheme is set to 'bind') --> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Attribute that holds jabber account status. Must be TRUE for AD, - and 1 for other LDAP server. - If not specified, then it will not be used. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- Group that users must be members of - If this is set, only user that are members of the specified LDAP - group can log in. The group must be specified with its full - distinguished name --> - <!-- - <group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn> - --> - - <fulluid/> - <!-- If pwscheme is not defined, then passwords are stored in clear - text and digest authentication may be done. - If passwords are hashed, then you cannot use digest authentication - and should use plain text authentication. - Any of sha, ssha, crypt, bind and clear may be specified. - 'sha' specifies that the attribute in pwattr holds a base-64 - encoded SHA-1 hashed password beginning with the string {SHA}. - 'ssha' specifies that the attribute in pwattr holds a base-64 - SHA-1 hashed password appended with 32 bits of salt and beginning - with the string {SSHA}. - 'crypt' specifies that the attribute in pwattr holds a UNIX-style - crypt(3) hashed password. - 'bind' specifies that the password is not stored in an attribute - but is authenticated directly by the LDAP server by binding - using the user's DN. This should be compatible with the - widest variety of LDAP servers. - --> - <!-- <pwscheme>bind</pwscheme> --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldapfull> - - <!-- LDAP module configuration --> - <!-- Remember that you need to use PLAIN auth with LDAP backend --> - <ldap> - <!-- LDAP server host and port (default: 389) --> - <host>ldap.example.com</host> - <port>389</port> - - <!-- Use LDAP v3 if possible. If disabled, v2 will be used. - Encryption options are only available if v3 is enabled. --> - <!-- - <v3/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the LDAP server using the LDAP STARTTLS mechanism. --> - <!-- - <starttls/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the server using the old-style "ldaps://" mechanism. It is - recommended that you use <starttls/> instead of this. --> - <!-- - <ssl/> - --> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - - <!-- Enable the append-realm element if you want to append - realm value (usernam@realm) to the uidattr value - <append-realm/> - --> - - <!-- Alternatively to <uidattr/> and <append-realm/> you may - specify full LDAP search <query/> that will be used to - get user objects from directory. - - The following replacements take place: - %u is replaced by user login name - %r is replaced by user login realm - - When <query/> is specified, <uidattr/> and <append-realm/> - are unused and take no effect. --> - <!-- - <query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldap> - <!-- if you want to configure more than one LDAP server - create ldap1, ldap2 etc. sections - <ldap1> - - </ldap1> - --> - - <!-- Pipe module configuration --> - <pipe> - <!-- Program to execute --> - <exec>/usr/bin/pipe-auth.pl</exec> - </pipe> - - </authreg> - -</c2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_c2s.xml.dist b/jabber/._cfg0000_c2s.xml.dist deleted file mode 100644 index e846d74..0000000 --- a/jabber/._cfg0000_c2s.xml.dist +++ /dev/null @@ -1,705 +0,0 @@ -<!-- c2s configuration --> -<c2s> - <!-- Our ID on the network (default: c2s) --> - <id>c2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/c2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/c2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. This should correspond to the - ID (host) that the session manager thinks it is. You can - specify more than one to support virtual hosts, as long as you - have additional session manager instances on the network to - handle those hosts. - - You may leave the content of the <id/> empty to setup default - virtual host setup, that will be used for all present but not - configured otherwise SM domains. - - realm - attribute specifies the auth/reg or SASL authentication realm - for the host. If the attribute is not specified, the realm will - be selected by the SASL mechanism, or will be the same as the ID - itself. Be aware that users are assigned to a realm, not a host, - so two hosts in the same realm will have the same users. If no - realm is specified, it will be set to be the same as the ID. - If empty "" realm is specified, the PAM backend wil authenticate - using plain usernames, not JIDs. - - pemfile - attribute specifies the file containing a SSL certificate and - private key for client connections. If this is non existant, - clients will not be offered the STARTTLS stream extension - From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - verify-mode - SSL verify mode - see SSL_CTX_set_verify(3), mode parameter. - Sum of the following options: - SSL_VERIFY_NONE 0x00 - SSL_VERIFY_PEER 0x01 - SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02 - SSL_VERIFY_CLIENT_ONCE 0x04 - Use 7 to require all clients to present _valid_ certificates. - - - cachain - SSL CA chain. Used to verify client certificates. - CA names published to client upon connection. - - require-starttls - If this attribute is set to any value, clients must do STARTTLS - before they can authenticate. Until the stream is encrypted, - all packets will be dropped. - - register-enable - Remove this attribute to disable account registrations. - - instructions - Human-readable instructions to be returned to client when - registration is requested. - - register-oob - URL to be attached as an alternative, out-of-band registration - method. Usually web-based http:// URL. - - password-change - Password change only. When registration is disabled, it may - still be useful to allow clients to change their password. If - you want this, add this attribute with any value, when you need - registration disabled. - --> - <id register-enable='mu'>localhost.localdomain</id> - <!-- or - <id realm='company.int' - pemfile='/etc/jabber/server.pem' - verify-mode='7' - cachain='/etc/jabber/client_ca_certs.pem' - require-starttls='mu' - register-enable='mu' - instructions='Enter a username and password to register with this server.' - register-oob='http://example.org/register' - password-change='mu' - >example.net</id> --> - <!-- or the default host - <id password-change='mu' /> --> - - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to, or 0 to disable unencrypted access to the - server (default: 5222) --> - <port>5222</port> - - <!-- Older versions of jabberd support encrypted client connections - via an additional listening socket on port 5223. If you want - this (required to allow pre-STARTTLS clients to do SSL), - uncomment this --> - <!-- - <ssl-port>5223</ssl-port> - --> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - Note: This certificate is ONLY used for old style SSL - connections on port 5223 (pre-STARTTLS). If you want to - use STARTTLS over the standard XMPP port 5222 then you - MUST specify the pemfile in the 'id' tag above. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection --> - <!-- - <cachain>/etc/jabber/client_ca_certs.pem</cachain> - --> - - <!-- Forward incoming HTTP clients to a real HTTP server --> - <!-- - <httpforward>http://www.jabber.org/</httpforward> - --> - </local> - - <!-- Input/output settings --> - <io> - <!-- Maximum number of file descriptors. This value sets an upper - limit on the number of users who may be logged in to this - server at a given time. Each user consumers one file - descriptor. - - Note that the number of possible connections will be slightly - less than this, because c2s itself can use up five on its own, - and auth/reg modules may need a few also. If the supply of - file descriptors is exhausted, new incoming connections will - be denied. - - Also note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum number of stanzas per second - if more than X stanzas - are sent in Y seconds, connection is throttled for Z seconds. - The format is: - - <stanzas seconds='Y' throttle='Z'>X</stanzas> - - Default Y 1, default Z is 5. Set X to 0 to disable --> - <stanzas>1000</stanzas> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Open client connections will be checked every n seconds, and - the following checks applied. - - 0 disables all checks. (default: 0) --> - <interval>0</interval> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 0) --> - <idle>0</idle> - - <!-- Keepalives. - - Connections that have not sent data for longer than this many - seconds will have a single whitespace character sent to them. - This will force the TCP connection to be closed if they have - disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - </io> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/c2s.packets</packet> - --> - </stats> - - <!-- PBX integration --> - <pbx> - <!-- Commands named pipe path. Allows creating "fake" sessions - with given resource and status --> - <!-- - <pipe>/var/run/jabber/pbx</pipe> - --> - <!-- Available commands: - START jid/resource [[priority ]status] [description] - STOP jid/resource [description] - where priority is integer between -128 and +127 - and status is one of: CHAT, ONLINE, DND, AWAY, XA - --> - </pbx> - - <!-- see-other-host error stream redirection support - This will redirect connections to specified domains to other host:port - Usefull when migrating service and DNS change did not propagate yet. - Note that to_address should be RFC 3986 compliant. --> - <stream_redirect> - <!-- - <redirect requested_domain="some.domain" to_address="other.hostname" to_port="5269" /> - <redirect requested_domain="other.domain" to_address="other.host" to_port="1234" /> - --> - </stream_redirect> - - <!-- Authentication/registration database configuration --> - <authreg> - <!-- Dynamic authreg modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- Backend module to use --> - <module>db</module> - - <!-- Available authentication mechanisms --> - <mechanisms> - - <!-- These are the traditional Jabber authentication mechanisms. - Comment out any that you don't want to be offered to clients. - Note that if the auth/reg module does not support one of - these mechanisms, then it will not be offered regardless of - whether or not it is enabled here. --> - <traditional> - <plain/> - <digest/> - </traditional> - - <!-- SASL authentication mechanisms. Comment out any that you - don't want to be offered to clients. Again, if the auth/reg - module does not support one of these mechanisms, then it will - not be offered. --> - <sasl> - <plain/> - <digest-md5/> - <!-- - <anonymous/> - <gssapi/> - --> - </sasl> - - </mechanisms> - - <!-- Additional mechanisms that are also available when the - connection is encrypted. Ie. when START-TLS had been - negotiated, or user connected on SSL-wrapped port. --> - <ssl-mechanisms> - - <!-- it's advisable that you disable plain in the above - <mechanisms/> section --> - <traditional> - <plain/> - </traditional> - - <sasl> - <plain/> - <external/> - </sasl> - - </ssl-mechanisms> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transacation support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </sqlite> - - <!-- MySQL module configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - <!-- use bcrypt passwords - NOTE: cost has to be higher than 3 and lower than 32 - <bcrypt cost='10'/> - --> - </password_type> - </mysql> - - <!-- PostgreSQL module configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </pgsql> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Berkeley DB module configuration --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- LDAPFULL module configuration --> - <ldapfull> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- Type of LDAP server. Currently "ad" for active directory and "ldap" - for other ldap servers. If not specified, then it is ldap. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <!-- LDAP attribute that holds the cleartext or hashed password - (not needed when pwscheme is set to 'bind') --> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Attribute that holds jabber account status. Must be TRUE for AD, - and 1 for other LDAP server. - If not specified, then it will not be used. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- Group that users must be members of - If this is set, only user that are members of the specified LDAP - group can log in. The group must be specified with its full - distinguished name --> - <!-- - <group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn> - --> - - <fulluid/> - <!-- If pwscheme is not defined, then passwords are stored in clear - text and digest authentication may be done. - If passwords are hashed, then you cannot use digest authentication - and should use plain text authentication. - Any of sha, ssha, crypt, bind and clear may be specified. - 'sha' specifies that the attribute in pwattr holds a base-64 - encoded SHA-1 hashed password beginning with the string {SHA}. - 'ssha' specifies that the attribute in pwattr holds a base-64 - SHA-1 hashed password appended with 32 bits of salt and beginning - with the string {SSHA}. - 'crypt' specifies that the attribute in pwattr holds a UNIX-style - crypt(3) hashed password. - 'bind' specifies that the password is not stored in an attribute - but is authenticated directly by the LDAP server by binding - using the user's DN. This should be compatible with the - widest variety of LDAP servers. - --> - <!-- <pwscheme>bind</pwscheme> --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldapfull> - - <!-- LDAP module configuration --> - <!-- Remember that you need to use PLAIN auth with LDAP backend --> - <ldap> - <!-- LDAP server host and port (default: 389) --> - <host>ldap.example.com</host> - <port>389</port> - - <!-- Use LDAP v3 if possible. If disabled, v2 will be used. - Encryption options are only available if v3 is enabled. --> - <!-- - <v3/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the LDAP server using the LDAP STARTTLS mechanism. --> - <!-- - <starttls/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the server using the old-style "ldaps://" mechanism. It is - recommended that you use <starttls/> instead of this. --> - <!-- - <ssl/> - --> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - - <!-- Enable the append-realm element if you want to append - realm value (usernam@realm) to the uidattr value - <append-realm/> - --> - - <!-- Alternatively to <uidattr/> and <append-realm/> you may - specify full LDAP search <query/> that will be used to - get user objects from directory. - - The following replacements take place: - %u is replaced by user login name - %r is replaced by user login realm - - When <query/> is specified, <uidattr/> and <append-realm/> - are unused and take no effect. --> - <!-- - <query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldap> - <!-- if you want to configure more than one LDAP server - create ldap1, ldap2 etc. sections - <ldap1> - - </ldap1> - --> - - <!-- Pipe module configuration --> - <pipe> - <!-- Program to execute --> - <exec>/usr/bin/pipe-auth.pl</exec> - </pipe> - - </authreg> - -</c2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_router.xml b/jabber/._cfg0000_router.xml deleted file mode 100644 index 9f264a2..0000000 --- a/jabber/._cfg0000_router.xml +++ /dev/null @@ -1,215 +0,0 @@ -<!-- Router configuration --> -<router> - <!-- ID of the router on the network (default: router) --> - <id>router</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/router</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/router.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to (default: 5347) --> - <port>5347</port> - - <!-- File containing the user table. This is where the router gets - its component and secret information from for component - authentication.--> - <users>/etc/jabber/router-users.xml</users> - - <!-- Shared secret used to identify XEP-0114 components (that is, - "jabber:component:accept" components that authenticate using - the Jabber Component Protocol's "handshake", for example - mu-conference). If this is commented out, support for XEP-0114 - components will be disabled. --> - <secret>secret</secret> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or - server certificate), followed by intermediate CA certificates - if applicable, and ending at the highest level (root) CA" - (the latter one being optional). - If this is commented out, connecting components will not be able - to request an SSL-encrypted channel. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - </local> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks. (default: 60) --> - <interval>60</interval> - - <!-- Keepalives. - Connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - the router itself can use up four on its own. If the supply of - file descriptors is exhausted, new incoming connections will be - denied. - - These file descriptors are really only used when a component - connects to the router. So unless you have a lot of components - for some reason then you probably don't need to change this - value. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - </limits> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - </io> - - <!-- Name aliases. - - Packets destined for the domain specified in the "name" attribute - will be routed to the component that has currently bound the name - in the "target" attribute (assuming it is online). - - This is usually only required for some kinds of legacy - components (particularly jabberd 1.4 "uplink" components) --> - <aliases> - <!-- Example for a MUC component running from a jabberd 1.4 uplink --> - <!-- - <alias name='conference.domain.com' target='muclinker'/> - --> - </aliases> - - <!-- Access control information --> - <aci> - <!-- The usernames listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <user>jabberd</user> - </acl> - - <!-- These users can bind names other than their username --> - <!-- - <acl type='bind'> - </acl> - --> - - <!-- These users can bind a name as a default route --> - <!-- - <acl type='default-route'> - <user>s2s</user> - </acl> - --> - - <!-- These users can elect to receive all packets that pass through the router --> - <!-- - <acl type='log'> - <user>msglog</user> - </acl> - --> - - <!-- File containing packet filter rules. - May be used for fine grained packet routing control. --> - <filter>/etc/jabber/router-filter.xml</filter> - - </aci> - - <!-- Simple message logging to flat file - Remove <enabled/> tag to disable logging --> - <!-- - <message_logging> - <enabled/> - <file>filename</file> - </message_logging> - --> - -</router> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_router.xml.dist b/jabber/._cfg0000_router.xml.dist deleted file mode 100644 index 9f264a2..0000000 --- a/jabber/._cfg0000_router.xml.dist +++ /dev/null @@ -1,215 +0,0 @@ -<!-- Router configuration --> -<router> - <!-- ID of the router on the network (default: router) --> - <id>router</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/router</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/router.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to (default: 5347) --> - <port>5347</port> - - <!-- File containing the user table. This is where the router gets - its component and secret information from for component - authentication.--> - <users>/etc/jabber/router-users.xml</users> - - <!-- Shared secret used to identify XEP-0114 components (that is, - "jabber:component:accept" components that authenticate using - the Jabber Component Protocol's "handshake", for example - mu-conference). If this is commented out, support for XEP-0114 - components will be disabled. --> - <secret>secret</secret> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or - server certificate), followed by intermediate CA certificates - if applicable, and ending at the highest level (root) CA" - (the latter one being optional). - If this is commented out, connecting components will not be able - to request an SSL-encrypted channel. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - </local> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks. (default: 60) --> - <interval>60</interval> - - <!-- Keepalives. - Connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - the router itself can use up four on its own. If the supply of - file descriptors is exhausted, new incoming connections will be - denied. - - These file descriptors are really only used when a component - connects to the router. So unless you have a lot of components - for some reason then you probably don't need to change this - value. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - </limits> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - </io> - - <!-- Name aliases. - - Packets destined for the domain specified in the "name" attribute - will be routed to the component that has currently bound the name - in the "target" attribute (assuming it is online). - - This is usually only required for some kinds of legacy - components (particularly jabberd 1.4 "uplink" components) --> - <aliases> - <!-- Example for a MUC component running from a jabberd 1.4 uplink --> - <!-- - <alias name='conference.domain.com' target='muclinker'/> - --> - </aliases> - - <!-- Access control information --> - <aci> - <!-- The usernames listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <user>jabberd</user> - </acl> - - <!-- These users can bind names other than their username --> - <!-- - <acl type='bind'> - </acl> - --> - - <!-- These users can bind a name as a default route --> - <!-- - <acl type='default-route'> - <user>s2s</user> - </acl> - --> - - <!-- These users can elect to receive all packets that pass through the router --> - <!-- - <acl type='log'> - <user>msglog</user> - </acl> - --> - - <!-- File containing packet filter rules. - May be used for fine grained packet routing control. --> - <filter>/etc/jabber/router-filter.xml</filter> - - </aci> - - <!-- Simple message logging to flat file - Remove <enabled/> tag to disable logging --> - <!-- - <message_logging> - <enabled/> - <file>filename</file> - </message_logging> - --> - -</router> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_s2s.xml b/jabber/._cfg0000_s2s.xml deleted file mode 100644 index 42b9464..0000000 --- a/jabber/._cfg0000_s2s.xml +++ /dev/null @@ -1,323 +0,0 @@ -<!-- s2s configuration --> -<s2s> - <!-- Our ID on the network (default: s2s) --> - <id>s2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- The router will only allow one component to be the default - route (ie the component that receives packets destined for - unknown hosts). If you want to run more than one s2s instance, - you need to uncomment this so that s2s does not try to become - the default route. Note that all outgoing s2s communication - will go to the component that is the default route. --> - <!-- - <non-default/> - --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/s2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- if logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/s2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP and port to listen for incoming s2s connections on - (default: 0.0.0.0, 5269) --> - <ip>0.0.0.0</ip> - <port>5269</port> - - <!-- Multihomed machines (with more than one interface and IP address) - need to specify outgoing S2S connections interface/address. - If not set, the <ip> section address above is used. --> - <!-- - <origins> - <ip>1.2.3.4</ip> - <ip>fe80::202:b3ff:fe1e:8329</ip> - </origins> - --> - - <!-- Secret used to generate dialback keys. If you have more than - one s2s instance configured, make sure that this is the same on - all of them. If this is commented out, a random one will be - generated. --> - <!-- - <secret>secret</secret> - --> - - <!-- File containing an SSL certificate and private key to use when setting - up encrypted s2s connections with other servers (STARTTLS + Dialback). - From SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt will be - made to establish encrypted connections with other servers. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- File containing an optional SSL certificate chain file for SSL - connections. --> - <!-- - <cachain>/etc/jabber/cachain.pem</cachain> - --> - - </local> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - s2s itself can use some on its own. If the supply of file - descriptors is exhausted, new incoming connections will be - denied. - - These connections are mainly consumed when we make a - connection to an external jabber server, or an external jabber - server connects to us. If you don't have a lot of users then - there's probably no need for s2s to establish connections to - external jabber servers and the default value here is probably - fine. On the other hand, if you have lots of users with lots - of remote buddies in their buddylist then s2s will need to have - lots of open connections with other jabber servers and you may - need to increase this value. - - Note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - </io> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks except DNS expiry. (default: 60) --> - <interval>60</interval> - - <!-- Queue expiry and connection timeout. - - While a connection is being established and dialback is in - progress, packets are queued. If a valid connection has not - been established within this many seconds, the connection - process will be aborted and the queued packets will be - bounced. Timeout checks are made for three phases of - setting up a route authenticated through dialback: - 1. Connection establishment to exchange of stream headers - 2. Initiating dialback (incoming connections) - 3. Completing dialback (incoming and outgoing) - - If stage 1 connection establishment fails and there are - alternative hosts for this route that have not failed - recently, they will be tried too before finally giving up. - - 0 disables queue expiry. (default: 60) --> - <queue>60</queue> - - <!-- Queue retry timeout. - - If the queue is older than this timeout, the connection - will not be retried even if there are alternative hosts - that have not failed recently. - - 0 disables retry expiry. (default: 300) --> - <retry>300</retry> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 86400) --> - <idle>86400</idle> - - <!-- Keepalives. - - Outgoing connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - <!-- Interval between DNS result/bad host expiry. - - 0 disables expiry checks. (default: 300) --> - <dnscache>300</dnscache> - </check> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/s2s.packets</packet> - --> - </stats> - - <lookup> - <!-- SRV TCP services will be resolved in the following order. The first - one that returns something will be used (ie dereferenced via an - A/AAAA lookup). If no SRV records are found, resolver will - fallback to a straight A/AAAA lookup. --> - - <!-- xmpp-server is mandated by the XMPP spec --> - <srv>xmpp-server</srv> - - <!-- traditionally, jabber has been used --> - <srv>jabber</srv> - - - <!-- If this is enabled, the resolver will look up AAAA records as well - as A records. This is needed if you want s2s to use IPv6. - Connection attempts will be made to all IPv6 hosts before trying - IPv4 (see bad host timeout below). --> - <!-- - <resolve-ipv6/> - --> - - <!-- Minimum time that DNS lookup results are cached (overrides max below). --> - <min-ttl>30</min-ttl> - - <!-- Maximum time that DNS lookup results are cached. --> - <max-ttl>86400</max-ttl> - - <!-- Time /etc/hosts lookup results are cached for (default: 86400). --> - <etc-hosts-ttl>86400</etc-hosts-ttl> - - <!-- Minimum time to wait before using hosts that we have failed to - establish a connection to (unless there are no alternatives). - Do not set this too low - it is required to detect permanent - problems like broken IPv6 connectivity in order to attempt IPv4. - - 0 disables bad host caching. (default: 3600) --> - <bad-host-timeout>3600</bad-host-timeout> - - <!-- Disable the DNS cache (negative caching will still be done). - This is likely to negatively impact performance while saving - a small amount of memory since multiple DNS requests must - then be made for every re-connection. --> - <!-- - <no-cache/> - --> - </lookup> - - <!-- If this is enabled, domains which share the same host will re-use - existing outgoing connections. This is a potential security risk - as the SSL connection from the first domain will be re-used too. --> - <out-conn-reuse/> - - <security> - <!-- Require TLS secured S2S connections --> - <!-- - <require_tls/> - --> - - <!-- - Domain whitelisting - --> - <!-- - <enable_whitelist/> - --> - - <!-- Domain whitelisting - When defined, only whitelisted domains are allowed to connect --> - <!-- - <whitelist_domain>domain1.tld</whitelist_domain> - <whitelist_domain>domain2.tld</whitelist_domain> - <whitelist_domain>other.tld</whitelist_domain> - --> - </security> -</s2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_s2s.xml.dist b/jabber/._cfg0000_s2s.xml.dist deleted file mode 100644 index 42b9464..0000000 --- a/jabber/._cfg0000_s2s.xml.dist +++ /dev/null @@ -1,323 +0,0 @@ -<!-- s2s configuration --> -<s2s> - <!-- Our ID on the network (default: s2s) --> - <id>s2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- The router will only allow one component to be the default - route (ie the component that receives packets destined for - unknown hosts). If you want to run more than one s2s instance, - you need to uncomment this so that s2s does not try to become - the default route. Note that all outgoing s2s communication - will go to the component that is the default route. --> - <!-- - <non-default/> - --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/s2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- if logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/s2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP and port to listen for incoming s2s connections on - (default: 0.0.0.0, 5269) --> - <ip>0.0.0.0</ip> - <port>5269</port> - - <!-- Multihomed machines (with more than one interface and IP address) - need to specify outgoing S2S connections interface/address. - If not set, the <ip> section address above is used. --> - <!-- - <origins> - <ip>1.2.3.4</ip> - <ip>fe80::202:b3ff:fe1e:8329</ip> - </origins> - --> - - <!-- Secret used to generate dialback keys. If you have more than - one s2s instance configured, make sure that this is the same on - all of them. If this is commented out, a random one will be - generated. --> - <!-- - <secret>secret</secret> - --> - - <!-- File containing an SSL certificate and private key to use when setting - up encrypted s2s connections with other servers (STARTTLS + Dialback). - From SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt will be - made to establish encrypted connections with other servers. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- File containing an optional SSL certificate chain file for SSL - connections. --> - <!-- - <cachain>/etc/jabber/cachain.pem</cachain> - --> - - </local> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - s2s itself can use some on its own. If the supply of file - descriptors is exhausted, new incoming connections will be - denied. - - These connections are mainly consumed when we make a - connection to an external jabber server, or an external jabber - server connects to us. If you don't have a lot of users then - there's probably no need for s2s to establish connections to - external jabber servers and the default value here is probably - fine. On the other hand, if you have lots of users with lots - of remote buddies in their buddylist then s2s will need to have - lots of open connections with other jabber servers and you may - need to increase this value. - - Note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - </io> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks except DNS expiry. (default: 60) --> - <interval>60</interval> - - <!-- Queue expiry and connection timeout. - - While a connection is being established and dialback is in - progress, packets are queued. If a valid connection has not - been established within this many seconds, the connection - process will be aborted and the queued packets will be - bounced. Timeout checks are made for three phases of - setting up a route authenticated through dialback: - 1. Connection establishment to exchange of stream headers - 2. Initiating dialback (incoming connections) - 3. Completing dialback (incoming and outgoing) - - If stage 1 connection establishment fails and there are - alternative hosts for this route that have not failed - recently, they will be tried too before finally giving up. - - 0 disables queue expiry. (default: 60) --> - <queue>60</queue> - - <!-- Queue retry timeout. - - If the queue is older than this timeout, the connection - will not be retried even if there are alternative hosts - that have not failed recently. - - 0 disables retry expiry. (default: 300) --> - <retry>300</retry> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 86400) --> - <idle>86400</idle> - - <!-- Keepalives. - - Outgoing connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - <!-- Interval between DNS result/bad host expiry. - - 0 disables expiry checks. (default: 300) --> - <dnscache>300</dnscache> - </check> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/s2s.packets</packet> - --> - </stats> - - <lookup> - <!-- SRV TCP services will be resolved in the following order. The first - one that returns something will be used (ie dereferenced via an - A/AAAA lookup). If no SRV records are found, resolver will - fallback to a straight A/AAAA lookup. --> - - <!-- xmpp-server is mandated by the XMPP spec --> - <srv>xmpp-server</srv> - - <!-- traditionally, jabber has been used --> - <srv>jabber</srv> - - - <!-- If this is enabled, the resolver will look up AAAA records as well - as A records. This is needed if you want s2s to use IPv6. - Connection attempts will be made to all IPv6 hosts before trying - IPv4 (see bad host timeout below). --> - <!-- - <resolve-ipv6/> - --> - - <!-- Minimum time that DNS lookup results are cached (overrides max below). --> - <min-ttl>30</min-ttl> - - <!-- Maximum time that DNS lookup results are cached. --> - <max-ttl>86400</max-ttl> - - <!-- Time /etc/hosts lookup results are cached for (default: 86400). --> - <etc-hosts-ttl>86400</etc-hosts-ttl> - - <!-- Minimum time to wait before using hosts that we have failed to - establish a connection to (unless there are no alternatives). - Do not set this too low - it is required to detect permanent - problems like broken IPv6 connectivity in order to attempt IPv4. - - 0 disables bad host caching. (default: 3600) --> - <bad-host-timeout>3600</bad-host-timeout> - - <!-- Disable the DNS cache (negative caching will still be done). - This is likely to negatively impact performance while saving - a small amount of memory since multiple DNS requests must - then be made for every re-connection. --> - <!-- - <no-cache/> - --> - </lookup> - - <!-- If this is enabled, domains which share the same host will re-use - existing outgoing connections. This is a potential security risk - as the SSL connection from the first domain will be re-used too. --> - <out-conn-reuse/> - - <security> - <!-- Require TLS secured S2S connections --> - <!-- - <require_tls/> - --> - - <!-- - Domain whitelisting - --> - <!-- - <enable_whitelist/> - --> - - <!-- Domain whitelisting - When defined, only whitelisted domains are allowed to connect --> - <!-- - <whitelist_domain>domain1.tld</whitelist_domain> - <whitelist_domain>domain2.tld</whitelist_domain> - <whitelist_domain>other.tld</whitelist_domain> - --> - </security> -</s2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_sm.xml b/jabber/._cfg0000_sm.xml deleted file mode 100644 index bc0f76c..0000000 --- a/jabber/._cfg0000_sm.xml +++ /dev/null @@ -1,811 +0,0 @@ -<!-- Session manager configuration --> -<sm> - <!-- Our ID on the network (default: sm) --> - <id>sm</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/sm</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/sm.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. - Users will have this as the domain part of their JID. - If you want your server to be accessible from other - Jabber servers, this IDs must be FQDN resolvable by DNSes. - If not set, the SM id is used. --> - <id>localhost.localdomain</id> - <!-- - <id>vhost1.localdomain</id> - <id>vhost2.localdomain</id> - --> - - </local> - - <!-- Storage database configuration --> - <storage> - <!-- Dynamic storage modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- By default, we use the SQLite driver for all storage --> - <driver>db</driver> - - <!-- Its also possible to explicitly list alternate drivers for - specific data types. --> - - <!-- Store vcards in a ldapvcard database instead --> - <!-- - <driver type='vcard'>ldapvcard</driver> - --> - - <!-- Only ldapvcard driver implements published-roster: --> - <!-- - <driver type='published-roster'>ldapvcard</driver> - --> - - <!-- Use ldapvcard driver for published-roster-groups. - See description in section sm/user/template/mapped-groups. - Used by mod_published_roster. - See ldapvcard section for options. - When resolving group id to group name, it searches for - groupsobjectclass objects at groupsdn base using group id - (in groupsidattr) as key and returns the first value of - groupattr of first found entry. - E.g.. in general case, if group id is "some-dep", and groupsdn - is o=org, and class is jabberGroup, it searches for - (&(objectClass=jabberGroup)(cn=some-dep)) and returns value of - jabberPublishedItem attribute, which may contain textual description. - --> - <!-- - <driver type='published-roster-groups'>ldapvcard</driver> - --> - - <!-- Rate limiting --> - <limits> - <!-- Maximum queries per second - if more than X queries are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <queries seconds='Y' throttle='Z'>X</bytes> - - Default Y is 5, default Z is 60. set X to 0 to disable. --> - <!-- - <queries>3</queries> - --> - </limits> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - </sqlite> - - <!-- MySQL driver configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. - - This will need to be disabled if you are using a MySQL - earlier than v3.23.xx, as transaction support did not appear - until this version. --> - <transactions/> - </mysql> - - <!-- PostgreSQL driver configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - </pgsql> - - <!-- Berkeley DB driver configuration. This does not support roster - maxitems or offline userquota (because the mod_roster - implementation does not implement the 'count' callback). --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Filesystem driver configuration --> - <fs> - <!-- Directory to store database files under. --> - <path>/var/spool/jabber/fs</path> - </fs> - - <!-- LDAPVCARD driver configuration --> - <ldapvcard> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Realm to append to uidattr. --> - <!-- - <realm>example.org</realm> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn>o=Example Corp.</basedn> - - <!-- attribute that holds published group name or id, - jabberPublishedGroup if not set --> - <!-- - <groupattr>jabberPublishedGroup</groupattr> - --> - - <!-- this option is helpful if your schema does not have designated - attribute that holds jabber group name - you can use any attribute in <groupattr> i.e. 'distinguishedName' - and then extract a part of it using Regular Expression; - first matching () group will be used --> - <!-- - <groupattr_regex>OU=([^,]*),</groupattr_regex> - --> - - <!-- boolean attribute that tells whether or not to publish this user - jabberPublishedItem by default --> - <!-- - <publishedattr>jabberPublishedItem</publishedattr> - --> - - <!-- If value specified, then keep cache of "published-roster" - database, which is used for all users. Cache is renewed when kept more seconds than value - specified. Setting this value increases perfomance of publishing - roster. If not specified, then we don't keep cache. --> - <publishedcachettl>60</publishedcachettl> - - <mapped-groups> - <!-- If turned on, then mapping of group ids to names with - LDAP will works. --> - <!-- - <map-groups/> - --> - - <!-- base for searches for group id to group name mappings --> - <basedn>ou=jabbergroups, o=Example Corp.</basedn> - - <!-- what objectclass to search, jabberGroup by default --> - <!-- - <objectclass>jabberGroup</objectclass> - --> - - <!-- what attribute to search, cn by default --> - <!-- - <idattr>cn</idattr> - --> - - <!-- attribute with text group name, description by default --> - <!-- - <nameattr>description</nameattr> - --> - </mapped-groups> - </ldapvcard> - </storage> - - <!-- Access control information --> - <aci> - <!-- The JIDs listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <jid>admin@localhost.localdomain</jid> - </acl> - - <!-- These JIDs can send broadcast messages (announce, motd) --> - <!-- - <acl type='broadcast'> - <jid>nocstaff1@localhost.localdomain</jid> - <jid>nocstaff2@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs will receive messages addressed to the sm itself - (help requestes and such) --> - <!-- - <acl type='messages'> - <jid>support@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs can discover active user/session information --> - <!-- - <acl type='disco'> - <jid>webstatus@localhost.localdomain</jid> - </acl> - --> - </aci> - - <!-- Module chain configuration - - Modules listed in a chain are called in the order specified at - the appropriate time for that chain (assuming that the module - knows how to work with that chain; otherwise it simply ignores - it). - - Removing a module from these lists will stop the module being - called, even if it's compiled into the server. - - Serveral modules have a presence in more than one chain. It is - possible to remove a module from one chain but not others, but - this may cause strange behaviour. Make sure you know what you're - doing. --> - <modules> - <!-- Dynamic sm modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- sess-start. The modules in this chain are called when a session - is first started (usually on request by c2s as part of the - authentication process). This is normally used to load - per-session data. --> - <chain id='sess-start'> - <module>status</module> <!-- record status information --> - </chain> - - <!-- sess-end. The modules in this chain are called just before a - session is destroyed (after the client has disconnected). --> - <chain id='sess-end'> - <module>status</module> <!-- update status information --> - <module>iq-last</module> <!-- update logout time --> - </chain> - - <!-- in-sess. The modules in this chain are called when a packet - arrives from an active user session. Note that this chain is - also responsible for delivering packets to their destinations - - this is usually handled by the "deliver" module. --> - <chain id='in-sess'> - <module>validate</module> <!-- validate packet type --> - <module>status</module> <!-- update status information --> - <module>privacy</module> <!-- manage privacy lists --> - <module>roster</module> <!-- handle roster get/sets and s10ns --> - <module>vacation</module> <!-- manage vacation settings --> - <!-- <module>pep</module> <!- - personal eventing --> - <module>iq-vcard</module> <!-- store and retrieve the user's vcard --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-private</module> <!-- manage the user's private data store --> - <module>disco</module> <!-- respond to agents requests from sessions --> - <module>amp</module> <!-- advanced message processing --> - <module>offline</module> <!-- if we're coming online for the first time, deliver queued messages --> - <module>announce</module> <!-- deliver motd --> - <module>presence</module> <!-- process and distribute presence updates --> - <module>deliver</module> <!-- deliver packets with full jids directly --> - </chain> - - <!-- out-sess. The modules in this chain are called just before a - packet is delivered to an active user session. --> - <chain id='out-sess'> - <!-- <module>pep</module> <!- - personal eventing --> - </chain> - - <!-- in-router. The modules in this chain are called when a packet - arrives from the router (ie another component or s2s), but - before any processing is done. This is a good place to filter - incoming packets. --> - <chain id='in-router'> - <module>session</module> <!-- perform session actions as required by c2s --> - <module>validate</module> <!-- validate packet type --> - <module>presence</module> <!-- drop incoming presence if user not online --> - <module>privacy</module> <!-- filter incoming packets based on privacy rules --> - </chain> - - <!-- out-router. The modules in this chain are called just before a - packet is delivered to the router (destined for another - component or s2s). This is a good place to filter outgoing - packets. --> - <chain id='out-router'> - <module>privacy</module> <!-- filter outgoing packets based on privacy rules --> - </chain> - - <!-- pkt-sm. The modules in this chain are called when a packet - arrives that is addressed to the session manager itself (ie the - to JID has no node part). This is normally used to provide - session-manager-wide services (like service discovery). --> - <chain id='pkt-sm'> - <module>iq-last</module> <!-- return the server uptime --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-time</module> <!-- return the current server time --> - <module>iq-version</module> <!-- return the server name and version --> - <module>amp</module> <!-- advanced message processing --> - <module>disco</module> <!-- build the disco list; respond to disco queries --> - <module>announce</module> <!-- send broadcast messages (announce, motd, etc) --> - <module>help</module> <!-- resend sm messages to administrators --> - <module>echo</module> <!-- echo messages sent to /echo --> - <module>status</module> <!-- track status information --> - <module>presence</module> <!-- proces server presence subscriptions --> - </chain> - - <!-- pkt-user. The modules in this chain are called when a packet - arrives that is address to a specific user. Note that this - chain is also responsible for delivering packets to user - sessions as appropriate - this is usually handled by the - "deliver" module. --> - <chain id='pkt-user'> - <module>roster</module> <!-- handle s10n responses --> - <module>presence</module> <!-- process and distribute incoming presence from external entities --> - <module>iq-vcard</module> <!-- grab user vcards --> - <module>amp</module> <!-- advanced message processing --> - <module>deliver</module> <!-- deliver the packet to an active session if we can --> - <module>vacation</module> <!-- send vacation messages --> - <module>offline</module> <!-- save messages and s10ns for later --> - <module>iq-last</module> <!-- return time since last logout --> - </chain> - - <!-- pkt-router. The modules in this chain are called when a - special-purpose packet arrives from the router (eg domain - advertisements). --> - <chain id='pkt-router'> - <module>session</module> <!-- take sessions offline if their c2s disappears --> - <module>disco</module> <!-- query new components for service information --> - </chain> - - <!-- user-load. The modules in this chain are called to load - per-user data. This will happen before a user can be used (ie - before a session is created). --> - <chain id='user-load'> - <module>active</module> <!-- get active status --> - <module>roster</module> <!-- load the roster and trust list --> - <module>roster-publish</module> <!-- load the published roster --> - <module>privacy</module> <!-- load privacy lists --> - <module>vacation</module> <!-- load vacation settings --> - </chain> - - <!-- user-unload. The modules in this chain are called right - after last per-user session is destroyed. --> - <chain id='user-unload'> - </chain> - - <!-- user-create. The modules in this chain are called when a user - creation request is received (usually from c2s as part of a - registration request). This initialises any per-user data. --> - <chain id='user-create'> - <module>active</module> <!-- activate new users --> - <module>template-roster</module> <!-- populate roster from template --> - </chain> - - <!-- user-delete. The modules in this chain are called when a user - deletion request is received (usually from c2s as part of a - registration removal request). This deletes all data that may - have been previously created for the user during normal - operation. --> - <chain id='user-delete'> - <module>active</module> <!-- deactivate users --> - <module>announce</module> <!-- delete motd data --> - <module>offline</module> <!-- bounce queued messages --> - <module>privacy</module> <!-- delete privacy lists --> - <module>roster</module> <!-- delete roster --> - <module>vacation</module> <!-- delete vacation settings --> - <module>status</module> <!-- delete status information --> - <module>iq-last</module> <!-- delete last logout time --> - <module>iq-private</module> <!-- delete private data --> - <module>iq-vcard</module> <!-- delete vcard --> - </chain> - - <!-- disco-extend. The modules in this chain are called when a disco - info request is send to session manager. It implements XEP-0128 - Service Discovery Extensions mechanizm to add additional - information to disco#info reply. --> - <chain id='disco-extend'> - <module>iq-version</module> <!-- add XEP-xxxx Software Information --> - <module>help</module> <!-- add XEP-0157 Contact Addresses --> - </chain> - - </modules> - - <!-- Service discovery configuration --> - <discovery> - - <!-- Service identity. these specify the category, type and name of - this service that will be included in discovery information - responses. --> - <identity> - <category>server</category> <!-- default: server --> - <type>im</type> <!-- default: im --> - <name>Jabber IM server</name> <!-- default: Jabber IM server --> - </identity> - - <!-- The discovery module can respond to jabber:iq:agents queries - for compatibility with older clients. Comment this out to - disable this. --> - <agents/> - - <!-- Static service list. - - The discover module can discover disco-capable services - automatically as they come online. Most XEP-0114 components, - however, will not support discovery. In order to get them to - appear in disco/agents lists returned to the client, they - should be listed here. - - Note that if a disco-capable service with the same name as one - listed below comes online, the information it provides will - override the information listed below. - - The "category" and "type" attributes, and the list of supported - namespaces are only used for agents compatibility. If you have - disabled this above, you may omit them. --> - <items> - - <!-- example entry for a user directory --> - <!-- - <item category='service' type='jud' jid='users.jabber.org' name='Jabber User Directory'/> - --> - - <!-- example entry for a groupchat (conference) service --> - <!-- - <item category='conference' type='public' jid='conference.jabber.org' name='Text conferencing'/> - --> - - </items> - - <!-- Server information added to server discovery information - in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157) - - May contain many values per item --> - <!-- - <serverinfo> - <admin-addresses> - <value>mailto:xmpp@localhost.localdomain</value> - <value>xmpp:admins@localhost.localdomain</value> - </admin-addresses> - <abuse-addresses> - <value>mailto:abuse@localhost.localdomain</value> - <value>xmpp:abuse@localhost.localdomain</value> - </abuse-addresses> - <feedback-addresses> - <value>http://example.org/feedback.php</value> - </feedback-addresses> - <sales-addresses/> - <security-addresses/> - <support-addresses/> - </serverinfo> - --> - - </discovery> - - <!-- User options --> - <user> - <!-- By default, users must explicitly created before they can start - a session. The creation process is usually triggered by a c2s - component in response to a client registering a new user. - - Enabling this option will make it so that user creation will be - triggered the first time a non-existant user attempts to start - a session. This is useful if you already have users in an - external authentication database (eg LDAP) and you don't want - them to have to register. --> - <!-- - <auto-create/> - --> - - <!-- Define maximum size in bytes of fields of vcards. - There is a recommendation that the avatar picture SHOULD NOT - be larger than 16 KiB. --> - <!-- - <vcard> - <max-field-size> - <default>16384</default> - <avatar>16384</avatar> - </max-field-size> - </vcard> - --> - - <!-- Templates. If defined, the contents of these files will be - stored in the users data store when they are created. --> - <template> - <!-- Uncomment <publish> if you wish to forcibly publish - roster template from ldap on each user login --> - <!-- - <publish> - --> - <!-- Key used for fetching published roster items. - Only one might be set at a time. - If not set, all items are fetched. --> - <!-- - <fetch-key> - <domain/> - <user/> - <fixed>grouping-key</fixed> - </fetch-key> - --> - <!-- If <check-remove-domain> given, then published contact is checked - against sm user database and if user is unknown to sm, contact - will be deleted from user's roster (if it is in roster). - If no domain set (tag empty) all contacts are checked. --> - <!-- - <check-remove-domain>jabber.example.com</check-remove-domain> - --> - <!-- Alternatively if <force-create-contacts/> is not commented, - published contact is added to sm user database - and user set known to sm, so it won't auto-unsubscribe - on connection established --> - <!-- - <force-create-contacts/> - --> - <!-- Keep cache of "active" database specified number of seconds. - This will significantly speed up publishing of roster. - If unspecified or 0, no cache is used. --> - <active-cache-ttl>60</active-cache-ttl> - <!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of - user's contacts to subscriptions of corresponding published - contacts. --> - <!-- - <fix-subscriptions/> - --> - <!-- If <override-names/> is uncommented, then displayed names of - contacts in user's roster will be updated accordingly to - published roster (if they differ). If commented, then user can - rename contacts in roster --> - <!-- - <override-names/> - --> - <!-- when mapped-groups is on (<map-groups/> is uncommented), the actual - group names for published contacts are read from - published-roster-groups storage type, which may be set - to ldapvcard driver. The key for searching is published user's - group, and returned value is used as group name. So you can assign - textual group IDs to users rather then group names. - group-cache-ttl keeps cache of mapping from group id to name for - specified number of seconds. If unspecified or 0, no cache is used. - --> - <!-- - <mapped-groups> - <map-groups/> - <group-cache-ttl>120</group-cache-ttl> - </mapped-groups> - --> - <!-- If <force-groups> is commented out, published roster's contact - added to user's roster only when user does not have this contact. - - If <force-groups> is uncommented, then these checks are performed - against each roster item already in user's roster: - If roster item already present in user's roster in - group of same name, no changes are made with this group (note - that contact may be in more than one group). - If <prefix> or <suffix> are given, then contact removed - from any matching groups. - After that, contact is added to group from published roster. - - In other words, all groups of updated contact, that match prefix - or suffix, are replaced with group of published contact. - This is done because there is no way to determine that group was - published or greated by user. --> - <!-- - <force-groups> - <prefix>MyOrg.</prefix> - <suffix>(MyOrg)</suffix> - </force-groups> - --> - <!-- - </publish> - --> - - <!-- If defined, the contents of these files will be - stored in the users data store when they are created. --> - <!-- If you defined publish, you should comment-out <roster> --> - <!-- - <roster>/etc/jabber/templates/roster.xml</roster> - --> - </template> - </user> - - <!-- Advanced Message Processing module configuration --> - <amp> - <!-- You can disable some actions --> - <!-- - <disableactions> - <drop/> - <error/> - <alert/> - <notify/> - </disableactions> - --> - - <!-- You can disable some conditions --> - <!-- - <disableconditions> - <expireat/> - <matchresource/> - <deliver/> - </disableconditions> - --> - - <!-- You need to enable this if your server has offline storage disabled --> - <!-- - <offlinestoragedisabled/> - --> - </amp> - - <!-- Offline module configuration --> - <offline> - <!-- Do not store messages in offline store --> - <!-- - <dropmessages/> - --> - - <!-- Store headline messages in offline store --> - <!-- - <storeheadlines/> - --> - - <!-- Do not store subscription requests in offline store --> - <!-- - <dropsubscriptions/> - --> - - <!-- Offline storage message quota. - Specifies how many messages will be stored in user offline store --> - <!-- - <userquota>500</userquota> - --> - </offline> - - <!-- roster module configuration --> - <roster> - <!-- maximum items per user roster --> - <!-- - <maxitems>100</maxitems> - --> - </roster> - - <!-- status module configuration --> - <status> - <!-- presence service resource - disabled when commented out --> - <!-- - <resource>webstatus</resource> - --> - </status> - -</sm> -<!-- - vim: syntax=xml ---> diff --git a/jabber/._cfg0000_sm.xml.dist b/jabber/._cfg0000_sm.xml.dist deleted file mode 100644 index bc0f76c..0000000 --- a/jabber/._cfg0000_sm.xml.dist +++ /dev/null @@ -1,811 +0,0 @@ -<!-- Session manager configuration --> -<sm> - <!-- Our ID on the network (default: sm) --> - <id>sm</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/${id}.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/sm</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/sm.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. - Users will have this as the domain part of their JID. - If you want your server to be accessible from other - Jabber servers, this IDs must be FQDN resolvable by DNSes. - If not set, the SM id is used. --> - <id>localhost.localdomain</id> - <!-- - <id>vhost1.localdomain</id> - <id>vhost2.localdomain</id> - --> - - </local> - - <!-- Storage database configuration --> - <storage> - <!-- Dynamic storage modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- By default, we use the SQLite driver for all storage --> - <driver>db</driver> - - <!-- Its also possible to explicitly list alternate drivers for - specific data types. --> - - <!-- Store vcards in a ldapvcard database instead --> - <!-- - <driver type='vcard'>ldapvcard</driver> - --> - - <!-- Only ldapvcard driver implements published-roster: --> - <!-- - <driver type='published-roster'>ldapvcard</driver> - --> - - <!-- Use ldapvcard driver for published-roster-groups. - See description in section sm/user/template/mapped-groups. - Used by mod_published_roster. - See ldapvcard section for options. - When resolving group id to group name, it searches for - groupsobjectclass objects at groupsdn base using group id - (in groupsidattr) as key and returns the first value of - groupattr of first found entry. - E.g.. in general case, if group id is "some-dep", and groupsdn - is o=org, and class is jabberGroup, it searches for - (&(objectClass=jabberGroup)(cn=some-dep)) and returns value of - jabberPublishedItem attribute, which may contain textual description. - --> - <!-- - <driver type='published-roster-groups'>ldapvcard</driver> - --> - - <!-- Rate limiting --> - <limits> - <!-- Maximum queries per second - if more than X queries are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <queries seconds='Y' throttle='Z'>X</bytes> - - Default Y is 5, default Z is 60. set X to 0 to disable. --> - <!-- - <queries>3</queries> - --> - </limits> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - </sqlite> - - <!-- MySQL driver configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. - - This will need to be disabled if you are using a MySQL - earlier than v3.23.xx, as transaction support did not appear - until this version. --> - <transactions/> - </mysql> - - <!-- PostgreSQL driver configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - </pgsql> - - <!-- Berkeley DB driver configuration. This does not support roster - maxitems or offline userquota (because the mod_roster - implementation does not implement the 'count' callback). --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Filesystem driver configuration --> - <fs> - <!-- Directory to store database files under. --> - <path>/var/spool/jabber/fs</path> - </fs> - - <!-- LDAPVCARD driver configuration --> - <ldapvcard> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Realm to append to uidattr. --> - <!-- - <realm>example.org</realm> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn>o=Example Corp.</basedn> - - <!-- attribute that holds published group name or id, - jabberPublishedGroup if not set --> - <!-- - <groupattr>jabberPublishedGroup</groupattr> - --> - - <!-- this option is helpful if your schema does not have designated - attribute that holds jabber group name - you can use any attribute in <groupattr> i.e. 'distinguishedName' - and then extract a part of it using Regular Expression; - first matching () group will be used --> - <!-- - <groupattr_regex>OU=([^,]*),</groupattr_regex> - --> - - <!-- boolean attribute that tells whether or not to publish this user - jabberPublishedItem by default --> - <!-- - <publishedattr>jabberPublishedItem</publishedattr> - --> - - <!-- If value specified, then keep cache of "published-roster" - database, which is used for all users. Cache is renewed when kept more seconds than value - specified. Setting this value increases perfomance of publishing - roster. If not specified, then we don't keep cache. --> - <publishedcachettl>60</publishedcachettl> - - <mapped-groups> - <!-- If turned on, then mapping of group ids to names with - LDAP will works. --> - <!-- - <map-groups/> - --> - - <!-- base for searches for group id to group name mappings --> - <basedn>ou=jabbergroups, o=Example Corp.</basedn> - - <!-- what objectclass to search, jabberGroup by default --> - <!-- - <objectclass>jabberGroup</objectclass> - --> - - <!-- what attribute to search, cn by default --> - <!-- - <idattr>cn</idattr> - --> - - <!-- attribute with text group name, description by default --> - <!-- - <nameattr>description</nameattr> - --> - </mapped-groups> - </ldapvcard> - </storage> - - <!-- Access control information --> - <aci> - <!-- The JIDs listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <jid>admin@localhost.localdomain</jid> - </acl> - - <!-- These JIDs can send broadcast messages (announce, motd) --> - <!-- - <acl type='broadcast'> - <jid>nocstaff1@localhost.localdomain</jid> - <jid>nocstaff2@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs will receive messages addressed to the sm itself - (help requestes and such) --> - <!-- - <acl type='messages'> - <jid>support@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs can discover active user/session information --> - <!-- - <acl type='disco'> - <jid>webstatus@localhost.localdomain</jid> - </acl> - --> - </aci> - - <!-- Module chain configuration - - Modules listed in a chain are called in the order specified at - the appropriate time for that chain (assuming that the module - knows how to work with that chain; otherwise it simply ignores - it). - - Removing a module from these lists will stop the module being - called, even if it's compiled into the server. - - Serveral modules have a presence in more than one chain. It is - possible to remove a module from one chain but not others, but - this may cause strange behaviour. Make sure you know what you're - doing. --> - <modules> - <!-- Dynamic sm modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- sess-start. The modules in this chain are called when a session - is first started (usually on request by c2s as part of the - authentication process). This is normally used to load - per-session data. --> - <chain id='sess-start'> - <module>status</module> <!-- record status information --> - </chain> - - <!-- sess-end. The modules in this chain are called just before a - session is destroyed (after the client has disconnected). --> - <chain id='sess-end'> - <module>status</module> <!-- update status information --> - <module>iq-last</module> <!-- update logout time --> - </chain> - - <!-- in-sess. The modules in this chain are called when a packet - arrives from an active user session. Note that this chain is - also responsible for delivering packets to their destinations - - this is usually handled by the "deliver" module. --> - <chain id='in-sess'> - <module>validate</module> <!-- validate packet type --> - <module>status</module> <!-- update status information --> - <module>privacy</module> <!-- manage privacy lists --> - <module>roster</module> <!-- handle roster get/sets and s10ns --> - <module>vacation</module> <!-- manage vacation settings --> - <!-- <module>pep</module> <!- - personal eventing --> - <module>iq-vcard</module> <!-- store and retrieve the user's vcard --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-private</module> <!-- manage the user's private data store --> - <module>disco</module> <!-- respond to agents requests from sessions --> - <module>amp</module> <!-- advanced message processing --> - <module>offline</module> <!-- if we're coming online for the first time, deliver queued messages --> - <module>announce</module> <!-- deliver motd --> - <module>presence</module> <!-- process and distribute presence updates --> - <module>deliver</module> <!-- deliver packets with full jids directly --> - </chain> - - <!-- out-sess. The modules in this chain are called just before a - packet is delivered to an active user session. --> - <chain id='out-sess'> - <!-- <module>pep</module> <!- - personal eventing --> - </chain> - - <!-- in-router. The modules in this chain are called when a packet - arrives from the router (ie another component or s2s), but - before any processing is done. This is a good place to filter - incoming packets. --> - <chain id='in-router'> - <module>session</module> <!-- perform session actions as required by c2s --> - <module>validate</module> <!-- validate packet type --> - <module>presence</module> <!-- drop incoming presence if user not online --> - <module>privacy</module> <!-- filter incoming packets based on privacy rules --> - </chain> - - <!-- out-router. The modules in this chain are called just before a - packet is delivered to the router (destined for another - component or s2s). This is a good place to filter outgoing - packets. --> - <chain id='out-router'> - <module>privacy</module> <!-- filter outgoing packets based on privacy rules --> - </chain> - - <!-- pkt-sm. The modules in this chain are called when a packet - arrives that is addressed to the session manager itself (ie the - to JID has no node part). This is normally used to provide - session-manager-wide services (like service discovery). --> - <chain id='pkt-sm'> - <module>iq-last</module> <!-- return the server uptime --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-time</module> <!-- return the current server time --> - <module>iq-version</module> <!-- return the server name and version --> - <module>amp</module> <!-- advanced message processing --> - <module>disco</module> <!-- build the disco list; respond to disco queries --> - <module>announce</module> <!-- send broadcast messages (announce, motd, etc) --> - <module>help</module> <!-- resend sm messages to administrators --> - <module>echo</module> <!-- echo messages sent to /echo --> - <module>status</module> <!-- track status information --> - <module>presence</module> <!-- proces server presence subscriptions --> - </chain> - - <!-- pkt-user. The modules in this chain are called when a packet - arrives that is address to a specific user. Note that this - chain is also responsible for delivering packets to user - sessions as appropriate - this is usually handled by the - "deliver" module. --> - <chain id='pkt-user'> - <module>roster</module> <!-- handle s10n responses --> - <module>presence</module> <!-- process and distribute incoming presence from external entities --> - <module>iq-vcard</module> <!-- grab user vcards --> - <module>amp</module> <!-- advanced message processing --> - <module>deliver</module> <!-- deliver the packet to an active session if we can --> - <module>vacation</module> <!-- send vacation messages --> - <module>offline</module> <!-- save messages and s10ns for later --> - <module>iq-last</module> <!-- return time since last logout --> - </chain> - - <!-- pkt-router. The modules in this chain are called when a - special-purpose packet arrives from the router (eg domain - advertisements). --> - <chain id='pkt-router'> - <module>session</module> <!-- take sessions offline if their c2s disappears --> - <module>disco</module> <!-- query new components for service information --> - </chain> - - <!-- user-load. The modules in this chain are called to load - per-user data. This will happen before a user can be used (ie - before a session is created). --> - <chain id='user-load'> - <module>active</module> <!-- get active status --> - <module>roster</module> <!-- load the roster and trust list --> - <module>roster-publish</module> <!-- load the published roster --> - <module>privacy</module> <!-- load privacy lists --> - <module>vacation</module> <!-- load vacation settings --> - </chain> - - <!-- user-unload. The modules in this chain are called right - after last per-user session is destroyed. --> - <chain id='user-unload'> - </chain> - - <!-- user-create. The modules in this chain are called when a user - creation request is received (usually from c2s as part of a - registration request). This initialises any per-user data. --> - <chain id='user-create'> - <module>active</module> <!-- activate new users --> - <module>template-roster</module> <!-- populate roster from template --> - </chain> - - <!-- user-delete. The modules in this chain are called when a user - deletion request is received (usually from c2s as part of a - registration removal request). This deletes all data that may - have been previously created for the user during normal - operation. --> - <chain id='user-delete'> - <module>active</module> <!-- deactivate users --> - <module>announce</module> <!-- delete motd data --> - <module>offline</module> <!-- bounce queued messages --> - <module>privacy</module> <!-- delete privacy lists --> - <module>roster</module> <!-- delete roster --> - <module>vacation</module> <!-- delete vacation settings --> - <module>status</module> <!-- delete status information --> - <module>iq-last</module> <!-- delete last logout time --> - <module>iq-private</module> <!-- delete private data --> - <module>iq-vcard</module> <!-- delete vcard --> - </chain> - - <!-- disco-extend. The modules in this chain are called when a disco - info request is send to session manager. It implements XEP-0128 - Service Discovery Extensions mechanizm to add additional - information to disco#info reply. --> - <chain id='disco-extend'> - <module>iq-version</module> <!-- add XEP-xxxx Software Information --> - <module>help</module> <!-- add XEP-0157 Contact Addresses --> - </chain> - - </modules> - - <!-- Service discovery configuration --> - <discovery> - - <!-- Service identity. these specify the category, type and name of - this service that will be included in discovery information - responses. --> - <identity> - <category>server</category> <!-- default: server --> - <type>im</type> <!-- default: im --> - <name>Jabber IM server</name> <!-- default: Jabber IM server --> - </identity> - - <!-- The discovery module can respond to jabber:iq:agents queries - for compatibility with older clients. Comment this out to - disable this. --> - <agents/> - - <!-- Static service list. - - The discover module can discover disco-capable services - automatically as they come online. Most XEP-0114 components, - however, will not support discovery. In order to get them to - appear in disco/agents lists returned to the client, they - should be listed here. - - Note that if a disco-capable service with the same name as one - listed below comes online, the information it provides will - override the information listed below. - - The "category" and "type" attributes, and the list of supported - namespaces are only used for agents compatibility. If you have - disabled this above, you may omit them. --> - <items> - - <!-- example entry for a user directory --> - <!-- - <item category='service' type='jud' jid='users.jabber.org' name='Jabber User Directory'/> - --> - - <!-- example entry for a groupchat (conference) service --> - <!-- - <item category='conference' type='public' jid='conference.jabber.org' name='Text conferencing'/> - --> - - </items> - - <!-- Server information added to server discovery information - in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157) - - May contain many values per item --> - <!-- - <serverinfo> - <admin-addresses> - <value>mailto:xmpp@localhost.localdomain</value> - <value>xmpp:admins@localhost.localdomain</value> - </admin-addresses> - <abuse-addresses> - <value>mailto:abuse@localhost.localdomain</value> - <value>xmpp:abuse@localhost.localdomain</value> - </abuse-addresses> - <feedback-addresses> - <value>http://example.org/feedback.php</value> - </feedback-addresses> - <sales-addresses/> - <security-addresses/> - <support-addresses/> - </serverinfo> - --> - - </discovery> - - <!-- User options --> - <user> - <!-- By default, users must explicitly created before they can start - a session. The creation process is usually triggered by a c2s - component in response to a client registering a new user. - - Enabling this option will make it so that user creation will be - triggered the first time a non-existant user attempts to start - a session. This is useful if you already have users in an - external authentication database (eg LDAP) and you don't want - them to have to register. --> - <!-- - <auto-create/> - --> - - <!-- Define maximum size in bytes of fields of vcards. - There is a recommendation that the avatar picture SHOULD NOT - be larger than 16 KiB. --> - <!-- - <vcard> - <max-field-size> - <default>16384</default> - <avatar>16384</avatar> - </max-field-size> - </vcard> - --> - - <!-- Templates. If defined, the contents of these files will be - stored in the users data store when they are created. --> - <template> - <!-- Uncomment <publish> if you wish to forcibly publish - roster template from ldap on each user login --> - <!-- - <publish> - --> - <!-- Key used for fetching published roster items. - Only one might be set at a time. - If not set, all items are fetched. --> - <!-- - <fetch-key> - <domain/> - <user/> - <fixed>grouping-key</fixed> - </fetch-key> - --> - <!-- If <check-remove-domain> given, then published contact is checked - against sm user database and if user is unknown to sm, contact - will be deleted from user's roster (if it is in roster). - If no domain set (tag empty) all contacts are checked. --> - <!-- - <check-remove-domain>jabber.example.com</check-remove-domain> - --> - <!-- Alternatively if <force-create-contacts/> is not commented, - published contact is added to sm user database - and user set known to sm, so it won't auto-unsubscribe - on connection established --> - <!-- - <force-create-contacts/> - --> - <!-- Keep cache of "active" database specified number of seconds. - This will significantly speed up publishing of roster. - If unspecified or 0, no cache is used. --> - <active-cache-ttl>60</active-cache-ttl> - <!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of - user's contacts to subscriptions of corresponding published - contacts. --> - <!-- - <fix-subscriptions/> - --> - <!-- If <override-names/> is uncommented, then displayed names of - contacts in user's roster will be updated accordingly to - published roster (if they differ). If commented, then user can - rename contacts in roster --> - <!-- - <override-names/> - --> - <!-- when mapped-groups is on (<map-groups/> is uncommented), the actual - group names for published contacts are read from - published-roster-groups storage type, which may be set - to ldapvcard driver. The key for searching is published user's - group, and returned value is used as group name. So you can assign - textual group IDs to users rather then group names. - group-cache-ttl keeps cache of mapping from group id to name for - specified number of seconds. If unspecified or 0, no cache is used. - --> - <!-- - <mapped-groups> - <map-groups/> - <group-cache-ttl>120</group-cache-ttl> - </mapped-groups> - --> - <!-- If <force-groups> is commented out, published roster's contact - added to user's roster only when user does not have this contact. - - If <force-groups> is uncommented, then these checks are performed - against each roster item already in user's roster: - If roster item already present in user's roster in - group of same name, no changes are made with this group (note - that contact may be in more than one group). - If <prefix> or <suffix> are given, then contact removed - from any matching groups. - After that, contact is added to group from published roster. - - In other words, all groups of updated contact, that match prefix - or suffix, are replaced with group of published contact. - This is done because there is no way to determine that group was - published or greated by user. --> - <!-- - <force-groups> - <prefix>MyOrg.</prefix> - <suffix>(MyOrg)</suffix> - </force-groups> - --> - <!-- - </publish> - --> - - <!-- If defined, the contents of these files will be - stored in the users data store when they are created. --> - <!-- If you defined publish, you should comment-out <roster> --> - <!-- - <roster>/etc/jabber/templates/roster.xml</roster> - --> - </template> - </user> - - <!-- Advanced Message Processing module configuration --> - <amp> - <!-- You can disable some actions --> - <!-- - <disableactions> - <drop/> - <error/> - <alert/> - <notify/> - </disableactions> - --> - - <!-- You can disable some conditions --> - <!-- - <disableconditions> - <expireat/> - <matchresource/> - <deliver/> - </disableconditions> - --> - - <!-- You need to enable this if your server has offline storage disabled --> - <!-- - <offlinestoragedisabled/> - --> - </amp> - - <!-- Offline module configuration --> - <offline> - <!-- Do not store messages in offline store --> - <!-- - <dropmessages/> - --> - - <!-- Store headline messages in offline store --> - <!-- - <storeheadlines/> - --> - - <!-- Do not store subscription requests in offline store --> - <!-- - <dropsubscriptions/> - --> - - <!-- Offline storage message quota. - Specifies how many messages will be stored in user offline store --> - <!-- - <userquota>500</userquota> - --> - </offline> - - <!-- roster module configuration --> - <roster> - <!-- maximum items per user roster --> - <!-- - <maxitems>100</maxitems> - --> - </roster> - - <!-- status module configuration --> - <status> - <!-- presence service resource - disabled when commented out --> - <!-- - <resource>webstatus</resource> - --> - </status> - -</sm> -<!-- - vim: syntax=xml ---> diff --git a/jabber/.keep_net-im_jabber-base-0 b/jabber/.keep_net-im_jabber-base-0 deleted file mode 100644 index e69de29..0000000 diff --git a/jabber/c2s.xml b/jabber/c2s.xml deleted file mode 100644 index 8ad1cfa..0000000 --- a/jabber/c2s.xml +++ /dev/null @@ -1,701 +0,0 @@ -<!-- c2s configuration --> -<c2s> - <!-- Our ID on the network (default: c2s) --> - <id>c2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-c2s.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/c2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/c2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. This should correspond to the - ID (host) that the session manager thinks it is. You can - specify more than one to support virtual hosts, as long as you - have additional session manager instances on the network to - handle those hosts. - - You may leave the content of the <id/> empty to setup default - virtual host setup, that will be used for all present but not - configured otherwise SM domains. - - realm - attribute specifies the auth/reg or SASL authentication realm - for the host. If the attribute is not specified, the realm will - be selected by the SASL mechanism, or will be the same as the ID - itself. Be aware that users are assigned to a realm, not a host, - so two hosts in the same realm will have the same users. If no - realm is specified, it will be set to be the same as the ID. - If empty "" realm is specified, the PAM backend wil authenticate - using plain usernames, not JIDs. - - pemfile - attribute specifies the file containing a SSL certificate and - private key for client connections. If this is non existant, - clients will not be offered the STARTTLS stream extension - From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - verify-mode - SSL verify mode - see SSL_CTX_set_verify(3), mode parameter. - Sum of the following options: - SSL_VERIFY_NONE 0x00 - SSL_VERIFY_PEER 0x01 - SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02 - SSL_VERIFY_CLIENT_ONCE 0x04 - Use 7 to require all clients to present _valid_ certificates. - - - cachain - SSL CA chain. Used to verify client certificates. - CA names published to client upon connection. - - require-starttls - If this attribute is set to any value, clients must do STARTTLS - before they can authenticate. Until the stream is encrypted, - all packets will be dropped. - - register-enable - Remove this attribute to disable account registrations. - - instructions - Human-readable instructions to be returned to client when - registration is requested. - - register-oob - URL to be attached as an alternative, out-of-band registration - method. Usually web-based http:// URL. - - password-change - Password change only. When registration is disabled, it may - still be useful to allow clients to change their password. If - you want this, add this attribute with any value, when you need - registration disabled. - --> - <id register-enable='mu'>localhost.localdomain</id> - <!-- or - <id realm='company.int' - pemfile='/etc/jabber/server.pem' - verify-mode='7' - cachain='/etc/jabber/client_ca_certs.pem' - require-starttls='mu' - register-enable='mu' - instructions='Enter a username and password to register with this server.' - register-oob='http://example.org/register' - password-change='mu' - >example.net</id> --> - <!-- or the default host - <id password-change='mu' /> --> - - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to, or 0 to disable unencrypted access to the - server (default: 5222) --> - <port>5222</port> - - <!-- Older versions of jabberd support encrypted client connections - via an additional listening socket on port 5223. If you want - this (required to allow pre-STARTTLS clients to do SSL), - uncomment this --> - <!-- - <ssl-port>5223</ssl-port> - --> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - Note: This certificate is ONLY used for old style SSL - connections on port 5223 (pre-STARTTLS). If you want to - use STARTTLS over the standard XMPP port 5222 then you - MUST specify the pemfile in the 'id' tag above. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection --> - <!-- - <cachain>/etc/jabber/client_ca_certs.pem</cachain> - --> - - <!-- Forward incoming HTTP clients to a real HTTP server --> - <!-- - <httpforward>http://www.jabber.org/</httpforward> - --> - </local> - - <!-- Input/output settings --> - <io> - <!-- Maximum number of file descriptors. This value sets an upper - limit on the number of users who may be logged in to this - server at a given time. Each user consumers one file - descriptor. - - Note that the number of possible connections will be slightly - less than this, because c2s itself can use up five on its own, - and auth/reg modules may need a few also. If the supply of - file descriptors is exhausted, new incoming connections will - be denied. - - Also note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum number of stanzas per second - if more than X stanzas - are sent in Y seconds, connection is throttled for Z seconds. - The format is: - - <stanzas seconds='Y' throttle='Z'>X</stanzas> - - Default Y 1, default Z is 5. Set X to 0 to disable --> - <stanzas>1000</stanzas> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Open client connections will be checked every n seconds, and - the following checks applied. - - 0 disables all checks. (default: 0) --> - <interval>0</interval> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 0) --> - <idle>0</idle> - - <!-- Keepalives. - - Connections that have not sent data for longer than this many - seconds will have a single whitespace character sent to them. - This will force the TCP connection to be closed if they have - disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - </io> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/c2s.packets</packet> - --> - </stats> - - <!-- PBX integration --> - <pbx> - <!-- Commands named pipe path. Allows creating "fake" sessions - with given resource and status --> - <!-- - <pipe>/var/run/jabber/pbx</pipe> - --> - <!-- Available commands: - START jid/resource [[priority ]status] [description] - STOP jid/resource [description] - where priority is integer between -128 and +127 - and status is one of: CHAT, ONLINE, DND, AWAY, XA - --> - </pbx> - - <!-- see-other-host error stream redirection support - This will redirect connections to specified domains to other host:port - Usefull when migrating service and DNS change did not propagate yet. - Note that to_address should be RFC 3986 compliant. --> - <stream_redirect> - <!-- - <redirect requested_domain="some.domain" to_address="other.hostname" to_port="5269" /> - <redirect requested_domain="other.domain" to_address="other.host" to_port="1234" /> - --> - </stream_redirect> - - <!-- Authentication/registration database configuration --> - <authreg> - <!-- Dynamic authreg modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- Backend module to use --> - <module>db</module> - - <!-- Available authentication mechanisms --> - <mechanisms> - - <!-- These are the traditional Jabber authentication mechanisms. - Comment out any that you don't want to be offered to clients. - Note that if the auth/reg module does not support one of - these mechanisms, then it will not be offered regardless of - whether or not it is enabled here. --> - <traditional> - <plain/> - <digest/> - </traditional> - - <!-- SASL authentication mechanisms. Comment out any that you - don't want to be offered to clients. Again, if the auth/reg - module does not support one of these mechanisms, then it will - not be offered. --> - <sasl> - <plain/> - <digest-md5/> - <!-- - <anonymous/> - <gssapi/> - --> - </sasl> - - </mechanisms> - - <!-- Additional mechanisms that are also available when the - connection is encrypted. Ie. when START-TLS had been - negotiated, or user connected on SSL-wrapped port. --> - <ssl-mechanisms> - - <!-- it's advisable that you disable plain in the above - <mechanisms/> section --> - <traditional> - <plain/> - </traditional> - - <sasl> - <plain/> - <external/> - </sasl> - - </ssl-mechanisms> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transacation support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </sqlite> - - <!-- MySQL module configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </mysql> - - <!-- PostgreSQL module configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </pgsql> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Berkeley DB module configuration --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- LDAPFULL module configuration --> - <ldapfull> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- Type of LDAP server. Currently "ad" for active directory and "ldap" - for other ldap servers. If not specified, then it is ldap. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <!-- LDAP attribute that holds the cleartext or hashed password - (not needed when pwscheme is set to 'bind') --> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Attribute that holds jabber account status. Must be TRUE for AD, - and 1 for other LDAP server. - If not specified, then it will not be used. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- Group that users must be members of - If this is set, only user that are members of the specified LDAP - group can log in. The group must be specified with its full - distinguished name --> - <!-- - <group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn> - --> - - <fulluid/> - <!-- If pwscheme is not defined, then passwords are stored in clear - text and digest authentication may be done. - If passwords are hashed, then you cannot use digest authentication - and should use plain text authentication. - Any of sha, ssha, crypt, bind and clear may be specified. - 'sha' specifies that the attribute in pwattr holds a base-64 - encoded SHA-1 hashed password beginning with the string {SHA}. - 'ssha' specifies that the attribute in pwattr holds a base-64 - SHA-1 hashed password appended with 32 bits of salt and beginning - with the string {SSHA}. - 'crypt' specifies that the attribute in pwattr holds a UNIX-style - crypt(3) hashed password. - 'bind' specifies that the password is not stored in an attribute - but is authenticated directly by the LDAP server by binding - using the user's DN. This should be compatible with the - widest variety of LDAP servers. - --> - <!-- <pwscheme>bind</pwscheme> --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldapfull> - - <!-- LDAP module configuration --> - <!-- Remember that you need to use PLAIN auth with LDAP backend --> - <ldap> - <!-- LDAP server host and port (default: 389) --> - <host>ldap.example.com</host> - <port>389</port> - - <!-- Use LDAP v3 if possible. If disabled, v2 will be used. - Encryption options are only available if v3 is enabled. --> - <!-- - <v3/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the LDAP server using the LDAP STARTTLS mechanism. --> - <!-- - <starttls/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the server using the old-style "ldaps://" mechanism. It is - recommended that you use <starttls/> instead of this. --> - <!-- - <ssl/> - --> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - - <!-- Enable the append-realm element if you want to append - realm value (usernam@realm) to the uidattr value - <append-realm/> - --> - - <!-- Alternatively to <uidattr/> and <append-realm/> you may - specify full LDAP search <query/> that will be used to - get user objects from directory. - - The following replacements take place: - %u is replaced by user login name - %r is replaced by user login realm - - When <query/> is specified, <uidattr/> and <append-realm/> - are unused and take no effect. --> - <!-- - <query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldap> - <!-- if you want to configure more than one LDAP server - create ldap1, ldap2 etc. sections - <ldap1> - - </ldap1> - --> - - <!-- Pipe module configuration --> - <pipe> - <!-- Program to execute --> - <exec>/usr/bin/pipe-auth.pl</exec> - </pipe> - - </authreg> - -</c2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/c2s.xml.dist b/jabber/c2s.xml.dist deleted file mode 100644 index 8ad1cfa..0000000 --- a/jabber/c2s.xml.dist +++ /dev/null @@ -1,701 +0,0 @@ -<!-- c2s configuration --> -<c2s> - <!-- Our ID on the network (default: c2s) --> - <id>c2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-c2s.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/c2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/c2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. This should correspond to the - ID (host) that the session manager thinks it is. You can - specify more than one to support virtual hosts, as long as you - have additional session manager instances on the network to - handle those hosts. - - You may leave the content of the <id/> empty to setup default - virtual host setup, that will be used for all present but not - configured otherwise SM domains. - - realm - attribute specifies the auth/reg or SASL authentication realm - for the host. If the attribute is not specified, the realm will - be selected by the SASL mechanism, or will be the same as the ID - itself. Be aware that users are assigned to a realm, not a host, - so two hosts in the same realm will have the same users. If no - realm is specified, it will be set to be the same as the ID. - If empty "" realm is specified, the PAM backend wil authenticate - using plain usernames, not JIDs. - - pemfile - attribute specifies the file containing a SSL certificate and - private key for client connections. If this is non existant, - clients will not be offered the STARTTLS stream extension - From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - verify-mode - SSL verify mode - see SSL_CTX_set_verify(3), mode parameter. - Sum of the following options: - SSL_VERIFY_NONE 0x00 - SSL_VERIFY_PEER 0x01 - SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02 - SSL_VERIFY_CLIENT_ONCE 0x04 - Use 7 to require all clients to present _valid_ certificates. - - - cachain - SSL CA chain. Used to verify client certificates. - CA names published to client upon connection. - - require-starttls - If this attribute is set to any value, clients must do STARTTLS - before they can authenticate. Until the stream is encrypted, - all packets will be dropped. - - register-enable - Remove this attribute to disable account registrations. - - instructions - Human-readable instructions to be returned to client when - registration is requested. - - register-oob - URL to be attached as an alternative, out-of-band registration - method. Usually web-based http:// URL. - - password-change - Password change only. When registration is disabled, it may - still be useful to allow clients to change their password. If - you want this, add this attribute with any value, when you need - registration disabled. - --> - <id register-enable='mu'>localhost.localdomain</id> - <!-- or - <id realm='company.int' - pemfile='/etc/jabber/server.pem' - verify-mode='7' - cachain='/etc/jabber/client_ca_certs.pem' - require-starttls='mu' - register-enable='mu' - instructions='Enter a username and password to register with this server.' - register-oob='http://example.org/register' - password-change='mu' - >example.net</id> --> - <!-- or the default host - <id password-change='mu' /> --> - - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to, or 0 to disable unencrypted access to the - server (default: 5222) --> - <port>5222</port> - - <!-- Older versions of jabberd support encrypted client connections - via an additional listening socket on port 5223. If you want - this (required to allow pre-STARTTLS clients to do SSL), - uncomment this --> - <!-- - <ssl-port>5223</ssl-port> - --> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or server - certificate), followed by intermediate CA certificates if - applicable, and ending at the highest level (root) CA" - (the latter one being optional). - - Note: This certificate is ONLY used for old style SSL - connections on port 5223 (pre-STARTTLS). If you want to - use STARTTLS over the standard XMPP port 5222 then you - MUST specify the pemfile in the 'id' tag above. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection --> - <!-- - <cachain>/etc/jabber/client_ca_certs.pem</cachain> - --> - - <!-- Forward incoming HTTP clients to a real HTTP server --> - <!-- - <httpforward>http://www.jabber.org/</httpforward> - --> - </local> - - <!-- Input/output settings --> - <io> - <!-- Maximum number of file descriptors. This value sets an upper - limit on the number of users who may be logged in to this - server at a given time. Each user consumers one file - descriptor. - - Note that the number of possible connections will be slightly - less than this, because c2s itself can use up five on its own, - and auth/reg modules may need a few also. If the supply of - file descriptors is exhausted, new incoming connections will - be denied. - - Also note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum number of stanzas per second - if more than X stanzas - are sent in Y seconds, connection is throttled for Z seconds. - The format is: - - <stanzas seconds='Y' throttle='Z'>X</stanzas> - - Default Y 1, default Z is 5. Set X to 0 to disable --> - <stanzas>1000</stanzas> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Open client connections will be checked every n seconds, and - the following checks applied. - - 0 disables all checks. (default: 0) --> - <interval>0</interval> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 0) --> - <idle>0</idle> - - <!-- Keepalives. - - Connections that have not sent data for longer than this many - seconds will have a single whitespace character sent to them. - This will force the TCP connection to be closed if they have - disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - </io> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/c2s.packets</packet> - --> - </stats> - - <!-- PBX integration --> - <pbx> - <!-- Commands named pipe path. Allows creating "fake" sessions - with given resource and status --> - <!-- - <pipe>/var/run/jabber/pbx</pipe> - --> - <!-- Available commands: - START jid/resource [[priority ]status] [description] - STOP jid/resource [description] - where priority is integer between -128 and +127 - and status is one of: CHAT, ONLINE, DND, AWAY, XA - --> - </pbx> - - <!-- see-other-host error stream redirection support - This will redirect connections to specified domains to other host:port - Usefull when migrating service and DNS change did not propagate yet. - Note that to_address should be RFC 3986 compliant. --> - <stream_redirect> - <!-- - <redirect requested_domain="some.domain" to_address="other.hostname" to_port="5269" /> - <redirect requested_domain="other.domain" to_address="other.host" to_port="1234" /> - --> - </stream_redirect> - - <!-- Authentication/registration database configuration --> - <authreg> - <!-- Dynamic authreg modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- Backend module to use --> - <module>db</module> - - <!-- Available authentication mechanisms --> - <mechanisms> - - <!-- These are the traditional Jabber authentication mechanisms. - Comment out any that you don't want to be offered to clients. - Note that if the auth/reg module does not support one of - these mechanisms, then it will not be offered regardless of - whether or not it is enabled here. --> - <traditional> - <plain/> - <digest/> - </traditional> - - <!-- SASL authentication mechanisms. Comment out any that you - don't want to be offered to clients. Again, if the auth/reg - module does not support one of these mechanisms, then it will - not be offered. --> - <sasl> - <plain/> - <digest-md5/> - <!-- - <anonymous/> - <gssapi/> - --> - </sasl> - - </mechanisms> - - <!-- Additional mechanisms that are also available when the - connection is encrypted. Ie. when START-TLS had been - negotiated, or user connected on SSL-wrapped port. --> - <ssl-mechanisms> - - <!-- it's advisable that you disable plain in the above - <mechanisms/> section --> - <traditional> - <plain/> - </traditional> - - <sasl> - <plain/> - <external/> - </sasl> - - </ssl-mechanisms> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transacation support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </sqlite> - - <!-- MySQL module configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </mysql> - - <!-- PostgreSQL module configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Passwords in DB may be stored in plain or hashed format --> - <!-- NOTE: If you are using hashed passwords, the only auth - method that will work is PLAIN. - Make sure that you disabled others in 'mechanisms' - sections of the config file. --> - <password_type> - <!-- only one may be enabled here --> - <plaintext/> - <!-- use crypt(3)ed passwords - <crypt/> - --> - <!-- use A1HASH passwords - This stores the MD5 digest of user:realm:password in the database - <a1hash/> - --> - </password_type> - </pgsql> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Berkeley DB module configuration --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- LDAPFULL module configuration --> - <ldapfull> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- Type of LDAP server. Currently "ad" for active directory and "ldap" - for other ldap servers. If not specified, then it is ldap. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <!-- LDAP attribute that holds the cleartext or hashed password - (not needed when pwscheme is set to 'bind') --> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Attribute that holds jabber account status. Must be TRUE for AD, - and 1 for other LDAP server. - If not specified, then it will not be used. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- Group that users must be members of - If this is set, only user that are members of the specified LDAP - group can log in. The group must be specified with its full - distinguished name --> - <!-- - <group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn> - --> - - <fulluid/> - <!-- If pwscheme is not defined, then passwords are stored in clear - text and digest authentication may be done. - If passwords are hashed, then you cannot use digest authentication - and should use plain text authentication. - Any of sha, ssha, crypt, bind and clear may be specified. - 'sha' specifies that the attribute in pwattr holds a base-64 - encoded SHA-1 hashed password beginning with the string {SHA}. - 'ssha' specifies that the attribute in pwattr holds a base-64 - SHA-1 hashed password appended with 32 bits of salt and beginning - with the string {SSHA}. - 'crypt' specifies that the attribute in pwattr holds a UNIX-style - crypt(3) hashed password. - 'bind' specifies that the password is not stored in an attribute - but is authenticated directly by the LDAP server by binding - using the user's DN. This should be compatible with the - widest variety of LDAP servers. - --> - <!-- <pwscheme>bind</pwscheme> --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldapfull> - - <!-- LDAP module configuration --> - <!-- Remember that you need to use PLAIN auth with LDAP backend --> - <ldap> - <!-- LDAP server host and port (default: 389) --> - <host>ldap.example.com</host> - <port>389</port> - - <!-- Use LDAP v3 if possible. If disabled, v2 will be used. - Encryption options are only available if v3 is enabled. --> - <!-- - <v3/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the LDAP server using the LDAP STARTTLS mechanism. --> - <!-- - <starttls/> - --> - - <!-- Encryption. If enabled, this will create an encrypted channel - to the server using the old-style "ldaps://" mechanism. It is - recommended that you use <starttls/> instead of this. --> - <!-- - <ssl/> - --> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - - <!-- Enable the append-realm element if you want to append - realm value (usernam@realm) to the uidattr value - <append-realm/> - --> - - <!-- Alternatively to <uidattr/> and <append-realm/> you may - specify full LDAP search <query/> that will be used to - get user objects from directory. - - The following replacements take place: - %u is replaced by user login name - %r is replaced by user login realm - - When <query/> is specified, <uidattr/> and <append-realm/> - are unused and take no effect. --> - <!-- - <query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn realm='company'>o=Company.com</basedn> - <basedn>o=Example Corp.</basedn> - </ldap> - <!-- if you want to configure more than one LDAP server - create ldap1, ldap2 etc. sections - <ldap1> - - </ldap1> - --> - - <!-- Pipe module configuration --> - <pipe> - <!-- Program to execute --> - <exec>/usr/bin/pipe-auth.pl</exec> - </pipe> - - </authreg> - -</c2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/jabberd.cfg b/jabber/jabberd.cfg deleted file mode 100644 index deb31e2..0000000 --- a/jabber/jabberd.cfg +++ /dev/null @@ -1,18 +0,0 @@ -# -# jabberd config file -# -# -# This file tells the jabberd wrapper what programs to launch, -# and the config files to launch them with. If the config file -# is left out, then the system default will be used. -# -# To run multiple Session Managers, just list them all seperatly -# and provide the path to the appropriate config files. -# -# program [ path to config file ] -# - -jabberd2-router /etc/jabber/router.xml -jabberd2-sm /etc/jabber/sm.xml -jabberd2-s2s /etc/jabber/s2s.xml -jabberd2-c2s /etc/jabber/c2s.xml diff --git a/jabber/jabberd.cfg.dist b/jabber/jabberd.cfg.dist deleted file mode 100644 index deb31e2..0000000 --- a/jabber/jabberd.cfg.dist +++ /dev/null @@ -1,18 +0,0 @@ -# -# jabberd config file -# -# -# This file tells the jabberd wrapper what programs to launch, -# and the config files to launch them with. If the config file -# is left out, then the system default will be used. -# -# To run multiple Session Managers, just list them all seperatly -# and provide the path to the appropriate config files. -# -# program [ path to config file ] -# - -jabberd2-router /etc/jabber/router.xml -jabberd2-sm /etc/jabber/sm.xml -jabberd2-s2s /etc/jabber/s2s.xml -jabberd2-c2s /etc/jabber/c2s.xml diff --git a/jabber/mu-conference.xml b/jabber/mu-conference.xml deleted file mode 100644 index 8a2ce34..0000000 --- a/jabber/mu-conference.xml +++ /dev/null @@ -1,61 +0,0 @@ -<jcr> - <!-- - This is a config file for a copy of MU-Conference, compiled against - the Jabber Component Runtime (JCR). This is the same file that I use - to connect to my development server, running jabberd2 beta2 - - In order to connect to a jabberd v1.4 server, simply change the - <name> value to muclinker, and make sure the muclinker section is in - your main jabber.xml file, as per the MU-Conference README file. - --> - - <name>conference.localhost</name> <!-- the jid of your component --> - <host>conference.localhost</host> <!-- this should be the same as above --> - <ip>localhost</ip> <!-- adress of the jabber server --> - <port>5347</port> <!-- port used to connect the service to the jabber server --> - <secret>secret</secret> <!-- secret shared with the jabber server --> - - <spool>/var/spool/jabber/mu-conference</spool> <!-- directory containing the rooms data --> - <logdir>/var/log/jabber</logdir> <!-- directory containing the debug log (the file is called mu-conference.log) --> - <pidfile>/var/run/jabber/mu-conference.pid</pidfile> <!-- file that will contain the PID of the process --> - - <!-- <logstderr/> --> <!-- uncomment to also send log to stderr --> - - <loglevel>124</loglevel> <!-- log verbosity, 255 for very verbose, 0 for quiet --> - - <conference xmlns="jabber:config:conference"> - <public/> <!-- rooms are public when created, comment to make them private by default --> - <!-- the vCard section contains the vCard of the service --> - <vCard> - <FN>Public Chatrooms</FN> - <DESC>This service is for public chatrooms.</DESC> - <URL>http://foo.bar/</URL> - </vCard> - <history>40</history> <!-- maximum numbers of history lines send when joining a room --> - <logdir>/var/log/jabber/mu-conference/</logdir> <!-- where to store the room logs, comment to disable logging --> - <!--logsubdirs/--> <!-- uncomment to stores the room logs in subdirs (for example 2007/08/02) --> - <stylesheet>/etc/jabber/style.css</stylesheet> <!--URL of the log stylesheet --> - <!-- default text to send to legacy clients, will also be used in the logs --> - <notice> - <join>has become available</join> - <leave>has left</leave> - <rename>is now known as</rename> - </notice> - <!-- lists of admins of the service, add a <user/> tag by admin --> - <sadmin> - <user>admin@localhost</user> - </sadmin> - <!-- <dynamic/> --> <!-- when uncommented, only dynamic rooms can be created --> - <!-- <persistent/> --> <!-- persistent rooms will be created, overide <dynamic/> --> - <!-- <locknicks/> --> <!-- enforce the user nickname to the user part of his jid --> - <!-- <roomlock/> --> <!-- uncomment to allow only admins to create rooms --> - <!-- <hideempty/> --> <!-- uncomment to hide rooms with no participants --> - <!-- configuration of MySQL, only used if the MySQL exports is activated, see README.sql --> - <!--<mysql> - <user>root</user> - <pass/> - <database>chat</database> - <host>localhost</host> - </mysql>--> - </conference> -</jcr> diff --git a/jabber/router-filter.xml b/jabber/router-filter.xml deleted file mode 100644 index 2499292..0000000 --- a/jabber/router-filter.xml +++ /dev/null @@ -1,47 +0,0 @@ -<!-- This is the router filter ruleset. - It allows for finegrained routing control. - - to, from - wildmat patterns - absent attribute matches absence of attribute - "*" matches any value of attribute - what - XPath like query - redirect - send packet to given JID instead original recipient - error - none given means allow, if given means deny - this is an XMPP RFC defined error condition - log - if set, the matched packets will be logged in router log - - Rules are matched in order of apperance. First match is efffective. ---> - -<filter> - <!-- first allow any routing without to or from - it's internal. --> - <!-- - <rule/> - <rule from="*"/> - <rule to="*"/> - --> - - <!-- create simple alias --> - <!-- <rule from="*" to="god@example.org" redirect="admin@example.org"/> --> - - <!-- don't allow msn registrations, but... --> - <!-- <rule from="dearhart@example.org" to="msn.example.org"/> --> - <!-- <rule error="not-allowed" from="*" to="msn.example.org" what="iq/query?xmlns=jabber:iq:register" log="yes"/> --> - - <!-- this user should not talk with evil --> - <!-- <rule error="not-allowed" from="user@example.org" to="*@evil.gov" what="message"/> --> - - <!-- I don't want evil to read my data --> - <!-- <rule error="forbidden" from="*@evil.gov" to="admin@example.org" what="iq/vCard" log="on"/> --> - - <!-- and finally, let's blind the world with some exceptions --> - <!-- - <rule from="*@goodguys.org" to="*" what="presence"/> - <rule from="admin@example.org" to="*" what="presence"/> - <rule error="not-acceptable" from="*" to="*" what="presence"/> - --> - -</filter> -<!-- - vim: syntax=xml ---> diff --git a/jabber/router-filter.xml.dist b/jabber/router-filter.xml.dist deleted file mode 100644 index 2499292..0000000 --- a/jabber/router-filter.xml.dist +++ /dev/null @@ -1,47 +0,0 @@ -<!-- This is the router filter ruleset. - It allows for finegrained routing control. - - to, from - wildmat patterns - absent attribute matches absence of attribute - "*" matches any value of attribute - what - XPath like query - redirect - send packet to given JID instead original recipient - error - none given means allow, if given means deny - this is an XMPP RFC defined error condition - log - if set, the matched packets will be logged in router log - - Rules are matched in order of apperance. First match is efffective. ---> - -<filter> - <!-- first allow any routing without to or from - it's internal. --> - <!-- - <rule/> - <rule from="*"/> - <rule to="*"/> - --> - - <!-- create simple alias --> - <!-- <rule from="*" to="god@example.org" redirect="admin@example.org"/> --> - - <!-- don't allow msn registrations, but... --> - <!-- <rule from="dearhart@example.org" to="msn.example.org"/> --> - <!-- <rule error="not-allowed" from="*" to="msn.example.org" what="iq/query?xmlns=jabber:iq:register" log="yes"/> --> - - <!-- this user should not talk with evil --> - <!-- <rule error="not-allowed" from="user@example.org" to="*@evil.gov" what="message"/> --> - - <!-- I don't want evil to read my data --> - <!-- <rule error="forbidden" from="*@evil.gov" to="admin@example.org" what="iq/vCard" log="on"/> --> - - <!-- and finally, let's blind the world with some exceptions --> - <!-- - <rule from="*@goodguys.org" to="*" what="presence"/> - <rule from="admin@example.org" to="*" what="presence"/> - <rule error="not-acceptable" from="*" to="*" what="presence"/> - --> - -</filter> -<!-- - vim: syntax=xml ---> diff --git a/jabber/router-users.xml b/jabber/router-users.xml deleted file mode 100644 index 9da7705..0000000 --- a/jabber/router-users.xml +++ /dev/null @@ -1,11 +0,0 @@ -<!-- This is the list of known router users, and their authentication - secrets. Access control is done via the settings in router.xml --> -<users> - <user> - <name>jabberd</name> - <secret>secret</secret> - </user> -</users> -<!-- - vim: syntax=xml ---> diff --git a/jabber/router-users.xml.dist b/jabber/router-users.xml.dist deleted file mode 100644 index 9da7705..0000000 --- a/jabber/router-users.xml.dist +++ /dev/null @@ -1,11 +0,0 @@ -<!-- This is the list of known router users, and their authentication - secrets. Access control is done via the settings in router.xml --> -<users> - <user> - <name>jabberd</name> - <secret>secret</secret> - </user> -</users> -<!-- - vim: syntax=xml ---> diff --git a/jabber/router.xml b/jabber/router.xml deleted file mode 100644 index be1a31d..0000000 --- a/jabber/router.xml +++ /dev/null @@ -1,215 +0,0 @@ -<!-- Router configuration --> -<router> - <!-- ID of the router on the network (default: router) --> - <id>router</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-router.pid</pidfile> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/router</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/router.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to (default: 5347) --> - <port>5347</port> - - <!-- File containing the user table. This is where the router gets - its component and secret information from for component - authentication.--> - <users>/etc/jabber/router-users.xml</users> - - <!-- Shared secret used to identify XEP-0114 components (that is, - "jabber:component:accept" components that authenticate using - the Jabber Component Protocol's "handshake", for example - mu-conference). If this is commented out, support for XEP-0114 - components will be disabled. --> - <secret>secret</secret> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or - server certificate), followed by intermediate CA certificates - if applicable, and ending at the highest level (root) CA" - (the latter one being optional). - If this is commented out, connecting components will not be able - to request an SSL-encrypted channel. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - </local> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks. (default: 60) --> - <interval>60</interval> - - <!-- Keepalives. - Connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - the router itself can use up four on its own. If the supply of - file descriptors is exhausted, new incoming connections will be - denied. - - These file descriptors are really only used when a component - connects to the router. So unless you have a lot of components - for some reason then you probably don't need to change this - value. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - </limits> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - </io> - - <!-- Name aliases. - - Packets destined for the domain specified in the "name" attribute - will be routed to the component that has currently bound the name - in the "target" attribute (assuming it is online). - - This is usually only required for some kinds of legacy - components (particularly jabberd 1.4 "uplink" components) --> - <aliases> - <!-- Example for a MUC component running from a jabberd 1.4 uplink --> - <!-- - <alias name='conference.domain.com' target='muclinker'/> - --> - </aliases> - - <!-- Access control information --> - <aci> - <!-- The usernames listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <user>jabberd</user> - </acl> - - <!-- These users can bind names other than their username --> - <!-- - <acl type='bind'> - </acl> - --> - - <!-- These users can bind a name as a default route --> - <!-- - <acl type='default-route'> - <user>s2s</user> - </acl> - --> - - <!-- These users can elect to receive all packets that pass through the router --> - <!-- - <acl type='log'> - <user>msglog</user> - </acl> - --> - - <!-- File containing packet filter rules. - May be used for fine grained packet routing control. --> - <filter>/etc/jabber/router-filter.xml</filter> - - </aci> - - <!-- Simple message logging to flat file - Remove <enabled/> tag to disable logging --> - <!-- - <message_logging> - <enabled/> - <file>filename</file> - </message_logging> - --> - -</router> -<!-- - vim: syntax=xml ---> diff --git a/jabber/router.xml.dist b/jabber/router.xml.dist deleted file mode 100644 index be1a31d..0000000 --- a/jabber/router.xml.dist +++ /dev/null @@ -1,215 +0,0 @@ -<!-- Router configuration --> -<router> - <!-- ID of the router on the network (default: router) --> - <id>router</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-router.pid</pidfile> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/router</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/router.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP address to bind to (default: 0.0.0.0) --> - <ip>0.0.0.0</ip> - - <!-- Port to bind to (default: 5347) --> - <port>5347</port> - - <!-- File containing the user table. This is where the router gets - its component and secret information from for component - authentication.--> - <users>/etc/jabber/router-users.xml</users> - - <!-- Shared secret used to identify XEP-0114 components (that is, - "jabber:component:accept" components that authenticate using - the Jabber Component Protocol's "handshake", for example - mu-conference). If this is commented out, support for XEP-0114 - components will be disabled. --> - <secret>secret</secret> - - <!-- File containing an SSL certificate and private key for client - connections. From SSL_CTX_use_certificate_chain_file(3): - "The certificates must be in PEM format and must be sorted - starting with the subject's certificate (actual client or - server certificate), followed by intermediate CA certificates - if applicable, and ending at the highest level (root) CA" - (the latter one being optional). - If this is commented out, connecting components will not be able - to request an SSL-encrypted channel. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - </local> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks. (default: 60) --> - <interval>60</interval> - - <!-- Keepalives. - Connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - </check> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - the router itself can use up four on its own. If the supply of - file descriptors is exhausted, new incoming connections will be - denied. - - These file descriptors are really only used when a component - connects to the router. So unless you have a lot of components - for some reason then you probably don't need to change this - value. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum bytes per second - if more than X bytes are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <bytes seconds='Y' throttle='Z'>X</bytes> - - Default Y is 1, default Z is 5. set X to 0 to disable. --> - <bytes>0</bytes> - - <!-- Maximum connects per second - if more than X connects are - attempted from a single IP in Y seconds, that IP is throttled - for Z seconds. The format is: - - <connects seconds='Y' throttle='Z'>X</connects> - - Default Y is 5, default Z is 5. set X to 0 to disable. --> - <connects>0</connects> - </limits> - - <!-- IP-based access controls. If a connection IP matches an allow - rule, the connection will be accepted. If a connecting IP - matches a deny rule, the connection will be refused. If the - connecting IP does not match any rules, or it matches both an - allow and a deny rule, the contents of the <order/> option - determines what happens. --> - <access> - <!-- Rule check order (default: allow,deny) - - allow,deny - Check allow rules, then check deny rules. - Allow by default. - deny,allow - Check deny rules, then check allow rules. - Deny by default. --> - <order>allow,deny</order> - - <!-- Allow a network. If the mask isn't specified, it defaults to - 255.255.255.255 (ie allow onle the specified IP) --> - <!-- - <allow ip='127.0.0.0' mask='255.0.0.0'/> - --> - - <!-- Allow a single host --> - <!-- - <allow ip='12.34.56.78'/> - --> - - <!-- Deny a network or a host --> - <!-- - <deny ip='127.0.0.1' mask='255.0.0.0'/> - <deny ip='87.65.43.21'/> - --> - </access> - </io> - - <!-- Name aliases. - - Packets destined for the domain specified in the "name" attribute - will be routed to the component that has currently bound the name - in the "target" attribute (assuming it is online). - - This is usually only required for some kinds of legacy - components (particularly jabberd 1.4 "uplink" components) --> - <aliases> - <!-- Example for a MUC component running from a jabberd 1.4 uplink --> - <!-- - <alias name='conference.domain.com' target='muclinker'/> - --> - </aliases> - - <!-- Access control information --> - <aci> - <!-- The usernames listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <user>jabberd</user> - </acl> - - <!-- These users can bind names other than their username --> - <!-- - <acl type='bind'> - </acl> - --> - - <!-- These users can bind a name as a default route --> - <!-- - <acl type='default-route'> - <user>s2s</user> - </acl> - --> - - <!-- These users can elect to receive all packets that pass through the router --> - <!-- - <acl type='log'> - <user>msglog</user> - </acl> - --> - - <!-- File containing packet filter rules. - May be used for fine grained packet routing control. --> - <filter>/etc/jabber/router-filter.xml</filter> - - </aci> - - <!-- Simple message logging to flat file - Remove <enabled/> tag to disable logging --> - <!-- - <message_logging> - <enabled/> - <file>filename</file> - </message_logging> - --> - -</router> -<!-- - vim: syntax=xml ---> diff --git a/jabber/s2s.xml b/jabber/s2s.xml deleted file mode 100644 index b89b82e..0000000 --- a/jabber/s2s.xml +++ /dev/null @@ -1,323 +0,0 @@ -<!-- s2s configuration --> -<s2s> - <!-- Our ID on the network (default: s2s) --> - <id>s2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-s2s.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- The router will only allow one component to be the default - route (ie the component that receives packets destined for - unknown hosts). If you want to run more than one s2s instance, - you need to uncomment this so that s2s does not try to become - the default route. Note that all outgoing s2s communication - will go to the component that is the default route. --> - <!-- - <non-default/> - --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/s2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- if logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/s2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP and port to listen for incoming s2s connections on - (default: 0.0.0.0, 5269) --> - <ip>0.0.0.0</ip> - <port>5269</port> - - <!-- Multihomed machines (with more than one interface and IP address) - need to specify outgoing S2S connections interface/address. - If not set, the <ip> section address above is used. --> - <!-- - <origins> - <ip>1.2.3.4</ip> - <ip>fe80::202:b3ff:fe1e:8329</ip> - </origins> - --> - - <!-- Secret used to generate dialback keys. If you have more than - one s2s instance configured, make sure that this is the same on - all of them. If this is commented out, a random one will be - generated. --> - <!-- - <secret>secret</secret> - --> - - <!-- File containing an SSL certificate and private key to use when setting - up encrypted s2s connections with other servers (STARTTLS + Dialback). - From SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt will be - made to establish encrypted connections with other servers. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- File containing an optional SSL certificate chain file for SSL - connections. --> - <!-- - <cachain>/etc/jabber/cachain.pem</cachain> - --> - - </local> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - s2s itself can use some on its own. If the supply of file - descriptors is exhausted, new incoming connections will be - denied. - - These connections are mainly consumed when we make a - connection to an external jabber server, or an external jabber - server connects to us. If you don't have a lot of users then - there's probably no need for s2s to establish connections to - external jabber servers and the default value here is probably - fine. On the other hand, if you have lots of users with lots - of remote buddies in their buddylist then s2s will need to have - lots of open connections with other jabber servers and you may - need to increase this value. - - Note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - </io> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks except DNS expiry. (default: 60) --> - <interval>60</interval> - - <!-- Queue expiry and connection timeout. - - While a connection is being established and dialback is in - progress, packets are queued. If a valid connection has not - been established within this many seconds, the connection - process will be aborted and the queued packets will be - bounced. Timeout checks are made for three phases of - setting up a route authenticated through dialback: - 1. Connection establishment to exchange of stream headers - 2. Initiating dialback (incoming connections) - 3. Completing dialback (incoming and outgoing) - - If stage 1 connection establishment fails and there are - alternative hosts for this route that have not failed - recently, they will be tried too before finally giving up. - - 0 disables queue expiry. (default: 60) --> - <queue>60</queue> - - <!-- Queue retry timeout. - - If the queue is older than this timeout, the connection - will not be retried even if there are alternative hosts - that have not failed recently. - - 0 disables retry expiry. (default: 300) --> - <retry>300</retry> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 86400) --> - <idle>86400</idle> - - <!-- Keepalives. - - Outgoing connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - <!-- Interval between DNS result/bad host expiry. - - 0 disables expiry checks. (default: 300) --> - <dnscache>300</dnscache> - </check> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/s2s.packets</packet> - --> - </stats> - - <lookup> - <!-- SRV TCP services will be resolved in the following order. The first - one that returns something will be used (ie dereferenced via an - A/AAAA lookup). If no SRV records are found, resolver will - fallback to a straight A/AAAA lookup. --> - - <!-- xmpp-server is mandated by the XMPP spec --> - <srv>xmpp-server</srv> - - <!-- traditionally, jabber has been used --> - <srv>jabber</srv> - - - <!-- If this is enabled, the resolver will look up AAAA records as well - as A records. This is needed if you want s2s to use IPv6. - Connection attempts will be made to all IPv6 hosts before trying - IPv4 (see bad host timeout below). --> - <!-- - <resolve-ipv6/> - --> - - <!-- Minimum time that DNS lookup results are cached (overrides max below). --> - <min-ttl>30</min-ttl> - - <!-- Maximum time that DNS lookup results are cached. --> - <max-ttl>86400</max-ttl> - - <!-- Time /etc/hosts lookup results are cached for (default: 86400). --> - <etc-hosts-ttl>86400</etc-hosts-ttl> - - <!-- Minimum time to wait before using hosts that we have failed to - establish a connection to (unless there are no alternatives). - Do not set this too low - it is required to detect permanent - problems like broken IPv6 connectivity in order to attempt IPv4. - - 0 disables bad host caching. (default: 3600) --> - <bad-host-timeout>3600</bad-host-timeout> - - <!-- Disable the DNS cache (negative caching will still be done). - This is likely to negatively impact performance while saving - a small amount of memory since multiple DNS requests must - then be made for every re-connection. --> - <!-- - <no-cache/> - --> - </lookup> - - <!-- If this is enabled, domains which share the same host will re-use - existing outgoing connections. This is a potential security risk - as the SSL connection from the first domain will be re-used too. --> - <out-conn-reuse/> - - <security> - <!-- Require TLS secured S2S connections --> - <!-- - <require_tls/> - --> - - <!-- - Domain whitelisting - --> - <!-- - <enable_whitelist/> - --> - - <!-- Domain whitelisting - When defined, only whitelisted domains are allowed to connect --> - <!-- - <whitelist_domain>domain1.tld</whitelist_domain> - <whitelist_domain>domain2.tld</whitelist_domain> - <whitelist_domain>other.tld</whitelist_domain> - --> - </security> -</s2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/s2s.xml.dist b/jabber/s2s.xml.dist deleted file mode 100644 index b89b82e..0000000 --- a/jabber/s2s.xml.dist +++ /dev/null @@ -1,323 +0,0 @@ -<!-- s2s configuration --> -<s2s> - <!-- Our ID on the network (default: s2s) --> - <id>s2s</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-s2s.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- The router will only allow one component to be the default - route (ie the component that receives packets destined for - unknown hosts). If you want to run more than one s2s instance, - you need to uncomment this so that s2s does not try to become - the default route. Note that all outgoing s2s communication - will go to the component that is the default route. --> - <!-- - <non-default/> - --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/s2s</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- if logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/s2s.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- IP and port to listen for incoming s2s connections on - (default: 0.0.0.0, 5269) --> - <ip>0.0.0.0</ip> - <port>5269</port> - - <!-- Multihomed machines (with more than one interface and IP address) - need to specify outgoing S2S connections interface/address. - If not set, the <ip> section address above is used. --> - <!-- - <origins> - <ip>1.2.3.4</ip> - <ip>fe80::202:b3ff:fe1e:8329</ip> - </origins> - --> - - <!-- Secret used to generate dialback keys. If you have more than - one s2s instance configured, make sure that this is the same on - all of them. If this is commented out, a random one will be - generated. --> - <!-- - <secret>secret</secret> - --> - - <!-- File containing an SSL certificate and private key to use when setting - up encrypted s2s connections with other servers (STARTTLS + Dialback). - From SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt will be - made to establish encrypted connections with other servers. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter --> - <!-- - <verify-mode>7</verify-mode> - --> - - <!-- File containing an optional SSL certificate chain file for SSL - connections. --> - <!-- - <cachain>/etc/jabber/cachain.pem</cachain> - --> - - </local> - - <!-- input/output settings --> - <io> - <!-- Maximum number of file descriptors. Note that the number of - possible connections will be slightly less than this, because - s2s itself can use some on its own. If the supply of file - descriptors is exhausted, new incoming connections will be - denied. - - These connections are mainly consumed when we make a - connection to an external jabber server, or an external jabber - server connects to us. If you don't have a lot of users then - there's probably no need for s2s to establish connections to - external jabber servers and the default value here is probably - fine. On the other hand, if you have lots of users with lots - of remote buddies in their buddylist then s2s will need to have - lots of open connections with other jabber servers and you may - need to increase this value. - - Note that this value only affects how many file descriptors - jabberd is able to handle internally. You may also need to - tell your operating system to allow jabberd to use more file - descriptors. On Linux this can be done using ulimit -n or by - changing the value of /proc/sys/fd/file-max. - - (default: 1024) --> - <max_fds>1024</max_fds> - - <!-- Rate limiting --> - <limits> - <!-- Maximum stanza size - if more than given number of bytes - are read in one incoming stanza, the stream is closed - with policy-violation error. - - Set to 0 to disable. - Values less than 16384 might not work. --> - <stanzasize>65535</stanzasize> - </limits> - - <!-- Enable XEP-0138: Stream Compression --> - <!-- - <compression/> - --> - - </io> - - <!-- Timed checks --> - <check> - <!-- Interval between checks. - - Checks will be run every n seconds. - - 0 disables all checks except DNS expiry. (default: 60) --> - <interval>60</interval> - - <!-- Queue expiry and connection timeout. - - While a connection is being established and dialback is in - progress, packets are queued. If a valid connection has not - been established within this many seconds, the connection - process will be aborted and the queued packets will be - bounced. Timeout checks are made for three phases of - setting up a route authenticated through dialback: - 1. Connection establishment to exchange of stream headers - 2. Initiating dialback (incoming connections) - 3. Completing dialback (incoming and outgoing) - - If stage 1 connection establishment fails and there are - alternative hosts for this route that have not failed - recently, they will be tried too before finally giving up. - - 0 disables queue expiry. (default: 60) --> - <queue>60</queue> - - <!-- Queue retry timeout. - - If the queue is older than this timeout, the connection - will not be retried even if there are alternative hosts - that have not failed recently. - - 0 disables retry expiry. (default: 300) --> - <retry>300</retry> - - <!-- Idle connection checks. - - Connections that have not sent data for longer than this many - seconds will be dropped. - - 0 disables idle timeouts. (default: 86400) --> - <idle>86400</idle> - - <!-- Keepalives. - - Outgoing connections that have not been used for longer than - this many seconds will have a single whitespace character sent - to them. This will force the TCP connection to be closed if - they have disconnected without us knowing about it. - - 0 disables keepalives. (default: 0) --> - <keepalive>0</keepalive> - - <!-- Interval between DNS result/bad host expiry. - - 0 disables expiry checks. (default: 300) --> - <dnscache>300</dnscache> - </check> - - <!-- Statistics --> - <stats> - <!-- file containing count of packets that went through --> - <!-- - <packet>/var/spool/jabber/stats/s2s.packets</packet> - --> - </stats> - - <lookup> - <!-- SRV TCP services will be resolved in the following order. The first - one that returns something will be used (ie dereferenced via an - A/AAAA lookup). If no SRV records are found, resolver will - fallback to a straight A/AAAA lookup. --> - - <!-- xmpp-server is mandated by the XMPP spec --> - <srv>xmpp-server</srv> - - <!-- traditionally, jabber has been used --> - <srv>jabber</srv> - - - <!-- If this is enabled, the resolver will look up AAAA records as well - as A records. This is needed if you want s2s to use IPv6. - Connection attempts will be made to all IPv6 hosts before trying - IPv4 (see bad host timeout below). --> - <!-- - <resolve-ipv6/> - --> - - <!-- Minimum time that DNS lookup results are cached (overrides max below). --> - <min-ttl>30</min-ttl> - - <!-- Maximum time that DNS lookup results are cached. --> - <max-ttl>86400</max-ttl> - - <!-- Time /etc/hosts lookup results are cached for (default: 86400). --> - <etc-hosts-ttl>86400</etc-hosts-ttl> - - <!-- Minimum time to wait before using hosts that we have failed to - establish a connection to (unless there are no alternatives). - Do not set this too low - it is required to detect permanent - problems like broken IPv6 connectivity in order to attempt IPv4. - - 0 disables bad host caching. (default: 3600) --> - <bad-host-timeout>3600</bad-host-timeout> - - <!-- Disable the DNS cache (negative caching will still be done). - This is likely to negatively impact performance while saving - a small amount of memory since multiple DNS requests must - then be made for every re-connection. --> - <!-- - <no-cache/> - --> - </lookup> - - <!-- If this is enabled, domains which share the same host will re-use - existing outgoing connections. This is a potential security risk - as the SSL connection from the first domain will be re-used too. --> - <out-conn-reuse/> - - <security> - <!-- Require TLS secured S2S connections --> - <!-- - <require_tls/> - --> - - <!-- - Domain whitelisting - --> - <!-- - <enable_whitelist/> - --> - - <!-- Domain whitelisting - When defined, only whitelisted domains are allowed to connect --> - <!-- - <whitelist_domain>domain1.tld</whitelist_domain> - <whitelist_domain>domain2.tld</whitelist_domain> - <whitelist_domain>other.tld</whitelist_domain> - --> - </security> -</s2s> -<!-- - vim: syntax=xml ---> diff --git a/jabber/sm.xml b/jabber/sm.xml deleted file mode 100644 index 079461f..0000000 --- a/jabber/sm.xml +++ /dev/null @@ -1,811 +0,0 @@ -<!-- Session manager configuration --> -<sm> - <!-- Our ID on the network (default: sm) --> - <id>sm</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-sm.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/sm</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/sm.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. - Users will have this as the domain part of their JID. - If you want your server to be accessible from other - Jabber servers, this IDs must be FQDN resolvable by DNSes. - If not set, the SM id is used. --> - <id>localhost.localdomain</id> - <!-- - <id>vhost1.localdomain</id> - <id>vhost2.localdomain</id> - --> - - </local> - - <!-- Storage database configuration --> - <storage> - <!-- Dynamic storage modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- By default, we use the SQLite driver for all storage --> - <driver>db</driver> - - <!-- Its also possible to explicitly list alternate drivers for - specific data types. --> - - <!-- Store vcards in a ldapvcard database instead --> - <!-- - <driver type='vcard'>ldapvcard</driver> - --> - - <!-- Only ldapvcard driver implements published-roster: --> - <!-- - <driver type='published-roster'>ldapvcard</driver> - --> - - <!-- Use ldapvcard driver for published-roster-groups. - See description in section sm/user/template/mapped-groups. - Used by mod_published_roster. - See ldapvcard section for options. - When resolving group id to group name, it searches for - groupsobjectclass objects at groupsdn base using group id - (in groupsidattr) as key and returns the first value of - groupattr of first found entry. - E.g.. in general case, if group id is "some-dep", and groupsdn - is o=org, and class is jabberGroup, it searches for - (&(objectClass=jabberGroup)(cn=some-dep)) and returns value of - jabberPublishedItem attribute, which may contain textual description. - --> - <!-- - <driver type='published-roster-groups'>ldapvcard</driver> - --> - - <!-- Rate limiting --> - <limits> - <!-- Maximum queries per second - if more than X queries are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <queries seconds='Y' throttle='Z'>X</bytes> - - Default Y is 5, default Z is 60. set X to 0 to disable. --> - <!-- - <queries>3</queries> - --> - </limits> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - </sqlite> - - <!-- MySQL driver configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. - - This will need to be disabled if you are using a MySQL - earlier than v3.23.xx, as transaction support did not appear - until this version. --> - <transactions/> - </mysql> - - <!-- PostgreSQL driver configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - </pgsql> - - <!-- Berkeley DB driver configuration. This does not support roster - maxitems or offline userquota (because the mod_roster - implementation does not implement the 'count' callback). --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Filesystem driver configuration --> - <fs> - <!-- Directory to store database files under. --> - <path>/var/spool/jabber/fs</path> - </fs> - - <!-- LDAPVCARD driver configuration --> - <ldapvcard> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Realm to append to uidattr. --> - <!-- - <realm>example.org</realm> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn>o=Example Corp.</basedn> - - <!-- attribute that holds published group name or id, - jabberPublishedGroup if not set --> - <!-- - <groupattr>jabberPublishedGroup</groupattr> - --> - - <!-- this option is helpful if your schema does not have designated - attribute that holds jabber group name - you can use any attribute in <groupattr> i.e. 'distinguishedName' - and then extract a part of it using Regular Expression; - first matching () group will be used --> - <!-- - <groupattr_regex>OU=([^,]*),</groupattr_regex> - --> - - <!-- boolean attribute that tells whether or not to publish this user - jabberPublishedItem by default --> - <!-- - <publishedattr>jabberPublishedItem</publishedattr> - --> - - <!-- If value specified, then keep cache of "published-roster" - database, which is used for all users. Cache is renewed when kept more seconds than value - specified. Setting this value increases perfomance of publishing - roster. If not specified, then we don't keep cache. --> - <publishedcachettl>60</publishedcachettl> - - <mapped-groups> - <!-- If turned on, then mapping of group ids to names with - LDAP will works. --> - <!-- - <map-groups/> - --> - - <!-- base for searches for group id to group name mappings --> - <basedn>ou=jabbergroups, o=Example Corp.</basedn> - - <!-- what objectclass to search, jabberGroup by default --> - <!-- - <objectclass>jabberGroup</objectclass> - --> - - <!-- what attribute to search, cn by default --> - <!-- - <idattr>cn</idattr> - --> - - <!-- attribute with text group name, description by default --> - <!-- - <nameattr>description</nameattr> - --> - </mapped-groups> - </ldapvcard> - </storage> - - <!-- Access control information --> - <aci> - <!-- The JIDs listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <jid>admin@localhost.localdomain</jid> - </acl> - - <!-- These JIDs can send broadcast messages (announce, motd) --> - <!-- - <acl type='broadcast'> - <jid>nocstaff1@localhost.localdomain</jid> - <jid>nocstaff2@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs will receive messages addressed to the sm itself - (help requestes and such) --> - <!-- - <acl type='messages'> - <jid>support@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs can discover active user/session information --> - <!-- - <acl type='disco'> - <jid>webstatus@localhost.localdomain</jid> - </acl> - --> - </aci> - - <!-- Module chain configuration - - Modules listed in a chain are called in the order specified at - the appropriate time for that chain (assuming that the module - knows how to work with that chain; otherwise it simply ignores - it). - - Removing a module from these lists will stop the module being - called, even if it's compiled into the server. - - Serveral modules have a presence in more than one chain. It is - possible to remove a module from one chain but not others, but - this may cause strange behaviour. Make sure you know what you're - doing. --> - <modules> - <!-- Dynamic sm modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- sess-start. The modules in this chain are called when a session - is first started (usually on request by c2s as part of the - authentication process). This is normally used to load - per-session data. --> - <chain id='sess-start'> - <module>status</module> <!-- record status information --> - </chain> - - <!-- sess-end. The modules in this chain are called just before a - session is destroyed (after the client has disconnected). --> - <chain id='sess-end'> - <module>status</module> <!-- update status information --> - <module>iq-last</module> <!-- update logout time --> - </chain> - - <!-- in-sess. The modules in this chain are called when a packet - arrives from an active user session. Note that this chain is - also responsible for delivering packets to their destinations - - this is usually handled by the "deliver" module. --> - <chain id='in-sess'> - <module>validate</module> <!-- validate packet type --> - <module>status</module> <!-- update status information --> - <module>privacy</module> <!-- manage privacy lists --> - <module>roster</module> <!-- handle roster get/sets and s10ns --> - <module>vacation</module> <!-- manage vacation settings --> - <!-- <module>pep</module> <!- - personal eventing --> - <module>iq-vcard</module> <!-- store and retrieve the user's vcard --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-private</module> <!-- manage the user's private data store --> - <module>disco</module> <!-- respond to agents requests from sessions --> - <module>amp</module> <!-- advanced message processing --> - <module>offline</module> <!-- if we're coming online for the first time, deliver queued messages --> - <module>announce</module> <!-- deliver motd --> - <module>presence</module> <!-- process and distribute presence updates --> - <module>deliver</module> <!-- deliver packets with full jids directly --> - </chain> - - <!-- out-sess. The modules in this chain are called just before a - packet is delivered to an active user session. --> - <chain id='out-sess'> - <!-- <module>pep</module> <!- - personal eventing --> - </chain> - - <!-- in-router. The modules in this chain are called when a packet - arrives from the router (ie another component or s2s), but - before any processing is done. This is a good place to filter - incoming packets. --> - <chain id='in-router'> - <module>session</module> <!-- perform session actions as required by c2s --> - <module>validate</module> <!-- validate packet type --> - <module>presence</module> <!-- drop incoming presence if user not online --> - <module>privacy</module> <!-- filter incoming packets based on privacy rules --> - </chain> - - <!-- out-router. The modules in this chain are called just before a - packet is delivered to the router (destined for another - component or s2s). This is a good place to filter outgoing - packets. --> - <chain id='out-router'> - <module>privacy</module> <!-- filter outgoing packets based on privacy rules --> - </chain> - - <!-- pkt-sm. The modules in this chain are called when a packet - arrives that is addressed to the session manager itself (ie the - to JID has no node part). This is normally used to provide - session-manager-wide services (like service discovery). --> - <chain id='pkt-sm'> - <module>iq-last</module> <!-- return the server uptime --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-time</module> <!-- return the current server time --> - <module>iq-version</module> <!-- return the server name and version --> - <module>amp</module> <!-- advanced message processing --> - <module>disco</module> <!-- build the disco list; respond to disco queries --> - <module>announce</module> <!-- send broadcast messages (announce, motd, etc) --> - <module>help</module> <!-- resend sm messages to administrators --> - <module>echo</module> <!-- echo messages sent to /echo --> - <module>status</module> <!-- track status information --> - <module>presence</module> <!-- proces server presence subscriptions --> - </chain> - - <!-- pkt-user. The modules in this chain are called when a packet - arrives that is address to a specific user. Note that this - chain is also responsible for delivering packets to user - sessions as appropriate - this is usually handled by the - "deliver" module. --> - <chain id='pkt-user'> - <module>roster</module> <!-- handle s10n responses --> - <module>presence</module> <!-- process and distribute incoming presence from external entities --> - <module>iq-vcard</module> <!-- grab user vcards --> - <module>amp</module> <!-- advanced message processing --> - <module>deliver</module> <!-- deliver the packet to an active session if we can --> - <module>vacation</module> <!-- send vacation messages --> - <module>offline</module> <!-- save messages and s10ns for later --> - <module>iq-last</module> <!-- return time since last logout --> - </chain> - - <!-- pkt-router. The modules in this chain are called when a - special-purpose packet arrives from the router (eg domain - advertisements). --> - <chain id='pkt-router'> - <module>session</module> <!-- take sessions offline if their c2s disappears --> - <module>disco</module> <!-- query new components for service information --> - </chain> - - <!-- user-load. The modules in this chain are called to load - per-user data. This will happen before a user can be used (ie - before a session is created). --> - <chain id='user-load'> - <module>active</module> <!-- get active status --> - <module>roster</module> <!-- load the roster and trust list --> - <module>roster-publish</module> <!-- load the published roster --> - <module>privacy</module> <!-- load privacy lists --> - <module>vacation</module> <!-- load vacation settings --> - </chain> - - <!-- user-unload. The modules in this chain are called right - after last per-user session is destroyed. --> - <chain id='user-unload'> - </chain> - - <!-- user-create. The modules in this chain are called when a user - creation request is received (usually from c2s as part of a - registration request). This initialises any per-user data. --> - <chain id='user-create'> - <module>active</module> <!-- activate new users --> - <module>template-roster</module> <!-- populate roster from template --> - </chain> - - <!-- user-delete. The modules in this chain are called when a user - deletion request is received (usually from c2s as part of a - registration removal request). This deletes all data that may - have been previously created for the user during normal - operation. --> - <chain id='user-delete'> - <module>active</module> <!-- deactivate users --> - <module>announce</module> <!-- delete motd data --> - <module>offline</module> <!-- bounce queued messages --> - <module>privacy</module> <!-- delete privacy lists --> - <module>roster</module> <!-- delete roster --> - <module>vacation</module> <!-- delete vacation settings --> - <module>status</module> <!-- delete status information --> - <module>iq-last</module> <!-- delete last logout time --> - <module>iq-private</module> <!-- delete private data --> - <module>iq-vcard</module> <!-- delete vcard --> - </chain> - - <!-- disco-extend. The modules in this chain are called when a disco - info request is send to session manager. It implements XEP-0128 - Service Discovery Extensions mechanizm to add additional - information to disco#info reply. --> - <chain id='disco-extend'> - <module>iq-version</module> <!-- add XEP-xxxx Software Information --> - <module>help</module> <!-- add XEP-0157 Contact Addresses --> - </chain> - - </modules> - - <!-- Service discovery configuration --> - <discovery> - - <!-- Service identity. these specify the category, type and name of - this service that will be included in discovery information - responses. --> - <identity> - <category>server</category> <!-- default: server --> - <type>im</type> <!-- default: im --> - <name>Jabber IM server</name> <!-- default: Jabber IM server --> - </identity> - - <!-- The discovery module can respond to jabber:iq:agents queries - for compatibility with older clients. Comment this out to - disable this. --> - <agents/> - - <!-- Static service list. - - The discover module can discover disco-capable services - automatically as they come online. Most XEP-0114 components, - however, will not support discovery. In order to get them to - appear in disco/agents lists returned to the client, they - should be listed here. - - Note that if a disco-capable service with the same name as one - listed below comes online, the information it provides will - override the information listed below. - - The "category" and "type" attributes, and the list of supported - namespaces are only used for agents compatibility. If you have - disabled this above, you may omit them. --> - <items> - - <!-- example entry for a user directory --> - <!-- - <item category='service' type='jud' jid='users.jabber.org' name='Jabber User Directory'/> - --> - - <!-- example entry for a groupchat (conference) service --> - <!-- - <item category='conference' type='public' jid='conference.jabber.org' name='Text conferencing'/> - --> - - </items> - - <!-- Server information added to server discovery information - in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157) - - May contain many values per item --> - <!-- - <serverinfo> - <admin-addresses> - <value>mailto:xmpp@localhost.localdomain</value> - <value>xmpp:admins@localhost.localdomain</value> - </admin-addresses> - <abuse-addresses> - <value>mailto:abuse@localhost.localdomain</value> - <value>xmpp:abuse@localhost.localdomain</value> - </abuse-addresses> - <feedback-addresses> - <value>http://example.org/feedback.php</value> - </feedback-addresses> - <sales-addresses/> - <security-addresses/> - <support-addresses/> - </serverinfo> - --> - - </discovery> - - <!-- User options --> - <user> - <!-- By default, users must explicitly created before they can start - a session. The creation process is usually triggered by a c2s - component in response to a client registering a new user. - - Enabling this option will make it so that user creation will be - triggered the first time a non-existant user attempts to start - a session. This is useful if you already have users in an - external authentication database (eg LDAP) and you don't want - them to have to register. --> - <!-- - <auto-create/> - --> - - <!-- Define maximum size in bytes of fields of vcards. - There is a recommendation that the avatar picture SHOULD NOT - be larger than 16 KiB. --> - <!-- - <vcard> - <max-field-size> - <default>16384</default> - <avatar>16384</avatar> - </max-field-size> - </vcard> - --> - - <!-- Templates. If defined, the contents of these files will be - stored in the users data store when they are created. --> - <template> - <!-- Uncomment <publish> if you wish to forcibly publish - roster template from ldap on each user login --> - <!-- - <publish> - --> - <!-- Key used for fetching published roster items. - Only one might be set at a time. - If not set, all items are fetched. --> - <!-- - <fetch-key> - <domain/> - <user/> - <fixed>grouping-key</fixed> - </fetch-key> - --> - <!-- If <check-remove-domain> given, then published contact is checked - against sm user database and if user is unknown to sm, contact - will be deleted from user's roster (if it is in roster). - If no domain set (tag empty) all contacts are checked. --> - <!-- - <check-remove-domain>jabber.example.com</check-remove-domain> - --> - <!-- Alternatively if <force-create-contacts/> is not commented, - published contact is added to sm user database - and user set known to sm, so it won't auto-unsubscribe - on connection established --> - <!-- - <force-create-contacts/> - --> - <!-- Keep cache of "active" database specified number of seconds. - This will significantly speed up publishing of roster. - If unspecified or 0, no cache is used. --> - <active-cache-ttl>60</active-cache-ttl> - <!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of - user's contacts to subscriptions of corresponding published - contacts. --> - <!-- - <fix-subscriptions/> - --> - <!-- If <override-names/> is uncommented, then displayed names of - contacts in user's roster will be updated accordingly to - published roster (if they differ). If commented, then user can - rename contacts in roster --> - <!-- - <override-names/> - --> - <!-- when mapped-groups is on (<map-groups/> is uncommented), the actual - group names for published contacts are read from - published-roster-groups storage type, which may be set - to ldapvcard driver. The key for searching is published user's - group, and returned value is used as group name. So you can assign - textual group IDs to users rather then group names. - group-cache-ttl keeps cache of mapping from group id to name for - specified number of seconds. If unspecified or 0, no cache is used. - --> - <!-- - <mapped-groups> - <map-groups/> - <group-cache-ttl>120</group-cache-ttl> - </mapped-groups> - --> - <!-- If <force-groups> is commented out, published roster's contact - added to user's roster only when user does not have this contact. - - If <force-groups> is uncommented, then these checks are performed - against each roster item already in user's roster: - If roster item already present in user's roster in - group of same name, no changes are made with this group (note - that contact may be in more than one group). - If <prefix> or <suffix> are given, then contact removed - from any matching groups. - After that, contact is added to group from published roster. - - In other words, all groups of updated contact, that match prefix - or suffix, are replaced with group of published contact. - This is done because there is no way to determine that group was - published or greated by user. --> - <!-- - <force-groups> - <prefix>MyOrg.</prefix> - <suffix>(MyOrg)</suffix> - </force-groups> - --> - <!-- - </publish> - --> - - <!-- If defined, the contents of these files will be - stored in the users data store when they are created. --> - <!-- If you defined publish, you should comment-out <roster> --> - <!-- - <roster>/etc/jabber/templates/roster.xml</roster> - --> - </template> - </user> - - <!-- Advanced Message Processing module configuration --> - <amp> - <!-- You can disable some actions --> - <!-- - <disableactions> - <drop/> - <error/> - <alert/> - <notify/> - </disableactions> - --> - - <!-- You can disable some conditions --> - <!-- - <disableconditions> - <expireat/> - <matchresource/> - <deliver/> - </disableconditions> - --> - - <!-- You need to enable this if your server has offline storage disabled --> - <!-- - <offlinestoragedisabled/> - --> - </amp> - - <!-- Offline module configuration --> - <offline> - <!-- Do not store messages in offline store --> - <!-- - <dropmessages/> - --> - - <!-- Store headline messages in offline store --> - <!-- - <storeheadlines/> - --> - - <!-- Do not store subscription requests in offline store --> - <!-- - <dropsubscriptions/> - --> - - <!-- Offline storage message quota. - Specifies how many messages will be stored in user offline store --> - <!-- - <userquota>500</userquota> - --> - </offline> - - <!-- roster module configuration --> - <roster> - <!-- maximum items per user roster --> - <!-- - <maxitems>100</maxitems> - --> - </roster> - - <!-- status module configuration --> - <status> - <!-- presence service resource - disabled when commented out --> - <!-- - <resource>webstatus</resource> - --> - </status> - -</sm> -<!-- - vim: syntax=xml ---> diff --git a/jabber/sm.xml.dist b/jabber/sm.xml.dist deleted file mode 100644 index 079461f..0000000 --- a/jabber/sm.xml.dist +++ /dev/null @@ -1,811 +0,0 @@ -<!-- Session manager configuration --> -<sm> - <!-- Our ID on the network (default: sm) --> - <id>sm</id> - - <!-- The process ID file. Comment this out if you don't need to know - the process ID from outside the process (eg for control scripts) --> - <pidfile>/var/run/jabber/jabberd2-sm.pid</pidfile> - - <!-- Router connection configuration --> - <router> - <!-- IP/port the router is waiting for connections on --> - <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> - <port>5347</port> <!-- default: 5347 --> - - <!-- Username/password to authenticate as --> - <user>jabberd</user> <!-- default: jabberd --> - <pass>secret</pass> <!-- default: secret --> - - <!-- File containing an SSL certificate and private key to use when - setting up an encrypted channel with the router. From - SSL_CTX_use_certificate_chain_file(3): "The certificates must be - in PEM format and must be sorted starting with the subject's - certificate (actual client or server certificate), followed - by intermediate CA certificates if applicable, and ending - at the highest level (root) CA" (the latter one being optional). - If this is commented out, or the file can't be read, no attempt - will be made to establish an encrypted channel with the router. --> - <!-- - <pemfile>/etc/jabber/server.pem</pemfile> - --> - - <!-- Router connection retry --> - <retry> - <!-- If the connection to the router can't be established at - startup, we should try again this many times before exiting. - Use -1 to retry indefinitely. [default: 3] --> - <init>3</init> - - <!-- If we lost the connection to the router during normal - operation (ie we've successfully connected to the router in - the past), we should try to reconnect this many times before - exiting. Use -1 to retry indefinitely. [default: 3] --> - <lost>3</lost> - - <!-- Sleep for this many seconds before trying attempting a - reconnect. [default: 2] --> - <sleep>2</sleep> - </retry> - </router> - - <!-- Log configuration - type is "syslog", "file" or "stdout" --> - <log type='syslog'> - <!-- If logging to syslog, this is the log ident --> - <ident>jabberd/sm</ident> - - <!-- If logging to syslog, this is the log facility - (local0 - local7) [default: local3] --> - <facility>local3</facility> - - <!-- If logging to file, this is the filename of the logfile --> - <!-- - <file>/var/log/jabber/sm.log</file> - --> - - <!-- Filename of the debug logfile --> - <!-- - <debug>/var/log/jabber/debug-${id}.log</debug> - --> - </log> - - <!-- Local network configuration --> - <local> - <!-- Who we identify ourselves as. - Users will have this as the domain part of their JID. - If you want your server to be accessible from other - Jabber servers, this IDs must be FQDN resolvable by DNSes. - If not set, the SM id is used. --> - <id>localhost.localdomain</id> - <!-- - <id>vhost1.localdomain</id> - <id>vhost2.localdomain</id> - --> - - </local> - - <!-- Storage database configuration --> - <storage> - <!-- Dynamic storage modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- By default, we use the SQLite driver for all storage --> - <driver>db</driver> - - <!-- Its also possible to explicitly list alternate drivers for - specific data types. --> - - <!-- Store vcards in a ldapvcard database instead --> - <!-- - <driver type='vcard'>ldapvcard</driver> - --> - - <!-- Only ldapvcard driver implements published-roster: --> - <!-- - <driver type='published-roster'>ldapvcard</driver> - --> - - <!-- Use ldapvcard driver for published-roster-groups. - See description in section sm/user/template/mapped-groups. - Used by mod_published_roster. - See ldapvcard section for options. - When resolving group id to group name, it searches for - groupsobjectclass objects at groupsdn base using group id - (in groupsidattr) as key and returns the first value of - groupattr of first found entry. - E.g.. in general case, if group id is "some-dep", and groupsdn - is o=org, and class is jabberGroup, it searches for - (&(objectClass=jabberGroup)(cn=some-dep)) and returns value of - jabberPublishedItem attribute, which may contain textual description. - --> - <!-- - <driver type='published-roster-groups'>ldapvcard</driver> - --> - - <!-- Rate limiting --> - <limits> - <!-- Maximum queries per second - if more than X queries are sent in Y - seconds, connection is throttled for Z seconds. The format - is: - - <queries seconds='Y' throttle='Z'>X</bytes> - - Default Y is 5, default Z is 60. set X to 0 to disable. --> - <!-- - <queries>3</queries> - --> - </limits> - - <!-- SQLite driver configuration --> - <sqlite> - <!-- Database name --> - <dbname>/var/spool/jabber/db/sqlite.db</dbname> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - - <!-- SQLite busy-timeout in milliseconds. --> - <busy-timeout>2000</busy-timeout> - </sqlite> - - <!-- MySQL driver configuration --> - <mysql> - <!-- Database server host and port --> - <host>localhost</host> - <port>3306</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. - - This will need to be disabled if you are using a MySQL - earlier than v3.23.xx, as transaction support did not appear - until this version. --> - <transactions/> - </mysql> - - <!-- PostgreSQL driver configuration --> - <pgsql> - <!-- PostgreSQL connection info. - For the rest of the options see - http://www.postgresql.org/docs/8.0/interactive/libpq.html --> - <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo> - - <!-- Alternatively you may set connection settings separately. - These are used only in absence of 'conninfo' --> - - <!-- Database server host and port --> - <host>localhost</host> - <port>5432</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database schema --> - <schema>public</schema> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - - <!-- Transaction support. If this is commented out, transactions - will be disabled. This might make database accesses faster, - but data may be lost if jabberd crashes. --> - <transactions/> - </pgsql> - - <!-- Berkeley DB driver configuration. This does not support roster - maxitems or offline userquota (because the mod_roster - implementation does not implement the 'count' callback). --> - <db> - <!-- Directory to store database files under --> - <path>/var/spool/jabber/db</path> - - <!-- Synchronize the database to disk after each write. If you - disable this, database accesses may be faster, but data may - be lost if jabberd crashes. --> - <sync/> - </db> - - <!-- Oracle driver configuration --> - <oracle> - <!-- Database server host and port. --> - <host>localhost</host> - <port>1521</port> - - <!-- Database name --> - <dbname>jabberd2</dbname> - - <!-- Database username and password --> - <user>jabberd2</user> - <pass>secret</pass> - </oracle> - - <!-- Filesystem driver configuration --> - <fs> - <!-- Directory to store database files under. --> - <path>/var/spool/jabber/fs</path> - </fs> - - <!-- LDAPVCARD driver configuration --> - <ldapvcard> - <!-- LDAP server host and port (default: 389) --> - <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> - - <!-- DN to bind as for searches. If unspecified, the searches - will be done anonymously. --> - <!-- - <binddn>cn=Directory Manager</binddn> - <bindpw>secret</bindpw> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <type>ad</type> - --> - - <!-- LDAP attribute that holds the user ID (default: uid) --> - <uidattr>uid</uidattr> - <objectclass>posixAccount</objectclass> - <pwattr>userPassword</pwattr> - <!-- if you use included jabberd.schema use this: - <uidattr>jid</uidattr> - <objectclass>jabberUser</objectclass> - <pwattr>jabberPassword</pwattr> - --> - - <!-- Realm to append to uidattr. --> - <!-- - <realm>example.org</realm> - --> - - <!-- see authreg.ldapfull in c2s.xml for description. --> - <!-- - <validattr>valid</validattr> - --> - - <!-- base DN of the tree. You should specify a DN for each - authentication realm declared in the <local/> section above, - by using the realm attribute. --> - <basedn>o=Example Corp.</basedn> - - <!-- attribute that holds published group name or id, - jabberPublishedGroup if not set --> - <!-- - <groupattr>jabberPublishedGroup</groupattr> - --> - - <!-- this option is helpful if your schema does not have designated - attribute that holds jabber group name - you can use any attribute in <groupattr> i.e. 'distinguishedName' - and then extract a part of it using Regular Expression; - first matching () group will be used --> - <!-- - <groupattr_regex>OU=([^,]*),</groupattr_regex> - --> - - <!-- boolean attribute that tells whether or not to publish this user - jabberPublishedItem by default --> - <!-- - <publishedattr>jabberPublishedItem</publishedattr> - --> - - <!-- If value specified, then keep cache of "published-roster" - database, which is used for all users. Cache is renewed when kept more seconds than value - specified. Setting this value increases perfomance of publishing - roster. If not specified, then we don't keep cache. --> - <publishedcachettl>60</publishedcachettl> - - <mapped-groups> - <!-- If turned on, then mapping of group ids to names with - LDAP will works. --> - <!-- - <map-groups/> - --> - - <!-- base for searches for group id to group name mappings --> - <basedn>ou=jabbergroups, o=Example Corp.</basedn> - - <!-- what objectclass to search, jabberGroup by default --> - <!-- - <objectclass>jabberGroup</objectclass> - --> - - <!-- what attribute to search, cn by default --> - <!-- - <idattr>cn</idattr> - --> - - <!-- attribute with text group name, description by default --> - <!-- - <nameattr>description</nameattr> - --> - </mapped-groups> - </ldapvcard> - </storage> - - <!-- Access control information --> - <aci> - <!-- The JIDs listed here will get access to all restricted - functions, regardless of restrictions further down --> - <acl type='all'> - <jid>admin@localhost.localdomain</jid> - </acl> - - <!-- These JIDs can send broadcast messages (announce, motd) --> - <!-- - <acl type='broadcast'> - <jid>nocstaff1@localhost.localdomain</jid> - <jid>nocstaff2@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs will receive messages addressed to the sm itself - (help requestes and such) --> - <!-- - <acl type='messages'> - <jid>support@localhost.localdomain</jid> - </acl> - --> - - <!-- These JIDs can discover active user/session information --> - <!-- - <acl type='disco'> - <jid>webstatus@localhost.localdomain</jid> - </acl> - --> - </aci> - - <!-- Module chain configuration - - Modules listed in a chain are called in the order specified at - the appropriate time for that chain (assuming that the module - knows how to work with that chain; otherwise it simply ignores - it). - - Removing a module from these lists will stop the module being - called, even if it's compiled into the server. - - Serveral modules have a presence in more than one chain. It is - possible to remove a module from one chain but not others, but - this may cause strange behaviour. Make sure you know what you're - doing. --> - <modules> - <!-- Dynamic sm modules path --> - <path>/usr/lib64/jabberd</path> - - <!-- sess-start. The modules in this chain are called when a session - is first started (usually on request by c2s as part of the - authentication process). This is normally used to load - per-session data. --> - <chain id='sess-start'> - <module>status</module> <!-- record status information --> - </chain> - - <!-- sess-end. The modules in this chain are called just before a - session is destroyed (after the client has disconnected). --> - <chain id='sess-end'> - <module>status</module> <!-- update status information --> - <module>iq-last</module> <!-- update logout time --> - </chain> - - <!-- in-sess. The modules in this chain are called when a packet - arrives from an active user session. Note that this chain is - also responsible for delivering packets to their destinations - - this is usually handled by the "deliver" module. --> - <chain id='in-sess'> - <module>validate</module> <!-- validate packet type --> - <module>status</module> <!-- update status information --> - <module>privacy</module> <!-- manage privacy lists --> - <module>roster</module> <!-- handle roster get/sets and s10ns --> - <module>vacation</module> <!-- manage vacation settings --> - <!-- <module>pep</module> <!- - personal eventing --> - <module>iq-vcard</module> <!-- store and retrieve the user's vcard --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-private</module> <!-- manage the user's private data store --> - <module>disco</module> <!-- respond to agents requests from sessions --> - <module>amp</module> <!-- advanced message processing --> - <module>offline</module> <!-- if we're coming online for the first time, deliver queued messages --> - <module>announce</module> <!-- deliver motd --> - <module>presence</module> <!-- process and distribute presence updates --> - <module>deliver</module> <!-- deliver packets with full jids directly --> - </chain> - - <!-- out-sess. The modules in this chain are called just before a - packet is delivered to an active user session. --> - <chain id='out-sess'> - <!-- <module>pep</module> <!- - personal eventing --> - </chain> - - <!-- in-router. The modules in this chain are called when a packet - arrives from the router (ie another component or s2s), but - before any processing is done. This is a good place to filter - incoming packets. --> - <chain id='in-router'> - <module>session</module> <!-- perform session actions as required by c2s --> - <module>validate</module> <!-- validate packet type --> - <module>presence</module> <!-- drop incoming presence if user not online --> - <module>privacy</module> <!-- filter incoming packets based on privacy rules --> - </chain> - - <!-- out-router. The modules in this chain are called just before a - packet is delivered to the router (destined for another - component or s2s). This is a good place to filter outgoing - packets. --> - <chain id='out-router'> - <module>privacy</module> <!-- filter outgoing packets based on privacy rules --> - </chain> - - <!-- pkt-sm. The modules in this chain are called when a packet - arrives that is addressed to the session manager itself (ie the - to JID has no node part). This is normally used to provide - session-manager-wide services (like service discovery). --> - <chain id='pkt-sm'> - <module>iq-last</module> <!-- return the server uptime --> - <module>iq-ping</module> <!-- return the server ping --> - <module>iq-time</module> <!-- return the current server time --> - <module>iq-version</module> <!-- return the server name and version --> - <module>amp</module> <!-- advanced message processing --> - <module>disco</module> <!-- build the disco list; respond to disco queries --> - <module>announce</module> <!-- send broadcast messages (announce, motd, etc) --> - <module>help</module> <!-- resend sm messages to administrators --> - <module>echo</module> <!-- echo messages sent to /echo --> - <module>status</module> <!-- track status information --> - <module>presence</module> <!-- proces server presence subscriptions --> - </chain> - - <!-- pkt-user. The modules in this chain are called when a packet - arrives that is address to a specific user. Note that this - chain is also responsible for delivering packets to user - sessions as appropriate - this is usually handled by the - "deliver" module. --> - <chain id='pkt-user'> - <module>roster</module> <!-- handle s10n responses --> - <module>presence</module> <!-- process and distribute incoming presence from external entities --> - <module>iq-vcard</module> <!-- grab user vcards --> - <module>amp</module> <!-- advanced message processing --> - <module>deliver</module> <!-- deliver the packet to an active session if we can --> - <module>vacation</module> <!-- send vacation messages --> - <module>offline</module> <!-- save messages and s10ns for later --> - <module>iq-last</module> <!-- return time since last logout --> - </chain> - - <!-- pkt-router. The modules in this chain are called when a - special-purpose packet arrives from the router (eg domain - advertisements). --> - <chain id='pkt-router'> - <module>session</module> <!-- take sessions offline if their c2s disappears --> - <module>disco</module> <!-- query new components for service information --> - </chain> - - <!-- user-load. The modules in this chain are called to load - per-user data. This will happen before a user can be used (ie - before a session is created). --> - <chain id='user-load'> - <module>active</module> <!-- get active status --> - <module>roster</module> <!-- load the roster and trust list --> - <module>roster-publish</module> <!-- load the published roster --> - <module>privacy</module> <!-- load privacy lists --> - <module>vacation</module> <!-- load vacation settings --> - </chain> - - <!-- user-unload. The modules in this chain are called right - after last per-user session is destroyed. --> - <chain id='user-unload'> - </chain> - - <!-- user-create. The modules in this chain are called when a user - creation request is received (usually from c2s as part of a - registration request). This initialises any per-user data. --> - <chain id='user-create'> - <module>active</module> <!-- activate new users --> - <module>template-roster</module> <!-- populate roster from template --> - </chain> - - <!-- user-delete. The modules in this chain are called when a user - deletion request is received (usually from c2s as part of a - registration removal request). This deletes all data that may - have been previously created for the user during normal - operation. --> - <chain id='user-delete'> - <module>active</module> <!-- deactivate users --> - <module>announce</module> <!-- delete motd data --> - <module>offline</module> <!-- bounce queued messages --> - <module>privacy</module> <!-- delete privacy lists --> - <module>roster</module> <!-- delete roster --> - <module>vacation</module> <!-- delete vacation settings --> - <module>status</module> <!-- delete status information --> - <module>iq-last</module> <!-- delete last logout time --> - <module>iq-private</module> <!-- delete private data --> - <module>iq-vcard</module> <!-- delete vcard --> - </chain> - - <!-- disco-extend. The modules in this chain are called when a disco - info request is send to session manager. It implements XEP-0128 - Service Discovery Extensions mechanizm to add additional - information to disco#info reply. --> - <chain id='disco-extend'> - <module>iq-version</module> <!-- add XEP-xxxx Software Information --> - <module>help</module> <!-- add XEP-0157 Contact Addresses --> - </chain> - - </modules> - - <!-- Service discovery configuration --> - <discovery> - - <!-- Service identity. these specify the category, type and name of - this service that will be included in discovery information - responses. --> - <identity> - <category>server</category> <!-- default: server --> - <type>im</type> <!-- default: im --> - <name>Jabber IM server</name> <!-- default: Jabber IM server --> - </identity> - - <!-- The discovery module can respond to jabber:iq:agents queries - for compatibility with older clients. Comment this out to - disable this. --> - <agents/> - - <!-- Static service list. - - The discover module can discover disco-capable services - automatically as they come online. Most XEP-0114 components, - however, will not support discovery. In order to get them to - appear in disco/agents lists returned to the client, they - should be listed here. - - Note that if a disco-capable service with the same name as one - listed below comes online, the information it provides will - override the information listed below. - - The "category" and "type" attributes, and the list of supported - namespaces are only used for agents compatibility. If you have - disabled this above, you may omit them. --> - <items> - - <!-- example entry for a user directory --> - <!-- - <item category='service' type='jud' jid='users.jabber.org' name='Jabber User Directory'/> - --> - - <!-- example entry for a groupchat (conference) service --> - <!-- - <item category='conference' type='public' jid='conference.jabber.org' name='Text conferencing'/> - --> - - </items> - - <!-- Server information added to server discovery information - in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157) - - May contain many values per item --> - <!-- - <serverinfo> - <admin-addresses> - <value>mailto:xmpp@localhost.localdomain</value> - <value>xmpp:admins@localhost.localdomain</value> - </admin-addresses> - <abuse-addresses> - <value>mailto:abuse@localhost.localdomain</value> - <value>xmpp:abuse@localhost.localdomain</value> - </abuse-addresses> - <feedback-addresses> - <value>http://example.org/feedback.php</value> - </feedback-addresses> - <sales-addresses/> - <security-addresses/> - <support-addresses/> - </serverinfo> - --> - - </discovery> - - <!-- User options --> - <user> - <!-- By default, users must explicitly created before they can start - a session. The creation process is usually triggered by a c2s - component in response to a client registering a new user. - - Enabling this option will make it so that user creation will be - triggered the first time a non-existant user attempts to start - a session. This is useful if you already have users in an - external authentication database (eg LDAP) and you don't want - them to have to register. --> - <!-- - <auto-create/> - --> - - <!-- Define maximum size in bytes of fields of vcards. - There is a recommendation that the avatar picture SHOULD NOT - be larger than 16 KiB. --> - <!-- - <vcard> - <max-field-size> - <default>16384</default> - <avatar>16384</avatar> - </max-field-size> - </vcard> - --> - - <!-- Templates. If defined, the contents of these files will be - stored in the users data store when they are created. --> - <template> - <!-- Uncomment <publish> if you wish to forcibly publish - roster template from ldap on each user login --> - <!-- - <publish> - --> - <!-- Key used for fetching published roster items. - Only one might be set at a time. - If not set, all items are fetched. --> - <!-- - <fetch-key> - <domain/> - <user/> - <fixed>grouping-key</fixed> - </fetch-key> - --> - <!-- If <check-remove-domain> given, then published contact is checked - against sm user database and if user is unknown to sm, contact - will be deleted from user's roster (if it is in roster). - If no domain set (tag empty) all contacts are checked. --> - <!-- - <check-remove-domain>jabber.example.com</check-remove-domain> - --> - <!-- Alternatively if <force-create-contacts/> is not commented, - published contact is added to sm user database - and user set known to sm, so it won't auto-unsubscribe - on connection established --> - <!-- - <force-create-contacts/> - --> - <!-- Keep cache of "active" database specified number of seconds. - This will significantly speed up publishing of roster. - If unspecified or 0, no cache is used. --> - <active-cache-ttl>60</active-cache-ttl> - <!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of - user's contacts to subscriptions of corresponding published - contacts. --> - <!-- - <fix-subscriptions/> - --> - <!-- If <override-names/> is uncommented, then displayed names of - contacts in user's roster will be updated accordingly to - published roster (if they differ). If commented, then user can - rename contacts in roster --> - <!-- - <override-names/> - --> - <!-- when mapped-groups is on (<map-groups/> is uncommented), the actual - group names for published contacts are read from - published-roster-groups storage type, which may be set - to ldapvcard driver. The key for searching is published user's - group, and returned value is used as group name. So you can assign - textual group IDs to users rather then group names. - group-cache-ttl keeps cache of mapping from group id to name for - specified number of seconds. If unspecified or 0, no cache is used. - --> - <!-- - <mapped-groups> - <map-groups/> - <group-cache-ttl>120</group-cache-ttl> - </mapped-groups> - --> - <!-- If <force-groups> is commented out, published roster's contact - added to user's roster only when user does not have this contact. - - If <force-groups> is uncommented, then these checks are performed - against each roster item already in user's roster: - If roster item already present in user's roster in - group of same name, no changes are made with this group (note - that contact may be in more than one group). - If <prefix> or <suffix> are given, then contact removed - from any matching groups. - After that, contact is added to group from published roster. - - In other words, all groups of updated contact, that match prefix - or suffix, are replaced with group of published contact. - This is done because there is no way to determine that group was - published or greated by user. --> - <!-- - <force-groups> - <prefix>MyOrg.</prefix> - <suffix>(MyOrg)</suffix> - </force-groups> - --> - <!-- - </publish> - --> - - <!-- If defined, the contents of these files will be - stored in the users data store when they are created. --> - <!-- If you defined publish, you should comment-out <roster> --> - <!-- - <roster>/etc/jabber/templates/roster.xml</roster> - --> - </template> - </user> - - <!-- Advanced Message Processing module configuration --> - <amp> - <!-- You can disable some actions --> - <!-- - <disableactions> - <drop/> - <error/> - <alert/> - <notify/> - </disableactions> - --> - - <!-- You can disable some conditions --> - <!-- - <disableconditions> - <expireat/> - <matchresource/> - <deliver/> - </disableconditions> - --> - - <!-- You need to enable this if your server has offline storage disabled --> - <!-- - <offlinestoragedisabled/> - --> - </amp> - - <!-- Offline module configuration --> - <offline> - <!-- Do not store messages in offline store --> - <!-- - <dropmessages/> - --> - - <!-- Store headline messages in offline store --> - <!-- - <storeheadlines/> - --> - - <!-- Do not store subscription requests in offline store --> - <!-- - <dropsubscriptions/> - --> - - <!-- Offline storage message quota. - Specifies how many messages will be stored in user offline store --> - <!-- - <userquota>500</userquota> - --> - </offline> - - <!-- roster module configuration --> - <roster> - <!-- maximum items per user roster --> - <!-- - <maxitems>100</maxitems> - --> - </roster> - - <!-- status module configuration --> - <status> - <!-- presence service resource - disabled when commented out --> - <!-- - <resource>webstatus</resource> - --> - </status> - -</sm> -<!-- - vim: syntax=xml ---> diff --git a/jabber/style.css b/jabber/style.css deleted file mode 100644 index ab1a8dc..0000000 --- a/jabber/style.css +++ /dev/null @@ -1,25 +0,0 @@ -html { - background-color: #efefef; -} - -body { - margin: 20px 20px 20px 20px; - padding: 10px 10px 10px 10px; - border: 1px solid black; - background-color: #fffff2; - color: #464543; - font-family : Verdana, Arial, Helvetica, sans-serif; - font-size: 12pt; -} - -span.time { - color: #8b8986; -} -span.time a{ - color: #8b8986; - text-decoration: none; -} - -span.nick { - color: black; -} diff --git a/jabber/templates/roster.xml b/jabber/templates/roster.xml deleted file mode 100644 index 70c6d11..0000000 --- a/jabber/templates/roster.xml +++ /dev/null @@ -1,7 +0,0 @@ -<!-- This is the roster template. If enabled in sm.xml, new users will - get this roster by default. --> -<query xmlns='jabber:iq:roster'> - <!-- - <item name='Helpdesk' jid='helpdesk@localhost' subscription='none'><group>Support</group></item> - --> -</query> diff --git a/jabber/templates/roster.xml.dist b/jabber/templates/roster.xml.dist deleted file mode 100644 index 70c6d11..0000000 --- a/jabber/templates/roster.xml.dist +++ /dev/null @@ -1,7 +0,0 @@ -<!-- This is the roster template. If enabled in sm.xml, new users will - get this roster by default. --> -<query xmlns='jabber:iq:roster'> - <!-- - <item name='Helpdesk' jid='helpdesk@localhost' subscription='none'><group>Support</group></item> - --> -</query> diff --git a/modprobe.d/._cfg0000_nvidia.conf b/modprobe.d/._cfg0000_nvidia.conf deleted file mode 100644 index f56bca1..0000000 --- a/modprobe.d/._cfg0000_nvidia.conf +++ /dev/null @@ -1,14 +0,0 @@ -# Nvidia drivers support -alias char-major-195 nvidia -alias /dev/nvidiactl char-major-195 - -# To tweak the driver the following options can be used, note that -# you should be careful, as it could cause instability!! For more -# options see /usr/share/doc/nvidia-drivers-355.06-r1/README -# -# !!! SECURITY WARNING !!! -# DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW -# WHAT YOU ARE DOING. -# ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO CRASH, -# COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE. -options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 NVreg_ModifyDeviceFiles=1 diff --git a/modprobe.d/nvidia.conf b/modprobe.d/nvidia.conf index 55a57c6..f56bca1 100644 --- a/modprobe.d/nvidia.conf +++ b/modprobe.d/nvidia.conf @@ -4,7 +4,7 @@ alias /dev/nvidiactl char-major-195 # To tweak the driver the following options can be used, note that # you should be careful, as it could cause instability!! For more -# options see /usr/share/doc/nvidia-drivers-343.36/README +# options see /usr/share/doc/nvidia-drivers-355.06-r1/README # # !!! SECURITY WARNING !!! # DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW